KC-News 1/2006

Transfer von Programmen und Grafiken zwischen verschiedenartigen Computern

von Thomas Rademacher

In der Zeit vor der Marktherrschaft der Windows-PCs gab es mehrere Dutzend verschiedene Heimcomputer unterschiedlicher Hersteller, zu einigen davon sind heute noch Clubs aktiv. Der folgende Artikel soll sich damit befassen, welche Möglichkeiten es gibt, trotz zunächst bestehender Verständigungsprobleme einen Datenaustausch zwischen diesen Oldies zu ermöglichen.

Mein Startcomputer war der KC compact, eine nichtautorisierte Weiterentwicklung des Amstrad CPC. Das Gehäuse hatte er vom Bildungscomputer A 5105 übernommen, eine Drittverwendung dieses Gehäuses ist die Komforttastatur D005 als Ersatz für die ursprüngliche Tastatur des KC 85.

Der Bildungscomputer A5105

Mit dem Bildungscomputer sollten die DDR-Schulen flächendeckend ausgestattet werden, als Komplettgerät war es ein CP/M-Computer mit 5,25-Zoll-Diskettenlaufwerk, jedoch mit dreikanaligem Sound über acht Oktaven und mit sechzehn Farben. Zwar ging das über die üblichen Eigenschaften von CP/M hinaus, doch war zu dieser Zeit anderswo die Verdrängung dieses 8-Bit-Betriebssystems durch DOS und später Windows bereits im vollen Gange.

Der BIC war auch unter der Bezeichnung K1505 bekannt und das separat betreibbare Grundgerät wurde unter dem Namen ALBA-PC auch exportiert.

In die Entwicklung des BIC sind offenbar Erfahrungen aus der Arbeit mit verschiedenen anderen Computern, die es davor gab, eingeflossen. So sind zum Beispiel (wie beim C64) Text- und Grafikbildschirm in unterschiedlichen Speicherbereichen abgelegt und können sich nicht gegenseitig störend beeinflussen. Einen Grafikbildschirm der Breite 640 Pixel kenne ich vom CPC und Commodore 128. Auch der Screen-Editor und das Auslösen häufig benötigter Funktionen durch F-Tasten, die man auch selbst neu belegen kann, scheint vom C64 inspiriert zu sein. Die Möglichkeit, für Grafikanweisungen Makros anzuwenden, erinnert mich wiederum an die Turtle-Grafik von DR-Logo auf CP/M-Computern. Wie der Sinclair ZX Spectrum durch das Interface I netzwerkfähig wird, ist der BIC von Haus ebenfalls auf die Arbeit in einem lokalen Netzwerk vorbereitet. Daß bereits das Basic Befehle für die Arbeit mit

Direktzugriffsdateien bereitstellt, kenne ich vom Mallard Basic des Amstrad PCW. Ein ROM-Basic hatten auch noch die ersten mit DOS laufenden IBM-PCs. In allen Punkten bringt der BIC aber auch Verbesserungen mit sich, so verfügt er über einen 40- und einen 80-Spalten-Textmodus (beide können je nach Wunsch auch mit zusätzlichem Abstand zwischen den Textzeilen genutzt werden) und über drei verschiedene Grafik-Modi.

Allerdings kannte ich vom BIC jahrelang nur den Artikel, der ihn in einer Elektronikzeitschrift (Mikroprozessortechnik 10/1988) vorstellte. Es sollte bis 1999 dauern, daß ich den Computer bei einem Tag der offenen Tür an einem hiesigen Gymnasium einmal zu Gesicht bekam, arbeiten sah ich ihn zum ersten Mal auf einer Commodore-Party Anfang Mai 2004 in Hohenstein-Ernstthal, wohin Ralle sein wohl frisch erworbenes Modell mitgebracht hatte.

Torsten Pauls KC-Emulator

Vor ein paar Wochen entdeckte ich, daß Torsten Pauls KC-Emulator mittlerweile auch den BIC emulieren kann.

Der Emulator befindet sich zwar noch im Beta-Stadium, hat z.B. noch keine Soundfunktionen und kann Disketten(-abbilder) nur lesen, das “Beschreiben“ mußte ich deswegen mit einem Hex-Editor realisieren. Trotzdem nutzte ich die Gelegenheit, den BIC auf diesem Wege endlich etwas näher kennenzulernen.

