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>Nemate nahodou  tak trochu hokej v tom, ze jeden vypravite o prenosu 
instrukce z pameti do CPU a druhy o cteni portu do CPU?
:) :)

Jarda

20. březen 2012 17:12:30, Michal Hučík (sharpemu@pandora.cz) napsal:
<span class="replyquote1">&gt;
&gt;
&gt; Netusim jak to je na jinych platformach, nicmene v MZ800 to tak skutecne je.
<img src="BODY_IMAGES_WRAP_GIF"> Poslednim bajtem na datove sbernici je myslen posledni instrukcni bajt.
&gt;
&gt; Tedy:
&gt;
&gt; IN A,(#44) == 0xdb, 0x44 == pokud neni obsazen, tak prectes 0x44
&gt;
&gt; LD C,#44
&gt; IN A,(C) == 0xed, 0x78 == pokud neni obsazen, tak prectes 0x78
&gt;
&gt; Tedy 0xff neprectes na neobsazenem portu nikdy ;)
&gt;
&gt;
&gt;
&gt; Dne 20.3.2012 16:48, VELESOFT (SPRINTER) (sharpemu@pandora.cz) napsal(a):
</span><span class="replyquote2">&gt;&gt;
&gt;&gt;
&gt;&gt; ----- Original Message ----- From: &quot;Michal Hučík (sharpemu@pandora.cz)&quot;
<img src="BODY_IMAGES_WRAP_GIF">&lt;ordoz@[doména skryta]&gt;
&gt;&gt; To: &quot;Konference &quot;Počítač SHARP MZ-800 a emulátory&quot;&quot;
<img src="BODY_IMAGES_WRAP_GIF">&lt;sharpemu@pandora.cz&gt;
&gt;&gt; Sent: Tuesday, March 20, 2012 10:40 AM
&gt;&gt; Subject: Re: RRD - detekce flash
&gt;&gt;
&gt;&gt;
</span><span class="replyquote3">&gt;&gt;&gt;
&gt;&gt;&gt;
&gt;&gt;&gt; Ahoj Martine,
&gt;&gt;&gt;
&gt;&gt;&gt; zda na nejakem portu visi nejake zarizeni, ktere umi vracet staticka data se
<img src="BODY_IMAGES_WRAP_GIF">pozna celkem jednoduse. instrukce IN na neobsazeny port totiz vraci vzdy stejnou
<img src="BODY_IMAGES_WRAP_GIF">hodnotu, jakou mel posledni byte na datove sbernici - v tomto pripade tedy
<img src="BODY_IMAGES_WRAP_GIF">posledni bajt instrukce IN. Test tedy muze postupne zkusit ruzne variace IN
<img src="BODY_IMAGES_WRAP_GIF">registr,(cislo) a IN registr,(C). Pokud tam je ROM disk, tak prectes pokazde
<img src="BODY_IMAGES_WRAP_GIF">stejnou hodnotu. Pokud tam neni nic, tak prectes hodnotu odpovidajici poslednimu
<img src="BODY_IMAGES_WRAP_GIF">bajtu instrukce IN.
&gt;&gt;&gt;
&gt;&gt;&gt; Michal
&gt;&gt;&gt;
</span><span class="replyquote2">&gt;&gt; No ja teda logicky predpokladam, ze pokud procesor cte neobsazeny port, mel
<img src="BODY_IMAGES_WRAP_GIF">by nacist hodnotu #FF, ktera by mela byt zajistena disky internim pull-up
<img src="BODY_IMAGES_WRAP_GIF">odporum. Nemam shema Sharpa po ruce, ale pevne verim tomu, ze tam odpory budou. 
<img src="BODY_IMAGES_WRAP_GIF">Takze bych odpovedel asi takhle:
&gt;&gt; Pri cteni jakehokoli neobsazeneho portu procesor vzdy nacte hodnotu 255
<img src="BODY_IMAGES_WRAP_GIF">(#FF).
&gt;&gt;
&gt;&gt; Ale co bylo mysleno tim poslednim bajtem na datove sbernici ? Bajty se po
<img src="BODY_IMAGES_WRAP_GIF">datove sbernici prenaseni smerem k nebo od CPU, ale pokud zadne zarizeni
<img src="BODY_IMAGES_WRAP_GIF">konkretni port nepouziva, zadna data na sbernici ani neposila a procesor cte jen
<img src="BODY_IMAGES_WRAP_GIF">stav, ktery by mel byt diky odporum prave 255.
&gt;&gt;
&gt;&gt; To znamena nacitat opakovane za sebou mnohokrat furt stejny port a sledovat, 
<img src="BODY_IMAGES_WRAP_GIF">jestli vraci stabilne 255. Pokud ano, s nejvetsi pravdepodobnosti port neni
<img src="BODY_IMAGES_WRAP_GIF">obsazeny (alespon pro cteni je neobsazeny).
&gt;&gt;
&gt;&gt; VELESOFT
&gt;&gt;
&gt;&gt; ---
</span><span class="replyquote1">&gt;
&gt;
&gt; ---
&gt;
</pre>