OldComp.cz

Toto jsem musel prerusit ale neni cas se tomu poradne venovat. Bohuzel 23.12.2024 peklo sestoupilo na zem .

Stale ale delam rozbor jak to naprogramovat.
Zatim vyhrava myslenka emulatoru ktery bude pocitat zpozdeni na hradlech. Sice to bude 100x nebo mozna i 1000x pomalejsi nez realny cip ale ukaze se jak rychle se propaguji zmeny uvnitr cipu. Hlavne to bude mit kontrolni cinnost. Premyslel jsem ze naprogramovat zaklad v Pythonu ale asi rovnou to budu delat v C nebo C#.

Cele to bude emulovat verilog kod. Proste verilog kod prepisi co C a to tak aby to pripadne slo predelat do strojaku ale to neni cil.
Proto jeden signal bude mit velikost 8bitu.

Zamerim se na par mist co mne zajimaji. A to hlavni citac uvnitr GDG. Nasledne hor. a ver. citac. Delic pro CPU. Zpozdeni pro serializaci - to je nejvetsi hrich v konstrukci.

Cely program by mel odpovedet jake je minimalni a maximalni zpozdeni modulem, napr. komparatorem. A samozrejme i kontrola zda vstup a vystup odpovida logicke funkci. Proto to take bude cele tak pomale.

Na druhou stranu vypoctene veci se muzou nasledne vypinat a tim vykon pocitace vzdy bude pocitat jen dulezite veci. Prozkoumane moduly se nebudou detailne zpracovavat.

Soucasne budu i menit model tak, ze NTSC a TEST vyvyod zrusim. Cela cast obvodu pro testovani gdg je pro mne k nicemu.

Zakladni emulovana frekvence GDG bude 35,4688 Mhz (nebo jeste 2x vetsi). To se uvidi. Cele bych to chtel udelat aby vse se menilo pouze nabeznou hranou hodin. Ale protoze se bude muset emulovat to zpozdeni hradel tak vse pojede 10x rychleji jako 354,688 MHz.

Tak na akci Vrbice jaro2025 jsem zacal programovat ten emulator. Zameril jsem se na zajimavy problem a to emulaci Z80 CPU v case podle datasheetu. Emulator bezi na 20x vetsi frekvenci nez realny Sharp MZ800. Pro emulaci Z80 by bohate stacila jen 10x vetsi frekvence ale ocekavam ze az budu resit GDG, prave to 20x bude spravne reseni. Chtel bych aby kod co budu pouzivat z Verilogu byl synchronni a reagoval pouze na nabeznou hradnu hlavnich hodin - to bude emulace GDG. Emulaci Z80 bude delat kod v C. To co ted mam naprogranovane bude delat to, ze se pokusi udelat podobne signaly jako ma realny Z80 CPU. To je dulezite pro overeni jak reaguje na signaly GDG a co je spoustec udalosti uvnitr GDG a jaka je zavislost na WAIT signal.

Jinak na akci byl i Michal Hucik - autor https://sourceforge.net/p/mz800emu/acti ... e0d9ac3ef6 a ma novou, rapidne vylepsenou verzi emulatoru! Planuje ji zverejnit. Mame se na co tesit.

Tak Milsa trosku jsem pokrocil.

Zameril jsem se na to kdy se muze zmenit rezim obrazovky. Je to mozno vzdy po 16 bodech obrazovky v rozliseni 640x200. V 320x200 je to po 8 bodech (je to 2x sirsi). Jedna radka ma 1136 bodu a zmena muze byt jen na 71 mistech.

Pak jsem se zameril na na to proc hodiny (CPU) pro wait latch jsou nejdrive vyvedeny ven z GDG a pak jdou zpet dovnitr GDG. Logicky to dela zpozdeni a dalsi casovou domenu. A opravdu podle vseho je to proto aby kdyz se dokoncuje cteni z GDG, tak muze nastat okamzik kdy presne ve stejnou dobu je ukonceno cteni ale chvilku trva nez se pres par hradel dostane tato informace az do obvodu co generuje Wait signal. On stale pri nabezne hrane CPU ma na vstupu log1 a tak bude i priste wait cyklus. Ale kdyz se to rozume zpozdi, tak ven z GDG uz pujde log1 a CPU muze uz dal pokracovat v praci.

Povedal si to dosť odborne. Usudzujem, že to má súvis s čakaním pri grafických operáciách (prečo je Flappy reálne pomalší než ako keby bežal na plnej frekvencii procesora). Ak správne chápem, chceš tým asi povedať, že ak niečo zmením na obrazovke, tak sa to nezmení reálne vtedy, ale až na určitom mieste, keď tam dôjde "lúč".

