Dateiformate

Achtung! Diese Seite beschreibt die Dateiformate, die zum Laden von Daten und Programmen in den Arbeitsspeicher des Emulators benutzt werden. Eine Beschreibung der Formate für Diskettenabbilddateien finden Sie unter:
JKCEMU unterstützt verschiedene Dateiformate, sowohl für das Laden als auch für das Speichern. Einige Dateiformate eignen sich nur für bestimmte Arten von Daten, z.B. für BASIC-Programme. Die meisten Dateiformate aber eignen sich zum Speichern beliebiger binärer Daten. Prinzipiell können Sie in jedem dieser Dateiformate die Programme und Daten eines jeden emulierten Systems speichern. Es empfiehlt sich aber, Programme immer nur in einem der Formate zu speichern, die für das emulierte System üblich sind.

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


1. Headersave-Format

Das Headersave-Format ist quasi das Standardformat beim Z1013. Es bietet sich, dieses Format im Emulatorumfeld auch als Standardformat für AC1-Daten zu verwenden.

Das Headersave-Dateiformat entspricht inhaltlich dem Headersave-Kassettenaufzeichnungsformat des Z1013. 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 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,
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 (Mini-/Tiny-BASIC)
C: Ausführbares Maschinencodeprogramm
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.

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.

JKCEMU 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 mehreren KC-Emulatoren verwendet und hat seinen Ursprung im Kassettenaufzeichnungsformat der KC-Computer (KC85/1-4, KC87, Z9001). 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 JKCEMU 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 Anfangsadresse 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.
JKCEMU 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 JKCEMU das KCC-Format folgendermaßen:
  1. Beim Speichern wird die 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 JKCEMU 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 zu dem vom JKCEMU erzeugten KCC-Format. Allerdings geht beim Einlesen von JTC-Dateien in JKCEMU trotzdem kein Byte verloren, da ja bis einschließlich zu der im Dateikopf eingetragenen Endadresse gelesen.

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.

JKCEMU 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 die 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.

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

Hinweis: KC-TAP-Dateien können auch mit den Audio-Funktionen wie Sound-Dateien eingelesen werden. Das ist übrigens der einzige Weg, KC-TAP-Dateien in JKCEMU zu laden, die ein KC-BASIC-Programm im ASCII-Format oder ein KC-BASIC-Datenfeld enthalten.

Hinweis: Im Datei-Browser können KC-TAP-Dateien in Sound-Dateien exportiert werden.

5.1. Multi-TAP-Dateien

Mehrere KC-TAP-Dateien können zu einer Datei zusammengekettet werden, was sinngemäß mehrere, hintereinander liegende Kassettenaufzeichnungen bedeutet. Solche Dateien heißen Multi-TAP-Dateien.

Multi-TAP-Dateien eignen sich für Programme, die aus mehreren Dateien bestehen. Meistens handelt es sich dabei um Spielprogramme. Die ersten Datei, d.h. die erste Kassettenaufnahme, enthält häufig nur ein kleines Programm, welches ein Startbild anzeigt und anschließend die restlichen Dateien, d.h., die nachfolgenden Kassettenaufnahmen, einliest und anschließend das eigentliche Programm startet.

JKCEMU unterstützt Multi-TAP-Dateien folgendermaßen:
  1. Beim Laden in den Arbeitsspeicher wird nur die erste Teildatei geladen und ggf. gestartet.
  2. JKCEMU erkennt das Vorhandensein weiterer Teildateien und fragt den Benutzer, ob diese dem Audio-System vorgelegt werden sollen, damit sie darüber eingelesen werden können.
Unabhägig davon können Multi-TAP-Dateien auch vollständig über die Audio-Funktionen eingelesen werden.

6. RBASIC-Programmdatei

Der A5105 (BIC, ALBA PC) benutzt dieses Dateiformat zur Speicherung von BASIC-Programmen auf Diskette. Das erste Byte in der Datei hat den Wert 0FFh. Danach folgt das RBASIC-Programm, so wie es im Arbeistspeicher des A5105 ab Adresse 8001h zu finden ist. Danach, d.h. hinter den abschließenden drei Null-Bytes des BASIC-Programms folgt ein Byte 1Ah. Die übliche Dateiendung ist *.bas.

7. 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

8. 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.