06 — Mapování paměti a bank switching (porty E0H-E6H)

Základní informace

MZ-800 ma vic fyzické paměti než je 64KB adresový prostor Z80. GDG řídí mapování a prekryvani paměťových bloku pomoci portů E0H-E6H. Samotna operace IN/OUT na danem portů přepíná banky — hodnota v akumulatoru je irelevantni. Dulezita je jen adresa portů a směr operace (IN vs OUT).

Fyzická paměť

GDG řídící signály pro paměť

Klíčový princip: GDG neovlada přímo paměť — generuje chip-select a řídící signály. Na zaklade stavu vnitrnich flip-flopu (nastavenych porty E0-E6) GDG rozhoduje, který signál aktivuje při každém CPU přístupu do daneho adresoveho rozsahu.

Bank switching — porty E0H-E6H

Prehledova tabulka — OUT operace (MZ-800 režim)

Podle Service Manualu MZ-800, strana 7 (Memory Bank Control):

Poznámky: - — = dany rozsah se nemění (zachova předchozí stav) - zakaz = oblast je odpojeny — INH5 signál jde na H (viz sekce nize) - navrat = oblast se vrati do stavu před zakazem (před OUT E5H)

Prehledova tabulka — OUT operace (MZ-700 režim)

Prehledova tabulka — IN operace

Detailní popis každého portů

OUT E0H — RAM na dolni polovinu

Přepne oblasti 0000-0FFF a 1000-1FFF na systémový DRAM.

MZ-800: Oblast 0000-7FFF se přepne na DRAM. GDG prestane generovat /CROM pro ROM a místo toho aktivuje SEL1+CASB pro systémový RAM přístup.

MZ-700: Oblast 0000-CFFF se přepne na DRAM.

Typické použití: Nahrani monitoru do RAM pro modifikaci, nebo zpřístupnění celeho dolniho adresoveho prostoru jako RAM pro uživatelský program.

; Priklad: ROM monitor do RAM
LD HL, 0000H    ; zdrojova adresa (ROM)
LD DE, 2000H    ; docasny buffer
LD BC, 1000H    ; 4 KB
LDIR            ; zkopiruj ROM do RAM
OUT (E0H), A    ; 0000-0FFF = RAM (obsah je nedefinovany!)
LD HL, 2000H    ; zdrojova adresa (buffer)
LD DE, 0000H    ; cilova adresa (ted uz RAM)
LD BC, 1000H
LDIR            ; zkopiruj do RAM na 0000

OUT E1H — RAM na horní část

Přepne horní část adresoveho prostoru na systémový DRAM.

MZ-800: E000-FFFF → DRAM (místo Monitor ROM). MZ-700: D000-FFFF → DRAM (místo VRAM + KEY/TIMER + ROM).

Pozor: V MZ-700 režimu toto odpoji i VRAM a mapovane I/O (8255 na E000-E003, 8253 na E004-E007), což může znepristupnit klavesnici a casovac!

OUT E2H — Monitor ROM na 0000-0FFF

Obnovi ROM monitor na 0000-0FFF (reverze OUT E0H pro dolni 4 KB). Ostatní oblasti se nemění.

OUT E3H — Monitor ROM / VRAM na horní část

MZ-800: E000-FFFF → Monitor ROM (EPROM). Reverze OUT E1H.

MZ-700: D000-DFFF → VRAM + pamatove mapovane periferie (8255 na E000-E003, 8253 na E004-E007) + Monitor ROM na E000-FFFF. Reverze OUT E1H pro MZ-700 režim.

OUT E4H — Kompletní výchozí konfigurace (stav po RESET)

Nastaví vse do vychodziho stavu:

MZ-800:

0000-0FFF: Monitor ROM
1000-1FFF: CG ROM (znakova sada)
2000-7FFF: DRAM
8000-BFFF: VRAM (pristupna pres WF/RF registry)
C000-DFFF: DRAM
E000-FFFF: Monitor ROM (EPROM)

MZ-700:

