Konference: Počítač SHARP MZ-800 a emulátory
Od: | Anonym |
Datum: | 26.5.2003 18:38 |
Předmět: | Re: 2. service packec pro MZ-IDE 16bit |
Tak tu máme service packec č. 2.
K aktivitě mě inspirovala reakce Marka
Šmihly na zveřejněný návrh 16bitového
rozhraní HDD pro Sharpa. Sice jsem se
nepokoušel počítat, jak se liší doba
přenosu jednoho 512ti bajtového sektoru
přes běžné I/O instrukce se současnou
manipulací se všemi potřebnými registry
A, BC, HL oproti použití repetičních
instrukcí INIR, OTIR, ale přesto jsem zkusil
podumat nad jinou alternativou...
Co je třeba dodržet, docílit:
-potřebujeme 16ti bitový přenos dat, aby
byla využita celá kapacita HDD
-možnost přenosu dat z/na porty
repetičními I/O instrukcemi
-možnost použít funkci autodetekce
parametrů disku
-zařízení by mělo být kompatibilní
s původní 8bitovou verzí
-obvodové řešení musí být co možná
nejjednodušší, malý počet IC snižuje cenu,
šetří místo v případě vývoje kombo desek
-v případě manipulace se signálem disku
/sels se nabízí možnost obsluhy dvou
HDD, tedy princip master/slave jako u PC
-pokud by byla akceptována možnost provozu
dvou HDD, pak se jasně nabízí možnost
využití souborových systémů FAT(32), tím
nemyslím přímé začlenění do CP/M, slave
disk by sloužil jako přenosný element
Sharp <-> PC. Konverzi souborových
systémů a vlastních dat může provádět
aplikační program pod CP/M typu
file-manažer; stejně tak CP/Movsky
nahraný disk by byl čitelný pro
aplikační program v PC, ten by ho
přečetl celý raz dva
Jak to tedy vyřešit:
Tahhle nějak vypadá zápis 512ti bajtového
sektoru na MZ-IDE 8bit (odhaduju):
xxx ; nastav příslušné hodnoty
xxx ; do registru stopy,
xxx ; sektoru atd.
LD HL, "odkud" ; adresa dat v paměti
LD B,00h ; 256 bajtů dat
LD C,78h ; adresa datového portu HDD
OTIR*** ; přenese B bajtů na port
; 78h od adresy v HL
OTIR ; ještě jednou totéž
Doufám, že jsem se nespletl, už jsem si
dlouho v asm Z80 nehrál, je-li pravda, že
po instrukci *** B=00h, HL="odkud"+256 a C
se nemění, pak se vykoná přenos jako dvě
256tice I/O cyklů po sobě pomocí instrukcí
OTIR (???)
U PC bych si představil něco podobného, jen
registry jsou víceslovné (to je výraz!) a
datová sběrnice je 16ti bitová, takže se
přenese jedním "OTIRem" (dejme tomu) jediná
256tice najednou, protože je široká 16 bitů
a ne 8.
Pokud by měl na tomto místě fungovat nějaký
obvodový supervizor, který by datový tok
na port 78h střídavě přepínal tak, abychom
docílili připravenosti 16ti bitů dat každé
dva I/O zápisy a pak by se provedl jeden
vybavovací zápis do HDD, připomíná mi to
křižovatku se semafory kde se po každém
projetém autě mění volný směr jízdy.
Můj návrh zní: využít toho, že se v každém
případě přenáší 256 bajtů 2x po sobě, navíc
obsah registru B sám inkrementuje a posílá
se na A8-A15 adresové sběrnice Sharpa!!!
Obvodové řešení by vycházelo z mého
původního návrhu 16ti bitového rozhraní tj.:
1x 74LS245
1x 27xxx
1-2 další 74LS241, 245 (podle výsledku)
1x SRAM 6116 2kB
Příklad zápisu:
LD HL,"odkud" ; adresa dat v paměti
LD B,00h ; 256 bajtů dat
LD C,77h ; adresa pomocného bufferu
OTIR ; naplní se pomocný 256ti
; bajtový buffer (Statická RAM)
LD C,78h ; adresa datového portu HDD
OTIR ; přenos 256ti bajtů na
; D0-D7 HDD, synchronně a
; "skrytě" se také přenáší
; obsah bufferu na D8-D15 HDD
-čtení by probíhalo obdobným způsobem
-rutina s příkladem přenosu je o jedinou
instrukci delší
-je třeba vyřešit správnou návaznost a
kontinuitu dat (záležitost OS), neboť
u PC je při 16ti bitovém přenosu sled dat
následující (pokud se pletu, tak prosím
nenadávat):
0. bajt na D0-D7 ; 1. 16ti bitový zápis
1. bajt na D8-D15
2. bajt na D0-D7 ; 2. 16ti bitový zápis
3. bajt na D8-D15
.
.
.
.
511. bajt na D0-D7 ; 256. 16ti bitový zápis
512. bajt na D8=D15
a tady se posílá jedna 256ka dat, fik ho,
druhá 256ka, hotovo
-je-li toto velký problém, pak zůstává ve
hře původní verze 16ti bitového rozhraní,
jednodušší Hw řešení nedovedu vymyslet
V průběhu týdne možná opravím výkres a
upřesním význam portů a počet IC.
Petr de Zviqov 26.5. 2003 0:55hod
--
Máte problémy s mobilem? Zkuste poradnu na Mobil.cz!
Ostatní příspěvky vlákna:
[2003/1 (22)] [2003/2 (25)] [2003/3 (14)] [2003/4 (20)] [2003/5 (73)] [2003/6 (108)] [2003/7 (88)] [2003/8 (81)] [2003/9 (146)] [2003/10 (60)] [2003/11 (12)] [2003/12 (5)]