Dateiformate


1. Dateiformate für Diskettenabbilddateien

Die von JKCEMU unterstützten Dateiformate für Diskettenabbilddateien finden Sie hier.

2. Dateiformate für Speicherabbilddateien

JKCEMU unterstützt verschiedene Dateiformate für Speicherabbilddateien. Diese dienen dazu, einen Bereich des Arbeitsspeichers des emulierten Systems in eine Datei zu speichern und umgekehrt, d.h., Daten aus einer Datei in den Arbeitsspeicher zu laden. 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.

2.1. Headersave-Format

Das Headersave-Format ist quasi das Standardformat beim Z1013. Es bietet sich an, 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
b: Mini-/Tiny-BASIC-Programm
C: Maschinencodeprogramm, selbststartend
M: Maschinencodeprogramm
13 3 Bytes Headersave-Kennung Hier stehen drei Bytes mit dem hexadezimalen Wert Wert D3.
16 16 Bytes Dateiname Das ist eine maximal 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.

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

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

Achtung! Ist der Name kürzer als 8 Zeichen, werden bei KC85/1, KC87 und Z9001 Nullbytes eingetragen, bei HC900 und KC85/2..5 dagegen Leerzeichen.

Da beim Emulator die Datei im Dateisystem des Computers liegt, hat sie bereits einen Namen. Dieser Name muss nicht mit dem im Dateikopf eingetragenen Namen übereinstimmen.
8 3 Bytes Dateityp Das ist ein maximal 3 Zeichen langer Dateityp. Die wichtigsten Typen sind:
ASM: Assemblerquelltext
COM: Maschinencodeprogramm
DUM: Speicherabzug
KCB: KC-BASIC-Programm als Maschinencodeprogramm gespeichert
KCC: CAOS-Maschinencodeprogramm
TXT: Textdatei

Achtung! Bei HC900 und KC85/2..5 ist dieses Feld zwar als Dateityp definiert (siehe KC85/3 Systemhandbuch, Seite 88), jedoch wird beim Speichern und Laden mittels Kassette ein Datetyp nicht berücksichtigt. Stattdessen werden Dateiname und Dateityp zusammen als eine 11 Zeichen lange Dateibezeichnung verwendet (siehe KC85/3 Systemhandbuch, Seite 32), die, sofern sie kürzer als 11 Zeichen ist, mit Leerzeichen aufgefüllt wird. Aus diesem Grund benutzt auch JKCEMU bei HC900 und KC85/2..5 eine 11 Zeichen lange Bezeichnung.
16 1 Byte Anzahl nachfolgender Adressen Dieses Feld gibt die Anzahl der nachfolgenden Adressen an (Anfangs-, End- und ggf. Startadresse). Steht hier eine Zahl größer 3, enthält die Datei trotzdem nur 3 Adressen. Allerdings rechnet dann ein HC900 bzw. KC85/2..5 die Startadresse beim Laden der Datei mit einem Adressoffset nicht um.
17 2 Bytes Anfangsadresse Anfangsadresse im emulierten Arbeitsspeicher
19 2 Bytes Endadresse Endadresse im emulierten Arbeitsspeicher

Achtung! Bei HC900 und KC85/2..5 wird die Endadresse + 1 eingetragen (siehe KC85/3 Systemhandbuch, Seite 88).
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 größer hat.

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 bei KC85/1, KC87 und Z9001 die reale Endadresse und bei HC900 und KC85/2..5 die Endadresse + 1. Da nicht 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 entsprechend der o.a. Regel 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.

2.3.1. KCM-Format

Das KCM-Format ist identisch zum KCC-Format. Der Unterschied in der Dateiendung soll anzeigen, dass die Datei zwar Maschinencode, aber kein ausführbares Programm enthät.

2.3.2. 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 (Dateiendung ist *.jtc).

Achtung! Entgegen der KC85/3-Dokumentation trägt der Ju+Te-Computer die tatsächliche Endadresse in den Dateikopf ein. Aus diesem Grund tut es auch der Emulator JTCEMU so.

2.3.3. Abweichende KCB-, KCC- und KCM-Dateien

Gelegentlich sind Dateien zu finden, die von dem oben beschriebenen Format abweichen. Diese abweichenden Dateien sind meistens eine Konvertierung von Kassettenaufnahmen. Auf Kassette werden KC-Dateien in Blöcken aufgezeichnet, wobei jeder Block eine Blocknummer und ein Prüfbyte enthält. Bei den abweichende KCB-, KCC- und KCM-Dateien sind die Blocknummern oder Blocknummern und Prüfbytes enthalten. JKCEMU erkennt solche Dateien und markiert sie als Dateityp B (Blocknummern enthalten) oder Dateityp B+P (Blocknummern und Prüfbytes enthalten). Diese Dateien können in den Emulator geladen, nicht aber gespeichert werden.

2.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. Danach folgt ein Byte mit dem Wert 3. Dahinter folgen Füllbytes, bis die Datelänge ein Vielfaches von 128 Bytes hat.

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.

2.4.1. Abweichende KC-BASIC-Programmdateien

Wie bei den KCB-, KCC- und KCM-Dateien gibt es auch bei KC-BASIC-Programmdateien abweichende Formate. JKCEMU erkennt solche Dateien und markiert sie als Dateityp K (Kopf enthalten), Dateityp K+B (Kopf und Blocknummern enthalten) oder Dateityp K+B+P (Kopf, Blocknummern und Prüfbytes enthalten). Der Kopf enthält die drei KC-BASIC-Typbytes gefolgt von den acht Zeichen für den Namen. Diese abweichenden Dateien können in den Emulator geladen, nicht aber gespeichert werden.

