KC-News 2/1995

KC-Bildformate intern

von Ralf Kästner

Wie zum KC-Treffen gewünscht, soll im folgenden Artikel der Aufbau der PI_- und HI_-Bildformate beschrieben werden. Zunächst ein paar Worte zur Geschichte, ich beschäftige mich seit über 5 Jahren mit der Grafikprogrammierung auf dem KC. Angefangen hat alles mit "EDIPIC32" für den KC 85/2 und 3, welches 1989/90 auf einem "dienstlichen" KC 85/3 mit Kassette programmiert wurde und im August `90 fertig war. Seit August 1989 stand dann privat ein KC 85/4 zur Verfügung.

Durch die unterschiedliche IRM-Adressierung des Nachfolgemodells traten die bekannten Probleme auf, als es darum ging Grafiken auszutauschen. Der damalige Zustand war alles andere als zufriedenstellend, mit zur Verfügung stehenden Programmen, wie GRAFIK (KC 85/3) oder LEONARDO konnte man zwar mal eine einfache Zeichnung machen aber so richtig zu gebrauchen waren wohl alle nicht, schon gar nicht, wenn es um Bildtransfer zwischen /3 und /4 ging.

Unverständlicherweise wurde "ArtStudio" für den /4 von Mühlhausen "geheimgehalten", ich bekam es auch erst Anfang 1992 zu Gesicht, dort war das Transferproblem zwischen den beiden Typen aber auch nicht gelöst.

Ich habe mir damals Gedanken gemacht, wie man die ganze Misere etwas entschärfen könnte und vor allem, wie bringe ich die Zeichnungen von dem einen auf den anderen Rechner. Eines war klar, es mußte eine Formatdefinition her, welche auf die Hardware der KC`s zugeschnitten und für beide Typen gleichermaßen einlesbar ist, eine Begrenzung auf 256*256 Bildpunkte, wie in LEONARDO, sollte auch nicht erfolgen.

So entwickelte ich das Konzept mit den PIC/PIP/PIF-Dateien, welches ein wenig Ordnung und System in die Grafikwelt auf dem KC bringen sollte. Mit der Fertigstellung von "EDIPIC40" für den KC 85/4 im September 1991 standen dann zwei Programme zur Verfügung, welche einen Austausch von bildschirmgroßen Grafiken zwischen KC 85/2,3 und KC 85/4 ermöglichten, ohne daß sich der User Gedanken machen muß.

Man kann also die PIC-Dateien des KC 85/2,3 in den KC 85/4 und die PIP/PIF-Dateien des KC 85/4 in den KC 85/2,3 einlesen! Die jeweils laufende "EDIPIC"-Version speichert ein Bild im rechnerspezifischen Format, beim Einlesen erkennt das Programm anhand der Formatdefinition Bilder vom anderen Rechner und konvertiert sie automatisch in die richtige Form.

Inzwischen haben wir 1995, ich hätte damals auch nicht gedacht, daß mich die Grafik auf dem KC bis heute "verfolgt". Die Entwicklung ist weitergegangen, nach "EDIPIC41" 1992 folgte 1993 "DIASHOW", zum Treffen konnte man das neue "UNIPIC" aus 1994 begutachten, der KC 85/2,3 spielt nur noch eine Nebenrolle, da fast alle mit dem KC 85/4 und Diskette arbeiten.

Die überwiegende Zustimmung zu den genannten Programmen hat das damalige Dateikonzept eigentlich bestätigt, die Formatdefinition ist immer noch die gleiche von 1990. Für die Hires-Grafik des KC 85/4 habe ich mit "DIASHOW" 1993 den HIP/HIF-Typ eingeführt, so kann man die Farbauflösung schon aus der Dateierweiterung erkennen, was Mißverständnisse ausschließt.

Mittlerweile sind damit PIP/PIF- und HIP/HIF-Definition fast zum Quasi-Standard für den KC geworden und werden von anderen Programmierern angenommen und unterstützt, z. B. "WordPro 6" von Herrn Leubner oder "4PCX090" von Herrn Jödicke. Ich bin auch gern bereit zusätzlich zum heutigen Artikel weitere Quelltexte zur Verfügung zu stellen, man muß ja nicht jedesmal das Fahrrad neu erfinden.

