Flash ROM és diagnosztikai kártya

[Pgyuri]

Üdv,

Ebben a részben lehetne beszélgetni a cikkekhez kapcsolódva, észrevételeket tenni, megdícsérni a szerzőjét, stb., stb.

Pgyuri

[Pgyuri]

.. és azonnal meg is kezdeném egy új cikk kapcsán.

Zozo megörvendeztetett egy új írással, amelyben egy újkori Spectrum tesztelő kártyát és annak működését mutatja be megfelelően mély és alapos kiegészítésekkel, amely még egy szoftveres számára is nagyon érdekes lett, köszönet érte!

A cikkhez kapcsolódva megkérdezném egy bennem régóta motoszkáló kérdést, amelyre úgy érzem, talán az írásban a sorok között eldugva ott lehet a válasz, de magam nem találom. Tehát a lényeg, idézve az angol ROM visszafejtésből:

"Now the memory is checked.
$11DA:

RAM-CHECK :
LD H,D Transfer the value in DE
LD L,E (START = +FFFF, NEW = RAMTOP).

RAM-FILL :
LD (HL),+02 Enter the value of +02 into
DEC HL every location above +3FFF.
CP H
JR NZ,11DC,RAM-FILL

RAM-READ:
AND A Prepare for true subtraction.
SBC HL,DE The carry flag will become
ADD HL,DE reset when the top is reached.
INC HL Update the pointer.
JR NC,11EF,RAM-DONE Jump when at top.
DEC (HL) +02 goes to +01.
JR Z,11EF,RAM-DONE But if zero then RAM is faulty.
Use current HL as top.
DEC (HL) +01 goes to +00.
JR Z,11E2,RAM-READ Step to the next test unless it fails.

RAM-DONE:
DEC HL HL points to the last actual location in working order.

A memória ellenőrzése két lépésből áll az eredeti ROM szerint, feltölti 2-vel először, visszaellenőrzi, majd feltölti 1-el és szintén ellenőrzi, végül 0-ra állít minden byte-ot. Emiatt látjuk azt a szép függőleges, halvány piros csíkozást a gép indulásakor. Hiba esetén csak az utolsó jó byte-ig határozza meg a használható memória méretét a BASIC számára.

A 2-el és 1-el feltöltés milyen hibát szűrhet ki, miért elégedetthetett meg a programozó ezzel a megoldással ?

Zozo, köszönjük az írást, 5 csillagos! (bár ez csak egy szoftveres véleménye)

Pgyuri

[Zozosoft]

A 2-el és 1-el feltöltés milyen hibát szűrhet ki, miért elégedetthetett meg a programozó ezzel a megoldással ?

Szerintem egyrészt akkoriban valószínűleg még nem voltak részletes tapasztalatok, hogy hogyan is hibásodnak meg a memóriák, hogyan is kéne tesztelni, másrészt itt szerintem csak arra törekedtek, hogy eldöntsék, 16-os vagy 48-as gép. (Tényleg 32K-s Spectrum konfig létezett? 16K-s gép plusz külső 16K-s bővítőre gondolok.) Két értékkel való tesztelésre úgy gondolhatták, az már tutira elég És azért pont 02 meg 01 mert így sorban DEC-el lehet elintézni a dolgot.

Összehasonlításként itt van ez EP RAM teszt rutinja, itt már alaposabban rákészültek a hibás memóriák kiszűrésére:

Kód: Egész kijelölése

    ;P1-en lévő RAM ellenőrzése és 0-val feltöltése.
    ;Eredmény: Z=0 lesz, ha hibátlan.
    
LC1FE:  INC     D		;nem működő szegmensek számának növelése
        IN      A,(0B1H)	        ;P1-en lévő szegmens száma A-ba
        LD      HL,0BED5H	;a vizsgálandó szegmens
        CALL    LC16A		;számának kiírása a képernyő
        INC     HL			;státuszsorába
        CALL    LC16A		;hexadecimális alakban
        LD      (0B909H),A	;szegmens száma, mint színkód
                                        ;a STATUS sor COL1 bájtjába
        LD      HL,4000H	;vizsgált szegmens P1-es kezdőcíme
        LD      BC,0C000H	;ROM0 P3-as kezdőcíme
