Test 8253 (nebo spíše ruské potvory KR580VI53)
Celotýdenní zkoumání zmíněného časovače v PMD85 vyústilo k několika poznatkům. Zvláště jde o chování čítače 1, který je v PMD85 taktován signálem φ2 (2,048MHz), a protože jsou současně tímto signálem synchronizovány i vnitřní pochody procesoru 8080, dochází k zajímavým jevům a občas i k hazardům při přímém čtení obsahu čítače. Kromě toho jsem odhalil dvě verze čipů – jeden se záchytným registrem (v PMD85-3) a druhý bez (nižší verze).
Za tím účelem vznikl i program, který rozezná verzi čipu a ověřují jeho funkci v některých klíčových okamžicích pro různé módy. Konkrétně prověřuje:
- Test nečítání po módování – v době mezi nastavením módu čítače a první předvolbou se hodnota čítače nesmí měnit.
- Hodnota čítače při prvním a druhém čtení po zadání předvolby v posloupnosti instrukcí OUT (předvolba)-IN (1. čtení)-IN (2. čtení). Zatímco mezi IN-IN je rozdíl 12 taktů, což odpovídá délce instrukce IN, mezi OUT-IN je rozdíl 7 taktů (což bylo nejprve záhadou, dokud jsem při použití latch registru nezjistil, že… no to až později). Abych si ověřil, že IN nijak neblokuje činnost čítače, čtu ještě hodnotu v posloupnosti OUT (předvolba) – mezera 12T – IN (2. čtení) – získáné číslo musí být stejné jako druhé čtení v předchozím případě.
- Funkce záchytného (latch) registru – při zadání povelu zachycení se uloží aktuální údaj čítače do pomocného registru. Při dalším čtení se nejprve vrátí uložený údaj a pak až údaj z čítače. I tady ověřuji, že i bez latch získám v okamžiku druhého čtení stejné číslo, tj. OUT nebrzdí činnosti čítače. Jak už bylo zmíněno, existuje verze čipu bez latch registru. Test tedy bude dávat špatné výsledky.
- Podtečení čítače – některé módy čítají do 0 a pokračují od nejvyššího čísla (0xFF pro binární čítání, 0x99 pro BCD), některé čítají do 1, jiné do 2, pak přichází opakované načtení předvolby. Tímto testem jsem chtěl zobrazit hodnotu čítače před a po podtečení. Jak se ovšem ukázalo, čtení přímo z čítače bez latch registru u čipu, který ho obsahuje, v okamžiku podtečení může narušit celý tento proces a zkrátka to někdy nedopadne dobře. V emulátoru to pochopitelně vždy dobře dopadne, na reálném železe je to náhodné, pouze mód 0 se ukázal jako bezproblémový.
- Podtečení čítače s latch registrem – kvůli předchozím chybám mapuji podtečení s latch registrem. Tady už je to 100%.
Program má v sobě uloženy i hodnoty, které mi dávalo reálné PMD85-2A a PMD85-3, a porovnává je se změřeným výsledkem, např. jeden z testů módu 0 dává tyto výsledky (co je dobře, má fajfku, jinak se v závorce dopíše očekávaná hodnota):
Verze čipů
A teď k jevům, které jsem tímto měřením odvodil. Jako inspiraci pro emulaci 8253 jsem si vybral PIT8253.cpp z arkádového emulátoru MAME. Pochopitelně naměřené výsledky se zcela rozcházely s realitou. Tak jsem začal „ladit“. Nejprve podle PMD85-2A – tam jsem přišel na to, že časovač nemá latch register a považoval jsem to za vlastnost ruského klonu. Protože mám ale tento kus mírně nestabilní, vzal jsem PMD85-3. Tam najednou latch byl, což bylo štěstí, protože bez něj bych nepoznal, jak se ke správným číslům dobrat. Mám těch PMD doma víc, vyzkoušel jsem ještě přehodit interfejsovou desku z dalších dvou péemdéček. Pouze u verze 3 byl latch, ale tu mám jen v jednom exempláři, takže to nemusí hrát roli. Značení čipů se liší pouze malým 4 ciferným číslem:
- bez latch registru: 2×8804, 8807,
- s latch registrem: 8808.
Nevím, co to číslo znamená, jestli je to výrobní série, pak možná vše od čísla 8808 je latch registrem vybaveno.
Čip bez latch registru.
Čip s latch registru v PMD85-3.
Jak to (asi) funguje
Takže jsem sestavil testy, změřil čísla a snažil se najít nějaké rozumné vysvětlení. Nejprve ta záhada 7 taktů mezi OUT-IN (teoreticky by mělo být 11, jelikož zápis na port probíhá v posledním taktu instrukce OUT a v 11. taktu instrukce IN). Přidal jsem do emulátoru zpoždění 4 taktů od okamžiku zadání předvolby. Jenže pak latch registr v emulátoru ukazoval vždy číslo o 2 větší než na reálném stroji. A latch je přesný, z toho se dalo vycházet, takže instrukce IN ve skutečnosti vrací o 2 takty menší hodnotu. Možné vysvětlení je to, že při čtení z čítače se na adresové sběrnici objeví aktivační adresa už o dva takty dříve a signál /CS způsobí, že se uvnitř 8253 hodnota čítače přesune do nějakého bufferu a teprve o dva takty později aktivním /RDIO se vyplivne na sběrnici. Dále platí, že zápis předvolby se trochu protáhne a propásne se tak jeden takt čítače. No a pokud k tomu připočtu 1 takt prodlení, které podle datasheetu má 8253 v módu 0, máme ty ztracené 4 takty (1 – out, 2 – in, 1 – prodlení módu 0).
Nic z tohoto jsem ale neověřoval logickým analyzátorem, takže možná existuje jiná, vše vysvětlující teorie. Jakmile jsem ale toto zanesl do svého emulátoru, začaly se výsledky shodovat.
Co může v reálu kolabovat aneb trochu toho ruského švába vystresujem
Pokud se během čtení trefíme do okamžiku právě probíhajícího podtečení čítače, přečte se napůl stará a napůl nová hodnota čítače. Tato chyba se ale paradoxně projevovala jen u čipu s latch registrem a častěji v BCD módu. Je docela možné, že ten jediný exemplář s latch registrem, který mám, je vadný a nebo je něco v nepořádku s celým PMD85. V datasheetu upozorňují, že podmínka bezchybného čtení je „klid na frontě“ ze strany GATE i CLK. U čipu s latch registrem vznikají chyby v módu 3 dokonce i mimo podtečení (kdo ví, jak tam udělali dekrementaci po dvou). Chyba se objevovala navíc jen u sudé předvolby. Čtení latch registrem ale dávalo správné výsledky. Nechal jsem opakovaně spouštět pouze testy na módu 3 a ukázalo se, že někdy naskočí hodnoty podle teoretického předpokladu a jindy ne (častěji ne). Jako by tady neplatilo, že IN čte hodnotu o dva takty dříve, ale jen pro sudou předvolbu v módu 3.
Proto je součástí programu i stress test – provede se 65536 konfigurací a čtení a očekává se pokaždé stejný výsledek. Testuji pouze módy 0, 2 a 3 v binárním i BCD módu. Na čipu bez latch registru dopadl vždy dobře, jinak selhával. Zdá se, že novější „vylepšená“ verze není žádnou výhrou.
Výstup ze zátěžového testu.
Módy
Pár poznámek ke konkrétním módům:
- Mód 0 – nejvíce spolehlivý mód, zřejmě díky primitivnímu podtečení z 0 na max. V binárním módu nevznikaly nikdy hazardy na žádné verzi čipů. Nejvhodnější mód na měření času.
- Mód 1 – tento mód spouští čítání náběžnou hranou na vstupu GATE. Jelikož má 8253 u všech čítačů GATE připojen na pullup rezistor, k žádné náběžné hraně nedochází a logicky by nemělo docházet k žádnému čítání. Ve skutečnosti se po zadání předvolby čítač rozběhne (protože GATE=1), ovšem předvolba se zavádí až náběžnou hranou na GATE, takže hodnota, která je v čítači, je zbytková hodnota z předchozího módu! V programu na to pamatuji, nejprve volím mód nula, nastavím předvolbu a pak změním na mód 1, který od této předvolby počítá. Bez vnějšího hardwaru připojeném na GATE mě nenapadá nějaké rozumné využití tohoto módu.
- Mód 2 – mód dekrementuje k 1 a pak znovu začíná od předvolby (např. 4, 3, 2, 1, 4, 3, 2, 1, …). Tady už občas dochází k nesprávnému čtení v blízkosti podtečení (např. místo 1 se načte 0). Čtení přes latch je ale bezchybné, takže vhodný mód pro opakované čítání s nastavitelnou předvolbou.
- Mód 3 – nejvíce „poruchový“ mód ze všech při čtení bez latch registru. Kupodivu na reálném PMD je lichá předvolba spolehlivější než sudá, ačkoliv zavádění předvolby je u ní více komplikované. Program netestuje zvláštnosti kolem čítání lichého čísla, ale je v něm neaktivní úsek programu, který zobrazuje posloupnost čísel u pomalejšího čítače T3, který je taktován každou sekundu. Uplatnění má hlavně jako generátor obdélníkového průběhu, jelikož vytváří dvojkový signál se střídou 1:1. Je zbytečné se tedy trápit s nestabilitou čtení.
- Mód 4 – jako mód 0 (po stránce čítání)
- Mód 5 – jako mód 1 (po stránce čítání)
V rámci testování jsem nepoužíval 16bitové předvolby. Tomu by odpovídalo i 16bitové čtení a hazardy by se zřejmě vyskytovaly častěji. Pouze pro kontrolu je zařazen jeden test pracující pouze s MSB slabikou.
Závěr (a předpoklady)
- V PMD85 se vyskytují dvě verze klonu 8253 – rozdíl je v absenci latch registru.
- Předpoklad: verze s latch registrem je pouze u trojkové verze PMD85 nebo u čipu s číslem 8808 a výše.
- Předpoklad: verze s latch registrem chybuje při přímém čtení obsahu čítače.
- Pro měření času je dobrý jen binární mód 0, dává správné výsledky u obou verzí čipu.
- Mód 3 používat jen ke generování signálu se střídou 1:1 (taktování 8251).
- Ostatní módy bez dalšího hardwaru (připojeném na GATE/OUT) nemá moc smysl používat.
Testovací program i se zdrojovými kódy je ke stažení zde: test8253.zip
Pokud by se někdo na reálném stroji dopracoval k jiným výsledkům nebo potvrdil stávající, budu rád za info, třeba tady do komentářů 🙂
Trochu se mi nezdá ta věta „PMD85-2A .. časovač nemá latch register „. Podle mne je LATCH register u všech tří čítačů v 8253 naprosto základním stavebním kamenem, bez kterého by to asi nemohlo být nazýváno 8253 (nojo, ono se to tak v CCCP vlastně fakt nejmenovalo..)
Ale teď vážně. Například u Arkanoidu testuji letmý průchod T1 v binárním módu 0 a pouze vyšší bajt. Přesto čítač raději před čtením načtu do LATCHe. A zdá se, že i na reálném PMD 85-2A to funguje. Naopak mám negativní zkušenost se čtením T2 (sekundové pulsy, opět verze 2A) ve hře Treasure Island. Binární mód 0, sekvenční čtení MSB/LSB přes LATCH. Doteď jsem ty problémy považoval za vadný oscilátor MH1116 ale asi se na to kouknu. Na emulátoru vše běží, ale na reálném PMD 85-2A se mi pouze jednou za několik minut „načte“ 1 sekunda.
Vyzkoušej, možná budeš mít ve svém PMD dobrý časovač. Já odhalil 3 interfejsové desky, kde latch nebyl (tím myslím ten register navíc, do kterého se po speciálním příkazu uloží aktuální stav čítače). Když ho nemá, tak prostě ten povel ignoruje a další čtení je přímé čtení obsahu čítače. Pokud „latchnutí“ a čtení je hned za sebou, rozdíl v načtené hodnotě je jen několik taktů a v případě čtení MSB je to zanedbatelné, takže fungovat to bude dobře.
I mně se u T2 stávala chyba – četl jsem jeho obsah a vypisoval, když se změnil. Očekával jsem sekvenci např. 09-08-07- atd. Místo toho se tam občas vloudila 0. Tvůj případ ale opravdu vypadá spíše na vadný zdroj signálu, mě ty sekundy naskakují normálně.
To čtyř místné číslo je z největší pravděpodobností datum výroby a to ve formátu rok/měsíc nebo měsíc/rok, zaleží na výrobci. Mám jednu desku do SAPI-1 ( http://wwww.sapi.cz/sapi/trc.php ) ve které je 8253 osazena v patici a také mám několik 8253 jak výroby CCCP tak originál INTEL či další výrobci. Mám i několik 8254. Puknut bude zájem tak mohu vyzkoušet. Jen ten program se bude muset upravit pro SAPI-1 a ideálně jedoucí pod CPM. Mé programátorské schopnosti nejsou moc velké takže s tou úpravou budu z velkou pravděpodobností pomoct.
Zájem je, pomoc bych uvítal. Nejvíce by mě zajímalo, které klony 8253 nemají záchytný registr a jestli se to dá odvodit z data výroby. Zbytek testu je až příliš vázáno na PMD85 a vlastně nemají ani nějaké extra využití (vznikly jen pro otestování přesnosti emulace). Stačí tedy napsat kód jen pro otestování latch registru. Ten nebude složitý, ale o SAPI-1 nic nevím. Díval jsem se na schéma té desky, 8253 se zřejmě adresuje mezi 38-3f a časovače jsou rovněž taktovány fi/2. CP/M je univerzální, takže jednoduchý program by šlo udělat přímo hexadecimálním zápisem strojového kódu. Takový prvotní pokus pro CP/M, který vypíše písmeno „O“ (je to OK – máme latch) nebo „X“ (čip nemá latch):
di ; nenecháme se vyrušovat
lxi h,0005h ; BDOS call
push h
mvi c,2 ; BDOS funkce CONSOLE OUTPUT
mvi a,50h
out 3fh ; mód 0
xra a
out 3dh ; předvolba 0
mvi a, 40h
out 3ch ; jen pro dodržení stejného zpoždění
xthl
xthl
in 3dh
mov b,a ; kam se dočítalo bez zachycení
xra a
out 3dh ; znova předvolba 0
mvi a, 40h
out 3fh ; zachycení do latch registru
xthl
xthl
in 3dh
cmp b ; liší se? takže máme latch...
mvi e,'O'
rnz
mvi e,'X'
ret
Teď je otázka, jestli jsem trefil ty porty (stejný program na PMD85 funguje, akorát adresy jsou 5c/5d/5f).
No se SAPI-1 je to trochu komplikované. Mám CPM rozchozeno pouze s JPR-1Z tj. se Z-80 a deska TRC používá horní adresné vodiče, takže se budou muset použít instrukce IN x,(C) a OUT(C),x. Taktéž je otočená datová sběrnice u 8253 na té desce TRC.
Tet mě ještě došlo, že jsem schopen dat do provozu MIKOS a ten chodí s JPR-1 tj. na 8080A v MIKOSu je mám pocit implementováno i pár funkci z CPM jen se volají na jiné adrese. Ale výpis na konzoly není problém předělat. Pod MIKOSem mám zálohovanou RAM takže stačí jednou napsat a pak jen spouštět. No nevím, zda mi nespadne systém, pokut budu tahat tu 8253 za provozu, lepší bude měnit tu 8253/8254 ve vypnutém stavu.
Ještě pár dodatku k SAPI-1 ZPS-2 na kterém budu zkoušet ty 8253/8254, krystal u 8224 bývá většinou 18MHz a CPU, není nijak brzděný, tj. běží plnou rychlostí. Deska videa AND-1 běží asynchronně vůči CPU takže pokut CPU začne přistupovat do VRAM je to doprovázeno býlími proužky na obrazovce,.aneb kolize dat, CPU má přednost.
Pokut nevadí otočená datová sběrnice u 8253 na desce TRC (řídící kódy upravím) a to že CPU, není brzděn tak se do toho pustím.
Důležité je, aby se doba vykonání instrukcí neměnila, je jedno jak dlouho trvají, ale musí to být pokaždé stejně. Takže pokud není CPU bržděný, podmínka je splněna a nic tomu nebrání. Té otočené datové sběrnice jsem si prvně nevšiml, takovou blbost bych ani nepředpokládal…
Tipuju, že intelácké 8253/8254 budou fungovat správně, a proto by měl být výstup „O“. Pokud budou všude vyskakovat „X“, zřejmě sestavený program není vhodný a do hry vstupuje ještě nějaký další faktor…
Hodně zdaru!
Tak jsem upravil program pro SAPI-1 ZPS2. Reálné adresy pro 8253 jsou 28H až 2BH tak snad jsem to upravil správně
Jdu zkoušet co to bude dělat na reálném železe.
;program T8253
ASEG
ORG 43A0H ;odtut prekladat
; SLUZBY Z MONITORU
CO EQU 0109H ;vystup znaku na obrazovk
;vstup: C - ASCII kod znaku
;rusi: PSW
DADR EQU 0130H ;zobrazi obsah HL na obrazovce
;vstup: HL - zobrazovana hodnota
;vystup: 4 cifry na obrazovce (HEX)
;rusi: PSW,C
NEXT EQU 0139H ;predani rizeni MONITORu
; KONSTANTY
CT0 EQU 028H ;citac 0
CT1 EQU CT0+1 ;citac 1
CT2 EQU CT0+2 ;citac 2
CTCW EQU CT0+3 ;modovaci registr
; PROGRAM
DI ;nenechame se vyrusovat
MVI A,0AH ;=50H
OUT CTCW ; mod 0
XRA A
OUT CT1 ;predvolba 0
MVI A,2H ;=40H
OUT CT0 ;jen pro dodrzeni stejneho zpozdeni
XTHL
XTHL
IN CT1
MOV H,A ;kam se docitalo bez zachyceni
XRA A
OUT CT1 ;znova predvolba 0
MVI A,2H ;=40H
OUT CTCW ;zachyceni do latch ...
XTHL
XTHL
IN CT1
MOV L,A
CMP H ;lisi se? takze mame latch
MVI C,'L' ;L = latch
JNZ ANO
MVI C,'X'
ANO: CALL CO
CALL DADR ;zobrazeni obou vysledku
JMP NEXT
END
vloudila se chybka 50H neni 10H ale AH
Ok, dovolil jsem si to v původním příspěvku opravit, ať je to na jednom místě.
Nakonec jsem zkoušel pouze 8253
Všechny KR580IV53 co jsem zkoušel, měly „LATCH“ a konkrétně data výroby, 0782, 0283, 0383, 3x 8407, 8603, 8607, 8610, 2x 8611, 8708, 2x 8712, 8803, 3x 8805, 8806, 8811, 8904, 2x 9002. Kapitalistické verze 8253 měly „LATCH“ všechny.
Jedna ze služeb monitoru umí vypsat obsah registru HL jako čtyř místné hexa číslo a tak jsem tuto službu použil k zobrazeni hodnot výsledku z testu, kdy v H je hodnota s přímého ctění a v L je hodnota ze ctění přes „LATCH“. Každý obvod byl zapnut min 1x a test puštěn minimálně čtyřikrát.
Nejčastější výsledek byl „L4F8F“ druhý nejčastější výsledek byl „L238F“ a sporadicky se objevovali „LA38F“ a „LAF8F“. A to tak že buď byl pouze výsledek „L4F8F“ nebo se pravidelně střídal „L4F8F“ s jedním z již zmíněného výsledku.
Jenom obvody 8x NEC D8253C-5(2), INS8253N a AMD D8253-5 vraceli vždy „L4F8F“ a ostatní obvody 21x KR580IV53, 3x M5L8253P-5 2x INTEL QP8253-5 vraceli „L4F8F“ s pravidelně se střídající se s jednou z již uvedených hodnot.
Vyskytli se ale i dvě anomálie kdy jedna KR580IV53 vracela X0000 tak jsem ji dal bokem jako vadnou, ale nadalo mi to tak jsem ji vyzkoušel potom ještě jednou a nejednou fungovala. S druhou a AMD D8253-5 byla větší zábava. Při prvním puštění testu byl výsledek úplně špatně a pak začala vracet „X8F8F“, po druhém zapnutí špatný výsledek, „X8F8F“ a pak jen „L4F8F“. Nedalo mi to a vytál jsem repliku Mikropočítače SPO 188 ONDRA, kde mám všechny IO v paticích a tam ta zlobící AMD chodila bez problému. Po opětovném testu po zapnutí špatný výsledek a pak jen „L4F8F“.
Až na dva obvody se všechny 8253 chovali dle předpokladu, jen dva obvody se zdají být nějak načaté a to jedna KR580IV53 a AMD D8253-5. Z čehož mně nejvíce udivilo že, až na jeden obvod KR580IV53 prošli na první dobrou tímto jednoduchým testem.
Obdivuhodná práce! Vřelé díky! Výsledky ale místo odpovědí spíše dávají další otázky.
Jelikož jsou vypsané HL hodnoty bitově otočené, můžeme je vypsat správně, co by čísla, která se určila z časovače:
4F8F => F2F1
238F => C4F1
A38F => C5F1
AF8F => F5F1
Jak si vysvětlit hodnotu F1? Po nastavení časovače na hodnotu 0 začíná dekrementace čítače. Mezitím proběhne instrukce MVI (7 taktů) a OUT (10 taktů). Zachycení do latch registru by tedy mělo přijít po 17 taktech, ale jak už mám v článku uvedeno, nastavení do módu 0 si vezme jeden takt, instrukce OUT si vezme jeden takt – ve výsledku by v časovači mělo být 0x00 – 17 + 2 = 0xF1. To sedí (občas F2, dobrá, je to synchronizováno stejným signálem jako CPU, stát se vinou šíření signálu může cokoliv.)
Hodnota C4/C5 – to je už rozdíl 60 taktů (mezi nastavením módu a čtení z CT1 jsou instrukce, které mají v součtu opravdu 60 taktů) – to sedí, pokud nečteme z latch registru.
Takže zatímco hodnoty C4F1 (238F/A38F) značí předpokládanou a správnou funkci časovače s latch registrem, hodnoty F2F1 spíše svědčí o tom, že zápis na jiný časovač (v tomto případě CT0) zastaví čítání časovače CT1, jako by došlo k latchnutí! Tyto čipy jsou podivné, dá se ještě určit, o které typy šlo? Možná mají latch registry všechny čipy, ale u některých čipů hraje roli i nastavení ostatních čítačů! To jsem samozřejmě v mém testování nezkoušel, možná se musejí namódovat všechny čítače, než se začne pracovat s jedním z nich. Tohle asi budu muset v PMDčku opět prozkoumat, jestli se latchovaní nedá vytřískat i z čipů, které se tvářily jako nedostatečně vybavené chuděrky.
Ještě jednou děkuji za masivní test a pokud by Tě náhodou napadla nějaká jiná interpretace, rád se na problém podívám i z jiného úhlu.
Tak nic, pořád mi ten latch nejede. Namodoval jsem všechny tři časovače, ze všech jsem 2x četl údaj, abych eventuelně zrušil náhodně nahozený stav – čtení z latch registru. Na časovač č. 0 jsem přivedl fi/2. Počkal jsem, dokud všechny časovače nejsou podrážděné alespoň jedním hodinovým impulsem – všechno proběhlo 2x po sobě. Vyzkoušel jsem test i na časovači 2, který je taktován z nezávislého zdroje 1 Hz. A pořád nedokážu zachytit stav čítače 🙁
Tak nevím, jestli do PMD montovaly vadné časovače, aby se ušetřilo, nebo mám štěstí na několik vadných kousků, které se chovají stejně (to mi přijde docela nepravděpodobné – všechno funguje, jen jeden povel ne). Pouze v PMD85-3 mi to funguje správně.
A výsledky ze SAPI ukazují, že se na chování těchto časovačů opravdu nedá spolehnout.
Nevím, zda u toho 1Hz kanálu 8253 není spíše problém s tím hodinovým strojkem na výrobu 1Hz. Mi totiž taky nejede. Ten generátor 1Hz myslím. Spíše než vadu 8253 bych čekal zádrhel v tom nestandardním řešení s napájením hodinového strojku, které je omezeno diodami. To řešení se mi moc nelíbí. A ještě ty DIL10 pouzdra narvané do připravených pozic DIL8 taky moc důvěry nebudí. A řešení s CMOS časovači použité u PMD 85-3 a zkrácením cyklu diodami se mi líbí ještě méně.
Mě generátory frčí, čítače čítají, přímé čtení hodnoty časovačů funguje. Jen na povel pro zachycení stavu čítače nereagují. Jen u PMD85-3 funguje, takže vím, že program mám dobře.
Zdeňku, měl bych prosbičku. Dokázal bys na nějakém reálném PMD-85 jakékoliv verze pustit T2 čítače 8253 a nechat vypisovat stav čítače v módu 0? Zajímalo by mě, jestli se Ti nebude stávat následující chyba: čítač správně čítá ale jednou za zhruba deset vteřin poskočí o dvě vteřiny najednou. Nevypadá to na vadu oscilátoru 1Hz, protože ty „jednoduché“ vteřiny jsou vizuálně všechny stejně dlouhé, spíše bych to odhadoval na občasný zákmit na hodinovém vstupu T2, který je sčítán ze dvou tranzistorů, které mají v bázi kondenzátor (to je můj favorit na příčinu problému). Ale potřeboval bych to ověřit. Já už jsem vyměnil všechno: pasivní součástky, krystal, polovodiče i samotný 8253 včetně blokovacího kondu (teď tam mám v patici 82C54). A pořád stejná chyba..
Jasně, odpoledne vyzkouším a dám vědět. Moje zkušenost s T2 byla taková, že když čtení údaje „trefí“ okamžik hrany vstupního impulsu, dojde k hazardu (zhruba taky co 10s) a přečte se špatný údaj (nejčastěji FF). Nicméně další čtení naváže tam, kde skončil, tj. k posunu o sekundu nedochází. Mimochodem, závidím Ti 8254, která se po tom maratónu zkoušení ve spolupráci s EC1045.01 ukázala jako nejstabilnější.
Tak mám otestováno, udělal jsem na to i testovací program a rovnou i samostatný článek. Při častém čtení z časovače mi opravdu dojde k přečtení falešné hodnoty, čtení jednou za sekundu je bezchybné.
Tak jsem všechny KR580IV53, zlobící AMD a po jednom NEC a INTELu prohnal znovu testem. Naštěstí jde docela rozumně přesměrovat výstup na monitor i na RS232 takže odpadlo přepisování a mohla vzniknout následující šílenost. (obvody jsou tak jam mi přišli pod ruku a je proveden i převod hodnot)
KR580IV53 8904
C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1
KR580IV53 0782
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8407
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8607
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 9002
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8712
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8805
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8806
C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1
KR580IV53 8708
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 0283
F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1
zlobici AMD
F1F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1
KR580IV53 8603
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8803
C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1
KR580IV53 8611
F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1
KR580IV53 8805
C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1
KR580IV53 8805
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8407
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 9002
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8811
C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1
KR580IV53 8407
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8610
F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1, F2F1, C5F1
KR580IV53 8712
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 8611
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
KR580IV53 0383
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
INTEL
F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1, F2F1, C4F1
NEC
F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1, F2F1
Pokut vymyslíš propracovanější test 8253, který bude respektovat možnosti desky TRC tak není problém ty obvody prohnat znovu propracovanějším testem.
Tak to je velká databáze dat!
Asi ten navržený program není úplně správný, vypadá to, že po latchnutí se s čipem ještě musí nějak pracovat, jinak po druhé zůstane zaseknutý (ta střídající se hodnota F2F1). Každopádně všechny ruské verze jeví příznaky latch registrů, takže v PMD budu mít spíše vadné kusy. Je to sice detail, ale tolik času jsem věnoval vytvoření přesné emulace tohoto čipu (včetně té chyby) a stejně nemůžu bezpečně říct, které PMD by mohly mít aušusový časovač 🙁
Zatím mockrát děkuji za ten čas tomu věnovaný. Možná mě ještě něco napadne, jak to otestovat. V nouzi vypájím jeden vadný obvod z PMD a podrobím ho testování v nepájivku.
Tak mi to nedalo a zkusil jsem i 8254.
SONY CXQ71054P, NEC D71054C, INTEL P8254 vracely vždy C4F0 a SUBARU KS82C54-10CP vracela vždy C3F0