Ich vertrete die Meinung, uns nützen viele verschiedene Formate für KC-Bilder gar nichts, wenn sich alle an ein Format halten, fällt die Arbeit auf dem KC leichter und die Programmierer haben es auch einfacher, insbesondere betrifft dies auch Grafik, welche unter MikroDOS entsteht, da dort der CAOS-Vorblock nicht zwingend erforderlich ist!

Die notwendigen Hintergrundinformationen sollen mit dem heutigen Artikel geliefert werden. Auf den KC 85/2,3 möchte ich nicht so genau eingehen, da er wohl nur noch eine untergeordnete Rolle spielt, "EDIPIC32" ist ja leider auch nur kassettenfähig, man kann aber alle PI_-Bilder mit einem normalen Kopierprogramm von/auf Diskette spielen und so auch auf diesem Wege weitergeben bzw. nutzen. Wird von Diskette auf Kassette kopiert, ist ein gesetzter Schreibschutz vorher zu entfernen!!!

Allgemeines

Jede Bilddatei enthält immer einen kompletten Bildinhalt des KC von 320*256 Bildpunkten. Der Dateiaufbau entspricht CAOS-Maschinenprogrammen, es ist also immer der 128 Byte umfassende Vorblock zu erzeugen, auch wenn von MikroDOS aus Grafiken gespeichert werden! Im Vorblock müssen die folgenden Bytes unbedingt enthalten sein (Zählung ab 0!):

0...15	beliebig
16	Anzahl der Parameter (2 oder 3 bei Selbststart)
17...18	Anfangsadresse LOW/HIGH
19...20	Endadresse+1 LOW/HIGH
21...22	Startadresse LOW/HIGH (bei Bedarf)
23...127	beliebig

Man bleibt so kompatibel zu den Kassettendateien, was für einen unkomplizierten Austausch einfach notwendig ist, bitte beachten, bei den Vorblockbytes der Kassettenaufzeichnung beginnen die Datenbytes erst ab dem 1. (bei Zählung von 0!) Byte, da im Byte 0 die Blocknummer auf Kassette gespeichert wird, im Systemhandbuch auf S.85 wird die Bytezählung allerdings bei 1 begonnen, so daß das Byte Nr.18 dort, dem Byte Nr.16 hier entspricht!

Eine Ausgabe von Bildern ohne CAOS-Vorblock halte ich auch heute noch für nicht sinnvoll, da die gesamte Grafik ohnehin im Grundgerät verwaltet wird und reine Grafikprogramme unter MikroDOS eher Raritäten sind. Sie wären wahrscheinlich durch den ESC-Flaschenhals des Koppel-RAM auch zu langsam und nur bei rechenintensiven Programmen sinnvoll, wo sich die 4 MHz auszahlen, Beispiel FRACTALE von Herrn Harder, die dort erzeugten PIP/PIF-Dateien sind aber mit der Formatdefinition nicht kompatibel, man kann diese Bilder beispielsweise über "WordPro 6" einlesen und als HIP/HIF-Bild von dort aus speichern.

Bei allen Formaten ist die Komprimierung durch einen beliebigen Algorithmus möglich, wobei folgende Punkte eingehalten werden müssen. Die komprimierte Datei darf nicht größer als die unkomprimierte Variante werden, das ist notwendig, damit nicht unnötig wertvoller Speicherplatz verschwendet wird, man muß also während der Komprimierung die entstehende Dateilänge überwachen und im Falle eines Überlaufes abbrechen und die Datei dann unkomprimiert speichern.

Die zugehörige Dekomprimierungsroutine muß in der komprimierten Datei am Anfang stehen (s.u.), auf 8000H entpacken und als Unterprogramm ausgeführt sein (Abschluß mit RET). Die Organisation der Bildbytes muß wie im IRM des Originalrechners erfolgen, also der Zusammenhang zwischen Pixel- bzw. Farbyteposition muß der Adressierung des KC 85/2,3 bzw. KC 85/4 entsprechen, in der Regel ist dies ja immer gegeben.

Lores-Grafiken

Als Lores-Grafik werden alle Bilder vom KC 85/3 bezeichnet und alle Bilder in der byteweisen Farbauflösung (1*8 Bildpunkte) des KC 85/4. Als Dateierweiterungen (Zeichen 9...11) sind vorgeschrieben:

