Přejít na obsah
ARCHIVEKArchiv e-mailových konferencí o 8bitových počítačích Archiv Pandory 1999 až 2013

Zpět na zprávu

Celé vlákno · 4 zprávy

Jaky je vyznam 4. bitu u WF a RF registru GDG?

Michal Hučík SHARP MZ-800

Zdravim,

pokousim se znova porozumet praci s grafikou v rezimech MZ-800 a narazil jsem na
 nejake nesrovnalosti. Jednou z nich je vyznam 4. bitu v RF a WF registrech
(porty 0xCD a 0xCC). Timto bitem by se melo nastavovat "Frame A/B" coz ma zrejme
vyznam jen tehdy, pokud je v Sharpu rozsirena VRAM a pokud je aktualne nastaveny
ctyr, nebo dvou barevny rezim, ktery bude pouzivat jen polovinu VRAM.

Video rezim nastavujeme dolnimi bity DMD registru:

0000 - MZ800 320x200/4(A - I., II. plane)
0001 - MZ800 320x200/4(B - III., IV. plane)
0010 - MZ800 320x200/16(AB - I., II., III., IV. plane)
0100 - MZ800 640x200/2(A - I. plane)
0101 - MZ800 640x200/2(B - III. plane)
0110 - MZ800 640x200/4(AB - I., III. plane)

Kazdy plane ma 8KB
A - je integrovana VRAM 16KB
B - je externi VRAM 16KB

WF registr (port 0xCC):

0. bit - plane I.
1. bit - plane II.
2. bit - plane III.
3. bit - plane IV.
4. bit - frame A/B 
5. - 7. bit - zapisovaci rezim

Nyni nastavim napr. DMD => "0100" (640x200/A), primapuju VRAM a v SINGLE WRITE
rezimu libovolne zapisuju do I. a III. plane, kam se to bez ohledu na stav 4.
bitu ulozi, coz si muzu overit zmenou zobrazovaciho rezimu na DMD => "0101"
(640x200/B). K cemu je tedy ten 4. bit dobry???

(Vyse uvedeny test jsem delal na skutecnem Sharpu - Zdenkuv emulator ma tady
zrejme bug a pri rezimu 640x200/B zobrazuje I. plane, ale mel by zobrazovat
III.)

Michal

Re: Jaky je vyznam 4. bitu u WF a RF registru GDG?

Michal Hučík SHARP MZ-800

Takze v rezimu 320x200/4 (A,nebo B) se Sharp pri hratkach s WF registrem 
chova take zajimave a uplne jinak, nez v emulatoru.
Nemam momentalne moc chut rozebirat pocitac a vyndavat z nej ExVRAM, ale 
v kontextu to zacinam chapat tak, ze pokud je v pocitaci zasunuta 
ExVRAM, tak se  se pouziva i v rezimech 320x200 (viz plna carka na radku 
100).
Nejsem si vedom toho, ze bych o podobnem zpusobu slozeni video pameti v 
Sharpu nekdy nekde cetl:

