Das Kassetten-Magnetband-Interface des Z1013 ist ein Diphase-Verfahren. Es kam speziell auf dem Z1013 zum Einsatz und ist auf anderen Computern nicht verbreitet.

Das Kassetten-Magnetband-Interface wurde vom Poly-Computer 880 übernommen, nur mit anderer Bitrate. Das ist gut in der Monitorbeschreibung (ASM-Quellen) zu vergleichen: Es ist derselbe Code! Später wurde das Verfahren auch beim AC1 (SCCH) als „Turbo“ verwendet (wieder andere Bautrate).¹⁾

Aufgezeichnet wird in Blöcken zu je 32 Byte. Jeder Block besteht aus einem Kopf: einem einzelnen Word 0000h, sowie den Daten; gespeichert als 10h Words. Anschließend folgt eine Prüfsumme (wieder ein Word) über den Datenblock. Tatsächlich werden also pro Block 36 Byte aufgezeichnet.

Programm:

Die Aufzeichnung erfolgt in Blöcken zu je 32 Datenbytes. Jeder Block hat folgenden Aufbau:

1. Vorton: 14 Halbschwingung a 640 Hz, beim ersten Block 2000 Schwingungen
2. Trennschwingung: 1 Vollschwingung a 1280 Hz
3. Blocknummer: 16 Bit, Bedeutung siehe „logisches Aufzeichnungsformat“
4. Datenbereich: 32 Bytes in Form von 16 Datenwörtern
5. Prüfsumme: 16-Bit-Addition über die Blocknummer und die 16 Datenwörter

Die Datenwörter sind Little-Endian-kodiert, d.h. niederwertiges Byte zuerst. Es wird jeweils das Bit 0 zuerst gespeichert.

Bit-Codierung: 0-Bit: 1 Vollschwingung mit 2560 Hz (2 Phasenwechsel nach jeweils 0,39 ms) 1-Bit: 1 Halbschwingung mit 1280 Hz (1 Phasenwechsel nach 0,78 ms)

Mit Blocknummer und Prüfsumme zusammen besteht ein Block damit aus 36 Byte (= 18 Word).

Es werden immer vollständige Blöcke aufgezeichnet, auch wenn die angegeben Endadresse in der Mitte eines Blocks liegt. Zwischen zwei Blöcken, d.h. zwischen dem letzten Phasenwechsel der Prüfsumme und dem ersten Phasenwechsel des Vortons, gibt es eine etwa 2,5 ms lange Pause.

Damit passen ca. 400 KByte auf eine Kassettenseite (30 min)!

Die Aufzeichnung enthält ausschließlich den zu sichernden Speicherbereich ohne jegliche Verwaltungsinformationen.

Die Blocknummer wird außer zur Berechnung der Prüfsumme inhaltlich nicht verwendet und kann deshalb jeden beliebigen Wert enthalten. Die originalen Monitorprogramme schreiben als Blocknummer immer 0000h.

Block:

Beim Headersave-Format wird ein zusätzlicher Kopfblock mit Verwaltungsinformationen (Anfangs-, End- und Startadresse, Dateityp, Headersave-Kennung, Dateiname) vorangestellt. Dieser Kopfblock und der erste nachfolgende Datenblock haben einen langen Vorton, die anderen Datenblöcke einen kurzen Vorton.

Aufbau des Kopfblocks:

Die Blocknummer hat bei Headersave eine inhaltliche Bedeutung, anhand derer man die Blockreihenfolge überprüfen kann. Als Blocknummer wird die jeweilige Blockanfangsadresse verwendet:

Die Blocknummer 0FFFFh wird als Endeblock erkannt.

Aufgrund der Kompatibilität zum originalen Format kann eine Headersave-Aufzeichnung mit den originalen Monitorprogrammen geladen werden, wenn das Laden erst nach dem Kopfblock (Header) gestartet wird.