No teraz som si to prečítal ešte raz a zrejme hovoríš len o zmene režimu obrazovky, takže to, kde píšem o zmene zrejme nie je pravda, ale cítim tam súvis s tým Waitom, takže to mazať nebudem.

Možno ale nakoniec len trepem, lebo som to celé nepochopil. Prosím teda o trochu stráviteľnejšie vysvetlenie, ideálne s príkladom, čoho sa to týka. Nemyslím programátorský príklad, ale len slovný, o čo ide. Trochu si mi s tým hlavu zamotal.

_________________
Sharp MZ-821
Milsa MZ-841

Zameril jsem se na to kdy se muze zmenit rezim obrazovky. Je to mozno vzdy po 16 bodech obrazovky v rozliseni 640x200. V 320x200 je to po 8 bodech (je to 2x sirsi). Jedna radka ma 1136 bodu a zmena muze byt jen na 71 mistech.

Toto je cast kde rikam ze jak reaguje GDG na out 0CEh. Jak jde /WR do log0, tak D0 az D3 se ulozi do dmd_store1. Ale nic se stale v GDG nezmeni. Az kdyz prijde signal DISP_nCPU do log0, tak se z dmd_store1 data zapisi do dmd_store2 a okamzite se vse v GDG zmeni. To se deje kazdych 16 bodu, v presne danych casech.

Pak jsem se zameril na na to proc hodiny (CPU) pro wait latch jsou nejdrive vyvedeny ven z GDG a pak jdou zpet dovnitr GDG. Logicky to dela zpozdeni a dalsi casovou domenu. A opravdu podle vseho je to proto aby kdyz se dokoncuje cteni z GDG, tak muze nastat okamzik kdy presne ve stejnou dobu je ukonceno cteni ale chvilku trva nez se pres par hradel dostane tato informace az do obvodu co generuje Wait signal. On stale pri nabezne hrane CPU ma na vstupu log1 a tak bude i priste wait cyklus. Ale kdyz se to rozume zpozdi, tak ven z GDG uz pujde log1 a CPU muze uz dal pokracovat v praci.

-----
Zde popisuji Wait signal. Jinak receno Wait signal se aktuvuje vzdy kdyz GDG potrebuje neco uvnitr delat a ceka se do doby nez se to dokonci.

Pri cteni z GDG se wait da se rici okamzite aktivuje a bude aktivni do doby nez se cteni dokonci. Pri cteni z GDG je dulezite zda je nahodou neni nedokonceny zapis. V tom pripade okamzite se cteni prerusi do doby nez bude zapis ukoncen. Jinak GDG pocka az CPU dostane cas na obsluhu a v tomto casovem slotu provede cteni z video ram. Nakonec kdyz ma vse hotove tak da vnitrni priznak ze chce blokovat GDG do log0 a odblokuje wait (GDG nema duvod blokovat CPU). A prave tento okamzik jsem v minulem prispevku popisoval.

Jinak pri zapisu se pocka na okamzik kdy CPU dokoncuje zapis a /WR jde do log1. Takze z pohledu CPU je vse ukonceno (zapis byl prave ukoncen). GDG prave v tomto okamziku pozadavek prijme, nastavi vnitrni klopny obvod do stavu kdy zakaze dalsi out a in pozadavky od CPU. Zacne cekat na okamzik kdy CPU dostane svuj time slot. Pak provede vlastni zapis do GDG. Kdyz jeste nedokonci zapis a prijde dalsi zapis od CPU, tak GDG okamzite nastavuje WAIT do doby nez se uvolni misto v bufferu, nez dokonci predchazejici zapis.

Fúha, ak tomu správne rozumiem, nie je teda jednoduché "vyčísliť", kedy a aký wait bude. Preto je také ťažké urobiť emulátor, ktorý emuluje absolútne presne.

_________________
Sharp MZ-821
Milsa MZ-841

Tak jsem se koukal na schema a resil jsem zda pujde vse predelat na flip-flop s nabeznou hranou. Vypada to ze ano. Pri tom jsem zjistil ze asi tech 35Mhz (10xcpu frekvence) bude optimalni frekvence. Soucasne to bude ok pro GDG a pripadne i pro emulaci CPU. Synchronni navrh by hodne pomohl. Idealni je udelat 71 slotu a kazdy bude mit 32 stavu. Jeden bod na obrazovce bude mit dva stavy. Takto bude vyresena jedna horizontalni radka.