0000-0FFF: Monitor ROM
1000-CFFF: DRAM
D000-D3E7: VRAM znaky (40x25)
D800-DBE7: VRAM atributy
E000-E003: 8255 PPI (mapovane I/O)
E004-E007: 8253 CTC (mapovane I/O)
E000-FFFF: Monitor ROM

Toto je jediný port, který nastaví všechny oblasti najednou. Všechny ostatní porty mění jen určitě oblasti a zbytek nechavaji v předchozím stavu.

IN E0H — Aktivace grafiky (VRAM + CGROM)

Zpristupni VRAM pro CPU čtení/zápis a CG ROM pro čtení znaků.

MZ-800: - 1000-1FFF → CG ROM (čtení znakové sady) - 8000-BFFF → VRAM (přístup přes WF/RF)

MZ-700: - 1000-1FFF → CG ROM - C000-CFFF → VRAM (PCG/CGRAM oblast)

Důležité: Oblast 8000-BFFF je v MZ-800 režimu po OUT E4H uz VRAM. IN E0H explicitne "aktivuje" přístup k VRAM — což je potřeba po IN E1H, které ji prevedlo na DRAM. V praxi to znamená ze IN E0H je reverze IN E1H.

IN E1H — Deaktivace grafiky (DRAM místo VRAM)

Nahradi VRAM a CG ROM systemovym DRAM.

MZ-800: - 1000-1FFF → DRAM (místo CG ROM, stav před nastavenim CG) - 8000-BFFF → DRAM (místo VRAM)

MZ-700: - 1000-1FFF → DRAM - C000-CFFF → DRAM (místo VRAM/CGRAM)

Typické použití: Program potřebuje plnych 64 KB RAM. VRAM je stále fizicky pristupna pro video fetch (zobrazení pokracuje), ale CPU přístup do 8000-BFFF nyni přistupuje k systemovemu DRAM, ne k VRAM.

OUT E5H a OUT E6H — Inhibit mechanismus

Co dělá OUT E5H

OUT E5H provádí dve veci současně:

1. Stejně jako OUT E1H: Přepne E000-FFFF (MZ-800) resp. D000-FFFF (MZ-700) na DRAM
2. Navíc aktivuje INH5 signál: Pin 38 GDG jde na log. H

INH5 je open drain výstup. Když je v H, signalizuje externim zarizenim na expansion buse, ze přístup do dane oblasti je zakazan (inhibited). Externí RAM rozšíření (napr. MZ-1R25) nebo jiná zařízení na expansion slotu se NESMI ozyvat na adresy v zakázané oblasti.

Praktické použití: Software může odpojit externí rozšíření z adresoveho prostoru, aby mohl použít systémový DRAM na E000-FFFF bez kolize s externim zarizenim.

Co dělá OUT E6H

OUT E6H vraci oblast do stavu před zakazem:

1. Oblast E000-FFFF (MZ-800) resp. D000-FFFF (MZ-700) se vrati do stavu, jaky mela před provedenim OUT E5H
2. INH5 se vrati na log. L (externí zařízení může opet odpovidat)

Příklad sekvence:

; Vychozi stav po RESET — E000-FFFF = ROM
OUT (E5H), A    ; E000-FFFF = DRAM, INH5=H (externi zakaz)
; ... pouzivame E000-FFFF jako RAM bez kolize s ext. zarizenimi ...
OUT (E6H), A    ; E000-FFFF = ROM (navrat ke stavu pred E5)
                ; INH5=L (externi zarizeni opet povoleno)

Proč existuji E5H a E6H

MZ-800 ma expansion slot, ke kterému se pripojovaly: - MZ-1R25 — externí RAM rozšíření - MZ-1E19/MZ-1E20 — I/O rozšíření - MZ-1R18 — RAM file

Tyto periferie mohou reagovat na stejně adresy jako systemova paměť. INH5 mechanismus umožňuje software DOCASNE odpojit externí zařízení, provest operaci se systemovym DRAM, a pak externe opet povolit.

