Hauptsprungleiste📈 Graphics VDUEintrag Nr. 198CPC 664/6128

GRA FILL

&BD52

Einen Bereich des Bildschirms füllen.

Original (SOFT 968): „Fill an area of the screen.“

🔀Wie der Aufruf die Routine erreicht

Dein Programm            RAM-Sprungleiste            Low Kernel (RAM/ROM)        unteres ROM
─────────────            ────────────────            ────────────────────        ───────────
CALL &BD52  ───────▶  &BD52: RST 1 ─────────▶  &0008 LOW JUMP:           GRA FILL
                         DW Low Address            ROM-Zustand merken,  ───▶  (Routine)
                         (Bit 15 = oberes ROM aus)  unteres ROM an                  │
     ◀──────────────────────────────────────────  ROM-Zustand zurück  ◀──── RET ──┘

📖Beschreibung

⚙️ Wirkung

  • Einen Bereich des Bildschirms füllen, der die aktuelle Grafikposition enthält und durch den Rand des Fensters und Pixel, die auf die Stiftfarbe gesetzt sind, begrenzt wird.

🧮 Register auf einen Blick

EingabeADEHL
AusgabeCarry
verändertABCDEFHL

Automatisch aus den Bedingungen abgeleitet – bei Fallunterscheidungen („wenn … dann“) gilt der Volltext unten.

➡️ Einsprungbedingungen

  • A enthält die (unkodierte) Farbe, mit der der Bereich gefüllt werden soll.
  • HL enthält die Adresse eines Puffers.
  • DE enthält die Länge des Puffers.

⬅️ Rücksprungbedingungen

  • Wenn der Bereich erfolgreich gefüllt wurde:
  • Carry gesetzt.
  • Wenn der Bereich nicht gefüllt wurde:
  • Carry gelöscht.
  • Immer:
  • A, BC, DE, HL und andere Flags verändert.
  • Alle anderen Register bleiben erhalten.

📝 Hinweise aus dem Handbuch

  • 🔀Diese Routine ist auf Firmware V1.0 nicht verfügbar.
  • Der Füllalgorithmus behandelt Pixel, die auf die aktuelle Stiftfarbe gesetzt sind, und Pixel, die auf die zum Füllen verwendete Farbe gesetzt sind, als Begrenzungen des Bereichsrands. Die Füllfarbe und die Stiftfarbe können dieselbe Farbe sein.
  • Pixel, die gefüllt werden, werden auf die Füllfarbe gesetzt. Der Grafikschreibmodus beeinflusst nicht die Art und Weise, wie Pixel beim Füllen geschrieben werden.
  • Der Füllalgorithmus bewegt sich nur nach oben, unten, rechts oder links. Er bewegt sich nicht diagonal, und daher wird der Algorithmus nicht durch eine Lücke zwischen diagonal benachbarten Randpixeln 'entweichen'. Das bedeutet, dass der Rand mit den normalen Linien begrenzt werden kann, die vom Graphics VDU gezeichnet werden.
  • Der Füllalgorithmus vermeidet Rekursion. Stattdessen speichert er 'interessante Punkte', Stellen, an denen der Algorithmus eine Route zum Füllen gewählt hat, aber eine andere Route hätte wählen können, in dem vom Benutzer bereitgestellten Puffer. Der Puffer kann sich irgendwo im RAM befinden. Jeder gespeicherte 'interessante Punkt' belegt 7 Bytes des Puffers, und es gibt einen Overhead von 1 Byte, der zum Markieren des Pufferendes verwendet wird. Ein 64 Bytes langer Puffer ermöglicht also das Speichern von 9 'interessanten Punkten', was für die Füllung der meisten einfachen Bereiche ausreichen sollte.
  • Form, desto länger muss der Puffer für 'interessante Punkte' sein.
  • Die Fehlerrückgabe dieser Routine kann aus drei Gründen auftreten. Erstens könnte die aktuelle Grafikposition außerhalb des Fensters liegen. Zweitens könnte das Pixel an der aktuellen Grafikposition Rand sein (Stift- oder Fülltinte). In diesen Fällen kehrt die Routine zurück, ohne etwas zu füllen. Drittens könnte der Algorithmus den Puffer für 'interessante Punkte' erschöpfen, in welchem Fall ein Teil des Bereichs nicht gefüllt wird.

🔀 markiert: Unterschiede zwischen Firmware V1.0 (464) und V1.1 (664/6128).

🧪Beispielprogramm – ausführen, ändern, Schritt für Schritt

Das Programm liegt bei &4000 und würde auf dem echten CPC mit CALL &4000 aus BASIC gestartet. Hier läuft es im Z80-Emulator; die Firmware ist nachgebildet.
bereit
🐞 Im großen Debugger öffnen
0
1
2
3
Rand
Modus 1 · Basis &C000 · Versatz &0000
Tastenpuffer: leer
Gedrückt gehaltene Tasten (für KM TEST KEY / KM GET JOYSTICK) per Klick umschalten; die Zahl ist die Tastennummer.
Register & Flags
AF
&FFFF
BC
&0000
DE
&0000
HL
&0000
IX
&FFFF
IY
&FFFF
SP
&C000
PC
&0000
S
1
Z
1
Y
1
H
1
X
1
P/V
1
N
1
C
1
Z80-Takte: 0 TCPC-Zeit: 0 µsROMs: unten aus, oben ausRAM-Konfig: &C0
Nächste Befehle (Disassembler)
0000HLE ▸ RESET ENTRY
0002RET
0003NOP
0004NOP
0005NOP
0006NOP
0007NOP
0008HLE ▸ LOW JUMP
Firmware
Firmware jetzt
▶ RESET ENTRY · Details
Letzte Falle: –
Letzte Firmware-Aufrufe
noch keine
Weitere Anzeigen: Speicher, Stapel, Ton, Dateien, Drucker, Kernel
Speicher
400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
401000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
402000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
403000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
404000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
405000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
406000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
407000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ················
PCSP(HL)(DE)Leseansicht mit aktueller ROM-/Bank-Einblendung
Stapel
C0000000← SP
C0020000
C0040000
C0060000
C0080000
C00A0000
C00C0000
C00E0000
Ton (Sound Manager)
Kanal A
still
4 von 4 Plätzen frei
Kanal B
still
4 von 4 Plätzen frei
Kanal C
still
4 von 4 Plätzen frei
Dateien (simuliertes Laufwerk)
DateiTypLängeLaden
HALLO.TXTASCII33–
ZAHLEN.BINbinär6&5000
MUSTER.DATbinär16&6000
Eingabe: keine · Ausgabe: keine
Drucker
(noch nichts gedruckt)
Kernel: Zeit & Ereignisse
Zeit (KL TIME PLEASE): 0 × 1/300 s = 0.00 s · Interrupts: 0
keine Ereignisblöcke angemeldet

🔗Verwandte Einträge

💡 Quellen
Amstrad SOFT 968 „CPC 464/664/6128 Firmware“, Abschnitt 15 (Beschreibung, übersetzt); Adresse und Name abgeglichen mit Taylor/Defoe „The Amstrad CPC Firmware Guide“. Simulation: eigene Nachbildung (HLE) – Laufzeiten der Firmware selbst werden nicht nachgebildet.