PIC

IRM-Inhalt vom KC 85/2,3 mit oder ohne Farbbytes

 

PIP

IRM-Inhalt der Pixel-IRM-Ebene vom KC 85/4 (IRM-Ebene 0 bzw.2)

 

PIF

IRM-Inhalt der Color-IRM-Ebene vom KC 85/4 (IRM-Ebene 1 bzw.3)

Damit das ladende Programm erkennen kann, von welchem Rechner die Datei stammt, ob eine Komprimierung der Daten erfolgte und ob die Farbbytes beim KC 85/3 mit abgespeichert wurden, steht vor den eigentlichen Daten als erstes Byte ein Kennbyte in der Datei.

Danach folgt bei den unkomprimierten Dateien der Inhalt des IRM als Speicherabzug. Bei den komprimierten Dateien kommt nach dem Kennbyte die Dekomprimierungsroutine als Unterprogramm (s.u.), danach folgen die komprimierten grafischen Daten. Die Gesamtlänge einer komprimierten Datei darf nicht größer sein als ohne Komprimierung!

Die folgende Tabelle stellt den Zusammenhang zwischen Kennbyte und Dateiinhalt dar, die vierte Spalte enthält die jeweiligen Adressen, welche bei allen o.g. Programmen verwendet werden und welche dann auch so im Vorblock stehen.

Alle Programme (bei "EDIPIC32" ähnlich) benutzen den Bereich von 03FFFH - 067FFH als Pufferbereich. Im Wesentlichen läuft das Speichern eines Bildes wie folgt ab, das Bild (die jeweilige Ebene beim /4) wird aus dem Bildspeicher in den IRM geladen, anschließend wird ein Komprimierungsversuch auf 4000H aufwärts durchgeführt.

Die Komprimierungsroutine gibt ein Fehlerkennbyte und im Register DE die Endadresse+1 der komprimierten Datei zurück, war alles in Ordnung, wird das Kennbyte auf 03FFFH eingetragen und die Datei gespeichert, kam eine Fehlermeldung, wird das Bild von 8000H auf 4000H mit einem LDIR-Befehl einfach umkopiert, das andere Kennbyte eingetragen und eine unkomprimierte Datei ausgegeben.

Beim Laden der Dateien läuft dies sinngemäß dann umgekehrt ab, also Laden der Datei auf 3FFFH, Kontrolle Kennbyte, wenn notwendig Dekomprimieren auf 8000H, wenn notwendig konvertieren von /3 nach /4 oder umgedreht und Retten der Datei in den Bildspeicher, bitte beachten, daß die PIC-Dateien bis 07200H reichen können!

Hires-Grafiken

Die Speicherung von HIRES-Grafiken in "DIASHOW" und "UNIPIC" wurde eingeführt, damit man aus der Dateierweiterung sofort auf den Dateiinhalt schließen kann und die Bilder nicht mit Lores-Grafik verwechselt werden können. Da diese Farbauflösung nur auf dem KC 85/4 existiert, wurde auf ein Kennbyte am Dateianfang verzichtet. Als Dateierweiterung ist vorgeschrieben:

HIP

IRM-Inhalt der Pixel-IRM-Ebene vom KC 85/4 im HIRES-Modus
(IRM-Ebene 0 bzw.2)

 

HIF

IRM-Inhalt der Color-IRM-Ebene vom KC 85/4 im HIRES-Modus
(IRM-Ebene 1 bzw.3)

Damit das ladende Programm erkennen kann, ob das Bild komprimiert wurde, ist eine komprimierte Datei selbststartend abgespeichert eine unkomprimierte nicht. Der Aufbau der Datei ist dann ähnlich wie oben, die unkomprimierten Dateien entsprechen dem Inhalt des IRM als Speicherabzug.

Bei den komprimierten Dateien kommt zuerst die Dekomprimierungsroutine als Unterprogramm (s.u.), danach folgen die komprimierten grafischen Daten. Die Gesamtlänge einer komprimierten Datei darf wieder nicht größer sein als ohne Komprimierung!

Nachfolgend die Tabelle:

