Ahoj,
taky jsem pro takovéto řešení. Na ZX to implementovali přesně tímto
způsobem (trio DTP; (P)VL byl na NP) a nemají s tím sebemenší problém.
Čtení/zápis provádějí přes INI(R)/OTI(R) a nic jim neschází ;-) Jen
si
nejsem jistý, jestli jim vychází časování tak, aby sektor přečetli
párem
INIR instrukcí, ale myslím, že ano.
R.
P.S.: Navíc MCE už tento způsob čtení IDE podporuje, tak si ho, Marku,
můžeš otestovat ;-) .. (port-type=16bit-lohi)
|---------+--------------------------->
| | "smihla tu byla ta zakroucena vec ceit.sk |
| | (sharpemu |
| | 26.05.2003 17:38|
| | Odpovězte prosím|
| | uživateli |
| | "Konference |
| | "Počítač SHARP |
| | MZ-800 a |
| | emulátory"" |
| | |
|---------+--------------------------->
>-------------------------------------------------------------------------------
------------------------------------------------|
|
|
| Komu: "Konference "Počítač SHARP MZ-800 a emulátory""
<sharpemu tu byla ta zakroucena vec pandora.cz> |
| Kopie:
|
| Předmět: Re: 2. service packec pro MZ-IDE 16bit
|
|
|
|
|
>-------------------------------------------------------------------------------
------------------------------------------------|
Ahoj,
Mal som na mysli nasledovné:
Prvý OUT 78h: zápis D0..D7 do záchytného registra.
Druhý OUT 78h: obsah záchytného registra do HDD (D0..D7) plus D0..D7 do HDD
(D8..D15).
A tak dalej striedavo... Podobne pri vstupe:
Prvý IN 78h: D0..D7 z HDD do D0..D7 na MZ, D8..D15 z HDD do záchytného
registra.
Druhý IN 78h: čítanie D0..D7 zo záchytného registra.
Iný sled resp. náväznosť bajtov neprichádza do úvahy (kvôli rýchlosti
a
kompatibilite s PC).
V podstate ide o pridanie deličky jedna ku dvom na dekodér adresy 78h,
ktorá by striedavo prepínala medzi HDD a záchytným registrom. To nemôže
byť
predsa až tak zložité, v žiadnom prípade netreba GAL či dokonca 8052!
Marek.
P.S. pokiaľ ide o filesystém FAT, už sa na ňom pracuje... ;-)
----- Original Message -----
From: Petr Žydek (sharpemu tu byla ta zakroucena vec pandora.cz)
To: Konference Počítač SHARP MZ-800 a emulátory
Sent: Monday, May 26, 2003 10:33 AM
Subject: 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!
--
Máte problémy s mobilem? Zkuste poradnu na Mobil.cz!