[SharpMZ] Nové foto GDG

[Michal Hucik - ORDOZ]

Ahoj Vasku, obrazek je to pekny. Diky za tu praci, kterou jste si s tim 
uzili a klobouk dolu.

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.

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:

1) melody - signal, ktery ma +/- 32 Hz

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.

2) HBLN

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.)

3) chovani WAIT v MZ700

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 :-)

4) chovani WAIT v MZ800

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.

5) jak zjistit za jak dlouho se projevi zmena parametru zapsanych do GDG

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.

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.

Myslim, ze si alespon en obrazek GDG necham vytisknout do ramu a povesim 
si ho na zed v pracovne ;)

Michal


Dne 12.12.2017 v 13:20 Vaclav Peroutka napsal(a):
> Ahoj vĹĄichni,
>
> 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ě.
>
> https://uloz.to/!ahINPZBLMSv5/gdg-velky-obraz-jpg
>
> 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í.
>
> 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.
>
> VaĹĄek
>
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZ na mail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz


------------- další část ---------------
HTML příloha byla odstraněna...
URL: http://mail.ordoz.com/pipermail/sharpmz/attachments/20171212/2b9bf7dc/attachment-0001.html