Das Dateihandling beim Speichern in den Programmen läuft wie in der Lores-Variante ab, wobei eine komprimierte Datei dann als selbststartendes File ausgegeben wird. Dies ist besonders beim Laden zu beachten, "UNIPIC" verwendet dort eine zugeschnittene Laderoutine. Darin wird das 16. Byte des Vorblocks in 0B781H eingetragen und der Selbststart nicht ausgeführt. Nach der Rückkehr vom Ladeprogramm (vergleichbar mit FLOAD) kann man so anhand des Inhalts von 0B781H nachprüfen, ob die geladene Datei dekomprimiert werden muß.

Leider legt das originale FLOAD nirgendwo Informationen ab, wo man nachträglich feststellen kann, ob eine Datei selbstartend war, bei Interesse kann der Quelltext der kompletten Bildlade- und speicherroutinen hier auch veröffentlicht oder von mir bezogen werden, dies würde den Rahmen des heutigen Artikels sprengen.

Komprimierung / Dekomprimierung

Eine komplette Bildebene umfaßt auf dem KC 85/4 10 kByte, arbeitet man mit Farben, kämen pro Bild schon 20 kB zusammen, bei den HIRES-Bildern muß man den Color-IRM z.B. immer mit speichern. Bezieht man sich auf eine normale 780 kB-Diskette (max. 776 kB frei) bekäme man 38 komplette Bilder auf eine Diskette. Platz ist aber für max. 64 Bilder, wenn man immer die Farben hinzurechnet.

1990 war das noch nicht so wichtig, da spielte eine möglichst kleine Datei eine Rolle, da dann das Laden von Kassette schneller geht. Deshalb wurde von Anfang an eine Komprimierung der Bilddateien berücksichtigt, inzwischen hatte ich von Herrn Leubner die recht leistungsfähige Variante aus FRACTAL4 erhalten.

Sie eignet sich eigentlich für alle Komprimierungsaufgaben und entspricht der auch auf PC's eingesetzten RLE-Kodierung, im Wesentlichen werden ab 4 aufeinanderfolgenden gleichen Datenbytes ein Steuercode (1BH), das Datenbyte und die Anzahl der Datenbytes abgelegt, wo man ein Byte Speicherplatz gewinnt.

Sind mehr als 4 gleiche Bytes vorhanden, verkürzt sich die Dateilänge entsprechend, z.B. reduzieren sich durch diese Variante abgespeicherte HIRES-Grafiken von original 10 kB auf durchschnittlich 2...6 kB. Die Geschwindigkeit der Komprimierung/Dekomprimierung ist dabei noch so hoch, daß die entstehenden Verzögerungen beim Speichern oder Laden überhaupt nicht bemerkbar sind.

Bei der Definition der Bildformate hatte ich damals festgelegt, daß die Dekomprimierungsroutine immer am Anfang der jeweiligen Datei enthalten sein muß, dadurch kann man jederzeit das verwendete Komprimierungsverfahren ändern.

Der Nachteil, daß solche Dateien immer auf die originale Adresse geladen werden müssen, läßt sich verschmerzen, so viele Alternativen hat man bei 64 kB Speicher ohnehin nicht, wird der Bereich benötigt, muß man den Inhalt vorher woanders hinschieben und danach wieder zurückholen, unter CAOS ist der RAM8 gut geeignet, unter MikroDOS ist der Speicher im Grundgerät ab 04000H, zumindest jetzt noch, in der Regel unbenutzt.

Sowohl in der Lores-, als auch in der Hires-Variante beginnt die Dekomprimierungsroutine immer auf Adresse 04000H. Sie wird in meinen Programmen nach dem Laden und Feststellen einer komprimierten Datei mit CALL 4000 aufgerufen und entpackt den Dateiinhalt auf Adresse 08000H, also den standardmäßigen IRM.

Sollen der Inhalt der PIF- bzw. HIF-Dateien im COLOR-IRM landen, ist dieser vorher mit ESC"9" aktiv zu schalten, da EDMOV (s.u.) den IRM nicht verändert!!! Dadurch hat man beispielsweise die Möglichkeit ein zu ladendes Bild "unsichtbar" in das aktive, aber nicht angezeigte Bild des KC 85/4 zu laden (nach ESC"3" oder ESC"4") oder nach Wegschalten des IRM unter CAOS direkt in RAM-Blöcke auf Adresse 08000H zu entpacken.

