CODINGLISTINGS ★ Jetzt wird's bunt : Video-Gate-Array mit Pep ★

Graphic - Jetzt Wird's Bunt - Video Gate - Array Mit Pep (CPC Amstrad International)Coding Listings
★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

Gleichzeitig:

  • mehr Farben im Modus 2
  • 27 Farben im Modus 0
  • mehrere Bildschirmmodi
  • verschiedene Randarben

So oder ähnlich machen verschiedene Firmen für ihre Software Werbung. Natürlich will man wissen, wie das funktionieren soll: Also - schlaue Bücher wälzen - und nicht immer nach dem Grundsatz: „Wissen ist Macht, nichts wissen macht auch nix..." handeln. ACHTUNG: Dies ist ein Artikel, der trotz Humors einer gewissen Ernsthaftigkeit nicht entbehrt! Klar?

Erste Ergebnisse bei den „kriminalistischen" Recherchen:

  1. Der Täter für solche „Sachen" ist wohl das Gate Array (GA): INK-, und PEN-Kommandos werden mit OUT's an das GA gegeben. Dieses GA wurde speziell für den Schneider entwickelt.
  2. Das Blinken der Farben (INK, SPEED INK) ist, wie die ENT-Hüllkurven, softwaregesteuert (das starke Stück des Schneider!).
  3. Tinten- und Bildschirmmodus werden im GA gespeichert und horizontal ausgegeben.

    und:

  4. Aller Anfang ist schwer Firmwarchandbuch her! Blätter, blätter - und siehe da: "Die Gate-Array-Hardware synchronisiert Modus-Änderungen mit der nächsten horizontalen Rücklauf-Periode, um die Software, die unterschiedliche Bereiche des Bildschirms in verschiedenen Modi handhabt, zu unterstützen."

Na schön, aber wie? - Prompte Antwort vom gewieften Bodo McBassick: „Na, das is'doch janz einfach: 300-er Interrupt einbinden, Code-Tabelle für die Modi anlegen und per OUT's die Modi setzen ..." - Aha! Nun gut, das könnte man versuchen. Wieder emsiges Blättern.

Erste wichtige Information, die wir unbedingt brauchen: Die Portadresse des GA ist #7Fxx (Video-Gate-Array) und soll nur zur Datenausgabe benutzt werden. „Die Software muß auf dieses Gate-Array zugreifen, um (...) das Laden der Farb-Informationen für die INK's im Paletten-Speicher zu steuern."

Und jetzt wird's interessant (und vor allem konkreter): „Ein Ein-/Ausgabe-Kanal wird für alle Befehle verwendet, deren obere zwei Daten-Bits den Befehl wie folgt spezifizieren:"

Tabelle 1

Bit 7 Bit 6 Verwendung
0 0 Lade Palettan-Pointer-Register

0 1 Lade Paletten-Speicher

1 0 Lade Kodua-und ROM-Freischaltregiater"

„Paletten-Pointer?" „Paletten-Speicher?" - Fragen über Fragen!

„Paletten-Pointer", das ist wohl das Register, das die Farbnummer (PEN) angibt und „Paletten^Speicher" ist wohl der Farbwert (INK)? Und für die Änderung des Hardwaremodes, muß Bit 7 Farbe bekennen? - Bodo McBassick: „Ja, das stimmt, bist'n helles Köpfchen!" Daß man bei solchem Gelaber immer auf Vermutungen angewiesen ist! Ob das „Firmwarehandbuch" so heißt, weil man firm in „wäre" (Hard-, und Software) sein muß? -Wir werden schon sehen:

"Paletten-Pointer-Register"

Dieses lediglich beschreibbare Register steuert das Laden der VDU-Farb-Palette wie folgt: Bit 7: 0 Bit 6: 0

Bit 5: Reserviert (sende 0)
Bit 4: Paletten-Pointer-Bit PR4
Bit 3: Paletten-Pointer-Bit PR3
Bit 2: Paletten-Pointer-Bit PR2
Bit 1: Paletten-Pointer-Bit PR1
Bit 0: Paletten-Pointer-Bit PR0

Die Bits PRO bis PR3 selektieren die zu ladende INK-Farbe, vorausgesetzt Bit PR4 ist im Low-Zustand. Wenn Bit PR4 im High-Zustand ist, werden die Bits PRO bis PR3 ignoriert und die Bildschirmrand-INK-Farbe geladen. „Soll das etwa heißen, daß man die INK's 0-15 einfach so per OUT 'rausläßt', und bei der Border-Farbe # 10, also 16, setzen muß?" - Bodo: „Genau das soll es!"