Bez INH5 by přístupy do E000-FFFF mohly zpusobit bus kolizi — jak systémový DRAM, tak externí zařízení by se snazily vystavit data na sbernici současně.

Stavovy automat bank switchingu

GDG interně udržuje stav bank switchingu jako sadu flip-flopu. Kazda operace IN/OUT na porty E0-E6 nastaví/resetuje specifický flip-flop. Kombinace těchto flip-flopu rozhoduje, jake signály GDG generuje při každém CPU přístupu.

Důvody, proč není trivialni

Bank switching NENÍ jednoduchý demultiplexer — jde o stavovy automat s nasledujicimi vlastnostmi:

1. OUT E4H resetuje vsechno: Jediný port který kompletne reinicializuje stav
2. Ostatní porty mění jen část: OUT E0H mění jen dolni oblast, OUT E1H jen horní oblast
3. IN E0H/E1H ovlivnuji jinou oblast než OUT E0H/E1H:
4. OUT E0H → dolni polovina (0000-7FFF)
5. IN E0H → VRAM+CGROM aktivace (8000-BFFF + 1000-1FFF)
6. E5H/E6H mají paměť: E6H vraci stav před E5H, což vyžaduje uložení predchoziho stavu

Tabulka stavu dle kombinace portů (MZ-800)

VRAM — fyzická organizace a mapování do CPU prostoru

Princip: CPU adresa ≠ DRAM adresa

Když CPU přistupuje k adrese 8000H, GDG prekonvertuje tuto adresu na DRAM RAS/ČAS. Toto mapování je nelinearni a závisí na režimu (viz dokument 07).

To znamená, ze stejný bajt v DRAM může byt pristupny pod jinou CPU adresou v jinem režimu. Fyzický je to stále ta sama DRAM bunka.

DRAM organizace v režimu 320x200 (SM strana 18)

VA bus (zakladni VRAM):           VC bus (rozsireni):
DRAM $0000 +-----------+         DRAM $0000 +-----------+
           | Plane I   |                    | Plane III |
           | (8000 B)  |                    | (8000 B)  |
DRAM $1F3F +-----------+         DRAM $1F3F +-----------+
           | nevyuzito |                    | nevyuzito |
DRAM $2000 +-----------+         DRAM $2000 +-----------+
           | Plane II  |                    | Plane IV  |
           | (8000 B)  |                    | (8000 B)  |
DRAM $3F3F +-----------+         DRAM $3F3F +-----------+
           | nevyuzito |                    | nevyuzito |
DRAM $3FFF +-----------+         DRAM $3FFF +-----------+

CPU mapování v 320x200: - CPU 8000-9FFF → DRAM $0000-$1FFF (Plane I na VA bus) - CPU A000-BFFF → DRAM $2000-$3FFF (Plane II na VA bus)

Obe roviny jsou v oddelenych polovinach 64K DRAM prostoru. ČAS adresa rozlisuje, zda se přistupuje k Plane I (ČAS bit 5 = 0) nebo Plane II (ČAS bit 5 = 1).

DRAM organizace v režimu 640x200 (SM strana 18)

VA bus (zakladni VRAM):           VC bus (rozsireni):
DRAM $0000 +-----------+         DRAM $0000 +-----------+
           | Plane I   |                    | Plane III |
           | sude bajty|                    | sude bajty|
           | (0,2,4...) |                   | (0,2,4...) |
DRAM $1F3F +-----------+         DRAM $1F3F +-----------+
           | nevyuzito |                    | nevyuzito |
DRAM $2000 +-----------+         DRAM $2000 +-----------+
           | Plane I   |                    | Plane III |
           | liche bajty|                   | liche bajty|
           | (1,3,5...) |                   | (1,3,5...) |
DRAM $3F3F +-----------+         DRAM $3F3F +-----------+
           | nevyuzito |                    | nevyuzito |
DRAM $3FFF +-----------+         DRAM $3FFF +-----------+

CPU mapování v 640x200: - CPU 8000-BFFF → celý Plane I (16000 B), prokadany do obou polovin DRAM prostoru