Der nachfolgende Quelltext enthält die in "UNIPIC 1.0" eingesetzte Variante, sie wird für alle Dateien PIF/PIP/HIF/HIP eingesetzt, zur Nutzung ist die zu komprimierende Ebene auf 08000H zu laden und aktiv zu schalten, dann ruft man sie mit CALL EDCOM auf und entscheidet anhand dem Inhalt von A bei der Rückkehr, ob komprimiert gespeichert wird, in DE wird die Endadresse+1 der erfolgreich komprimierten Datei zurückgegeben.

Über die Steuerzelle COMNF läßt sich eine Komprimierung der Dateien grundsätzlich unterbinden, dann bringt die Routine sofort einen Fehler. Alles Weitere kann den Kommentaren im Quelltext entnommen werden.

;-------------------------------------------
;
COMNF   DEFB 1                ;Steuerzelle Komprimierung (aus=0/ein0)
;
EDCOM   LD A,(COMNF)
        OR A
        JR Z,EKO7             ;bei aus
        LD HL,EDMOV
        LD DE,4000H           ;Komprimierung auf 4000H
        LD BC,EDTOP-4000H
        LDIR                  ;Dekomprimierung eintragen
        LD HL,8000H           ;Ebene auf 8000H im Zugriff !!!
EKO0    LD A,0A8H             ;bis 0A800H
        CP H
        JR Z,EKO6             ;fertig und ok!
        LD B,1
        LD C,(HL)             ;Zeichen
        INC HL
        LD A,0A8H
        CP H
        JR Z,EKO3             ;Bildende
EKO1    LD A,(HL)
        CP C
        JR NZ,EKO2            ;ungleich
        INC HL
        INC B
        JR Z,EKO5             ;maximal 256 mal
        LD A,0A8H
        CP H
        JR NZ,EKO1            ;bis Bildende
EKO2    LD A,C
        CP 1BH
        JR Z,EKO5             ;1BH immer codiert
        LD A,B
        CP 4
        JR NC,EKO5            ;erst ab 4 Bytes Wdhlgn. eintragen
EKO3    LD A,C
EKO4    CALL EKOTE
        JR Z,EKO7             ;Fehler - Bild wird zu groß
        DJNZ EKO4
        JR EKO0               ;weiter
EKO5    LD A,1BH              ;Kennung
        CALL EKOTE
        JR Z,EKO7             ;zu groß
        LD A,C                ;Zeichen
        CALL EKOTE
        JR Z,EKO7             ;zu groß
        LD A,B                ;Anzahl
        CALL EKOTE
        JR Z,EKO7             ;zu groß
        JR EKO0               ;weiter
EKO6    XOR A                 ;A=0 ENDE o.k., in DE Endadresse+1
        RET
EKO7    LD A,1                ;A=1 ENDE FEHLER
        RET
EKOTE   PUSH BC
        LD B,A
        LD A,68H
        CP D                  ;=6800H ?
        LD A,B
        POP BC
        RET Z                 ;Z=1 Fehler
        LD (DE),A
        INC DE
        RET                   ;Z=0 o.k.
;
;-------------------------------------------
;
; -Dekomprimierungsroutine von 4000H auf 8000H
; -ist in jedem komprimierten Bild ab 4000H enthalten
; -kann vom übergeordneten Programm mit CALL 4000H auf-
; gerufen werden, vorher richtige IRM-Ebene zuschalten !!!
;
EDMOV   LD HL,EDTOP
        LD DE,8000H           ;Zieladresse beim Dekomprimieren
EMOV0   LD A,0A8H
        CP D
        RET Z                 ;fertig!
        LD A,(HL)
        INC HL
        CP 1BH                ;Kennung
        JR Z,EMOV1
        LD (DE),A
        INC DE
        JR EMOV0
EMOV1   LD A,(HL)             ;Zeichen
        INC HL
        LD B,(HL)             ;Anzahl
        INC HL
EMOV2   LD (DE),A
        INC DE
        DJNZ EMOV2
        JR EMOV0
EDTOP   EQU $-EDMOV+4000H     ;Länge + 4000H
;
; ab hier folgen komprimierte Bytes bis
; maximal 67FFH
;
;-------------------------------------------

Nutzung in anderen Programmen

