[SharpMZ] Nové foto GDG

[Radek Suk]

Ahoj Michale

Myslim si ze to reseni pres blackbox jak pises je jeste slozitejsi nez 
zanalyzovat obrazky. Pekne jsi popsal problemy, ktere se musi resit. Mne 
nejvice zajima ten Wait signal. Na T.M.3 kdyz Bohous delal kopii 
hlavniho zakaznickeho obvodu pro MZ700 jsem rikal ze idelani je vychazet 
ze schematu pro MZ80K a pres MZ80A jit na MZ700. Proste ve schematu pro 
MZ80K jsou jeste pekne videt obvody citacu uvnitr pocitace. Logicky 
autor MZ700 pouzival stejne casovani jak treba MZ80K. To se da pouzit i 
pro MZ800. I zde se da ocekavat podobne zapojeni. Stale verim ze budou 
pekne fotky GDG a prace pujde od ruky.

Radek


Dne 12.12.2017 v 23:26 Michal Hucik - ORDOZ napsal(a):
>
> 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
>
>
>
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZ na mail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz



--Radek SukVedoucí administrátor sítěSOFTEX NCP, s.r.o., Růžová 1426, 434 01 MostWeb: www.softex.cz, Tel.: 840 77 88 99

------------- další část ---------------
HTML příloha byla odstraněna...
URL: http://mail.ordoz.com/pipermail/sharpmz/attachments/20171217/c52bc10d/attachment-0001.html 
------------- další část ---------------
Netextová příloha byla odstraněna...
JmÊno: [Şådný popis není k dispozici]
Typ: image/jpeg
Velikost: 12005 bytes
Popis: [Şådný popis není k dispozici]
Url : http://mail.ordoz.com/pipermail/sharpmz/attachments/20171217/c52bc10d/attachment-0002.jpe 
------------- další část ---------------
Netextová příloha byla odstraněna...
JmÊno: [Şådný popis není k dispozici]
Typ: image/jpeg
Velikost: 24632 bytes
Popis: [Şådný popis není k dispozici]
Url : http://mail.ordoz.com/pipermail/sharpmz/attachments/20171217/c52bc10d/attachment-0003.jpe