V 640x200 režimu je rovina I rozlozena přes OBE poloviny DRAM prostoru (sude adresy v dolni, liche v horní). To je zásadní rozdíl oproti 320x200, kde kazda polovina obsahuje jinou rovinu.

Co se stane při přepnutí režimu (klíčová otazka)

Když software naplni VRAM v jednom režimu a pak přepne do jineho, data v DRAM se nemění — mění se pouze způsob, jakym je GDG interpretuje. Protože mapování CPU→DRAM je pro každý režim jiné, stejný pixel na stejně CPU adrese ukazuje na jinou DRAM bunku v jinem režimu.

Příklad: 320x200 → 640x200

1. V režimu 320x200 (DMD=00H) zapíšeme sachovnici do Plane I:

2. CPU 8000H = 0xAA → DRAM bunka na adrese odpovídající ČAS=0x88 (320x200 ČAS základ)

3. Prepneme na 640x200 (DMD=04H):

4. CPU 8000H ted čte z DRAM bunky na adrese odpovídající ČAS=0x0A (640x200 ČAS základ)
5. To je úplně jiná DRAM bunka!

6. Obraz bude obsahovat nahodna data (to co bylo drive v te DRAM oblasti)

7. Ale: Video fetch také používá jiné ČAS adresy v každém režimu, takže zobrazeny obraz odpovídá obsahu DRAM v oblasti, kterou dany režim čte.

Příklad: Frame A → Frame B (320x200)

Frame A (DMD=00H) a Frame B (DMD=01H) používají odlišně ČAS adresy (viz dokument 07):

Frame A a Frame B tedy čtou z úplně různých DRAM bunek. Data napsana do Frame A se nezobrazi při přepnutí na Frame B a naopak. To je právě podstata double-bufferingu.

WF/RF registr a B/A bit — přístup k Frame B z CPU

CPU přistupuje k VRAM vždy na adresach 8000-BFFF (resp. 8000-9FFF v 320x200). Která DRAM bunka se skutečně přečte/zapise, závisí na:

1. WF registr (CCH) pro zápis:
2. Bity 3-0: výběr rovin (I, II, III, IV)
3. Bit 4 (B/A): výběr Frame A (0) nebo Frame B (1)

4. Bity 7-5: režim zápisu (SINGLE, EXOR, OR, RESET, REPLACE, PSET)

5. RF registr (CDH) pro čtení:

6. Bity 3-0: výběr rovin pro čtení
7. Bit 4 (B/A): výběr framu
8. Bit 7: SING/SRCH režim

B/A bit určuje, na který bus GDG smeruje CPU data: - B/A = 0 (Frame A): data jdou přes VA bus (roviny I, II) - B/A = 1 (Frame B): data jdou přes VC bus (roviny III, IV)

Důležité: B/A bit mění jen smerovani dat na bus, ne DRAM adresu. DRAM adresa (RAS/ČAS) je stejná — GDG zapisuje na stejnou DRAM pozici, ale smeruje data na jiný fyzický bus (VA vs VC).

Jak se 16 barev mapuje do DRAM

V 16-barevném režimu (DMD=02H) GDG používá všechny 4 roviny. Každý pixel ma 4-bitový index:

palette_index = (plane_IV << 3) | (plane_III << 2) | (plane_II << 1) | plane_I

CPU přistupuje vždy na 8000-9FFF, ale musí přepnout B/A bit pro přístup k rovinám III a IV:

; Zapis do rovin I+II (Frame A)
LD A, 00000011B    ; WMD=SINGLE, B/A=0, roviny I+II
OUT (CCH), A
LD A, data
LD (8000H), A      ; zapise na VA bus

; Zapis do rovin III+IV (Frame B)
LD A, 00011100B    ; WMD=SINGLE, B/A=1, roviny III+IV
OUT (CCH), A
LD A, data
LD (8000H), A      ; zapise na VC bus (STEJNA CPU adresa!)

