Dateiformate

J1013 unterstützt verschiedene Dateiformate, sowohl für das Laden als auch für das Speichern. Standard ist das Headersave-Format. Die anderen Formate werden unterstützt, um einen Datenaustausch mit anderen Programmen, insbesondere mit KC-Emulatoren, zu erleichtern.

Folgende Formate werden unterstützt:
  1. Z1013-Headersave-Format
  2. KCB-Format
  3. KCC-Format
  4. KC-BASIC-Programmdatei
  5. KC-TAP-Format
  6. Intel-HEX-Format
  7. Speicherabbilddatei


1. Z1013-Headersave-Format

Das Headersave-Format ist quasi das Standardformat beim Z1013. Das Headersave-Dateiformat entspricht inhaltlich dem Headersave-Kassettenaufzeichnungsformat. Es enthält einen 32 Byte großen Kopfblock, an den sich der Datenbereich anschließt, der wiederum ein 1:1-Abbild eines Teils des Arbeitsspeichers darstellt. Die übliche Dateiendung ist *.z80.

Der Kopfblock hat folgenden Aufbau:
Offset Länge Feld Bedeutung
0 2 Bytes Anfangsadresse Anfangsadresse im Z1013-Arbeitsspeicher,
In den Speicherbereich ab dieser Adresse wird der hinter dem Kopfblock folgende Datenbereich der Datei geladen. Es ist i.d.R. auch möglich, beim Laden eine andere Adresse anzugeben. In diesem Fall wird die im Kopfblock stehende Anfangsadresse ignoriert.
2 2 Bytes Endadresse Endadresse im Arbeitsspeicher des Z1013,
Es werden (Endadresse - Anfangsadresse + 1) Bytes geladen.
4 2 Bytes Startadresse Die Startadresse ist nur relevant, wenn die Datei ein ausführbares Maschinencodeprogramm (Dateityp "C") enthält. Das Programm wird mit einem Sprungbefehl auf diese Adresse gestartet.
12 1 Byte Dateityp Der Dateityp wird mit einem Buchstaben angegeben. Die wichtigsten Typen sind:
A: Assemblerquelltext
B: BASIC-Programm (KC-BASIC)
b: BASIC-Programm (Tiny-BASIC)
C: Ausführbares Maschinencodeprogramm
T: Text
13 3 Bytes Headersave-Kennung Hier stehen drei Bytes mit dem hexadezimalen Wert Wert D3.
16 16 Bytes Dateiname Das ist eine 16 Zeichen lange Bezeichnung, die bei Speicherung auf Magnettonband als Dateiname dient. Ist die Bezeichnung kürzer als 16 Zeichen, wird mit Leerzeichen aufgefüllt.
Da beim Emulator die Datei im Dateisystem des Computers liegt und somit bereits einen Namen hat, hat dieses Feld nur die Bedeutung einer zusätzlichen Bezeichnung. Diese Bezeichnung muss nicht mit dem Namen im Dateisystem übereinstimmen.

Z1013-Headersave-Dateien sind Little-Endian kodiert, d.h., das niederwertige Byte steht vor dem höherwertigen. Das gilt auch für die Adressangaben im Kopfblock.

1.1. Headersave-Kassettenaufzeichnungsformat

Die beiden originalen Z1013-Monitorprogramme (2.02 und A.2) speichern Programmme und Daten, indem ein Bereich des Arbeitsspeichers auf den Massenspeicher (Magnettonband) geschrieben wird. Dabei werden keine Verwaltungsinformationen mit abgespeichert, d.h., der Anwender muss sich die Anfangs- und Endadresse des Speicherbereichs und bei einem Maschinencodeprogramm auch die Startadresse separat merken.

