Enterprise Forever
:HUN => Hardver => Memória => Topic started by: Zozosoft on 2006.August.24. 10:52:05
-
És az utolsó csemege a tegnapi kupacból :-)
Gyári diagnosztikai programok Ep-hez!
Azt még nem tudom, hogyan lehet használni õket :-)
Annyira már rájöttem, hogy bekapcsolás után teleírja az FC szegmenst 55H-val, majd megáll. Ha resettel újra indítjuk akkor leellenõrzi, hogy az 55H-k megvannak-e még. Ha igen után jön egy olyan rész ahol kavar valamit a B5/B6 portokkal, ha jól sejtem valamilyen loopback dugó kéne valamelyik csatlakozóba... ha jól sejtem itt is egy alapos disassemblálásra lesz szükség :-)
-
ha jól sejtem itt is egy alapos disassemblálásra lesz szükség :-)
Akkor egy ideig lesz mit csinálnod :-D
-
Akkor egy ideig lesz mit csinálnod :-D
Nekem is úgy tünik :-)
Asszem ezekkel fogom kezdeni az IDA-zást, rövidke programok, és remélhetõleg nincs benne semmi EXOS hívás vagy hasonló :-)
-
Akkor egy ideig lesz mit csinálnod :-D
Nekem is úgy tünik :-)
Asszem ezekkel fogom kezdeni az IDA-zást, rövidke programok, és remélhetõleg nincs benne semmi EXOS hívás vagy hasonló :-)
Szívesen fejtegetnék én is vissza, ha lenne időm :-(
-
Na az már kiderült, hogy a printer porttal szórakozik egy csomót, egyelõre még számámra ismeretlen célból :-)
Mivel EP32-ben nincs printer támogatás, így nem is indult el...
Mondjuk az szerintem elég súlyos programozási baki, hogyha rossz a printer port akkor végtelen ciklusban ragad a program, el se jut oda, hogy kiirja, hogy rossz a printer port...
És minden egyéb tesztben is piszkálja a printer portot...
Most egy nagyrakás NOP-ot szétszórva likvidáltam az összes végtelen ciklust, így már lehetett screenshot-okat gyártani EP32-vel :-)
(http://enterpriseforever.com/userpix/12_functest1_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_functest1_1.png)
(http://enterpriseforever.com/userpix/12_functest2_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_functest2_1.png)
(http://enterpriseforever.com/userpix/12_functest3_1.png.thumb.jpg) (http://enterpriseforever.com/userpix/12_functest3_1.png)
Itt a "kiherélt" ROM fájl EP32-höz, ha netán valaki a hangra is kiváncsi :-)
Indítás után egy meleg resetet kell nyomni úgy indul a program.
-
Na az már kiderült, hogy a printer porttal szórakozik egy csomót, egyelõre még számámra ismeretlen célból :-)
.
.
.
Indítás után egy meleg resetet kell nyomni úgy indul a program.
grat :) érdekes dolgok kerülnek elõ :)
-
Itt a 3.5-ös disassemblálva, lehet elmélkedni, hogy vajon mit is csinál :-)
A printerport matatással kapcsolatban ilyen ötleteim vannak:
-tényleg nyomtatni akar valamit, bár igazából adat kiküldést nem igen látok, csak Strobe/Ready jelekkel szórakozást
-"hardverkulcs" kell a program futattásához, elsõ ránézésre ha két lábat összekötünk a printer csatlakozóban akkor menni fog a program, legalábbis az elsõ ellenõrzésen átjut :-)
-netán a vizsgálandó cuccokat kell valahogy odadrótozni?
-
Senki nem elmélkedett a problémán? :-(
Addig is nézzünk egy kicsit mást, az EXOS saját teszt rutinjait.
Van bennük egy csúnya hiba:
Elsõnek a 255-ös szegmenst (rendszerszegmenst) ellenõrzi, mely a P1-re van belapozva. Az ellenõrzés alatt szükséges verem a még ellenõrizetlen 254. szeqmensen van, melyet a P2-re lapoz be. Az ellenõrzés nem látszik, mivel a VIDEO eszköz nincs még inicializálva.
* C066 3EFE LD A,0FEh 254. szegmens
C068 D3B2 OUT (0B2h),A P2-re belapozása
C06A AF XOR A A=0 Szín kódja (fekete)
C06B D381 OUT (081h),A Keretszín (BORDER) beállítása feketére
C06D CDFEC1 CALL 0C1FEh P1-en lévo RAM ellenõrzése és 0-val feltöltése
C070 203D JR NZ,0C0AFh Ha hibás a RAM => keretszín villogtatása
Ez a csúnya hiba az, hogy ellenõrízetlen RAM terület van használva! Az itt látható CALL hívás, és a meghívott rutinban szereplõ további CALL hívások használják a vermet, ami az ellenõrízetlen területen van.
Ez a módszer mûködhet, ha csak itt-ott van pár bit hiba a memóriában, ekkor tényleg eljut a hibajelzõ keretvillogtatáshoz.
Viszont ha 1 vagy több memória IC teljesen halott, akkor végig minden bájt hibás lesz az alap 64K RAM-ban. És ezért az ellenõrízetlen verembõl hibás címre tér vissza, vagyis elszáll az egész, és nem jut el a hibát jelzõ keretszín villogtatáshoz!
Így nincs esélyünk megtudni, hogy mi is a hiba... lehet találgatni, hogy Nick, Dave, Z80, ROM, RAM, stb...
Van is egy ilyen gépem :-( meg most hozott egyet Spidermans Friend is.
Az EXOS rutinjából az hiányzik, (az EXOS 2.4-be bele is fogom tenni :-) ), hogy legalább azt a pár bájtot, ami a veremhez kell, külön le kell ellenõrizni, olyan rutinnal, ami nem használ vermet. Ha hiba egybõl ugrás a hibajelzés rutinhoz.
-
A hibakijelzéssel is vannak fenntartásaim...
Vajon egy LPT tábla nélkül futó, teljesen inicializálatlan Nick chip esetén látszik bármi is a a keretvillogtatásból?
Arról nem is beszélve, ha netán rossz a Nick :-(
Arra gondoltam, hogy a PC-n ismert módszer szerint hanggal is kéne jelezni hiba esetén.
Próbából alkottam egy ilyet:
OBJECT TESZT.ROM
ORG 0
DI
LD A,4
OUT (191),A
LD A,1FH
OUT (0A7H),A
VEGTELEN LD DE,200H
LD B,63
CIKLUS LD A,B
OUT (0A8H),A
OUT (0ACH),A
LD B,0
CIKLUS2 DJNZ CIKLUS2
XOR 63
LD B,A
DEC DE
LD A,D
OR E
JR NZ,CIKLUS
LD DE,300H
LD B,63
CIKLUS3 LD A,B
OUT (0A8H),A
OUT (0ACH),A
LD B,128
CIKLUS4 DJNZ CIKLUS4
XOR 63
LD B,A
DEC DE
LD A,D
OR E
JR NZ,CIKLUS3
JP VEGTELEN
DF 16384-$,255
END
Ez szírénázó hangot produkál végtelen ciklusban :-)
Beégettem EPROM-ba és kipróbáltam mindkét lentebb említett hibás gépben (az EXOS helyére behelyezve):
Mindkettõben megszünt a se kép se hang effekt, azaz hang már van :-)
Ezekszerint a proci megy, és a DAVE se lehet túl beteg hiszen hang van :-) No meg az állítja elõ a Z80 órajelét, a ROM engedélyezõ jelét is.
Most majd egy olyat próbálok írni ami megvizsgálja az alap 64K RAM-ot, és az eredményt "elfütyüli".
Szerencsés esetben kiderül, hogy RAM hiba :-)
Peches esetben marad a Nick hiba :-(
Valahol korábban írta valaki, hogy neki volt anno Nick hibája, és akkor elindult a gép, hallotta a billentyû hangot, csak kép nem volt... ezért reménykedek még egy kicsit ezen gépek kapcsán, mivel ezek nem jutnak el ide. Viszont egy hibás RAM IC a lentebb leírt EXOS hibával produkálhat ilyet, hogy az elsõ pár utasítás után fagyi...
-
Ez szírénázó hangot produkál végtelen ciklusban :-)
Beégettem EPROM-ba és kipróbáltam mindkét lentebb említett hibás gépben (az EXOS helyére behelyezve):
Mindkettõben megszünt a se kép se hang effekt, azaz hang már van :-)
Ezekszerint a proci megy, és a DAVE se lehet túl beteg hiszen hang van :-) No meg az állítja elõ a Z80 órajelét, a ROM engedélyezõ jelét is.
Most majd egy olyat próbálok írni ami megvizsgálja az alap 64K RAM-ot, és az eredményt "elfütyüli".
Szerencsés esetben kiderül, hogy RAM hiba :-)
Ez nekem nagyon tetszik! :-) Tiszta "krimi", hogy a fekete képernyõ "mögött" vajon mennyire él egy Ep, és hanggal kommunikálsz vele a kép helyett... :-)
Tök poén! :smt023
-
Nekem is tetszik:) A süllyedõ Titanic S.O.S. jelt ad:)
-
Helyzet jelentés a Titanicról :-)
Elkészült az elsõ primitív teszt.
Azt csinálja, hogy sorba megy végig az FFH szegmens bájtjain, sorban 00H,FFh,55H,AAH értékeket beírva. Minden beírás után kiolvassa az adott bájtot, és az olvasott értéket elfütyüli: sorban b0,b1,stb magas hang az 1-es mély hang a 0-ás. Bitek között kis szünet, bájtok között nagyobb.
Normál esetben 11111111 00000000 10101010 01010101 sorozatnak kell ismétlõdnie.
Ime ez a remek program :-)
Assembly programozók figyelmébe ajánlom: hogyan kell "CALL"-t megvalósítani, ha nem használhatunk vermet, mert nincs RAM-unk.
Mellékelem a lefordított ROM fájlt is, EP32 alatt ki lehet próbálni (Az EXOS ROM helyére kell berakni a config fájlba.)
OBJECT TESZT.ROM
HIVAS MACRO @CIM
LD HL,$+6
JP @CIM
ENDM
BITHANG MACRO
SRL A
LD HL,$+9
JP C,MAGAS
JP MELY
HIVAS SZUNET
ENDM
ORG 0
DI
LD A,4
OUT (191),A
LD C,81H
EXX
LD A,1FH
OUT (0A7H),A
LD A,255
OUT (0B1H),A
DEC A
OUT (0B2H),A
DEC A
OUT (0B3H),A
LD IX,4000H
TESZTELES LD (IX),0
LD A,(IX)
LD B,8
BITTESZT1 BITHANG
DJNZ BITTESZT1
HIVAS SZUNET
HIVAS SZUNET
HIVAS SZUNET
LD (IX),255
LD A,(IX)
LD B,8
BITTESZT2 BITHANG
DJNZ BITTESZT2
HIVAS SZUNET
HIVAS SZUNET
HIVAS SZUNET
LD (IX),55H
LD A,(IX)
LD B,8
BITTESZT3 BITHANG
DJNZ BITTESZT3
HIVAS SZUNET
HIVAS SZUNET
HIVAS SZUNET
LD (IX),0AAH
LD A,(IX)
LD B,8
BITTESZT4 BITHANG
DJNZ BITTESZT4
HIVAS SZUNET
HIVAS SZUNET
HIVAS SZUNET
INC IX
LD A,XH
OR XL
JP NZ,TESZTELES
VEGTELEN HIVAS MAGAS
HIVAS MELY
JP VEGTELEN
MELY: EXX
EX AF,AF'
LD DE,100H
LD B,63
CIKLUS LD A,B
OUT (0A8H),A
OUT (0ACH),A
LD B,0
CIKLUS2 OUT (C),B
DJNZ CIKLUS2
XOR 63
LD B,A
DEC DE
LD A,D
OR E
JR NZ,CIKLUS
EXX
EX AF,AF'
JP (HL)
MAGAS
EXX
EX AF,AF'
LD DE,180H
LD B,63
CIKLUS3 LD A,B
OUT (0A8H),A
OUT (0ACH),A
LD B,128
CIKLUS4 OUT (C),B
DJNZ CIKLUS4
XOR 63
LD B,A
DEC DE
LD A,D
OR E
JR NZ,CIKLUS3
EXX
EX AF,AF'
JP (HL)
SZUNET:
EXX
EX AF,AF'
LD DE,100H
LD B,63
CIKLUS5 LD A,B
IN A,(0A8H)
IN A,(0ACH)
LD B,0
CIKLUS6 OUT (C),A
DJNZ CIKLUS6
XOR 63
LD B,A
DEC DE
LD A,D
OR E
JR NZ,CIKLUS5
EXX
EX AF,AF'
JP (HL)
DF 16384-$,255
END
-
A hibakijelzéssel is vannak fenntartásaim...
Vajon egy LPT tábla nélkül futó, teljesen inicializálatlan Nick chip esetén látszik bármi is a a keretvillogtatásból?
Most akkor kipróbáltam ezt is, mint látható raktam némi keretvilogtatást is a hang rutinokba.
EP32-n szépen látszik, de mint az EXOS 2.0 bug kapcsán írtam, ez hiba, mert inicializálja a NICK-et induláskor, míg a valódi a bekapcsoláskor véletlenszerüen beállítodott regiszterértékek alapján indul el, nem sok értelmes képet generálva...
Ebbõl adódik az a válasz, amit már sejtettem: inicializálatlan Nick esetén szinte semmi nem látszik a keretvillogtatásból. Néha ha szerencsénk van, akkor olyan értékekkel indul el, amivel kicsit több látszik. Az egy jó kérdés, hogy rá lehet venni a Nicket, hogy LPT nélkül csak keretszínt rakjon ki?
És akkor az "SOS jelzések":
Spidermansék gépén állandó 11001111 ismétlõdik, bár egy idõ után kicsit cifrázza, de nem hasonlít az elvárt jó bitsorozatra.
Az én rossz gépemen pedig minden cifrázás nélkül 11111111111111111111111111111111111111111111111111111111111111111111111111111111...
Mint látható mind két gépen erõsen halott az alaplapi RAM, így nem csoda, hogy a korábban leírt EXOS hiba alapján minden életjel nélküli fagyi volt...
-
Ez a call rutin nagyon tetszik, beletelt pár percembe, mire leesett a mûködési elv :oops: :shock: , a macro egy kicsit bezavart.
-
És akkor az "SOS jelzések":
Spidermansék gépén állandó 11001111 ismétlõdik, bár egy idõ után kicsit cifrázza, de nem hasonlít az elvárt jó bitsorozatra.
Az én rossz gépemen pedig minden cifrázás nélkül 11111111111111111111111111111111111111111111111111111111111111111111111111111111...
Mint látható mind két gépen erõsen halott az alaplapi RAM, így nem csoda, hogy a korábban leírt EXOS hiba alapján minden életjel nélküli fagyi volt...
De legalább kiderült, hogy egy esetleges RAM cserével életre kelthetõek ezek a gépek... :-)
Ügyi vagy, már tegnap is tetszett a módszer lényege... :-)
-
De legalább kiderült, hogy egy esetleges RAM cserével életre kelthetõek ezek a gépek... :-)
Ez még nem bíztos, az ennyire konstans értékekhez 8 db halott RAM IC kéne ami nem túl valószínû...
Inkább az a valószínû, hogy a RAM vezérlése körül van valami hiba. Ebben szerepet játszanak az U4,5,6,7,8,9,37 jelû IC-k.
Az U4 a Nick...
A többi sima 74LS, az nem gond.
Mindenesetre már van egy támpont, hogy hol kell méricskélni.
-
Ez a call rutin nagyon tetszik
Akkor már volt értelme felraknom :-)
-
Az U4 a Nick...
Ami miatt egy picit reménykedek: amikor éppen sikerült úgy indítani a gépet, hogy voltak keretszínt tartalmazó részek is a képen, akkor mindkettõn látszik a keretcsikozás. Vagyis valami mocorgást már a Nickbõl is sikerült kicsalni.
-
Szupi! (Így hívják az EP-met, valami sci-fi könyvbõl vettem az elnevezést még anno. Anyu rá is írta a gépre a nevét öntapadós betûkkel.:) )
Szóvel egy fél lépéssel közelebb vagyunk a magoldáshoz:)
Én sem értem a hívás mûködését, pl. honna tudja a visszatérési címet, meg ilyesmi. De úgy általában is érdekelne a Z80 gépi kód, azon belül az EP programozás. PC-n már assemblyztem, utoljára kb. 10 éve... Ha valakinek van türelme válaszolgatni, az Assembly topikban alkalomadtán kérdezgetnék, vagy ajánlhatnátok valami okítóanyagot.
-
Szóvel egy fél lépéssel közelebb vagyunk a megoldáshoz:)
Mint kiderült a te gépedben is a Z80 volt a hibás!