SM strana 19 upozornuje: V 16-barevném režimu GDG provádí zápis do všech 4 rovin ve dvou DRAM cyklech (ne jednom): - Cyklus 1: Plane I + Plane III (VA + VC bus současně) - Cyklus 2: Plane II + Plane IV (VA + VC bus současně)

To je důvod, proč 16-barevný režim generuje delsi WAIT stavy než 4-barevný (viz dokument 15).

Tabulka: Co CPU vidi na 8000-BFFF v různých režimech

Poznámky: - V režimech 640x200 se CPU adresa 8000-BFFF mapuje na JINÝ DRAM prostor než v 320x200 (viz ČAS zaklady v dok. 12). Proto data zapsána v jednom režimu jsou "neviditelna" v druhém — ne proto ze by zmizela, ale proto ze jsou na jiných DRAM bunkach. - DMD=0x03 používá výhradně VC bus — data z VA busu jsou při video fetch ignorovana (viz dok. 13). CPU přístup vyžaduje WF s B/A=1. - DMD=0x07 používá VC bus pro oba bity paletoveho indexu — Plane I (VA) je při video fetch ignorovan. Efektivně mono přes VC s paletami 0 a 3. - DMD=0x0C-0x0F se chovaji identický s 08H-0BH — bit DMD2 nemá žádný vliv když DMD3=1 (viz dok. 13).

Tabulka: Video fetch — které DRAM bunky GDG čte pro obraz

Klíčové pozorovani: - Frame A (DMD=00H) a Frame B (DMD=01H) mají zcela odlišně ČAS zaklady. Obsah jednoho framu je fyzický nezávislý na druhém. - DMD=0x03 (nedokumentovaný) kombinuje ČAS zaklady z 16c režimu (0x0A, 0x4A) i Frame B (0xBE, 0xFE) — čte z OBOU DRAM oblasti. Používá výhradně VC bus (viz dok. 13). - DMD=0x07 (nedokumentovaný) ma identický ČAS pattern jako 0x06, ale používá VC bus pro oba bity palety (Plane I je ignorovan). - DMD=0x0C-0x0F se chovaji identický jako 0x08 (MZ-700 text) — bit DMD2 nemá vliv když DMD3=1.

Nedokumentované DMD režimy — vliv na VRAM mapování

DMD=0x03 — hybridni 320x200 (VC only)

DMD=0x03 je nedokumentovaný režim, který kombinuje vlastnosti 16-barevneho režimu (0x02) a Frame B (0x01):

• DRAM fetch: 284 video čtení/řádek (jako Frame B), žádné mystery reads
• ČAS zaklady: 0x0A, 0x4A (jako 16c) + 0xBE, 0xFE (jako Frame B)
• Bus použití: Výhradně VC — data z VA busu jsou ignorovana

Dopad na VRAM přístup: - CPU musí použít WF s B/A=1 pro zápis dat, která se zobrazi - Data zapsána s B/A=0 (na VA bus) se v tomto režimu NEZOBRAZI - Režim čte z jiných DRAM bunek než 0x00 nebo 0x02, protože používá odlišně ČAS zaklady

Přepnutí 0x02 → 0x03: Data zapsána v 16-barevném režimu se cástecne zobrazi (ČAS zaklady 0x0A, 0x4A jsou sdilene), ale obraz bude jiný — chybí data z ČAS 0x1E/0x5E a pribyly data z ČAS 0xBE/0xFE.

DMD=0x07 — 640x200 mono přes VC

DMD=0x07 ma identický DRAM fetch pattern jako 0x06 (640x200/4c): - ČAS zaklady: 0x0A, 0x4A, 0xFE (identický s 0x04-0x06) - Bus použití: Oba bity paletoveho indexu z VC busu (Plane III) - Plane I (VA bus) je při video fetch ignorovan

Dopad na VRAM přístup: - CPU musí použít WF s B/A=1 pro zápis viditelenych dat - Data na VA busu se nezobrazi (ale zustavaji v DRAM) - Vysledny obraz je efektivně monochromaticky (palety 0 a 3)