Dieses einfache Prinzip ist nicht sehr komfortabel und wurde deshalb bereits beim Tiny-BASIC-Interpreter, der als Hex-Listing im Z1013-Handbuch abgedruckt ist, um einen 32-Byte großen Kopfblock mit Verwaltungsinformationen erweitert. Dieses Verfahren haben später engagierte Z1013-Anwender zum sogenannten Headersave-Format weiterentwickelt, welches sich als Quasi-Standard durchsetzte. Werkseitig wurde jedoch das Headersave-Format bei keinem einzigen Z1013 implementiert. Man kann aber trotzdem mit den originalen Monitorprogrammen eine Headersave-Datei von Kassette laden, indem man das Laden erst nach dem akustisch deutlich unterscheidbaren Kopfblock startet.

Der Kopfblock beim Aufzeichnungsformat des Tiny-BASIC-Interpreters ist kompatibel zum Headersave-Format. Es fehlen nur die Startadresse und die Headersave-Kennung.

2. KCB-Format

Das KCB-Format ist identisch zum KCC-Format (siehe weiter unten). Die unterschiedliche Dateiendung besagt nur, dass die Datei ein KC-BASIC-Programm enthält, obwohl das Dateiformat für eine KC-Systemdatei und eben nicht für eine KC-BASIC-Datei steht. Dieses Packen eines BASIC-Programms in eine Systemdatei wird üblicherweise deshalb getan, um das BASIC-Programm selbststartend zu machen. Dazu enthält die Datei zusätzlich eine kleine Maschinencode-Routine, auf die die Startadresse in den Kopfdaten zeigt.

J1013 unterstützt das KCB-Format dahingehend, dass es das BASIC-Programm lädt und für das RAM- beziehungsweise ROM-BASIC reloziert. Der in der Datei enthaltene Maschinencode und ggf. sonstige Daten werden ignoriert. Möchten Sie dagegen die Datei komplett laden, also nicht nur das BASIC-Programm, müssen Sie die Datei als KCC-Datei anfassen, d.h. in dem Dialog mit den Ladeoptionen einfach das Format umstellen. Allerdings wird dann das BASIC-Programm nicht mehr reloziert.

3. KCC-Format

Das KCC-Format wird von einigen KC-Emulatoren verwendet und hat seinen Ursprung im Kassettenaufzeichnungsformat der KC-Computer (KC: Serie von Kleincomputer, die von Robotron in Dresden (Z9001, KC81/1, KC87) und vom VEB Mikroelektronik Mühlhausen (HC 900, KC85/2-4) hergestellt wurden). Das Dateiformat enthält einen Kopfblock, an den sich der Datenbereich anschließt, der wiederum ein 1:1-Abbild eines Teils des Arbeitsspeichers darstellt. Die übliche Dateiendung ist *.kcc.

Der Kopfblock hat folgenden Aufbau:
Offset Länge Feld Bedeutung
0 8 Bytes Dateiname Das ist eine maximal 8 Zeichen lange Bezeichnung, die bei Speicherung auf Magnettonband als Dateiname dient.
Da beim Emulator die Datei im Dateisystem des Computers liegt und somit bereits einen Namen hat, hat dieses Feld nur die Bedeutung einer zusätzlichen Beschreibung. Diese Beschreibung muss nicht mit dem Namen im Dateisystem übereinstimmen.
8 3 Bytes Dateityp Das ist eine maximal 3 Zeichen lange Dateinamenerweiterung. Da die Dateinamenerweiterung, die als Dateityp fungiert, sich direkt an den Dateinamen anschließt, werden häufig beide Felder zu einer 11-Zeichen langen Dateibezeichnung zusammengefasst. Auch J1013 bietet hierfür nur ein Feld an und füllt ggf. mit Leerzeichen auf.
16 1 Byte Anzahl nachfolgender Adressen Dieses Feld gibt die Anzahl der nachfolgenden Adressen an (Anfangs-, End-, Start-/Kaltstart- und Warmstartadresse). Hier steht meistens eine zwei oder drei und selten eine vier.
17 2 Bytes Endadresse Anfangsadresse im emulierten Arbeitsspeicher
19 2 Bytes Endadresse + 1 Endadresse + 1 im emulierten Arbeitsspeicher
21 2 Bytes Startadresse Mit dieser Adresse wird das in der Datei enthaltene Maschinencodeprogramm gestartet.
Die Startadresse ist nur gültig, wenn das Feld Anzahl nachfolgender Adressen den Wert drei oder vier hat.
23 2 Bytes Warmstartadresse Wenn ein Programm zwei Startadressen hat (Kalt- und Warmstart), ist hier die Warmstartadresse zu finden.
Die Warmstartadresse ist nur gültig, wenn das Feld Anzahl nachfolgender Adressen den Wert vier hat.
J1013 wertet die Warmstartadresse nicht aus.