Über den Autor

Nun wird es langsam Zeit, daß ich mich erst einmal vorstelle. Ich bin ein Computerhobbyist, der zur Wende 31 Jahre jung war, in der Schule oder in AGs also Computer nicht mehr kennengelernt hatte.

Ein Schwerpunkt meiner Freizeitbeschäftigung wurde im Laufe der Zeit BasiCode, eine Entwicklung niederländischer Computerenthusiasten, die Basic-Programme auf andere Computer übertragbar und dort nutzbar werden läßt.

Hierdurch (und möglicherweise auch zur Kompensation der Computerlosigkeit meiner Jugendjahre) befaßte ich mich nach und nach auch mit anderen Computern, zunächst als Hardware, aber zunehmend auch als Emulation unter DOS oder Windows.

Was ist BasiCode?

Dieses Thema haben zwei Hobbykollegen und ich bereits in den KC-News 1/99 vorgestellt. BasiCode ist kurz gesagt eine gemeinsame Bedienoberfläche für unterschiedliche Computer. Von daher liegt ein Vergleich mit CP/M nahe (Software-Pool für Computer mit unterschiedlichem Hardwareaufbau), jedoch ist das ursprüngliche Speichermedium die Kassette, vor zwanzig Jahren waren Disketten für Heimcomputer noch die Ausnahme und sehr teuer. Heutzutage können BasiCode-Programme selbstverständlich auch per Diskette übertragen werden, ebenso wie die Nutzung nicht auf 8-bit-Oldies beschränkt, sondern auch unter DOS oder Windows möglich ist.

Version 3C für BIC

Was lag für mich also näher, mich ein wenig mit dem (emulierten) BIC vertraut zu machen, als mir einmal seine Umsetzung von BasiCode (siehe Bild 14) anzusehen? Hier überraschte mich ein Konzept, wie ich es bisher noch auf keinem anderen Computer gesehen hatte: menügeführt wird man bis zum lauffähigen Programm (Bild 14 rechts unten) geleitet.

Für mich waren beispielsweise die Menüpunkte O (zum Einlesen des Programmlistings von der Diskette, Bild 14 oben) und G (zur Komplettierung durch die Bascoderroutinen, Bild 14 links unten) von Belang. Interessant hierbei ist, daß Funktionen, die vom Programm (genauer: vom übertragbaren Teil ab Zeile 1000) nicht benötigt werden, im Bascoderteil weggelassen werden. Verwendet ein Programm beispielsweise keine Soundausgabe, gibt es im computerspezifischen Teil (unterhalb der Zeile 1000) auch keine Subroutine 450. Das ist auf alle Fälle sinnvoller als pauschal alles zu linken, was zur Verfügung steht, egal, ob es tatsächlich gebraucht wird, wie man es von Compilern schon aus der CP/M-Zeit kennt und wie es heute in Form von Dynamic Link Libraries (DLLs) unter Windows allzu bekannt ist.

Nun entdeckte ich auch gleich ein Projekt, an dem ich mich im Zurechtkommen mit der Programmierung testen konnte: der Bascoder war auf dem Stand der Version 3, enthielt noch nicht die zusätzlichen Funktionen des 1991 vorgestellten Standards 3C. Zwar gibt es vielleicht nur ein halbes Dutzend Programme, die die Möglichkeiten der Farbversion nutzen (zu schnell ebbte nach der Maueröffnung bei den meisten das Interesse an den Oldies ab, man kam jetzt an AMIGAs, ATARIs und sogar PCs – auf SEGA und Nintendo will ich an dieser Stelle mal nicht eingehen – und an deren leistungsfähigere Software heran), doch wenn der BIC einmal Farben kann, ist es doch einen Versuch wert.

Die neuen Funktionen der Version 3C von BasiCode sind in BASC3C.ASC beschrieben: es stehen jetzt acht Farben zur Verfügung, beim Zurücklesen aus dem Bildschirm kann jetzt zwischen Groß- und Kleinbuchstaben unterschieden werden.