Přepnutí 0x06 → 0x07: DRAM adresy jsou shodné, takže data zapsána v 0x06 jsou stále na spravnych DRAM bunkach. Ale obraz se změní — místo 4-barevneho indexu (plane_III, plane_I) se pouzije (plane_III, plane_III), což změní barvy.

DMD=0x0C-0x0F — identický s MZ-700 text

Všechny DMD hodnoty s bitem 3=1 (0x08-0x0F) se chovaji identický jako MZ-700 textový režim. Bit DMD2 (rozlišení 640/320) NEMÁ žádný meritelny vliv když DMD3=1.

VRAM mapování: Shodné s 0x08 — textova VRAM na D000-D3E7, atributova na D800-DBE7, CG data z DRAM.

Souhrnna tabulka — VRAM mapování všech 16 DMD režimu

Poznámka k DRAM nezavislosti: "Sdilene ČAS" znamená, ze režimy čtou z NĚKTERÝCH stejnych DRAM bunek. Přepnutí mezi nimi zobrazi (částečně) stejná data. "Nezávislý" znamená, ze režimy čtou z úplně jiných DRAM bunek — přepnutí zobrazi "nahodna" data.

MZ-700 režim — VRAM organizace

V MZ-700 režimu (DMD bit 3 = 1) je VRAM organizovana jinak:

VA bus:
DRAM $0000 +-----------+
           | nevyuzito |
DRAM $2000 +-----------+
           | CG oblast |  (znakove vzory)
DRAM $3000 +-----------+
           | TEXT VRAM  |  (40x25 = 1000 B znaku, D000-D3E7)
DRAM $3800 +-----------+  (pozor: adresa v DRAM, ne CPU!)
           | ATR VRAM   |  (40x25 = 1000 B atributu, D800-DBE7)
DRAM $3FFF +-----------+

VC bus (rozšíření): V MZ-700 režimu se nepoužívá.

CPU mapování v MZ-700 (po OUT E4H nebo OUT E3H): - CPU D000-D3E7 → TEXT VRAM (znakové kody, 40 bajtů/řádek) - CPU D800-DBE7 → ATR VRAM (barevné atributy) - CPU C000-CFFF → CG oblast (po IN E0H, programovatelne znaky)

VRAM sdileni mezi MZ-700 a MZ-800 režimy

Protože MZ-700 a MZ-800 režimy používají stejná fyzická DRAM pole (VA bus celá), ale s různými ČAS adresami, data se navzajem neprepisuji — existuji v různých castech 64K DRAM prostoru:

Poznámka: MZ-800 grafické roviny a MZ-700 textova VRAM se v DRAM cástecne prekryvaji (obe používají oblast $2000-$3FFF na VA busu). Proto přepnutí z MZ-700 do MZ-800 a zpet může poškodit textový obsah (a naopak).

Pamatova mapa po RESET (SM strana 6)

MZ-800 režim (výchozí stav)

0000H +------------------------+
      | Monitor ROM 1Z-013B    |  4 KB
0FFFH +------------------------+
1000H | CG ROM (znakova sada)  |  4 KB (512 znaku x 8B)
1FFFH +------------------------+
2000H |                        |
      |     Hlavni DRAM        | 24 KB
      |                        |
7FFFH +------------------------+
8000H |                        |
      |   VRAM (grafika)       | 16 KB (pristupna pres WF/RF)
      |                        |
BFFFH +------------------------+
C000H |                        |
      |     Hlavni DRAM        |  8 KB
      |                        |
DFFFH +------------------------+
E000H |                        |
      | Monitor ROM (horni)    |  8 KB (E-Monitor)
      |                        |
FFFFH +------------------------+

Systemova operace (po nahrani programu, SM strana 6)

Po dokonceni IPL a nahrani systemoveho programu se pamatova mapa změní na "systém operation" režim:

0000H +------------------------+
      |                        |
      |    DRAM (plna RAM)     | 64 KB
      |                        |
FFFFH +------------------------+