Paletten-Speicher

Dieses lediglich beschreibbare Register steuert die VDU-Farb-Palette wie folgt:

Bit 7: 0
Bit 6: 1
Bit 5: Reserviert (sende 0)
Bit 4: Farb-Datenbit CD4
Bit 3: Farb-Datenbit CD3
Bit 2: Farb-Datenbit CD2
Bit 1: Farb-Datenbit CD1
Bit 0: Farb-Datenbit CD0

Der INK-Eintrag, auf den durch das Paletten-Pointer-Register gezeigt wird, ist mit der auf diesem Kanal zu sendenden Farbe geladen. Die Anzahl der zu ladenden Farben reicht von zwei Farben im Modus 2 bis 16 Farben im Modus 0.

Zusätzlich zum Laden der Farben muß ein Extra-Datenbyte auf diesem Kanal gesendet werden, welches die Farbe des Bildschirmrandes definiert... „Das Bit 6 muß also gesetzt werden, um das Farbwertregister anzuwählen?" - Bodo: „Natürlich!" Und wie soll ich bitte die Farbcodes 'rausbringen, für jedes einzelne INK? Etwa durch Ausprobieren in BASIC mit OUT &7FOO,1:OUT &7FOO,&x010xxxxx? Jetzt wird Bodo ernstlich böse: „Mensch, schau doch ins ROM-Listing, du Dödel. Diese Codes nennt man Farbmatrixeinträge und die finden sich ab #0D93 im Lower-ROM im SCREEN PACK, klar?" - „Schon klar, aber kein Grund, gleich zu schreien ..." Zur Ausgabe von den INK-Nummern werden die unteren fünf Bits benutzt. Aber da sind doch fünf Bits: Das sind, äh, 1+2+4+8-1-16=31 Farben, oder sollten es zumindest sein?

Bodo widerspricht: „Sogar 32, wenn man das Nullbyte mitzählt, aber 'die verbleibenden Farben sind mit anderen Farben identisch'. Das steht doch schon im ROM-Listing!" Auch gut. Ein Versuch kann jetzt nicht schaden. Also GENA her, aber schnell (wo ist denn der Assembler bloß?):

Listing1

Das ist ein netter Erfolg: Es funktioniert! Jetzt mal in der Zeile 60 statt dem Rand eine INK angeben,wie wär s mit INK 1?

Also, schnell mal einsetzen:

150 ld c,#01 ; c=#01 Code für INK 1

Einfach verblüffend! Wer jetzt noch Bock hat, kann auch INK 0 noch probieren:

150 ld c,#00 ; c=#00 Code für INK 0

Wer sich nicht sattsehen kann, kann auch in Zeile 130 die Bedingung für den Sprung entfernen (einziger Nachteil: der Computer will jetzt nichts anderes mehr machen):

240 jr loop ; Und nochmal ...

Schön und gut: beeindruckende Effekte, aber noch lange nicht das Wahre! Zumindest hat sich die Theorie bewahrheitet.

Bodo schaut mir über die Schulter und meint: „Probier's doch lieber mit einem Interrupt!" (Das ist ein Kernel-Impuls, der dafür sorgt, daß ein Programm, das neben anderen Programmen abläuft, alle 1/300 Sekunde aufgerufen wird, ähnlich dem BASIC-Befehl EVERY.)

Listing 2
Nun gut - äh - das Ergebnis ist zugegebenermaßen noch wenig ausgefeilt. Hier und da blinkt ein Rest der Border. Sch... !

Und das Flimmern der Balkenränder bei einem Tastendruck ... (woher kommt das bloß?) Bodo gibt mal wieder seinen Senf dazu (er hatte schon immer einen Hang zum Sarkasmus): „Na ja, noch nicht ganz ausgereift, aber es funktioniert immerhin ... - Mensch, mach es doch besser, du Idiot!"