Alle Programme von "EDIPIC" über "DIASHOW" bis "UNIPIC" enthalten eigene Laderoutinen, welche den Vorblock einer CAOS-Datei zwar voraussetzen, es aber zulassen, bei den unkomprimierten Dateien beliebige Adressen zu nutzen. Dies wurde in den beiden letztgenannten noch auf beliebige IRM-Abzüge erweitert

In "UNIPIC" wurde dann auch der Dateityp ".KCC" nicht mehr vorgeschrieben. Dort muß man nur noch sicher sein, daß in der Datei der IRM-Inhalt eines KC's enthalten ist und unter CAOS abgespeichert wurde. Über diese Schnittstelle (DIR auf ALL FILES) ist alles einlesbar, was in irgendwelchen CAOS-Programmen als SCREEN-DUMP gespeichert wurde.

Aus den Adressen im Vorblock wird die Dateilänge berechnet, wenn notwendig auf 02800H Bytes begrenzt und dann ab Adresse 04000H...06800H geladen. So bekommt man nahezu jede Datei in das PIP/PIF- oder HIP/HIF-Format.

Die unkomprimierten Varianten entsprechen nach Ergänzung des Kennbytes bei Lores und Wahl des zugehörigen Dateityps in Lores- und Hires-Variante im Wesentlichen einem SCREEN-DUMP. Dort ist auch kein Programmcode enthalten, so daß sie frei verschieblich sind, da sie beim Laden in meinen Programmen wie die SCREEN-DUMPS adressmäßig umgerechnet werden.

Diese Eigenschaften kann man nutzen, wenn man Grafiken aus eigenen Programmen so speichern will. Folgendes Beispiel habe ich in BASIC schon praktiziert:

1. Inhalt von 7FFFH in einer Variable merken
2. mit POKE auf Adresse 7FFFH das entsprechende Kennbyte bei Lores eintragen
3. mit VPOKE in 0B781H...0B785H IRM-Adressen eintragen (Anf.adr.: 7FFFH bei Lores, 8000H bei Hires / Endadr.: A800H)
4. NAME.PI_ bzw. .HI_ für das Bild ab Adresse 0 poken
5. mit CALL*DB FSAVE in SERVICE oder DIENST aufrufen
6. in 0B781H wieder 0 eintragen mit VPOKE
7. Variableninhalt wieder in 07FFFH eintragen

Sehr wichtig ist hierbei, man verletzt dadurch die soeben gemachten Vorschriften bezüglich der Adressen der Originale. Das wirkt sich bei meinen Programmen nicht aus, da sie selbst für den richtigen Platz im Programm sorgen.

Will aber ein anderes Programm beispielsweise eine PIP-Datei laden, stimmen die Adressen nicht mehr und die Datei gerät an die falsche Stelle im RAM, im ungünstigen Fall ist ein Absturz die Folge. Solche Bilder sollte man unter keinen Umständen weitergeben!

Der sicherste Weg besteht darin, die Dateien in eines der genannten Programme einzulesen und noch einmal abzuspeichern, dann stimmen die Adressen wieder, wenn man komprimiert speichert, spart man zusätzlich noch Speicherplatz auf der Diskette.

Alle Programmierer, denen eine Komprimierung zu umständlich oder kompliziert erscheint, sollten immer auf die unkomprimierte Variante ausweichen, dort hat man es am leichtesten, in der Lores-Variante ist nur das Kennbyte vorzusetzen, die Hires-Speicherung beim /4 entspricht dann einem Screendump mit vorgeschriebener Dateierweiterung!

Es sollten im Interesse aller KC-User allerdings nur Bilddateien in Umlauf gebracht werden, wo die oben genannten Adressen im Vorblock stehen. Man kann so beispielsweise alle unkomprimierten Dateien mit einem Offset von 4000H direkt in den IRM laden (vorher 7FFFH merken, danach wieder eintragen bei Lores).

Dies verbraucht nicht ein Byte zusätzlichen Speicherplatz für die Bildpufferung, es funktioniert aber nur wenn die Adressen richtig eingetragen sind!!! Weiterhin halte ich es für wichtig, daß die benutzten Dateierweiterungen auch nur verwendet werden, wenn der eben beschriebene Aufbau zu 100% eingehalten wird. Wer möchte, kann ja eigene neue Bildformate erfinden, dann bitte aber nicht mit PIC/PIP/PIF- oder HIP/HIF-Erweiterung.