Konference: Počítač SHARP MZ-800 a emulátory

Od: Anonym
Datum: 26.5.2003 15:52
Předmět: Re: 2. service packec pro MZ-IDE 16bit


Ešte som zabudol: delička by sa resetovala automaticky pri zápise na command port (7Fh), tým zároveň odpadá potreba jej čítania (vid Roldov mail).
 
Marek.
----- 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!


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)]


[1999 (1)] [2000 (168)] [2001 (733)] [2002 (459)] [2003 (654)] [2004 (224)] [2005 (105)] [2006 (182)] [2007 (201)] [2008 (294)] [2009 (363)] [2010 (782)] [2011 (522)] [2012 (642)] [2013 (442)]