LC214:  LD      A,(BC)		;átmásolás P3-ról
        LD      (HL),A		;P1-re
        CP      (HL)		;ellenőrzés
        RET     NZ			;hiba esetén visszatérés
        CPL     			;komplemens		
        LD      (HL),A		;letárolás
        INC     HL			;címek
        INC     BC			;növelése
        BIT     7,B			;cím vizsgálata
        JR      NZ,LC214	        ;ugrás visza, ha még nincs
                                        ;vége a lapnak
                            
    ;visszafelé haladva	0-val tölti fel a RAM-ot, és újra ellenőrzi a bájtokat.
    
LC220:  DEC     BC		;címek
        DEC     HL			;csökkentése
        BIT     6,H			;ellenőrzött bájtok számának vizsgálata
        RET     Z			;visszatérés, ha a teljes szegmens hibátlan
        LD      A,(BC)		;ROM-ban lévő érték
        ADD     A,(HL)		;RAM-ban lévő érték hozzáadása,
                                        ;ami a ROM-beli érték komplemense
                                        ;hibátlan esetben az érték 255
        INC     A			;A növelése, hibátlan esetben A=0
        LD      (HL),A		;érték letárolása
        RET     NZ			;hibás RAM esetén visszatérés
        JR      LC220		;feltöltés folytatása

Ez két menetben ellenőriz, elsőként a ROM bájtjait írja be, és ellenőrzi, ha stimmelt, akkor az adott bájt komplemensét hagyja ott, amit aztán a második menetben ellenőriz is, így az is kiderül, ha időközben (pl más címre írástól) megváltozott egy bájt tartalma.
Ez a módszer leginkább a cikkben emlegetett Random Fill-hez hasonlít.

[Pgyuri]

Üdv,

Nem hiszem, hogy a RAM 2-vel és 1-el tesztelése bármilyen szintű programozó számára elegendő lett volna, ha már ilyen "primitíven" gondolkoztak volna, akkor a 254, 255 magasan jobb lett volna és azt is egy sima INC utasítással megúszhatták volna, főleg, ha kihagyják a képernyő memória tesztjét, ami teljesen felesleges, úgyis mindenki látja, ha rossz.

Erre gondoltam az írásodból:

"A RAM fizikai elrendezése
Az általános feltételezés az, hogy mivel a Spectrum 8 bites gép, ezért a RAM chipek 8 bit széles adatokat tárolnak. Nos ez egyáltalán nem igaz, ezért különösen nagy csapda a meggondolatlan RAM teszt program íróknak! Minden RAM chip a Spectrumban csak 1 bit széles adatokat tárol! Ha megnézzük a kapcsolási rajzot, láthatjuk, hogy 8 db 4116 és 8 db 4164 (kompatibilis) RAM IC van a gépben, ezek mindegyike csak egy-egy adatvonalra csatlakozik az adatbuszon. Tehát amikor a CPU 1-1 bájtot ír vagy olvas, akkor egyszerre 8 memória IC-t választ ki, és ezek mindegyike 1-1 bitet kezel a kérdéses bájtból. Ez azt jelenti, hogy pl amikor "inversion test"-et akarunk futtatni, amely az 101010101… minták tárolásából áll, nem megfelelő az olyan módszer, hogy POKE 16384, BIN 10101010 , POKE 16385, BIN 10101010 , stb mivel így minden egyes RAM IC-ben folyamatos 1-esek vagy 0-ák lesznek tárolva. A helyes módszer POKE 16384, BIN 11111111 , POKE 16385, BIN 00000000 , stb így lesz megfelelő "inversion test" a 48K Spectrum felépítéséhez. "

Nem lehet, hogy a %00000010 és a %00000001 érték olyan RAM IC-t vizsgál, ami valakiért kiemelt ?

Pgyuri

[Zozosoft]

ha már ilyen "primitíven" gondolkoztak volna, akkor a 254, 255 magasan jobb lett volna

Nem, mert a nem létező címekről általában 1-esek olvashatóak, ill. legtöbbször a döglött IC-kből is.

Nem lehet, hogy a %00000010 és a %00000001 érték olyan RAM IC-t vizsgál, ami valakiért kiemelt ?

