[SharpMZ] Adolf z Interkarate+
Ahoj,
nedavno jsem do SVN poslal upravu emulatoru ve ktere se uz otrocky nevykonava kazdy takt 1M1 hodin (zdroj pro CTC0). Kratce na to mi Jirka Cervinka reportoval, ze mu s touto upravou obcas nefunguje nahravani vicedilne verze Interkarate+.
Poprve jsem se tedy pustil do analyzy tohoto loaderu, hrabal jste
se v nem uz nekdy nekdo? Hned na jeho zacatku mam pocit, ze jeho
fungovani je zalozeno na hazardnim vztahu. Pro zajimavost to
posilam sem:
1. Start programu je na 0x14f3, nasleduje pomerne kratky kod ve kterem si na adrese 0038 pripravime rutinu interruptu:
0x0038:
ld b,xx (xx na adrese 0x0039 se bude prepisovat na 0x83)
djnz -2
ei
reti
2. Prijde interrupt, na 0x0038 si odkroutime ty DJNZ, pak do regR ulozime obsah regA a zpet precteme do regA - vykonaly se 2 optokody, takze regA se tim zvednul na hodnotu 0x85.
3. Nasleduje prvni kratky decryptovaci blok, ktery provadi XOR (HL). Vzdy pred XOR se do regA nacte obsah z regR. Decryptuje se od 0x1534 do 0x1561.
4. Jsme na adrese 0x1534, kde se nachazi jiz dekryptovany kod. Prvni instrukci je HALT. Tedy cekame na prichod nasledujiciho VBLN interruptu od PIOZ80. Ve chvili, kdy jsme vstoupili na 0x1534 byla hodnota regR = 0x98. S kazdym vykonanym HALT se nam regR zvysi o 1. Po prichodu interruptu si odskocime opet na 0x0038.
5. Po navratu z interruptu jsme na adrese 0x1535 a hodnota regR je 0xb7, nebo 0xb6 - coz je ten hazard o kterem jsem psal v uvodu. Myslim si, ze duvodem toho rozdilu je ten fakt, ze i kdyz mezi jednotlivymi VBLN je konstantni pocet taktu, tak diky tomu, ze nelze vyvolat interrupt uprostred instrukce, tak se obcas muze stat, ze se pocet vykonanych optokodu o jeden lisi.
6. Skocime na 0x1558. nastavime regHL=0x15b6.
7. Na adrese 0x155b: regA = regR, zapiseme jej do (HL=0x15b6) a snizime HL. V nekonecne smycce skaceme z 0x155f: JR 0xfa zpet na 0x155b a se zapisem po jednom bajtu postupujeme az k neodvratnemu prepisu adresy 0x1560, cimz se zmeni parametr toho JR.
8a. V pripade, ze jsme v bode 6 meli v regR hodnotu 0xb7, tak na 0x1560 zapiseme 0xe9, coz znamena 0x155f: JR 0x154a. Tam je LDIR, ktery 0x0300 bajtu z 0x1200 nakopiruje do 0x0000. Program zije.
8b. V pripade, ze jsme v bode 6 meli v regR hodnotu 0xb6, tak na 0x1560 zapiseme 0xe9, coz znamena 0x155f: JR 0x1549. Tam je RST 0x00. Za "normalnich" okolnosti, kdy je pocitac ciste nastartovan a ma implicitni obsah RAM, tak se zde nachazi 0x0000: RST 0x38.
Prozatim se mi moc nechtelo dal zkoumat, co se deje dal za bodem 8b. Je zrejme, ze nez k necemu takovemu dojde, tak program nemanipuluje se zasobnikem (tedy nevyuziva vedome moznosti projit pres RETI a zbrchat se) a ani nenastavuje zadny vlastni obsah na adrese 0x0000.
V pripade, ze jsem uz jednou Interkarate loader nacetl spravne a dam reset. Pak znova nahraju zavadec Interkarate, tak je obsah na adrese 0x0000 natolik destruktivni, ze je program vetsinou uiplne v haji.
V pripade, ze program projde pres RETI, tak se zda, ze nejakou nahodou, ktera mozna sekundarne trochu souvisi s nejakou operaci s CTC dojde ke zbrchani vykolejeneho zavadece a program nacte s drobnymi deformacemi screen, ktery nasleduje v dalsim CMT bloku.
Zkusim to jeste dale zkoumat, protoze je taky dost mozne, ze ten hazardni stav nastava jen v emulatoru a pak by bylo potreba pustit se znova do pruzkumu spravneho chovani obvodu PIOZ80 :(
Michal