Takty i8080 v PMD85
Vykonávání instrukcí mikroprocesoru 8080 použitého v počítači PMD 85 je prodlužováno vkládáním čekacích stavů tak, aby videoprocesor měl volný přístup k operační paměti. Nakolik je procesor zpomalený se dá docela přesně odvodit, konkrétně se dá přepsat tabulka taktů pro jednotlivé instrukce.
Dovolím si vypustit vysvětlování přesného fungování taktování, odborníci vědí, pro laiky je tento článek zbytečný.
Pravidla vkládání čekacích taktů jsou popsána v manuálu PMD85, důležitý je stav signálu VIDEO – signál je aktivní každý druhý strojový takt a vymezuje čas pro videosystém, aby načetl 1 byte z videopaměti. Čekací stav TW se vkládá mezi T2 a T3 každého strojového cyklu:
Pokud VIDEO = 1 a zároveň se má v T3 číst, vkládá se TW.
Pokud VIDEO = 0 a zároveň se má v T3 zapisovat, vkládá se TW.
Každá instrukce zahajuje své vykonávání cyklem M1 – čtení operačního znaku, který se skládá z taktů T1-T2-T3. Podle stavu signálu VIDEO jsou dvě možnosti, jak tento cyklus proběhne:
Průběhy taktů prvního strojového cyklu
Důležitý fakt plynoucí z průběhů je, že další cyklus M2 vždy začíná v aktivním signálu VIDEO a proto další taktování instrukce má pokaždé identický průběh (a víme kdy skončí).
Například průběh instrukce STA vypadá takto:
Průběh taktů instrukce STA
Tato instrukce trvá 14 nebo 15 taktů. Záleží na tom, jak se zakončila předcházející instrukce. A teď přijde rozřešení celého problému: protože víme dopředu, kdy každá instrukce skončí (např. STA končí vždy v aktivní signálu VIDEO), tak taky víme, zda způsobí natažení následující instrukce o jeden čekací stav nebo ne. A právě tento jeden takt, ačkoliv proběhne až v následující instrukci, můžeme přičíst k celkové době vykonávání, a proto doba vykonávání jakékoliv instrukce je pokaždé stejná!
Příklad: instrukce DCX B končí vždy v neaktivním signálu VIDEO, tj. vynutí si u následující instrukcí čekací stav v prvním strojovém taktu. Kdykoliv použiji instrukci DCX B, utrhnu si celkem 6 taktů instrukce = to je její doba trvání.
Navázání dvou instrukcí
Dal jsem si tu práci a rozpracoval jsem všechny instrukce. Po nějaké době jsem opravoval jedno PMD, napíchl jsem některé signály na logický analyzátor a jen tak mimoděk si ověřil, že výše uvedená úvaha je správná. Nakonec jsem provedl dodatečné měření i za pomocí časovače 8253 přímo v PMD a zmýlil jsem se pouze u instrukcí IN a OUT.
Nová tabulka taktů je ke stažení zde: 8080.pdf
A pro emulátorovníky dávám rovnou ke stažení i v jazyku C (upraveno 19.7.2017 podle 8080.pdf – byl rozdíl v IN a opcode DD/ED/FD).
int cycles8080[256]={
/* 0 1 2 3 4 5 6 7 8 9 A B C D E F */
/* 0 */ 4, 12,8, 6, 6, 6, 8, 4, 4, 10,8, 6, 6, 6, 8, 4,
/* 1 */ 4, 12,8, 6, 6, 6, 8, 4, 4, 10,8, 6, 6, 6, 8, 4,
/* 2 */ 4, 12,18,6, 6, 6, 8, 4, 4, 10,20,6, 6, 6, 8, 4,
/* 3 */ 4, 12,14,6, 10,10,10,4, 4, 10,16,6, 6, 6, 8, 4,
/* 4 */ 6, 6, 6, 6, 6, 6, 8, 6, 6, 6, 6, 6, 6, 6, 8, 6,
/* 6 */ 6, 6, 6, 6, 6, 6, 8, 6, 6, 6, 6, 6, 6, 6, 8, 6,
/* 6 */ 6, 6, 6, 6, 6, 6, 8, 6, 6, 6, 6, 6, 6, 6, 8, 6,
/* 8 */ 8, 8, 8, 8, 8, 8, 8, 8, 6, 6, 6, 6, 6, 6, 8, 6,
/* 8 */ 4, 4, 4, 4, 4, 4, 8, 4, 4, 4, 4, 4, 4, 4, 8, 4,
/* 9 */ 4, 4, 4, 4, 4, 4, 8, 4, 4, 4, 4, 4, 4, 4, 8, 4,
/* A */ 4, 4, 4, 4, 4, 4, 8, 4, 4, 4, 4, 4, 4, 4, 8, 4,
/* B */ 4, 4, 4, 4, 4, 4, 8, 4, 4, 4, 4, 4, 4, 4, 8, 4,
/* C */ 6, 12,12,12,14,12,8, 12,6, 12,12,12,14,20,8, 12,
/* D */ 6, 12,12,10,14,12,8, 12,6, 12,12,12,14,20,8, 12,
/* E */ 6, 12,12,20,14,12,8, 12,6, 6, 12,4, 14,20,8, 12,
/* F */ 6, 12,12,4, 14,12,8, 12,6, 6, 12,4, 14,20,8, 12 };
Doplnění 4.4.2020
Soubor s časovými průběhy signálu VIDEO a takty pro všechny instrukce: cykly8080.zip
Zaujala mě věta „A právě tento jeden takt, ačkoliv proběhne až v následující instrukci, můžeme přičíst k celkové době vykonávání, a proto doba vykonávání jakékoliv instrukce je pokaždé stejná!“
Je to tedy tak, že všechny (nebo jen některé?) instrukce se zasynchronizují na sudý a vždy stejný počet taktů CPU, k čemuž je vede mechanismus generování signály READY? Nemůže se stát, že když úplně na začátku „posunu“ program o jeden takt vůči pozici přístupu videoprocesoru k paměti, že začne existovat druhá tabulka prodloužených taktů CPU? Intuice mi říká, že by ty tabulky mohly existovat právě dvě a k jejich volbě bude docházet ve výjimečných stavech.
V záhlaví článku vidím zřejmě autentické obrázky z měření této problematiky na PMD-85. Dělal jsi i řekněme rozbor na logické (vy smyslu logika jako myšlenková cesta) úrovni, kterým jsi vyloučil potenciální existenci alternativní prodloužené časovací tabulky?
PS: Nikde tady nevidím jméno ale předpokládám, že jsi Zdeněk..
Všechny instrukce se synchronizují během cyklu M1 tak, aby M2 začal s aktivním VIDEO signálem. I instrukce NOP může být natažená a jednou trvat 5 taktů a jindy 4. Např. v posloupnosti MOV NOP NOP:
MOV A,A ; vždy končí v T5 s VIDEO=0 (nezávisle kdy začala, co je před ní)
NOP ; kvůli tomu trvá 5 taktů, ale ten takt navíc způsobila MOV a způsobila by ho u každé instrukce, NOP vždy končí s VIDEO=1
NOP ; teď bude trvat 4 takty
Takže pro celou posloupnost můžu počítat takty podle skutečného časování 5+5+4 nebo podle mého zjednodušujícího závěru 6+4+4.
Potenciální alternativní tabulka by platila jen pro první instrukci vykonávané po resetu. Od cyklu M2 už by její součinnost se signálem VIDEO byla vždy stejná (jen M1 nabízí variantu natažení o jeden takt) a u časování druhé instrukce už nepoznáš, jestli byl při resetu VIDEO=0 nebo 1.
To, co intuitivně vnímáš jako možnou existenci jiné prodloužené tabulky, je ve skutečnosti jen existence posunutí vykonávání všech instrukcí o jeden takt k časovému začátku t=0 (reset) – tam je to hod mincí, jednou se nám PMD po resetu spustí o 0,5us později a jindy ne 🙂