Kassettenformate

Das Kassetten-Magnetband-Interface des Z9001, ein Diphase-Verfahren, wurde von Dr. Ulrich Kordon entwickelt, als ausreichend sicher gefunden und auf alle DDR-HC übernommen.

Deshalb benutzt der Z9001 im Prinzip das gleiche Kassettenaufzeichnungsformat wie auch die Mühlhauser Rechner HC900 und Nachfolger. Aber - leider nur im Prinzip:

• Systemprogramme beginnen mit dem Block Nummer 0 und haben als Endekennung den Block Nummer 255 (0FFh). Beim HC900 beginnen Systemprogramme mit dem Block Nummer 1. Das übersehen leider viele Tools und Emulatoren.
• Der HC900 interpretiert den Kopfblock anders: Hier können bis zu 9 Parameter genutzt werden; beim Z9001 sind es 3 (AADR, EADR, SADR).
• Basic-Programme beginnen mit dem Block Nummer 1.
• Ab dem KC 87.2x werden Basic-Programme mit einem willkürlichen Block Nummer 0 begonnen, dann folgt das BASIC-Programm, dann folgt manchmal noch ein willkürlicher Block Nummer 255. Diese Außenblöcke stören nur und können gefahrlos entfernt werden.
• Es gibt Programme, die nicht die Systemroutinen zum Speichern nutzen und die aufeinanderfolgende Blocknummerierung durcheinanderwirbeln. Hierzu gehören z.B. relokatible Programme wie OS-SAVE.

Basic-Programme

Basic-Programme haben am Anfang 3x dasselbe Zeichen: 0D3h für Basic-Programme, 0D4h für Basic-Data-Feld-Dateien, 0D5h für ASCII-Listings. Wurde ein SAVE-Schutz mittels POKE 861,<>0 eingeschaltet, erhalten die BASIC-Programme die Codenummern 0D7h, 0D8h bzw. 0D9h. Dann folgen 8 Zeichen für den Dateinamen (mit Leerzeichen aufgefüllt).

Neben dem Standardformat zum Speichern aus Kassette gibt es eine Reihe weiterer Formate:

• BASICODE
• TURBO (mit doppelter Frequenz sichern)
• TURBO (dem C64 nachempfunden - mit flackerndem Bildschirmrand)
• …

TAP Arne Fitzenreiter:

• 16 byte Header mit „KC-TAPE by AF“
• 129 byte Blöcke mit Blocknummer aber ohne Prüfumme
• TAP hat sich als Standardformat für Emulatoren und Tools durchgesetzt

Es können mehrere Files hintereinander gespeichert werden. Dazu werden die einzelnen Files einfach zusammengehängt (einschließlich des 16 byte Headers).

GPF/GBF (ganz alter »GEMINI« KC85/3 Emulator):

• 128 byte Header mit Text-Markern
• 128 byte Blöcke ohne Blocknummer und Prüfsumme
• *.GPF sind COM-Files, *.GBF sind Basic-Files

KCC (Haftmann-Emulator u.a.):

• 128 byte Header kompatibel zum originalen Tape-Header
• 128 byte Blöcke ohne Blocknummer und Prüfsumme

KCT (T.Paul-Emulator):

• blockorientiertes Format, die Dateien werden komprimiert gespeichert (zlib)
• es existiert ein extra Inhaltsverzeichnis, in dem Namen, Adressen und Typen gespeichert sind
• Intern werden die Dateien mit 129 byte Blöcken gespeichert, also mit Blocknummer aber ohne Prüfsumme

Zum Konvertieren der Kassetten habe ich mit das Programm KCLOAD des Haftmann-Emulators umgeschrieben, so daß ich TAP-Dateien erzeugen kann (Achtung: nur Laden funktioniert noch!). Der Modus „Z9001-all(TAP)“ lädt unabhängig von der Blockreihenfolge. Liegt länger als 1/2 Sekunde kein Signal an, wird das Einlesen beendet.

Ich habe die Kassetten einfach mit einem Soundtool und 22KHz, 8bit,mono aufgenommen und dann mit meinem modifizerten KCLOAD in TAP-Dateien konvertiert. (Aufnahme vom WAVE-Mapper, im Lautstärkeprogramm die Aufnahmequelle Stereo-Out (linker Kanal), oder WAVE wählen; bei direkter Aufnahme vom angeschlossenen Kassettenrecorder natürlich diesen auswählen).
Bei Lesefehlern kann man - wie auch beim direkten Anschluß eines Kassettenrecorders - einfach ein Stück zurückspulen oder zur Kopie weiterspulen

Zum Konvertieren zwischen TAP und KCC nutze ich mein KC-SAVE und ein paar kleine Perl-Programme, für den Paul-Emulator gibt es das Programm kctape und selbst eine ganze Reihe Utilities.

Zum Anschauen und auch Konvertieren der Emulator-Dateien gibts von mir noch ein kleines Plugin für den TotalCommander. Details siehe PC Emulation Tools.