V tomto stavu (OUT E0H + OUT E1H) je VRAM stále fyzický pristupna pro video fetch (zobrazení), ale CPU přístup do 8000-BFFF jde do systemoveho DRAM. Pro přístup k VRAM je nutně provest IN E0H.

Praktické scenare

Double buffering (Frame A ↔ Frame B)

; 1. Kreslime do Frame B zatimco zobrazujeme Frame A
LD A, 00H          ; DMD = 320x200, Frame A (zobrazuje se)
OUT (CEH), A
LD A, 00010001B    ; WF = SINGLE, B/A=1, Plane I (Frame B)
OUT (CCH), A
; ... kreslime do 8000-9FFF (jde na VC bus → Plane III) ...

; 2. Prepneme zobrazeni na Frame B
LD A, 01H          ; DMD = 320x200, Frame B (zobrazuje se)
OUT (CEH), A
LD A, 00000001B    ; WF = SINGLE, B/A=0, Plane I (Frame A)
OUT (CCH), A
; ... kreslime do 8000-9FFF (jde na VA bus → Plane I) ...

Data v DRAM jsou nezávislá — přepnutí DMD mezi 00H a 01H jen mění, které ČAS adresy GDG čte pro video fetch.

Naplneni 16-barevné VRAM

; Krok 1: Nastavit roviny I+II (Frame A)
LD A, 00000011B    ; WF = SINGLE, B/A=0, Plane I+II
OUT (CCH), A
; ... zapisovat data do 8000-9FFF ...

; Krok 2: Nastavit roviny III+IV (Frame B)
LD A, 00011100B    ; WF = SINGLE, B/A=1, Plane III+IV
OUT (CCH), A
; ... zapisovat data do 8000-9FFF (stejna CPU adresa!) ...

; Krok 3: Zapnout 16-barevne zobrazeni
LD A, 02H          ; DMD = 320x200, 16 barev
OUT (CEH), A

Přístup k RAM pod VRAM

; Chceme cist/zapisovat systemovy DRAM na 8000-BFFF
IN A, (E1H)        ; 8000-BFFF = DRAM, 1000-1FFF = DRAM
; ... pristupujeme k systemovemu DRAM ...

; Navrat k VRAM
IN A, (E0H)        ; 8000-BFFF = VRAM, 1000-1FFF = CG ROM

Důležité: Během IN E1H stavu video fetch STÁLE čte z VRAM (GDG čte přímo přes /VRAS//VCAS, ne přes bank switching logiku). Obraz se zobrazi normálně. Jen CPU přístup do 8000-BFFF jde do systemoveho DRAM místo VRAM.

Použití s expanzni paměti

; Odpojit externi zarizeni z E000-FFFF
OUT (E5H), A       ; E000-FFFF = DRAM, INH5=H (ext. zakaz)
; ... pracujeme se systemovym DRAM na E000-FFFF ...

; Znovu pripojit externi zarizeni
OUT (E6H), A       ; E000-FFFF = predchozi stav, INH5=L

Stav ověření

Dokumentace: Informace v tomto dokumentu pochází z: - Service Manual MZ-800 (strany 6-19) — primarni zdroj - HTML dokumentace mz-800.scav.cz — doplnkovy zdroj - docs-ai/04_pamet_banky.md, 05_vram_organizace.md

Simulace (HDL): Částečně ověřeno: - OUT E0H, OUT E4H, OUT E5H: SEL1 a INH5 signály zaznamenany v simulací (test_mz700_pipeline.py) - VRAM přístup přes WF/RF: Plně ověřeno (test_vram.py, test_mz800_propagation.py) - DRAM ČAS adresy pro všechny režimy: Ověřeno (test_dmd_undocumented.py)

Neověřeno v simulací: - Kompletní stavovy automat E0-E6 (všechny kombinace) - Přesně chování IN E0H/E1H (aktivace/deaktivace VRAM) - Interakce E5H/E6H s různými predchozimi stavy - CPU přístup k systemovemu DRAM na 8000-BFFF (IN E1H stav)

Reálně HW: Ještě neověřeno.