[SharpMZ] Adolf z Interkarate+

Michal Hucik - ORDOZ ordoz na ordoz.com
Čtvrtek Říjen 27 09:35:15 CEST 2016


Ahoj Zdenku,

tak jsem schvalne zkusil 3600 Bd a bez potizi se to nacte jak v te 
otrocke, tak i v te rychle verzi ... tedy samozrejme pokud pred tim 
nedojde k tomu zminenemu hazardu.

Nicmene - rika se, ze dobre polozena otazka je nekdy pro tazatele 
zaroven cestou odpovedi :) V tomto pripade spise jen castecne, ale uz 
asi vim, kde hledat. Zkusil jsem si nakompilovat otrockou - pomalou - 
verzi, ktera odpovida tomu co je vydano jako rev. 1.0.3. Zkusil jsem cca 
30x po sobe nahrat zavadec Interkarate+ a naprosto ve vsech pripadech 
jsem pri prhodu na adresu 0x1535 mel v regR hodnotu 0xb7 - program se 
vzdy nacetl spravne.

Nasledne jsem se pokusil o to same s tim, ze jsem si nakompiloval 
rychlou verzi CTC0 a zkousel jsem nahodnym nahravanim loaderu 
zreprodukovat na te adrese chybu s tou hodnotou 0xb6 ... Nekdy se mi ji 
povedlo dosahnout hned napoprve. Nekdy az na 12 pokus.

Je to tedy spise jen takova pocitova statistika, ale vse smeruje k tomu, 
ze i kdyz program na CTC0 nesaha, tak je jim ovlivnen - resp. je jim 
ovlivneno chovani emulovaneho PIOZ80. Pokud by sis nahodou vzpomnel, zda 
tve experimenty dospely ke stejne pricine zboreni programu - tedy 
promenliva delka trvani bloku, ktery ceka na Interrupt, tak jsme zrejme 
oba v te pocitane verzi CTC zapomneli na neco, co v otrocke variante CTC 
ovlivnuje chovani obvodu PyjusZ80.

Michal

Dne 26.10.2016 v 14:10 zdeneka na seznam.cz napsal(a):
> Michale,
>
> někdo už se v tom určitě hrabal  :-D Více méně jsem dospěl k tomu samému co
> Ty. Navzdory veškeré teorii mám ale pocit, že na skutečném železe to chodí
> naprosto spolehlivě :-) A co víc, oproti mému emulátoru ten loader přímo na
> Sharpovi zkousnul myslím i rychlost 3600 Bd.
>
> Zdeněk
>
>
>
> From: Michal Hucik - ORDOZ
> Sent: Wednesday, October 26, 2016 2:05 PM
> To: Počítače SHARP MZ a jejich emulátory
> Subject: [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
>
>
> Do regA ulozime 0x83. Tuto hodnotu zapiseme i na (0x0039). Nasledne se
> nastavi IM 1, v PIOZ80 se povoli interrupt od VBLN a v HALTu cekame na
> prichod interruptu.
>
> 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
>
>
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZ na mail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZ na mail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz
>



Další informace o konferenci SharpMZ