<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><br>
      Ahoj Vasku, obrazek je to pekny. Diky za tu praci, kterou jste si
      s tim uzili a klobouk dolu.<br>
      <br>
      Nicmene kdyz se na to ted chvilku divam a snazim se v tom cist,
      tak se obavam, ze GDG zustane i nadale zastreno tajemstvim... Mam
      z toho pocit, ze mnohem jednodussi je vzit to jako blackbox a ten
      z gruntu navrhnout podle odpozorovaneho chovani, nez zanalyzovat
      ty bunky na obrazku. Byl bych rad, kdyby k tomu neco rekli kluci,
      kteri se uz pred rokem zabyvali analyzou te mrizky.<br>
      <br>
      Mam pocit, ze cca pred rokem a pul jsem tady napsal tech par
      vlastnosti, ktrere o GDG nevime, protoze je nelze presne
      odpozorovat z mereni, ktere vychazi z aplikace ve ktere je obvod
      zapojen. Nedokazal jsem vymyslet test, kterym by je slo zmerit at
      uz v Sharpu, nebo treba hypoteticky mimo nej. Dnes uz si
      nepamatuju co presne jsem psal a priznam se, ze se mi to nechce
      zpetne hledat. Myslim vsak, ze slo o tohle:<br>
      <br>
      1) melody - signal, ktery ma +/- 32 Hz<br>
      <br>
      Nema vystupni pin a proto je exaktnimi metodami nemeritelny. Pri
      psani emu jsem s nim trochu experimentoval a dospel jsem k
      vlastnimu zaveru, ze jeho citac je mozna zdrojovan z radkove
      synchronizace, ci z HBLN.<br>
      <br>
      2) HBLN <br>
      <br>
      Rovnez neni citelny jinak, nez pres IORQ. Podle mych pozorovani
      nemusi byt zcela shodny s tim, kde se skutecne na vystupu nachazi
      paprsek.  (Mimochodem HS a VS, ktere vidime na IORQ zarucene
      nejsou shodne se stavem, ktery je na RGBI vystupu, ale to uz jsem
      psal vicekrat.)<br>
      <br>
      3) chovani WAIT v MZ700 <br>
      <br>
      Bude IMHO vazano na stejny princip jakym je realizovan HBLN +
      nejaky IORQ buffer. V emu jsem toto odpozorovane chovani
      naimplementoval, ale vim, ze v hranicnich hodnotach se zrejme
      neshoduji s realitou, protoze ji nemam jak lepe zmerit. (rozumej -
      muze to byt treba i presne, ale neni jak to overit :-)<br>
      <br>
      4) chovani WAIT v MZ800<br>
      <br>
      Ten jsem objevil tusim pomerne nedavno a merenim jsem snad nasel i
      presnou periodu, v jake jsou data z registru nabirana, coz uvolni
      WAIT. Bohuzel stejne jako v bode 3 se jedna o jev, ktery je
      zavisly na nekolika hodinovych signalech a je to docela blbe
      meritelne. V SVN verzi emu je tohle dle mereni implementovano.<br>
      <br>
      5) jak zjistit za jak dlouho se projevi zmena parametru zapsanych
      do GDG<br>
      <br>
      Napr. Mafro kdysi napsal program, ktery v ramci jednoho snimku
      meni DMD, coz zpusobi na vystupu to, ze je obrazovka soucasne ve
      dvou ruznych rezimech. Nelze bohuzel objektivne presne zmerit.
      Tohle jsem do emu nenaimplementoval - zmeny v emulatoru se myslim
      projevi ve chvili, kdy je zapisete do GDG, nicmene jak uz jsem
      napsal, tak jsem presvedceny, ze vystupni paprsek je trochu
      popredu oproti tomu co se deje na IORQ.<br>
      <br>
      Odpovedi z tech fotek asi bohuzel neziskame... Svym zpusobem se
      jedna o pitomosti, ktere v takto nepresne formulovane emulaci a)
      pozorovatel nedokaze nikdy odhalit, b) jsou diky kombinaci
      nekolika hodinovych signalu natolik randomizovane, ze zrejme
      neexistuje situace, kdy by mohla byt presnost jejich emulace
      kriticka.<br>
      <br>
      Myslim, ze si alespon en obrazek GDG necham vytisknout do ramu a
      povesim si ho na zed v pracovne ;)<br>
      <br>
      Michal<br>
      <br>
      <br>
      Dne 12.12.2017 v 13:20 Vaclav Peroutka napsal(a):<br>
    </div>
    <blockquote type="cite"
      cite="mid:6K%7D.JDjy.1pkbj5zlPMh.1QBycZ@seznam.cz">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      Ahoj všichni,<br>
      <br>
      takže nemožné se stalo skutečností a máme nový lepší obraz GDG.
      Uložil jsme ho tady, ale bude lepší, dá-li jej někdo někam
      archivně.<br>
      <br>
      <a class="moz-txt-link-freetext" href="https://uloz.to/!ahINPZBLMSv5/gdg-velky-obraz-jpg">https://uloz.to/!ahINPZBLMSv5/gdg-velky-obraz-jpg</a><br>
      <br>
      Je to 20x zvětšeno a automaticky poskládáno. Kolega zkoušel i
      zvětšení 50x, bohužel to hynulo na příliš se opakujícím motivu. Je
      to děláno na našem interním zařízení.<br>
      <br>
      Jsem zvědav, jestli se z toho během dlouhých zimních večerů někomu
      z vás povede vytěžit nějaké informace.<br>
      <br>
      Vašek<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SharpMZ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
<a class="moz-txt-link-freetext" href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>