17 — Propagace změny palety a border color

Základní informace

Tento dokument popisuje jak rychle se změny I/O registru palety (port F0H) a border color (port CF06H) projeví v generovanem video výstupu. Oba registry sdileji stejný výstupní signálový řetězec uvnitř GDG.

Klíčová otazka: Projevy se změna palety/borderu uprostřed řádku, nebo až na následujícím?

Odpoved: Uprostřed řádku. Oba registry propagovany okamžitě přes kombinacni logiku, zpozdenych pouze o výstupní F666 flip-flop.

Signálový řetězec

bus_inPAL[0-3]     paletove registry (F601 D-latche, transparentni)
    |
bus_outPAL[0-3]    NAND mux (vyber palety podle pixel dat)
    |
bus_BRGI[3:0]      4x NAND: BRGI(n) = NAND(outPAL_n[3:0])
    |
bus_INK_BKG[3:0]   MUX: MZ-800 grafika (BRGI) vs MZ-700 text (INK)
    |                   *** BIT SWAP: INK_BKG(3)<->RBGI(0) ***
bus_RBGI[3:0]      MUX: border (BORDER) vs obsah (INK_BKG)
    |
F666 flip-flop     vystupni registr (clocked CLK0), nO vystup
    |
vystupni piny      YITN, GREEN, RED, BLUE

F601 D-latche jsou transparentni při aktivnim write strobe. Jakmile GDG dekóduje I/O zápis na příslušný port, data prochazi latcem a kombinacni logiku až k F666 flip-flopu. Ten zachyti novou hodnotu na následující CLK0 hrane.

Propagace palety

Měření

VRAM naplnena 0xFF (palette 3 pro všechny pixely), paleta 3 nastavena na černou (IGRB 0000). Uprostřed viditelneho řádku zapsána nova barva palette 3 = IGRB 1111 (bílá).

Write CLK0 První bílý pixel Delay Poznámka
400 410 10 CLK0
500 512 12 CLK0
600 612 12 CLK0
700 714 14 CLK0
800 810 10 CLK0

Průměrná latence: ~12 CLK0 (~0.68 us) od zahajeni io_write k prvnimu pixelů s novou barvou.

Proč 10-14 CLK0?

Latence odpovídá dobe io_write cyklů od zacatku do okamziku, kdy write strobe aktivuje F601 latch:

  1. await RisingEdge(CPU) — synchronizace na CPU clock (0-5 CLK0)
  2. await FallingEdge(CPU) — IORQ=0, WR=0, data na DT (5 CLK0)
  3. F601 latch transparentni → data prochazi kombinacni logiku
  4. F666 FF zachyti novou hodnotu na následující CLK0 hrane (~1 CLK0)

Celkem: 6-14 CLK0 podle fáze CLK0 vuci CPU clock při zahajeni.

Změna uprostřed řádku

Paleta se projeví na aktualnim řádku. Pixely před změnou mají starou barvu, pixely po změně novou. Na následujícím řádku je paleta uz celé platná.

Příklad (write@CLK0=600, 320x200 mode):

CLK0:  340         600  612                    980
       |           |    |                      |
       | cerne     |    | bile                 |
       | pixely    |    | pixely               |
       | (palette  |    | (palette 3 = IGRB 1111)
       |  3=0000)  |    |                      |
                   |
               io_write start

Propagace border color

Měření

Border color = IGRB 0000 (černá). Změna na IGRB 1111 (bílá) provedena v různých castech řádku.

Test A: Změna během blanking - Levy border: 156/156 pixelů bilych (100%) - Pravy border: 132/132 pixelů bilych (100%) - Změna se projeví na celem následujícím řádku.

Test B: Změna uprostřed canvas (CLK0~600) - Canvas: 0 necernych pixelů (správně — border neovlivnuje canvas) - Pravy border: 132/132 bilych - Změna se projeví ještě na pravem borderu TEHOZ řádku.

Test C: Změna v levem borderu (CLK0~250) - První bílý pixel: CLK0=256, delay = 6 CLK0 od zahajeni io_write - Zbytek leveho borderu: bílý - Pravy border: 132/132 bilych

Border vs paleta — proč je border rychlejsi?

Border delay (6 CLK0) je kratsi než palette delay (10-14 CLK0). Pravděpodobně proto, ze border latch je přímo v RBGI MUXu (jednodussi dekodovaci řetězec než paletový), takže write strobe je aktivní drive v I/O cyklů.

Kde je border videt

CLK0:  0          184              340       980       1112    1136
       |           |                |         |         |       |
       | H-blank   | levy border   | canvas  | pravy   |H-blank|
       | (IGRB=0)  | (border       | (VRAM   | border  |(IGRB=0)
       |           |  barva)       | data +  | (border |       |
       |           |  156 px       | paleta)  | barva)  |       |
       |           |               | 640 px  | 132 px  |       |

Border color je videt v CLK0 184-340 (levy) a 980-1112 (pravy). Během canvas oblasti se zobrazi VRAM data přes paletový systém.

Praktické dopady

Mid-scanline efekty

GDG umožňuje rasterove efekty změnou palety ci borderu uprostřed řádku: - Změna palety mění barvy všech pixelů od aktualni pozice - Změna borderu mění barvu okraje od aktualni pozice - Typicky použití: per-scanline paleta pro vice než 4 barev

HBLN polling a latence

Software typicky používá HBLN polling (IN + BIT + JR ≈ 25 T-stavu = 125 CLK0) pro synchronizaci zápisu. Po detekci HBLN=0 (blanking) je dostupnych ~496 CLK0 pro bezpečné zápisy bez artefaktu.

Pro mid-scanline efekty je třeba přesně časování: - Po HBLN=1 (CLK0 335): canvas zacina za 5 CLK0 - Paleta zapsána v CLK0 X se projeví v CLK0 X+10 až X+14 - Border zapsany v CLK0 X se projeví v CLK0 X+6

Bez WAITu

Zápisy do I/O portů (paleta, border) negeneruji WAIT. GDG neblokuje CPU během I/O zápisu — latch se aktualizuje okamžitě. Toto se liší od VRAM zápisu (které mohou generovat WAIT v režimu 800).

Stav ověření

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

Ověřeno: - Paleta: 5 různých write pozic (CLK0 400-800), delay 10-14 CLK0 - Border: změna během blanking (100% propagace), uprostřed canvas (pravy border OK), v levem borderu (delay 6 CLK0) - Oba registry propagovany mid-scanline, ne až na následujícím řádku - Následující řádek po změně: 640/640 bilych pixelů (paleta)

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