xor a
out (#ce), a      ; rezim 320/4 A
in a, (#e0)      ; namapujeme VRAM

; nastavime si prvni 4 palety barev
xor a
out (#f0), a
ld a,  #1c
out (#f0), a
ld a, #2a
out (#f0), a
ls a, #3f
out (#f0), a

; WF nastavime na jednoduchy zapis do I. A
ld a, #01
out (#cc), a

; na prvnim radku obrazovky nakreslime teckovanou carku
ld a, #aa
ld (#8000), a

; WF nastavime na jednoduchy zapis do I. B
ld a, #11
out (#cc), a

; na radku 100 nakreslime plnou carku
ld a, #ff
ld (#8000), a

di
halt

Navic pokud nastavime rezim 320x200/4 B, tak pokud chceme neco zapsat na 
spravne misto ve III. a IV. color plane, tak uz musime nastavit 4. bit 
na hodnotu "1" coz je IMHO tak jak by melo byt, ale je to uplne jine 
chovani, nez v rezimech 640x200.

Michal

Re: Jaky je vyznam 4. bitu u WF a RF registru GDG?

Michal Hučík SHARP MZ-800

:))) Tak tohle beru zpet !!! Takhle pitome se to bude chovat jen v 
debuggeru MRSu, protoze on zrejme pri vykonavani kodu prepina video 
rezimy :))) Dobra pasticka ... Asi dnes uz radeji pujdu nekam do prirody :)


Michal Hučík (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (10 řádků)
>
>
> Takze v rezimu 320x200/4 (A,nebo B) se Sharp pri hratkach s WF 
> registrem chova take zajimave a uplne jinak, nez v emulatoru.
> Nemam momentalne moc chut rozebirat pocitac a vyndavat z nej ExVRAM, 
> ale v kontextu to zacinam chapat tak, ze pokud je v pocitaci zasunuta 
> ExVRAM, tak se  se pouziva i v rezimech 320x200 (viz plna carka na 
> radku 100).
> Nejsem si vedom toho, ze bych o podobnem zpusobu slozeni video pameti 
> v Sharpu nekdy nekde cetl:

Re: Jaky je vyznam 4. bitu u WF a RF registru GDG?

Zdenek Adler SHARP MZ-800

Zdenkuv emulator a bug? :-) Takove veci se nesmi prede mnou rikat nahlas :-D 
Zrovna na spravne rozlozeni dat ve VRAM jsem se snazil pri psani emulace GDG 
dbat a porovnaval s realnym MZ-800 ta sama data zobrazena v ruznych 
rezimech. Nevylucuji ze se chyba vloudila, ale aspon programy ktere toho 
vyuzivaji (kupr. Lamacuv Foreign affair /viz. 
http://mz-800.xf.cz/kvalita.htm / ) mi funguji spravne. Bude-li mozne udelat 
testovaci MZF (nejlepe doplneny i screenshoty z obrazovky realneho Sharpa) 
prokazujici nespravne rozlozeni VRAM, zkusil bych se do toho ponorit a 
provest korekci.

Zdenek


Zobrazit citovaný text (52 řádků)
----- Original Message ----- 
From: "Michal Hučík (sharpemupandora.cz)" <pandora.idnes.cz[doména skryta]>
To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz>
Sent: Saturday, April 10, 2010 12:51 PM
Subject: Jaky je vyznam 4. bitu u WF a RF registru GDG?


>
> Zdravim,
>
> pokousim se znova porozumet praci s grafikou v rezimech MZ-800 a narazil 
> jsem na nejake nesrovnalosti. Jednou z nich je vyznam 4. bitu v RF a WF 
> registrech (porty 0xCD a 0xCC). Timto bitem by se melo nastavovat "Frame 
> A/B" coz ma zrejme vyznam jen tehdy, pokud je v Sharpu rozsirena VRAM a 
> pokud je aktualne nastaveny ctyr, nebo dvou barevny rezim, ktery bude 
> pouzivat jen polovinu VRAM.
>
> Video rezim nastavujeme dolnimi bity DMD registru:
>
> 0000 - MZ800 320x200/4(A - I., II. plane)
> 0001 - MZ800 320x200/4(B - III., IV. plane)
> 0010 - MZ800 320x200/16(AB - I., II., III., IV. plane)
> 0100 - MZ800 640x200/2(A - I. plane)
> 0101 - MZ800 640x200/2(B - III. plane)
> 0110 - MZ800 640x200/4(AB - I., III. plane)
>
> Kazdy plane ma 8KB
> A - je integrovana VRAM 16KB
> B - je externi VRAM 16KB
>
> WF registr (port 0xCC):
>
> 0. bit - plane I.
> 1. bit - plane II.
> 2. bit - plane III.
> 3. bit - plane IV.
> 4. bit - frame A/B
> 5. - 7. bit - zapisovaci rezim
>
> Nyni nastavim napr. DMD => "0100" (640x200/A), primapuju VRAM a v SINGLE 
> WRITE rezimu libovolne zapisuju do I. a III. plane, kam se to bez ohledu 
> na stav 4. bitu ulozi, coz si muzu overit zmenou zobrazovaciho rezimu na 
> DMD => "0101" (640x200/B). K cemu je tedy ten 4. bit dobry???
>
> (Vyse uvedeny test jsem delal na skutecnem Sharpu - Zdenkuv emulator ma 
> tady zrejme bug a pri rezimu 640x200/B zobrazuje I. plane, ale mel by 
> zobrazovat III.)
>
> Michal
>
> ---