Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<pre> 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@[doména skryta] 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@mail.ordoz.com > http://mail.ordoz.com/mailman/listinfo/sharpmz > > _______________________________________________ > SharpMZ mailing list > SharpMZ@mail.ordoz.com > http://mail.ordoz.com/mailman/listinfo/sharpmz > </pre>