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

Od: Jiří Roleček
Datum: 27.4.2004 09:43
Předmět: Re: Detailní popis RD Müller 256KB

No je pravda, ze sloty na SIMM moduly jsem zkousel parat ze zakladni desky nejake 386, a slo to docela dobre. Parani primo pametovych cipu bych se trosku obaval ...

Rolda

Zdenek Adler (sharpemu tu byla ta zakroucena vec pandora.cz) wrote:

Jenom bych rád přihodil pár informací o tom, v jakých situacích může v MZ-800 dojít k "přibržďování" procesoru pomocí signálu /WAIT:
 
1. Zápis do VRAM v MZ-700 režimu během aktivního HBLN (tzn. v průběhu toho, co paprsek na obrazovce vykresluje 320 pixelů aktivní plochy obrazovky - ne border). Plyne z toho tedy, že v tomto případě může být WAIT generován až s frekvencí 15625 Hz a může trvat méně než 128 TStates procesoru (v 700 režimu trvá vykreslení 1 pixelu přesně 2,5T).
2. Čtení z VRAM v 800 modu - tady jsou už čekací doby minimální a myslím že se není čeho bát
3. Zápis do programovatelného zvukového generátoru (PSG)
4. WAIT signál od jiného zařízení připojeného do rozšiřujícího slotu (žádné takové neznám, snad jen jednoduché "zpomalovače" her které se dělaly s obvodem NE555)
 
To by bylo asi tak vše, kdyby byl zájem o další informace, tak je rád poskytnu. Ještě si dovolím jednu poznámku na Petra - myslíš, že se při konstrukci toho ramdisku můžeme vyhnout "párání" paměťových čipů ze SIMM modulů, nebo je to nezbytné? Myslel jsem že všechno potřebné máme i na SIMM modulu a ta parita která je tam navíc nás přeci nemusí rozptylovat...
 
Zdeněk
 
----- Original Message -----
From: Petr Žydek (sharpemu tu byla ta zakroucena vec pandora.cz)
To: Konference Počítač SHARP MZ-800 a emulátory
Sent: Tuesday, April 27, 2004 8:06 AM
Subject: Re: Re: Detailní popis RD Müller 256KB

Nejprve upřesnění:
podrobný popis "Müllera" je výklad činnosti
odzkoušeného a 100% funkčního zařízení, nikoliv
teoretizování nad schematem před stadiem výroby
prototypu. Teď jsem ho oprášil v souvislosti
se snahou o nějakou tu kombo desku (taky jde
o ty hochy programátorské, to maximum 16MB
je skvělá příležitost pro ty z nich, kteří
loni přišli s myšlenou multitaskingového
prostředí, ať už na bázi 8bitového Unixu
nebo dokonce grafického).
A něco z toho nového už skutečně chodí!!

Výpadek refreshe může nastat jen při dlouhém
aktivním signálu do CPU WAIT\' (řídí jej GDG)
nebo při aktivním požadavku BUSRQ\' (není
v Sharpu zapojeno). M1\' je živý i po instrukci
HALT, LDIR a jiné by neměly vadit, jednak se
mikroprogram takových instrukcí skládá ze
dvou běžných, navíc se všechny instrukce
s prefixem operačního znaku čtou ve dvou
cyklech M1\' (takže vlastně periodicita M1\' při
instrukci LDIR není každých 21 taktů CPU, ale
17).
LD SP, HL (20 taktů): nejdelší neprefixová
instrukce co jsem objevil, vyskytuje se řidčeji

S časováním si hlavu nelámu, ty přísné limity jsou
tu proto, aby byla dosažena deklarovaná doba
jednoho cyklu čtení/zápisu, já mám popis DRAM 4Mx4,
kde jsou tabulky se všemi možnými názvy intervalů,
ale zkoumal jsem spíš kresby časování. Co půjde,
půjde. Dvě paměti 1Mx4 vypreparované ze SIMMu a
připájené na "visutou redukci", vložené do soklů
místo dvou 64Kx4, chodí určitě (viz fota).
Nelze předpokládat, že by při refreshování držela
náhodou jen ta 64KB část z 1MB, kterou jsem
podrobil zahořovacímu testu.

Multiplex adres do hlavní RWM Sharpa řídí GDG,
jestli se o refresh dělí s CPU, toť otázka...

Petr de Zviqov

---
Jarmark.cz - nejlepší místo když chcete koupit nebo prodat

---
Jarmark.cz - nejlepší místo když chcete koupit nebo prodat

Ostatní příspěvky vlákna:

 
[2004/1 (1)] [2004/2 (1)] [2004/4 (33)] [2004/5 (34)] [2004/6 (12)] [2004/7 (1)] [2004/8 (12)] [2004/9 (31)] [2004/10 (52)] [2004/11 (43)] [2004/12 (4)]

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