Auch beim TINY-BASIC (originales CSAVE-Kommando) wird ein zusätzlicher Header geschrieben. Dieser hat einen einfacheren Aufbau als der von Headersave. Das Tiny-BASIC-Verfahren stand Pate für das von R. Brosig entwickelte Headersave.

Tiny-Basic-Kopf

Neben dem Hausformat gibt es auch 10K-BASIC-Programme im Kassettenaufzeichnungsformat des Z9001 sowie Basicode-Programme im BASICODE3-Kassettenaufzeichnungsformat.

*.z13 Originalformat des Z1013
also Bin-Datei (ohne Kopf) oder Tiny-Basic (Tiny-Basic-Programme haben Kopf ähnlich wie Headersave: nur aadr (1000), eadr und filename)
kein Headersave-Kopfblock

*.z80 Header-Save-Programme
32 Byte Vorblock (aadr, eadr, sadr, 6 byte frei, typ, 3x 0d3h, 16 Zeichen Filename, mit Leerzeichen aufgefüllt. Die 6 freien Byte enthalten den (Programm-)Autor, (z.B. Brosig), Müll, eine CRC-Summe oder andere Identifikatoren, sind aber nicht notwendig)

Sowohl bei *.z13 als auch bei *.z80 werden die Kopf-Daten der Blöcke nicht gespeichert. Die *.z13-Dateien sind damit reine Speicherdumps (außer Tiny-Basic, auch hier gibt es einen Header), bei *.z80 kommt noch der Headersave-Kopf davor.

Gebräuchlich sind eigentlich nur *.z80-Dateien.

*.TAP Arne Fitzenreiter:

• 16 byte Header mit „KC-TAPE by AF“
• 129 byte Blöcke mit Blocknummer aber ohne Prüfumme
• nur für wenige 10K-BASIC-Programme genutzt; gebräuchlicher war HSAVE (Headersave-Aufzeichnung als *.Z80-Datei)

(vp, jmue)

Zum Einlesen der Kassetten am PC gibt es das Programm KCLOAD von H. Haftmann (http://www-user.tu-chemnitz.de/~heha/hs_freeware/kcemu/). Das ist ein extrem kleines Windows-16Bit-Programm, das aber auch unter Windows 7 (32 Bit) noch lauffähig ist und zum Einlesen einer Vielzahl von Kassettenformaten genutzt werden kann.

Zum automatisierten Einlesen von 54 übergebenen Z1013-Kassetten habe ich Version 02/02 des Programms ein wenig modifiziert, so dass „automatisch speichern“ auch wirklich funktioniert. Wegen diverser Probleme mit langen Dateinamen werden als Programmnamen dabei einfach hochgezählte Nummern vergeben. Zwei kurze Perl-Programme rename_z80.pl und rename_z13.pl benennen die eingelesenen Dateien dann in einem Rutsch um und entfernen auch gleich noch Duplikate.

Nun braucht man bloß noch eine Kassette einlegen – nach einer halben Stunde hat man 20..60 Programme eingelesen!

• kcload_auto.zip + Perl-Programme

Zum Ausgeben von .Z80-Headersave-Dateien auf den Z1013 müssen die Binärdaten wieder in Audiosignale zurückverwandelt werden. Im obigen KCLOAD funktioniert bei mir unter Windows 7 die Audio-Ausgabe gar nicht mehr; unter Windows 98 funktioniert die Audioausgabe, allerdings gibt KCLOAD keinen Headersave-Vorblock aus. Deshalb gibt es ein kleines 32-Bit-Programm ZSAVE von mir. Über Speichern kann das Audiosignal als WAV-Datei gespeichert werden.

• zsave.rar Programm incl. Quellen (Delphi 10.2 Starter)
  

V0.2 2017/01/12 mit extra Swing am Ende, damit der letzte Block komplett gelesen wird
V0.3 2017/02/15 Checkbox, um ohne Header auszugeben (orig. Z1013)
V0.4 2017/07/21 lauffähig unter Windows 10, neues Hilfeformat