2.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 die sich 129 Byte große Blöcke anschließen. Jeder Block beginnt mit einer Blocknummer gefolgt von 128 Nutzbytes. Der erste Block ist gewöhnlich 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 werden auch als Tape-Dateien unterstützt und können deshalb auch mit der Funktion Audiodaten aus Sound- oder Tape-Datei lesen in den Emulator geladen werden. Das ist übrigens der einzige Weg, eine KC-TAP-Datei, die ein KC-BASIC-Programm im ASCII-Format oder ein KC-BASIC-Datenfeld enthält, so zu laden, dass der BASIC-Interpreter damit auch etwas anfangen kann.

2.5.1. Multi-KC-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-KC-TAP-Dateien.

Multi-KC-TAP-Dateien eignen sich für Programme, die aus mehreren Dateien bestehen. Meistens handelt es sich dabei um Spielprogramme. Die erste 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-KC-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 Audiosystem vorgelegt werden sollen, damit sie darüber eingelesen werden können.
Unabhägig davon können Multi-KC-TAP-Dateien auch vollständig über die Audiofunktionen eingelesen werden.

2.6. BASIC-Programmdatei

Eine BASIC-Programmdatei enthält ein BASIC-Programm, so wie es im Arbeitsspeicher vorliegt. Das erste Byte in der Datei ist das erste Byte des eigentlichen BASIC-Programms. Die Dateiendung ist *.bas (Ausnahme bei AC1-BASIC6: *.abc).

2.7. 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 Nullbytes des BASIC-Programms folgt ein Byte 1Ah. Die übliche Dateiendung ist *.bas.

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

2.9. Einfache Speicherabbilddatei

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

3. Dateiformate für Tape-Dateien

Tape-Dateien enthalten die Daten einer digitalen Magnetbandaufzeichnung (i.d.R. von einer Kassette). Da Magnetbandaufzeichnungen im Original über die Kassettenschnittstelle in den Computer geladen werden, müssen Tape-Dateien über die emulierte Kassettenschnittstelle in JKCEMU geladen werden. Dazu wird die Funktion Audiodaten aus Sound- oder Tape-Datei lesen verwendet.

Tape-Dateien unterscheiden sich von Sound-Dateien dadurch, dass sie entweder die Audiodaten nur mit einem Bit Auflösung oder sogar nur die eigentlichen Datenbytes enthalten. Im zweiten Fall sind ggf. noch Informationen enthalten, wie die Datenbytes in Audiodaten umzuwandeln sind. Tape-Dateien sind üblicherweise deutlich kleiner als Sound-Dateien.

3.1 CDT-Format

CDT steht für CPC Digital Tape. Das Format ist identisch zum TZX-Format. Der andere Name und die andere Dateiendung sollen nur zeigen, dass eine CDT-Datei Programme oder Daten für CPC-Computer bzw. deren kompatiblen wie dem KC compact enthält.

3.2 CSW-Format

CSW steht für Compressed Square Wave und wurde speziell für die Speicherung digitaler Kassettenaufzeichnungen entwickelt. Das Format speichert die Audiodaten mit einem Bit Auflösung.

JKCEMU unterstützt CSW-Dateien lesend und schreibend, und zwar sowohl im alten CSW1- als auch im CSW2-Format. Wenn Sie beim Speichern einer Datei die Endung .csw angeben, wird im CSW2-Format gespeichert. Sie können bei Bedarf auch das alte CSW1-Format erzeugen. Dazu müssen Sie die Endung .csw1 angeben und nach dem Speichern die Datei in .csw umbenennen.

3.3 TZX-Format

Das TZX-Format wurde entwickelt, um Magnetbandaufzeichungen für den ZX Spectrum speichern zu können. Mit dem Format sind neben dem ZX-Spectrum-Standardaufzeichnungsverfahren auch Turbo-Lader und andere individuelle Aufzeichnungsverfahren abbildbar. Diese Anforderung gepaart mit dem Prinzip, möglichst nur die eigentlichen Datenbytes statt Audiodaten zu speichen, machen das TZX-Format allerdings recht kompliziert.

Eine TZX-Datei besteht aus einzelnen Blöcken. Es gibt verschiedene Arten von Blöcken, um Metadaten, Steuerungsinformationen und natürlich die zu speichernden Daten in den unterschiedlichen Aufzeichnungsverfahren abbilden zu können.

JKCEMU unterstützt TZX-Dateien, allerdings mit einigen Einschränkungen:

3.4 TAP-Format

TAP steht für Tape. Allerdings gibt es nicht ein TAP-Format, sondern viele. JKCEMU unterstützt von den vielen das KC-TAP- und das ZX-TAP-Format. Beide Formate werden als Tape-Datei nur lesend unterstützt, d.h., sie lassen sich über die emulierte Kassettenschnittstelle einlesen, nicht aber speichern. Darüber hinaus wird das KC-TAP-Format von JKCEMU in vollem Umfang lesend und schreibend auch als Speicherabbilddatei unterstützt. Es können also Bereiche des Arbeitsspeichers direkt in eine KC-TAP-Datei gespeichert und von dort wieder direkt zurück in den Arbeitsspeicher geladen werden.