Außerdem besteht die Möglichkeit, bei der Tastaturabfrage die F-Tasten zu erkennen, doch das halte ich für wenig zweckmäßig. Oft sind diese Tasten bereits mit Funktionen belegt und daher gar nicht z.B. für die Auswahl aus Menüs oder sonstige Verwendung verfügbar. Da viele der Oldie-Computer gar keine F-Tasten haben, steht es obendrein im Widerspruch zum angestrebten Ziel der Übertragbarkeit der Programme. Deswegen habe ich auf die Umsetzung dieser Funktion verzichtet.

Das Resultat ist die Datei INITCOLO.URS. Das gewünschte Programm (z.B. OTHELLOC.ASC) wird in gewohnter Weise vorbereitet und, wenn es sich um ein Farb-Programm handelt, vor dem Starten lediglich INITCOLO.URS hinzugeMERGEt.

Stilgerechter wäre gewesen, die neuen Funktionen entsprechend dem bisherigen Konzept mit in BACD3BIC.RMC hineinzuarbeiten, doch dafür fehlt mir als Neuling auf diesem Gerät natürlich die Programmiererfahrung.

In der derzeitigen Version des Emulators stimmen noch nicht alle Farben, ich habe sie so programmiert, daß sie auf der Originalhardware (hoffe ich jedenfalls) richtig dargestellt werden und bin zuversichtlich, daß es mit einer späteren Version des Emulators dann auch auf der virtuellen Maschine stimmen wird. Interessieren würde mich einmal die Arbeitsgeschwindigkeit des Originalgerätes – auf dem emulierten BIC zieht sich so eine Reversi-Partie über mehrere Stunden hin, was allerdings auch damit zusammenhängen kann, daß mein Notebook schon etwa zehn Jahre alt ist...

HRG-Transfer

Ermutigt von dem Erfolg nahm ich gleich das nächste Projekt in Angriff. Dieses kann als Ergänzung zu BasiCode gesehen werden, ist ihm zumindest vom Ansatz her sinnverwandt.

Seine Wurzel hat es mehr oder weniger in einem Tool, das 2001 spontan auf einem CPC-Treffen in Erlangen entstand, die Geschichte wurde schon in den KC-News 2/01 erwähnt. Auch in Erlangen war Ralle zugegen. Eine Grafik, die ich (damals noch als Binärdatei) von einer Diskette des Plus/4-Clubs auf den CPC übertragen hatte, gefiel ihm so gut, daß er sie unbedingt auf dem KC haben wollte. So knobelten wir auf die Schnelle eine Möglichkeit aus, sie auf Diskette abzuspeichern und von dieser Diskette in seinen KC einzulesen.

Die damalige Spontanlösung war äußerst umständlich, aber inzwischen habe ich die Methode optimiert und verfeinert und auch noch auf diversen anderen Computern nutzbar gemacht.

Die Grafikdaten werden in eine Textdatei umgewandelt, ein Buchstabe verschlüsselt jeweils vier benachbarte Pixel (Bild 15 oben). Binärdateien würden im Vergleich zu ASCII-Dateien zusätzliche Probleme bei der Übertragung bringen. Diese Textdatei wird auf dem Zielcomputer eingelesen und dort wieder zurückgewandelt.

Auf den meisten Computern repräsentiert das höchstwertige Bit eines Bytes aus dem Grafikspeicher den am weitesten links liegenden Punkt einer Gruppe benachbarter Pixel.

Unterschiedlich ist jedoch die Reihenfolge dieser Bytes, am schwersten überschaubar nebenbei bemerkt auf dem KC 85/3.

Auf dem BIC ist es umgekehrt – die Byte-Reihenfolge ist unkompliziert (einfach wie beim Lesen und Schreiben, von oben nach unten zeilenweise von links nach rechts), aber hier ist die Zuordnung der Pixel zu den Bits gegenläufig, das höchstwertige Bit steht für den am weitesten rechts liegenden Punkt einer Pixelgruppe.

Außerdem gehören mehrere Bits zu einem Pixel: welche gesetzt oder nicht gesetzt

sind, entscheidet über die Farbe, in der der Punkt am Ende auf dem Monitor sichtbar wird.

