09 — Video fetch pipeline v MZ-700 textovém režimu

Základní informace

Tento dokument popisuje časování video fetch pipeline v MZ-700 textovém režimu (DMD bit 3 = 1, MOD7 = 1). Určuje kdy přesně GDG čte jednotlive datove slozky z DRAM a jak rychle se změny VRAM projeví v generovanem obrazu.

Struktura pipeline: 4 DRAM čtení na znak

Každý ze 40 znaků na řádku vyžaduje přesně 4 DRAM čtení provedena v page-mode (společný RAS, 4 ČAS cykly):

Čtení CLK0 offset Účel
1 +0 Znakový kod (text VRAM)
2 +4 Barevný atribut (color RAM)
3 +8 CG vzor — bajt 1
4 +12 CG vzor — bajt 2

Každý znakový sloupec trvá 16 CLK0 (= 1 COLUMN hodnota čítače). Všechna 4 čtení mají konstantní rozestup 4 CLK0.

Časování

Časová osa jednoho řádku

CLK0:  0       313 321  335  340            957 961  975      1135
       |        |   |    |    |              |   |    |         |
       |  DRAM  |   |HBLN|    |              |   |DRAM|         |
       | refresh|   |vis.|    |              |   |ref.|         |
       | gap=8  |   |    |    |              |   |gap=8         |
       |        |   |    |    |              |   |    |         |
       |        |  ch.0  | canvas       ch.39   |    |         |
       |        | fetch  | start        fetch   |    |         |
       |        |        |                      |    |         |
       |        |        |    40 znaku x 16 CLK0|    |         |
       |        |        |    = 640 CLK0        |    |         |

Přesně pozice (PAL, CKSW=0)

Udalost CLK0 Poznámka
DRAM refresh 1–313 40 cyklů, addr=0000, gap=8 CLK0
Prefetch char 0 321 14 CLK0 před HBLN visible!
HBLN visible 335 Status Register bit 7 = 1
Canvas start 340 První pixel na výstupu
Char N fetch 321 + N*16 První DRAM čtení pro znak N
Char 39 fetch 945–957 Poslední znakový sloupec
DRAM refresh 961–1129 22 cyklů, addr=0000, gap=8 CLK0
HBLN blank 975 Status Register bit 7 = 0

Pipeline latence: 19 CLK0

Od prvniho DRAM čtení (CLK0 321) k prvnimu pixelů na výstupu (CLK0 340) = 19 CLK0 (~1.07 us).

To je mirne vice než 1 znakový sloupec (16 CLK0). Pipeline tedy obsahuje cca 1 znak prefetch — GDG čte data pro následující znak zatímco aktualni znak ještě prochazi shift registrem.

HBLN offset

HBLN visible (CLK0 335) je o 14 CLK0 pozdeji než skutečný zacatek DRAM čtení (CLK0 321). To znamená:

HBLN indikuje stav pipeline výstupu (kdy pixely jdou na obrazovku), ne stav DRAM přístupu.

nCROM: znakové vzory z DRAM, ne z CGROM

Klíčové zjištění

Signál nCROM (pin 81) není nikdy aktivní během video generování v MZ-700 režimu. GDG čte znakové vzory (character generator patterns) přímo z DRAM, ne z externiho CGROM chipu.

To znamená, ze v MZ-700 display mode na MZ-800 hardwaru: - Všechna video data (znak, barva, CG vzor) pochází z DRAM - CG vzory jsou uložený v DRAM na specifickych adresach - Modifikace CG dat v DRAM se projeví v generovanem obrazu

DRAM adresy CG čtení

CG čtení (3. a 4. čtení v každém sloupci) používají adresy, které závisí na znakoven kodu precteneho v 1. čtení:

Typ sloupce CG RAS CG ČAS
Sudy 0x32 0x1A, 0x90
Lichy 0x3A 0x1A, 0x90

Alternace RAS (0x32 vs 0x3A, rozdíl v bitu 3) koreluje s bitem 0 znakoveho kodu. Přesně adresové mapování viz 07-dram-address-map.md.

Propagace změn do obrazu

Zápis během HBLN blanking

Změny VRAM během blanking se VŽDY projeví na aktualnim řádku.

Ověřeno simulací: změna celeho VRAM obsahu během blanking zpusobila změnu všech 640 canvas pixelů na následujícím řádku (IGRB 0000→1111).

Důvod: během blanking GDG nepristupuje k VRAM (provádí pouze DRAM refresh na addr=0000). CPU zápisy jdou přímo do DRAM. Když GDG zacne číst na CLK0=321, nova data uz jsou v paměti.

Bezpečné okno pro CPU zápisy

CLK0:  961                        321
        |    bezpecne okno         |
        |    496 CLK0              |
        |    ~99 T-stavu CPU       |
        |                          |
     posledni                   prvni
     DRAM refresh               char fetch

Bezpečné okno pro CPU zápisy do VRAM: CLK0 961–320 = 496 CLK0 = priblizne 99 T-stavu CPU (při 3.547 MHz). Odpovídá HBLN blanking.

Hazardni okno

CLK0 321–334 (14 CLK0): GDG uz čte VRAM, ale HBLN rika "blanking" a WAIT mechanismus nechrani přístup. CPU zápis v tomto okne by mohl kolidovat s video fetch.

V praxi: software používá HBLN polling, který pridava latenci (minimalne IN + BIT + JR = 25 T-stavu = 125 CLK0). Po detekci HBLN=0 je CPU daleko od hazardniho okna.

Racing the beam (zápis během visible)

V MZ-700 režimu je první VRAM přístup na řádku bez WAIT. Druhý a další přístupy dostavaji WAIT až do konce visible oblasti.

Pokud jediný free zápis cili na pozici, kterou GDG ještě neprecetl:

Char N fetch = CLK0 321 + N * 16

Napriklad: zápis na pozici 20 při CLK0 ~400 (zacatek visible): char 20 fetch = CLK0 321 + 20*16 = CLK0 641. Změna se projeví.

Ale po tomto jednom zápisu CPU čeká na WAIT až do CLK0 ~975.

Porovnání s MZ-800 grafickymi režimy

Vlastnost MZ-700 text MZ-800 320x200 MZ-800 640x200
Video data čtení 160 (40x4) 80 (40x2) * 80 (40x2) *
Celk. DRAM čtení/řádek 224 284 * 182 *
Čtení/sloupec 4 2 (+1 mystery) * 2 *
Rozestup 4 CLK0 4 CLK0 * 4 CLK0 *
Prefetch CLK0 321 329 * 329 *
Pipeline latence 19 CLK0 ~8 CLK0 * ~8 CLK0 *
nCROM aktivní Ne Ne Ne

* Hodnoty opravený v doc 13 na zaklade detailniho měření (test_mz800_propagation.py). Puvodni tabulka uvadela: 160 čtení, 4/sloupec, prefetch 337, latence 3 CLK0 — tyto hodnoty pochazeji z odlisneho způsobu měření (pocitani všech ČAS cyklů v HBLN visible okne, resp. rozdíl HBLN-canvas místo přímo merene pipeline latence).

Detail viz 16-mz800-propagation.md.

Stav ověření

Simulace (HDL): Všechny hodnoty pochází z gate-level simulace (GDG_core.vhd + cocotb testbench test_mz700_pipeline.py). Ověřeno:

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