Én nem tudok semmilyen hw indokot, ami ennek értelmet adna.

[Pgyuri]

Üdv,

Nos, ha a nemlétező cím 255-öt ad vissza, akkor minden érthetővé válik. Alaposan megvizsgálva a Spectrum indulásakor futó memória-tesztelő részt, valóban megállapítható, hogy semmi más célja nem volt, mint a 16/48K gépek megkülönböztetése. Bár fura módon úgy írták meg, hogy legutolsó "hibátlan" byte legyen a memória felső határa, nem foglalkoztak olyan "apróságokkal", mint mi van, ha ez már a BASIC elindításához is kevés. Valószínűleg a RAM hiba nem volt olyan gyakori, mert annyit se tettek meg, hogy megnézték, mi az a minimális érték, ami alatt felesleges bejelentkeztetni a Spectrumot. Gyakorlatban azt jelenti, hogy ha a hiba $5E00 cím alatt következik be, akkor teljesen kiszámíthatatlanná válik a Spectrum reakciója, lehet, hogy állandóan újraindítja magát színkavalkáddal, de békésen várakozhat fekete képernyőn is. A legjobb eredménynél sikerült elérni, hogy bejelentkezett a gép, elfogadta a parancsot, de az ENTER után bénán állt, mert ahhoz már kevés volt a memóriája, hogy értelmezze is. Érdemes kipróbálni emulátorban:

Breakpoint $11EF-en, HL regiszter értékét $5E00-ra állítani, majd bejelentkezést követően mehet a PRINT 65536-USR 7962 hogy megnézzük a szabad helyet......

Összefoglalva ez a rész nem a memória tesztelésére készült, elsődleges célja a memória 0 értékekkel feltöltése és közben a 16/48K méret eldöntése. Legalább Zozo cikke segítségével ennek is utánajártam(tunk). Köszi

Pgyuri

[Zozosoft]

Valószínűleg a RAM hiba nem volt olyan gyakori, mert annyit se tettek meg, hogy megnézték, mi az a minimális érték, ami alatt felesleges bejelentkeztetni a Spectrumot.

Igen, itt lehetne pl. villogó keretszínnel jelezni a hibát, ahogy pl az EP esetén tették.

Ami érdekes még, hogy a ZX80 esetén, még csak 01-el ellenőriz:

Kód: Egész kijelölése

; ----------------------------
; THE 'INITIALIZATION' ROUTINE
; ----------------------------
; A holds $3F, HL holds $7FFF.

;; RAM-FILL
L0261:  LD      (HL),$01        ; fill location with 1 (null).
        DEC     HL              ; decrement address.
        CP      H               ; compare address high byte to $3F.
        JR      NZ,L0261        ; back, while higher, to RAM-FILL.

;; RAM-READ
L0267:  INC     HL              ; address the next higher location.
        DEC     (HL)            ; decrement to zero.
        JR      Z,L0267         ; back, if successful to RAM-READ.

; else we have encountered first unpopulated RAM location.

        LD      SP,HL           ; initialize stack pointer at end.

ZX81-nél lett 02,01, lényegében ugyanaz a rutin mint Spectrumnál:

Kód: Egész kijelölése

; -----------------------
; THE 'RAM CHECK' ROUTINE
; -----------------------
;
;

;; RAM-CHECK
L03CB:  LD      H,B             ;
        LD      L,C             ;
        LD      A,$3F           ;

;; RAM-FILL
L03CF:  LD      (HL),$02        ;
        DEC     HL              ;
        CP      H               ;
        JR      NZ,L03CF        ; to RAM-FILL

;; RAM-READ
L03D5:  AND     A               ;
        SBC     HL,BC           ;
        ADD     HL,BC           ;
        INC     HL              ;
        JR      NC,L03E2        ; to SET-TOP

        DEC     (HL)            ;
        JR      Z,L03E2         ; to SET-TOP

        DEC     (HL)            ;
        JR      Z,L03D5         ; to RAM-READ

;; SET-TOP
L03E2:  LD      ($4004),HL      ; set system variable RAMTOP to first byte 
                                ; above the BASIC system area.