Přejít na obsah
ARCHIVEKArchiv e-mailových konferencí o 8bitových počítačích Archiv Pandory 1999 až 2013

Re: RRD - detekce flash

Michal Hučík SHARP MZ-800

Netusim jak to je na jinych platformach, nicmene v MZ800 to tak skutecne 
je. Poslednim bajtem na datove sbernici je myslen posledni instrukcni bajt.

Tedy:

IN A,(#44) == 0xdb, 0x44 == pokud neni obsazen, tak prectes 0x44

LD C,#44
IN A,(C) == 0xed, 0x78 == pokud neni obsazen, tak prectes 0x78

Tedy 0xff neprectes na neobsazenem portu nikdy ;)



Dne 20.3.2012 16:48, VELESOFT (SPRINTER) (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (44 řádků)
>
>
> ----- Original Message ----- From: "Michal Hučík 
> (sharpemupandora.cz)" <ordoz[doména skryta]>
> To: "Konference "Počítač SHARP MZ-800 a emulátory""
 <sharpemupandora.cz>
> Sent: Tuesday, March 20, 2012 10:40 AM
> Subject: Re: RRD - detekce flash
>
>
>>
>>
>> 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
>>
> 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
>
> ---

Zobrazit původní podobu

Vlákno · 27 zpráv

Zobrazit celé vlákno na jedné stránce

  1. RRD - detekce flash Fuzzy
  2. Re: RRD - detekce flash VELESOFT (SPRINTER)
  3. Re: RRD - detekce flash Radek Suk
  4. Re: RRD - detekce flash Fuzzy
  5. Re: RRD - detekce flash Michal Hučík
  6. Re: RRD - prace s PEZIKem Michal Hučík Přílohy: 1
  7. Re: RRD - detekce flash Radek Suk
  8. Re: RRD - detekce flash Vaclav Peroutka
  9. Re: RRD - detekce flash Radek Suk
  10. Re: RRD - detekce flash Vaclav Peroutka
  11. Re: RRD - detekce flash Fuzzy
  12. Re: RRD - detekce flash Radek Suk
  13. Re: RRD - detekce flash Vaclav Peroutka
  14. Re: RRD - detekce flash Fuzzy Přílohy: 1
  15. Re: Re: RRD - detekce flash Michal Medek
  16. Re: RRD - detekce flash Michal Hučík
  17. Re: RRD - detekce flash VELESOFT (SPRINTER)
  18. Re: RRD - detekce flash Michal Hučík
  19. Re: RRD - detekce flash Jardax
  20. Re: RRD - detekce flash Michal Hučík
  21. Re: RRD - detekce flash Jardax
  22. Re: RRD - detekce flash Michal Hučík
  23. Re: RRD - detekce flash Radek Suk
  24. Re: RRD - detekce flash Zdenek Adler
  25. Re: RRD - detekce flash Michal Hučík
  26. Re: RRD - detekce flash Radek Suk
  27. Re: RRD - detekce flash Fuzzy