„Na, na, na, war doch nicht so gemeint (ist der empfindlich). Aber vielleicht können ein paar Tips Abhilfe schaffen:

  • Ein Interrupt mit höherer Priorität: Vielleicht der RST7 mit dem wohlklingenden Namen „Restart Seven Interrupt Entry Continued". Du könntest dich an der Routine bei #B939 vergreifen und einen Vektor auf ein eigenes Unterprogramm einrichten.
  • Den aktuellen, mit MODE gesetzten Hardwaremodus und die mit INK und BORDER gesetzten Farben mit einem 1/50-Interrupt ausgeben, so daß nicht definierte Balken in der „normalen" Form ausgegeben werden.
  • Der Aufbau erfolgt normalerweise beim Bildrücklauf. Lege doch einfach deinen eigenen Interrupt dazwischen: Wenn kein vertikaler Synchronisationsimpuls am Port B auftritt, kannst du eigene Farben setzen. Zur Abfrage kannst du den „MC Wait Flyback" (#BD19) benutzen.
  • Den obersten, und den untersten Balken würde ich weglassen; die verlangsamen den Prozeß nur noch und können doch mit BORDER gesetzt werden.
  • Die Interrupts würde ich während der Verarbeitung der neuen Farben natürlich mit 'DI' sperren, dann geht's noch schneller!
  • Außerdem würde ich die Border, alle INK's (0 - 15), und den Hardwaremodus in eine Tabelle eintragen. Die Verzögerungsrate und ein Flag, ob der

Balken in Betrieb ist, dürften doch auch keine Schwierigkeiten mehr bereiten -oder? Dann kannst du Balken mit verschiedenen Breiten betreiben und auch noch an-, und abschalten ..."

Das nenne ich konstruktive Kritik. Trotzdem einleuchtend (das meiste wenigstens!).

„Schlag nach bei RST?" , heißt die Devise! „Und ?" -

Der RST7 Interrupt Entry Cont'd

Die Routine steht ab #03CA im Lower ROM und ab

#B939 im RAM: Der MONA-Disassembler bringt einiges ans Licht:

Listing 4

[NOIMG]

Gut, daß das „Ding" im RAM ist, dann kann man wenigstens daran „rumfummeln"! Aberwas hat es mit dem Register AF' auf sich ?

„Carry' befindet sich normalerweise im Zustand 'falsch'.

Ist Carry' wahr, so zeigt dies an, daß sich die Firmware im Unterbrechungs-Bereich befindet." Und wie sieht der wechselseitige Registersatz im CPC aus? - Bodo: „Der wird vom Betriebssystem benutzt, also Vorsicht! A' darf verändert werden. Hände weg vom C'-Flag! B' enthält die G A-Portadresse #7F, das Register C' enthält die ROM-Auswahl und den momentanen Modus, DE' und HL' dürfen verändert werden, aber werden auch vom Betriebssystem benutzt. Vergiß nicht, die Interrupts zu sperren!"

Wie findet man das? Der Typ is'gar nich' so dumm ... Aber, wenn ich den Modus ändere, per OUT und per Register C', gibt es doch sicherlich Probleme mit der Zeichenausgabe?

,Ja. Das Bitmuster des mit 'MODE' gesetzten Hardware-modes wird auch bei anders gesetzten Modes benutzt! Eine wirklich zufriedenstellende Lösung gibt es nicht: Man kann zum Beispiel Sprites, die im Modus 0 erzeugt wurden, auf dem Balken mit dem Modus 0 richtig darstellen. Oder man lädt die Grafik direkt in den Bildschirmspeicher."

Übrigens, ich will euch nichts vorenthalten:

Listing 5

[NOIMG]

Übrigens - „Elaborat" - das heißt übles Machwerk ...

