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

Od: Anonym
Datum: 28.5.2003 12:40
Předmět: RE: Snad poslední návrh 16ti bitového I DE + shrnutí


Pripájam sa k Zdenkovmu názoru, posledná varianta je rozumná (súdim z
 uhla
vyštudovaného hardvéristu). Už aby bol prvý prototyp. Ešte tak na dosku
dostať PCMCIA konektor - s PCMCIA alebo CF diskom spravovateľným aj na PC
úplná nádhera (prihováram sa za PCMCIA, tak sa dajú za malé peniaze
pripojiť
všetky typy Flash kariet, CF redukcie sú dosť drahé a nedostupné). Podľa
Tomášovho článku na Zdenkových stránkach by to až taký problém nemal
byť. Čo
Ty na to, Peter?
Roman.

> -----Original Message-----
> From:	Zdenek Adler (sharpemu tu byla ta zakroucena vec pandora.cz) [SMTP:zdeneka tu byla ta zakroucena vec seznam.cz]
> Sent:	28. mája 2003 10:52
> To:	Konference "Počítač SHARP MZ-800 a emulátory"
> Subject:	Re: Snad poslední návrh 16ti bitového IDE + shrnutí
> 
> Jak to pročítám, tak zavrhuji variantu 1 :-))) (ikdyž sám mám
postavený
> řadič s 74138) a téměř jednoznačně hlasuji pro variantu poslední s
LS245,
> 27xxx a LS646 (543) - budu rád kdybychom se zaměřili spíše na moderní
> součástkovou základnu která je běžně k dostání ať již v takových
kšeftech
> jako je GM, GES apod. nebo i od různých firem na dobírku - krom toho
> myslím, že tyto obvody nejsou nijak drahé (celkem to odhaduji na max. 200
> Kč).
>  
> Zdenek
> 
> 	----- Original Message ----- 
> 	From: Petr Žydek (sharpemu tu byla ta zakroucena vec pandora.cz) <mailto:sharpemu tu byla ta zakroucena vec pandora.cz)>
> 
> 	To: Konference Počítač SHARP MZ-800 a emulátory
> <mailto:sharpemu tu byla ta zakroucena vec pandora.cz> 
> 	Sent: Wednesday, May 28, 2003 10:04 AM
> 	Subject: Snad poslední návrh 16ti bitového IDE + shrnutí
> 
> 
> 
> 	Než jsem stačil dotvořit schéma s novou
> 	variantou řadiče, byl tu další námět...
> 
> 	Cíl: aby můj "OTI(R)able" řadič uměl nikoliv
> 	princip "nabufferovat 256 bajtů určených pro
> 	odesílání přes data HI s následným odbavením
> 	při odesílání 256ti bajtů na data LO", nýbrž
> 	princip "0. bajt do bufferu; 1.bajt do data
> 	LO a zároveň buffer do data HI; 2. bajt do
> 	bufferu; 3. bajt do data LO a zároveň buffer
> 	do data HI......
> 
> 	Heuréka! Ono vlastně vyhovuje zapojení s LS245
> 	a statickou pamětí 6116!!! Neprve tedy popis
> 	řadiče 2x 256 bajtů nestřídaných:
> 	Místo obvodů LS541 a LS573 (LS574) jsem použil
> 	obousměrný třístavový zesilovač LS245 a paměť
> 	6116 2Kx8 (je na starých kartách MDA/Hercules,
> 	vadí-li rozměry pouzdra DIP24-WIDE, existuje
> 	varianta SMD, resp. paměť Winbond 2465
> 	DIP28-úzká 8Kx8 z cache aplikací pro PC desky),
> 	dostupnost paměti(í) je velká (viz výše),
> 	nadbytečné adresové vodiče >A7 se musí připojit
> 	na LOW.
> 
> 	Příklad zápisu:
> 	do B nulu (256 bajtů přenést), do HL adresu
> 	dat v paměti, do C 77h (adresa bufferu-statické
> 	paměti), první OTIR, do C 78h, druhý OTIR.
> 	To je to, co mi vytýkáte-posloupnost dat
> 	z paměti a sektor na HDD není totéž, pokud ho
> 	procházíme bajt po bajtu. Pro zpětné čtení to
> 	nevadí (obdobný princip). Jde jen o ztíženou
> 	spolupráci při dvou discích, SharpWritten+PC disk.
> 	To je programátorská práce navíc, uznávám.
> 
> 	Teď popis fukce HW (zápis):
> 	Při OUT 77h se otvírá "menší" LS245 (ve schematu)
> 	ve směru Sharp->IDE, D8-D15 HDD je ve stavu HI-Z
> 	(data tam neprojdou, nekolidují) a paměť 6116
> 	se otevře pro zápis 256ti bajtů, adresu do
> 	6116ky dodává registr B na A8-A15 (automaticky
> 	se mění během vykonávání OTIRu, i když
> 	s podivným pořadím 00h, FFh, FEh ... 01h).
> 	Při OUT 78h je "menší" LS245 uzavřen a data na
> 	D8-D15 HDD dodává 6116ka otevřená pro čtení,
> 	její adresu dodává opět reg. B na A8-A15.
> 
> 	Čtení je obdobné, nejprve při I/Oad. 78h vstoupí
> 	prvním INIRem dolní 256tice bajtů dat a zároveň
> 	jde horní 256tice do 6116, odtud se odbaví 
> 	druhým INIRem s I/O adr. 77h
> 	Komplikované, ale obvodově nenáročné a umí INIR,
> 	OTIR.
> 
> 
> 	Celé toto zapojení stačí lehce modifikovat,
> 	abychom dosáhli efektu "střídání bajtů".
> 	Ať odesíláme dva bajty (jedna 16tice) nebo
> 	512bajtů-celý sektor (256 16tic), vždy jde o
> 	sudý počet! Pak ovšem můžeme A8 Sharpa přidat
> 	mezi adresní vstupy na Eprom-dekodéru a je
> 	hotovo.
> 	Přiklad:
> 	Do B 02h, do C 78h, do HL adresu dat v paměti,
> 	OUTI.
> 	Hodnota B je sudá --> selekční výstupy z Eprom
> 	uvedou /SELP do HIGH (deselekt HDD a D0-D15 ve
> 	stavu HI-Z, jakkoliv se jedná o OUT 78h!)
> 	menší LS245 se otevře a 6116ka přijme bajt
> 	z D0-D7.
> 	OUTI.
> 	První I/O instrukce zapsala do B 01h, lichá
> 	hodnota dovolí zapsat bajt na D0-D7 HDD, zároveň
> 	6116ka pošle zachycený bajt na D8-D15 HDD, menší
> 	LS245 je uzavřen.
> 	Po provedení druhé OUTI je B rovno nule a zápis
> 	končí.
> 	Pro 512 bajtů dat (odeslat 256 16tic) se naplní
> 	B 00h a následuje např. 2x OTIR.
> 	Sudost/lichost registru B sama indikuje povahu
> 	odesílaného bajtu, zda je určen k z! achycení pro
> 	následné odeslání na D8-D15 nebo je určen přímo
> 	na D0-D7.
> 	Vadí nám ovšem tanec na A0-A7 6116ky. V režimu
> 	"střídání bajtů" potřebujeme jen adresu 00h této
> 	paměti, řešit to lze kontaktním polem jumperů,
> 	které by odpojily A0-A7 paměti od A8-A15 Sharpa
> 	a stáhly by vstupní adresu na 00h.
> 	Je to sice humpolácké, ale šikovné aspoň na
> 	výrobu prototypu, než se rozhodne, která varianta
> 	řadiče uspěje.
> 	Proto předkládám poslední (snad) variantu:
> 	dvojice 6116ka+LS245 se dá nahradit obvodem
> 	LS646 (LS543)!!!!!!! Thank's to Jiří Roleček.
> 	Jedná se o obvod LS245, který má "na každém
> 	konci registr". Selekční vývody z Eprom-dekodéru
> 	se přivedou na ovládací vývody tohoto IC a máme
> 	to doma!!! Je to definitivní řešení???
> 
> 
> 	Raději si to sesumarizujeme:
> 
> 	1a) řadič Zdeněk Adler - s LS10
> 	   (+) jeden IC, láce, není nutná výroba desky
> 	   (-) neúplná I/O adresace, jen 8 bitový přenos
> 
> 	1b) řadič Marek Šmihla - s LS138
> 	   (+) jeden IC, láce, není nutná výroba desky
> 	   (+) úplná I/O adresace
> 	   (-) jen 8 bitový přenos
> 
> 	2) Žydkoidní řadič I. generace - s LS245, 27xxx,
> 	   LS541, LS573 (574)   
> 	   (+) relativně malý počet IC
> 	   (+) 8 i 16ti bitový přenos
> 	   (+) úplná adresace
> 	   (-) neumí repetiční I/O instrukce
> 	   (-) nižší rychlost přenosu
> 
> 	3) 2) Žydkoidní řadič II. generace - s 2x LS245,
> 	   27xxx, 6116 (W2465)
> 	   (+) relativně malý počet IC
> 	   (+) 8 i 16ti bitový přenos
> 	   (+) úplná adresace
> 	   (+) umí repetiční I/O instrukce
> 	   (+) rychlost srovnatelná s 8 bitovým přenosem
> 	   (-) špatný datový "slovosled"
> 
> 	4) 2) Žydkoidní řadič III. generace - s 2x LS245,
> 	      27xxx, 6116 (W2465)
> 	      používá 6116ku jako registr
> 	   (+) relativně malý počet IC
> 	   (+) 8 i 16ti bitový přenos
> 	   (+) úplná adresace
> 	   (+) umí repetiční I/O instrukce
> 	   (+) rychlost srovnatelná s 8 bitovým přenosem
> 	   (+) správný datový "slovosled"
> 	   (-) nutnost (možná) modifikovat Eprom oproti
> 	       variantě 3), degradace 6116ky na registr,
> 	       nutno použít pole jumperů na adrese
> 	       do 6116 (vhodné pro desku s režimy 3, 4
> 	       a výrobu prototypu, jinak humpolácké)
> 	       nebo musí být adresa do 6116ky trvale
> 	       na 00h (nelze kombinovat režim 3,4)
> 
> 	5) 2) Žydkoidní řadič IV. generace - s LS245,
> 	      27xxx, LS646 (543)
> 	   (+) relativně malý počet IC (3!!!)
> 	   (+) 8 i 16ti bitový přenos
> 	   (+) úplná adresace
> 	   (+) umí repetiční I/O instrukce
> 	   (+) rychlost srovnatelná s 8 bitovým přenosem
> 	   (+) správný datový "slovosled"
> 	   (+) 8 bitový přenos při lichém obsahu B
> 	       a použití IN/OUT (C),A
> 	   (-) neumí režim "2x přenos 256ky bajtů za sebou"
> 	       (to asi lidem vadit nebude), jen režim
> 	       "střídání"
> 	   (-) IC LS646 (543) nutno koupit, ve starých PC
> 	       komponentech nebývá (ve variantách 3,4 se
> 	       dají ze starých komponentů získat všechny
> 	       obvody)
> 	 &nb! sp; (-) nelze použít I/O instrukce s přímou adresou:
> 	       OUT (78h),A a IN A,(78h)
> 	       snad se dají oželet
> 
> 	Teď babo raď, co je nejvýhodnější...
> 
> 	Petr de Zviqov
> 	
> 
> 
> 
> 	-- 
> 	Máte problémy s mobilem? Zkuste poradnu na Mobil.cz!
> <http://mobil.cz/ad_campaign.html?client=poradna> 
> 
> 
> 	---
> 	Odchozí zpráva neobsahuje viry.
> 	Zkontrolováno antivirovým systémem AVG ( <http://www.grisoft.cz>).
> 	Verze: 6.0.483 / Virová báze: 279 - datum vydání: 19.5.2003
> 
> -- 
> Máte problémy s mobilem? Zkuste poradnu na Mobil.cz!
> <http://mobil.cz/ad_campaign.html?client=poradna> 

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