Contact us
Leave a message

Mitglied bei

Logo "Bündnis '90/Die Grünen"
B'90/Grüne, OV Lehrte
Logo "Gospelchor 'Swing Low', Markus-Gemeinde, Lehrte"
Gospelchor "Swing Low", Markus-Gemeinde, Lehrte
Logo "Verein zum Erhalt klassischer Computer"
Verein zum Erhalt klassischer Computer

Das Rauschen der Bits

Datentransfer C64 <=> PET via Datasette

Mit dem Erwerb eines gebrauchten CBM 3032 stellte sich die Frage, wie all die zu Schulzeiten mühsam eingetippten und auf Diskette gespeicherten Basic-Spiele wiederbelebt werden könnten. Zum Glück ließ sich die alte Datasette 1530 wieder auftreiben, die ich ursprünglich zum C64 bekommen hatte (damals, als Diskettelaufwerke noch um die 1000 und 5 1/4-Zoll-Disketten pro Stück um die 10 DM kosteten...). Dieser modifizierte Kassettenrecorder sollte kompatibel mit beiden Geräten sein, und so lag es nahe, einen -- wie man heute wohl sagen würde -- Workflow mit folgender Pipeline zu implementieren:

Floppy-Laufwerk 1541 --> C64 --> Datasette 1530 --> CMB 3032

Haste gedacht...!

Beim C64 werden Basic-Programme bei Angabe der Sekundäradresse 0 (oder Weglassen einer solchen) immer an den Anfang des Basic-RAMs geladen -- also an die Adresse $0801. Dies klappt auch wunderbar mit den auf dem CBM erstellten Programmen, dessen Basic-Speicher ja bei $0401 beginnt. Das Laden der alten CBM-Spiele von Diskette funktionierte daher absolut problemlos.

Konnte man jedoch ahnen, dass die alten CBM-Geräte die automatische Relokation von Basic-Programmtext noch nicht beherrschen? So musste ich leider feststellen, dass die vom C64 aus auf Band gespeicherten Programme beim Laden in den CBM stumpf an die von ersterem in den Header geschriebene Ladeadresse $0801 geladen werden -- und nicht an den Anfang des CBM-Basic-RAMs bei $0401!

Die Rettung...

...liegt in der flexiblen Speicherverwaltung des C64. Folgendes Progrämmchen konfiguriert den 64er so um, dass er sich in wesentlichen Dingen wie ein PET verhält -- insb. wird der Basic-Start nach $0401 und das Video-RAM (von $0400) nach $8000 verschoben:

Das Programm...
...und seine Ausgabe. Die freien Bytes sind gemogelt -- tatsächlich gibt FRE(0) 2 Bytes weniger aus -- und ich habe nicht die geringste Ahnung, wo die abgeblieben sind.

Und so funktioniert's:

Nach Definition einiger Konstanten (Zeile 100) wird in Zeile 110 zunächst die Speicherbank 2 des VIC ausgewählt (binär %10; allerdings haben die Bits 0 und 1 im Data-Port A-Register der CIA 2 eine inverse Bedeuting, daher das OR mit %01). In Zeile 120 wird das obere Nibble des VIC-Basis-Adressregisters genullt, um das Video-RAM direkt an den Anfang der ausgewählten Speicherbank ($8000) zu legen. Zeile 130 teilt diese Änderung dem Betriebssystem mit, so dass PRINT (bzw. die BSOUT-Routine) weiterhin zur Ausgabe auf dem Bildschirm führen. In Zeile 140 wird der NMI-Vektor direkt auf einen RTI-OpCode umgelenkt, um RUN-STOP/RESTORE zu unterbinden. In den drei Folgezeilen wird der Anfang (150) und das Ende (170) des Basic-RAMs neu festgelegt ($0401 bzw. $8000), wobei dem Rechnung getragen wird, dass der Basic-Interpreter im Byte direkt vor dem Basic-Start gerne eine 0 stehen haben möchte. Ab Zeile 200 werden noch PET-ähnliche Farbeinstellungen vorgenommen (schade, dass der C64 nur ein so verwaschenes Grün und so fette Zeichen produziert) und in Zeile 230 ein NEW durchgeführt, was -- davon abgesehen, dass der Programmtext nach Verschieben des Basic-Speichers sowieso nicht mehr für den Editor sichtbar ist -- den angenehmen Nebeneffekt hat, dass auch CLR aufgerufen und alle Variablenzeiger den veränderten Bedingungen angepasst werden.