Nun lasse ich lieber einige Wochen mit Probieren, Entwerfen, Programmieren, Verbessern und schließlich Optimieren bei meinen Schilderungen aus (sonst wird's langweilig):

Als Bodo McBassick dann mal wieder vorbeischaut, hat er für mein Produkt nur eine lapidare Antwort übrig: „Kommt aber gegen meinen Amiga noch nicht ganz an

Was sagt man da? - Na, mir egal. Ich geh'jetzt jedenfalls zu Ferdi Flachmann und Herbie Hickup. Tschau ...

SPLIT SCREEN heißt die Parole

Tabelle 1 (Die Ink-Code-Tabelle)

Werte für den OUT-Befehl der Farbe (GA-Paletten-Speicher)

Formel: i = Inknummer 0-26
f(c) = Farbmatrix-Eintrag als Element (i-1) der Tabelle ab #0D93: Der Code für Ink 0 ist das erste Element
c = Farbcode-Ergebnis
->c = (f(c)AND 31)OR 64

Ink 00 Code 84 Farbe Schwarz
Ink 01 Code 68 Farbe Dunkelblau
Ink 02 Code 85 Farbe Hellblau
Ink 03 Code 92 Farbe Dunkelrot
Ink 04 Code 88 Farbe Magenta
Ink 05 Code 93 Farbe Hellviolett
Ink 06 Code 76 Farbe Hellrot
Ink 07 Code 69 Farbe Purpur
Ink 08 Code 77 Farbe Hellmagenta
Ink 09 Code 86 Farbe Dunkelgrün
Ink 10 Code 70 Farbe Türkisblau
Ink 11 Code 87 Farbe Himmelblau
Ink 12 Code 94 Farbe Ockergelb
Ink 13 Code 64 Farbe Grau
Ink 14 Code 95 Farbe Pastellblau
Ink 15 Code 78 Farbe Orange
Ink 16 Code 71 Farbe Rosarot
Ink 17 Code 79 Farbe Pastellmagenta
Ink 18 Code 82 Farbe Hellgrün
Ink 29 Code 66 Farbe Seegrün
Ink 20 Code 83 Farbe Helltürkis
Ink 21 Code 90 Farbe Limonengrün
Ink 22 Code 89 Farbe Pastellgrün
Ink 23 Code 91 Farbe Pastelltürkis
Ink 24 Code 74 Farbe Gelb
Ink 25 Code 67 Farbe Pastellgelb
Ink 26 Code 75 Farbe Weiß

Tabelle 2 (die Balkentabelle zum Interrupt) BAR:

Balkennummer 1 (unten) bis 4 (oben)

Bit 7 Bit 6 Verwendung
0 0 Lade Paletten-Pointer-Register
0 1 Lade Paletten-Speicher
1 0 Lade Modus- und ROM-Freischaltregister

FLAG:
Enthält den Hardwaremode im aktuellen Balken. Der Balken ist eingeschaltet, wenn Bit 7 gesetzt ist, sonst werden die normalen Farben/Modi ausgegeben! Bit 1 und 2 enthalten Mode (0 - 2) und Bit 7 enthält On(l) oder C>ff(0)-Status
— Platzbedarf: Je 1 Byte/Balken

DELAY:
Verzögerungsrate (verursacht Breite des Balkens)
— Platzbedarf: Je 1 Byte/Balken

BORDER:
Enthält den codierten Wert des Randes des aktuellen Balkens (s. Tabelle 1)

— Platzbedarf: Je 1 Byte/Balken

INKS:
Enthält die codierten Werte der INK's 0 bis 15 im aktuellen Balken (siehe Tabelle 1)
— Platzbedarf: Je 16 Bytes/Balken

BAR FLAG DELAY BORDER INKS

< 1 > 1 B. 1 B. 1 B. 16 B.
< 2 > 1 B. 1 B. 1 B. 16 B.
< 3 > 1 B. 1 B. 1 B. 16 B.
< 4 > 1 B. 1 B. 1 B. 16 B.

Tabelle 3 (Bildschirmaufteilung)

Border 0 Border 0 Border 0
Border 4 Balken 4 Border 4
Border 3 Balken 3 Border 3
Border 2 Balken 2 Border 2
Border 1 Balken 1 Border 1
Border 0 Border 0 Border 0

Tabelle 4:

Anzahl der maximal anzuzeigenden Farben (einschließlich Rand):

5 verschiedene Randfarben
+ 4 * mögliche Farben im jeweiligen Hardwaremodus

— 27 Farben im Modus 0
— 21 Farben im Modus 1
— 13 Farben im Modus 2

CPCAI

★ YEAR: 1986
★ AUTOR: H.-J. Ringel
 

★ AMSTRAD CPC ★ DOWNLOAD ★

File:
» Jetzt  wird  s  bunt-Video  Gate  Array  mit  PepDATE: 2013-01-01
DL: 283
TYPE: ZIP
SiZE: 6Ko
NOTE: 40 Cyls
.HFE: Χ

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding Src's » Sound - Reflexion Rag
» Coding Src's » Rom Kopie Ins Ram (CPC Amstrad International)
» Coding Src's » Wieczny Kalendarz (Bajtek)
» Coding Src's » Relocating Z80 Code (The Amstrad User)
» Coding Src's » Window-Routinen (CPC Amstrad International)
» Coding Src's » Virages et loopings
Je participe au site:
» Vous avez des infos personnel, des fichiers que nous ne possédons pas concernent ce programme ?
» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 664 millisecondes et consultée 1706 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.