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é).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"></td><td align=right valign="middle"></td></tr></table><BR><pre> ----- Original Message ----- From: "Michal Hučík (sharpemu@pandora.cz)" <ordoz@[doména skryta]> To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemu@pandora.cz> Sent: Tuesday, March 20, 2012 10:40 AM Subject: Re: RRD - detekce flash <span class="replyquote1">> > > Ahoj Martine, > > zda na nejakem portu visi nejake zarizeni, ktere umi vracet staticka data se > pozna celkem jednoduse. instrukce IN na neobsazeny port totiz vraci vzdy > stejnou hodnotu, jakou mel posledni byte na datove sbernici - v tomto pripade > tedy posledni bajt instrukce IN. Test tedy muze postupne zkusit ruzne variace > IN registr,(cislo) a IN registr,(C). Pokud tam je ROM disk, tak prectes > pokazde stejnou hodnotu. Pokud tam neni nic, tak prectes hodnotu odpovidajici > poslednimu bajtu instrukce IN. > > Michal > </span>No ja teda logicky predpokladam, ze pokud procesor cte neobsazeny port, mel by nacist hodnotu #FF, ktera by mela byt zajistena disky internim pull-up odporum. Nemam shema Sharpa po ruce, ale pevne verim tomu, ze tam odpory budou. Takze bych odpovedel asi takhle: Pri cteni jakehokoli neobsazeneho portu procesor vzdy nacte hodnotu 255 (#FF). Ale co bylo mysleno tim poslednim bajtem na datove sbernici ? Bajty se po datove sbernici prenaseni smerem k nebo od CPU, ale pokud zadne zarizeni konkretni port nepouziva, zadna data na sbernici ani neposila a procesor cte jen stav, ktery by mel byt diky odporum prave 255. To znamena nacitat opakovane za sebou mnohokrat furt stejny port a sledovat, jestli vraci stabilne 255. Pokud ano, s nejvetsi pravdepodobnosti port neni obsazeny (alespon pro cteni je neobsazeny). VELESOFT </pre>