KCC-Dateien sind Little-Endian kodiert, d.h., das niederwertige Byte steht vor dem höherwertigen. Das gilt auch für die Adressangaben im Kopfblock.

Achtung! Die im Dateikopf eingetragene zweite Adresse ist die Endadresse + 1 (siehe KC85/3 Systemhandbuch, Seite 88). Allerdings scheint das nicht überall so implementiert zu sein. Um sicherzustellen, dass das letzte Byte nicht verloren geht, behandelt J1013 das KCC-Format folgendermaßen:
  1. Beim Speichern wird die tatsächliche Endadresse + 1 in den Dateikopf eingetragen. Der KC-Header entspricht somit der offiziellen Dokumentation.
  2. Beim Laden wird bis einschließlich der in den Kopfdaten eingetragenen Adresse geladen, u.U. also ein Byte zuviel.
Damit ist sichergestellt, dass niemals ein Byte zu wenig geladen wird, egal, ob nun ein Fremdprogramm eine von J1013 erzeugte KCC-Datei laden will oder umgekehrt.

3.1. JTC-Format

Der Jugend+Technik-Computer verwendet in der Ausbaustufe mit dem erweiterten Betriebssystem EMR-ES 1988 das Kassettenaufzeichnungsformat der KC-Computer. Aus diesem Grund wird beim JTCEMU, dem Ju+Te-Computer-Emulator, das KCC-Dateiformat verwendet. Um jedoch deutlich zu machen, dass eine solche Datei kein KC-Programm sondern ein Ju+Te-Computer-Programm enthält, wird das Format bei JTCEMU JTC-Format genannt, und die Dateiendung ist *.jtc.

Achtung! Entgegen der KC85/3-Dokumentation trägt der Ju+Te-Computer die tatsächliche Endadresse in den Dateikopf ein und nicht die Endadresse + 1. Aus diesem Grund tut es auch der Emulator JTCEMU so. Insofern ist das von JTCEMU erzeugte JTC-Format nicht ganz identisch zum vom J1013 erzeugten KCC-Format. Allerdings geht beim Einlesen von JTC-Dateien in J1013 trotzdem kein Byte verloren, da ja sicherheitshalber ein Byte mehr gelesen wird.

4. KC-BASIC-Programmdatei

Eine KC-BASIC-Programmdatei hat üblicherweise die Dateiendung *.sss und enthält am Anfang zwei Bytes die die Läge des BASIC-Programms angeben. Ab dem dritten Byte folgt das eigentliche Programm. Abgeschlossen wird die Datei mit einem Byte mit dem Wert 3. Die Programmdatei ist somit drei Bytes länger als die Längenangabe in den ersten beiden Bytes.

Manche KC-BASIC-Programmdateien haben einen 11-Byte großen Dateikopf, der mit einer BASIC-Programmdateikennung beginnt (drei mal D3 oder drei mal D6) und dahinter einen 8 Zeichen langen Namen enthält.

J1013 kann beide Arten von KC-BASIC-Programmdateien laden. Beim Speichern wird jedoch nur die Form ohne Kopfdaten unterstützt.

KC-BASIC-Progammdateien sind Little-Endian kodiert, d.h., das niederwertige Byte steht vor dem höherwertigen. Das gilt auch für die Längenangabe am Dateianfang.

5. KC-TAP-Format

Das KC-TAP-Format wurde von Arne Fitzenreiter definiert und wird von vielen KC-Emulatoren verwendet. Es ist nicht nur inhaltlich, sondern auch verwaltungstechnisch vom Kassettenaufzeichnungsformat der KC-Computer abgeleitet, denn es enthält neben den Nutzbytes auch Blocknummern.

