CPC-Bilder auf dem JOYCE

Übertragung von Grafikdaten als ASCII-File

Der Schneider JOYCE war, nicht zuletzt wegen der einseitigen Strategie seiner Vermarktung in Deutschland, als "Nur-Büro-Computer", als pures Textsystem, verschrieen. Wir JOYCEr wissen natürlich, daß er eine ausgezeichnete 720 * 256 - Pixel - Grafikmaschine darstellen kann. Solche Fähigkeiten, die von DR LOGO oder dem grandiosen Micro Design genutzt werden bzw. mittels der Systemerweiterung GSX nutzbar sind, stehen leider unter Mallard Basic nicht zur Verfügung, jedenfalls nicht (wie beim Locomotive Basic des CPC) von vornherein. Das ist in der Hinsicht bedauerlich, daß Basic wohl immer noch für die meisten Anfänger der Einstieg in eigene Programmierversuche ist.

Den Tüftler verlockt es natürlich, aus dem Computer herauszuholen, was er angeblich nicht kann. So hat sich erwiesen, da der JOYCE, von der Mehrfarbigkeit abgesehen und betreffs des Sounds, nun ja, mit Einschränkungen, in der Lage ist, die Normen von BasiCode-3C zu erfüllen, womit sich auf einen Schlag ein beachtlicher Programmpool erschließt.

Programme lassen sich also von anderen Computern (in Zeiten der schieren PC-Übermacht müssen wir verbliebenen 8-bit-Nostalgiker enger zusammenrücken) transferieren, Sounds vergessen wir mal ganz schnell - und wie sieht es mit Grafiken aus? Für monochrome Grafiken, die gewöhnlich zugleich die hochauflösenden sind (Mehrfarbigkeit geht bei unseren Oltimern in der Regel zu Lasten der Auflösung) gilt bei allen mir bekannten Computern (ich beschäftige mich mit verschiedenen - realen und emulierten - Oldies), daß jeweils acht waagerecht nebeneinanderliegende Pixel durch ein Byte zusammengefaßt werden und der am weitesten links liegende Bildpunkt durch das höchstwertige Bit repräsentiert wird.

Unterschiede gibt es in der Reihenfolge, in der diese Bytes im Speicher abgelegt werden: überraschenderweise zeigt sich hier übrigens, daß der JOYCE mehr Gemeinsamkeiten mit dem Commodore 64 als mit dem Schneider/Amstrad CPC hat. Bei beiden wird der Bildschirm sozusagen buchstabenweise beschrieben, also erst ein 8 * 8-Pixel-Block, dann der nächste daneben usw. Außerdem ist bei beiden die Nutzung von Pixelgrafik unter Basic mit Klimmzügen verbunden, beim JOYCE noch durch den Roller-RAM verschärft...

Am einfachsten wäre es (ähnlich, wie es bei savepic unter LOGO geschieht), einen Grafikspeicher-Abzug als Binärdatei zu speichern. Doch erstens hat Mallard Basic auch dafür keinen Befehl und zweitens würden andere Computer diese Bytes in ganz anderer Reihenfolge auf den Bildschirm bringen.

Die Bytes eines Grafik-Speicher-Abzugs hätten den Wertevorrat von 0 (kein Pixel gesetzt, alles Hintergrundfarbe) bis 255 (alle 8 Pixel gesetzt, Vordergrundfarbe). Das würde auf manchen Computern auch ungewollte Reaktionen wegen Interpretation mancher Bytes als Drucksteuerzeichen hervorrufen. Besinnen wir uns deswegen wieder auf BasiCode und erinnern uns, daß für die Datenübertragung der ASCII-Code verwendet wird.

Wollen wir nun Bilder als ASCII-Dateien codieren und verbreiten, müssen wir uns auf den Bereich von 32 bis 127 einschränken. Darunter liegen die eben erwähnten Steuercodes und darüber ist der ASCII-Code "zu Ende", ihm stehen nur sieben Bit zur Verfügung.

Man könnte zum Beispiel jedes Byte in zwei Halbbyte aufspalten, das wäre jeweils ein Wertebereich von 0 bis 15. Das liegt nun aber endgültig mitten in den Steuercodes, also addieren wir zu jedem Halbbyte, sagen wir, 64 und verlagern so den Wertevorrat in den Bereich von 64 bis 79, wunderschöne ASCII-Zeichen (das §-Symbol und die Großbuchstaben von A bis O).

Eine Pixelzeile von z.B. 320 Pixeln würde also statt 40 Byte als Zeichenkette von der Länge 80 codiert. Auch hier gibt es schon wieder Computer, über deren Grenze das liegen würde, deswegen machen wir zwei Zeichenketten von je vierzig Zeichen Länge daraus.

An dieser Stelle muß ich schon einmal offenbaren, daß ich von einem Format von 320 * 200 Pixeln ausgehe, das ist recht verbreitet. Es entspricht 40 * 25 Textzeichen, das ist die Bildschirmgröße des am weitesten verbreiteten Heimcomputers Commodore 64, auch der Schneider CPC hat in MODE 1 diese Auflösung. Nichtsdestotrotz kann jeder das Protokoll an seine Bedürfnisse anpassen, Näheres folgt. Man würde also 400 Zeichenketten der Länge 40 zu übertragen haben.

Um nicht das Rad komplett neu zu erfinden, suchte ich einen Standard, auf dem die Angelegenheit aufbauen könnte. Dabei fiel meine Wahl zunächst auf das BMP-Format von MS Windows - bei Abspeicherung als Schwarz-Weiß-Grafik, Farbe wollen wir weiter außen vor lassen.

Doch dann fand ich in einer Zeitschrift von 1986 einen Artikel, in dem ganz ähnliche Gedankengänge beschrieben werden und der ein Codierungsver-fahren vorstellt, das die Redaktion der Sendung "Computerclub" des WDR-Fernsehens entwickelt hatte, um HiRes-Grafiken per DFÜ übertragen zu können.

Der Unterschied ist, daß damals je sechs Pixel zusammengefaßt wurden, das erfordert weniger Speicher- und Übertragungskapazität. Inzwischen ist die Technik so rasant fortgeschritten, daß man da (zugunsten einer bequemeren rechnerischen Handhabbarkeit) ruhig verschwenderischer sein kann.

Somit hat eine Grafik-Transfer-Datei (die ich durch die Erweiterung "HRT" wie HiRes-Transfer kenntlich mache) folgenden Aufbau:

Das Programm HRGIMPRT.BAS ermöglicht, Grafiken aus MODE 1 (320 * 200) und MODE 2 (640 * 200) des CPC, die dort in eine .HRT-Datei umgewandelt wurden, auf dem JOYCE einzulesen und wieder als Grafik darzustellen. Entsprechende Programme habe ich in mehr oder minder fortgeschrittenem Stadium auch für den C 64, C +4, KC 85/4 sowie BASICA und QBASIC für DOS-PC.

Als Beispiele liegen einige Grafiken und .HRT-Dateien bei, eine davon in MODE 2-Auflösung. Weiterhin die 'Import-Programme' für CPC, JOYCE und DOS.

Thomas Rademacher ... im Oktober 2003