Daher rührt, daß der BIC im SCREEN 5 sechzehn Farben darstellen kann, wenn alle vier Bits gesetzt sind, ist die Farbe weiß (Bild 15 unten links). In SCREEN 3 gehören zu jedem Punkt zwei Bit, deswegen sind hier nur vier Farben darstellbar (Bild 15 unten rechts). Ich habe in beiden Grafikbetriebsarten jeweils alle Pixel gesetzt.

In SCREEN 3, der Grafikbetriebsart mit 640 Pixeln Breite, stellt der Emulator leider noch nicht die rechte Hälfte des Bildschirms dar, hierfür mußte ich das Programm geringfügig abändern (und die beiden Hälften auf dem PC nebeneinanderstellen).

Bild 16: Grafik in der Grafikbetriebsart SCREEN 3, auf dem PC zusammengesetzt.

Vorläufig realisiert das Programm HRGIMPRT.ASC nur das Einlesen von Grafiken in den BIC, die umgekehrte Richtung kann ich auf dem virtuellen Gerät nicht testen, solange das Schreiben auf Disketten noch nicht emuliert wird. Wer, vielleicht auf der Originalhardware, den Export programmieren möchte, der hat freie Bahn, ich stelle es jedem frei, das Programm zu vervollkommnen.

Der Aufbau einer .HRT-Datei ist in den REM-Zeilen kurz skizziert, ausführlichere Informationen und mehr umgewandelte Bilder kann man im WWW finden.

Auf dem KC 85/3 und /4 bin ich mit diesem Programm schon weiter, möchte ihm vor einer Veröffentlichung aber noch den letzten Schliff geben, vielleicht klappt es ja schon bis zur nächsten Ausgabe der KC-News.

Die besprochenen Programme stehen hier einzeln zur Verfügung, sind aber auch alle im Teledisk-Abbild BASICODE.DUMP enthalten, so daß sie unter der Emulation oder nach Übertragung auf eine reale 5,25-Zoll-Diskette auf dem Originalgerät ausprobiert werden können.

Dateien

Im Archiv TRANSFER.ZIP sind unter anderem die folgenden Dateien zu finden:

BACD3BIC.RMC

Der beim BIC-Download fehlende Maschinencode zum Bascoder

INITCOLO.URS

Das Farb-Update zu BasiCode-3, bei Farbprogrammen (sonst aber auch nicht schädlich) vor RUN hinzuzuMERGEn

HRGIMPRT.ASC

Der Grafik-Transfer, jetzt für drei Formate

BIC?.BMP

Screenshots des BIC-Emulators mit je einem der Formate. Das 640-Pixel-Breite-Format wird leider (ich denke, ein Bug der Noch-Beta-Version des Emulators) nur in der linken Hälfte angezeigt, daher habe ich den Emulator ein zweites Mal gestartet und zwei Kommandos eingefügt, um (auf der linken Seite) auch die rechte Hälfte sehen zu können. Ich bin gespannt, ob es auf der Originalhardware funktioniert, auf die Dauer, ein Bild zu laden (hat vor allem für BIC3.BMP Stunden gedauert, was aber auch an der Betagtheit meines Notebooks liegen kann).

BASICODE.DUMP

Abgewandelte Systemdiskette (Teledisk-Abbild) Ich hoffe, mit Teledisk läßt sich daraus eine echte 5,25“-Diskette bespielen...

Änderungen:

• • Systemdatei in USER 1 verschoben (mit Hex-Editor – Emulator kann bisher nur lesen), damit Computer im RBASIC bleibt 
  • AUTOEXEC.BAS lädt BASICODE.BAS 
  • Directory umsortiert, BasiCode-Sachen sind vornedran, Grafik-Transfer-Sachen am Ende

Weiterführende Informationen:

• DDR-Computer-Oldies: https://www.robotrontechnik.de/
• KC-Emu: https://kcemu.sourceforge.net/
• PDFs zum BIC: http://www.sax.de/~zander/bic/bc_bedal.pdf u.a.
• Wikipedia-Artikel: http://de.wikipedia.org/wiki/BASICODE
• Website: http://www.basicode.de/
• YAHOO-Forum: http://groups.yahoo.com/group/basicode
• Grafiktransfer, weitere HRT-Dateien in unterschiedlichen Formaten: https://www.joyce.de/software/grafik/grafik.htm