Das KC-TAP-Format beginnt mit einer 16 Byte großen Kennung, an den sich 129 Byte große Blöcke anschließen. Jeder Block beginnt mit einer Blocknummer gefolgt von 128 Nutzbytes. Der erste Block ist gewöhlich der Kopfblock und gibt Auskunft über die Art und die Länge der Datei.

Die Datei hat folgenden Aufbau:
Offset Länge Bedeutung
0 16 Bytes KC-TAP-Kennung mit der hexadezimalen Bytefolge:
C3 4B 43 2D 54 41 50 45 20 62 79 20 41 46 2E 20

Als C-String geschrieben:
"\xC3KC-TAPE by AF. "
16 129 Bytes Kopfblock
145 129 Bytes 2. Block
... ... ...
16 + ((n - 1) * 129) 129 Bytes n. Block
Der letzte Block hat häufig die Blocknummer 255 (hexadezimal: FF).

Lässt man die KC-TAP-Kennung und Blocknummern weg und kettet nur die Nutzdaten der einzelnen Blöcke zusammen, erhält man entweder das KCC- oder das KC-BASIC-Programmdateiformat, je nachdem, was die KC-TAP-Datei enthält.

Eine KC-TAP-Datei kann aber auch ein KC-BASIC-Programm im ASCII-Format oder ein KC-BASIC-Datenfeld enthalten. Diese Formate werden von J1013 jedoch nicht unterstützt.

Mehrere KC-TAP-Dateien können zu einer Datei zusammengekettet werden, was sinngemäß mehrere hintereinander liegende Kassettenaufzeichnungen bedeutet. J1013 unterstützt zusammengekettete KC-TAP-Dateien nicht, d.h., bei einer solchen Datei liest der Emulator nur die erste Teildatei.

Achtung! Bezüglich der beim KC-TAP-Format im Kopfblock eingetragenen Endadresse gilt das gleiche wie beim KCC-Format (siehe hier).

6. Intel-HEX-Format

In einer Intel-HEX-Datei werden die binären Daten als hexadezimale Zahlen in textueller Form gespeichert, d.h., die Intel-HEX-Datei ist eine reine ASCII-Datei. Die Daten sind in Segmente, sogenannte Records, gruppiert, wobei üblicherweise jedes Segment eine eigene Textzeile bildet. Der Aufbau eines Records ist:
Offset Länge Feld Bedeutung
0 1 Zeichen Startmarkierung Hier steht ein Doppelpunkt. Alle Zeichen zwischen dem letzten Record und der Startmarkierung werden ignoriert. Üblicherweise betrifft das einen Zeilenumbruch.
1 2 Zeichen Anzahl der Datenbytes Die Anzahl der Datenbytes wird hexadezimal angegeben.
3 4 Zeichen Startadresse des Records Die Adresse wird hexadezimal angegeben.
7 2 Zeichen Record-Typ 00: Daten-Record
01: Dateiende-Record
Andere Record-Typen werden je nach Typ entweder ignoriert oder führen zum Abbruch des Ladens.
9 n Zeichen Daten des Records Jeweils zwei Zeichen kodieren hexadezimal ein Datenbyte, d.h., der Record enthält n / 2 Datenbytes.
9 + n 2 Zeichen Prüfsumme Die Prüfsumme sind die unteren 8 Bits des Ergebnisses aus Null minus der Summe der einzelnen Bytes, wobei jeweils hexadezimale Zeichen ein Byte ergeben.


Der Dateiende-Record sieht üblicherweise so aus: :00000001FF

7. Speicherabbilddatei

Eine Speicherabbilddatei enthält ein reines Abbild eines Teils des Arbeitsspeichers des Emulators. Es sind keine Kopfdaten enthalten, d.h., Anfangs- und ggf. Startadresse muss man sich separat merken. Die übliche Dateiendung ist *.bin.