DiskTool Handbook

Automatically synchronized from app/disktool/help/handbuch.md. Edit the source file in the project repository.

k1520DiskTool — Kurzhandbuch

Version 0.4.0-beta

Dieses Werkzeug holt Dateien von Disketten der K1520-Rechner (A5120, A5130, PC 1715 …) auf den heutigen Rechner und schreibt sie zurück. Es liest und schreibt die Dateisysteme von CP/A, SCPX, UDOS/ZDOS, UDOS1715/NDOS und SCP1700 (CP/M-86 des A7100) und die Etikettendisketten des SIOS 1526 in den Abbildformaten .hfe, .dmk, .img, .cqm (CopyQM), .td0 (TeleDisk) und .imd (ImageDisk; soweit das Medium darstellbar ist). Dazu kommen die UNIX-Disketten des P8000: WEGA (mit Modus, Besitzer und Zeit je Datei), tar-Disketten ohne Dateisystem und Plattenabbilder (.img.gz) mit ihren Partitionen — alle ohne UDOS-Angaben. Alles Wesentliche zu den neueren Funktionen steht in den Abschnitten tar-Disketten, P8000-Platten (WEGA), CopyQM-Abbilder, Containerformate im Vergleich, Was eine Datei außer ihren Bytes hat und Archivieren (einschließlich Archive auf der Kommandozeile).

Es gibt dasselbe auch als Kommandozeilenwerkzeug (k1520disktool); beide benutzen dieselbe Bibliothek und kommen deshalb immer zum selben Ergebnis.

Der übliche Weg

Diskette öffnen — Datei ▸ Abbild öffnen (Strg+O). Das Werkzeug erkennt Format und Dateisystem selbst; was es erkannt hat, steht im Kopfbereich.
Ansehen — die Dateien stehen in der linken Liste, der Ordner des Wirtsystems rechts. Beim Start steht dort der Standardordner (siehe unten); von da aus navigiert man wie in einem Dateimanager: .. ganz oben führt hinauf (auch die Rücktaste), ein Doppelklick auf einen Ordnernamen hinein. Die Adresszeile darüber lässt sich überschreiben — Pfad eintippen, Eingabetaste. Der Knopf mit dem Ordnersymbol daneben öffnet stattdessen den gewohnten Auswahldialog (auch Übertragung ▸ Zielordner wählen). Ein Rechtsklick in die rechte Liste legt einen neuen Ordner an (neu, neu2, …, Strg+Umschalt+N) oder benennt den angeklickten Eintrag um (F2). Beides geschieht im Feld an Ort und Stelle: Name eintippen, Eingabetaste oder ein Klick daneben übernimmt ihn, Esc verwirft. Findet das Werkzeug auf der Diskette keine Datei — leer formatiert oder mit einem unpassenden Format geöffnet —, steht das in der linken Hälfte: Keine Dateien gefunden.
Holen — Dateien links markieren, dann →|. Ganze Diskette: →→|. Enthält ein CP/M-Name ein / oder \ (Disketten aus WEGA-Übertragungen: /Z/HOFFM, GW/ZSID.DOC), wird es zu _, ein führender Punkt bekommt ein _ davor; fallen zwei Namen zusammen, erhält der spätere ~1 (Hinweis im Protokoll). Der Zielordner wird nie verlassen.
Ändern erlaubt? Eine geöffnete Diskette ist zunächst schreibgeschützt. Wer schreiben will, hebt den Schutz bewusst auf: Diskette ▸ Schreibschutz (Strg+R) — der Knopf rechts in der Symbolleiste wechselt dann von 🔒 R/O auf 🔓 R/W.
Schreiben — Dateien rechts markieren, dann |←. Ganzer Ordner: |←←.
Sichern — Datei ▸ Speichern (Strg+S). Ein * im Fenstertitel zeigt an, dass noch etwas ungespeichert ist.

Wo die Dateien liegen

Das Werkzeug arbeitet in denselben Ordnern wie der Emulator — im Dokumentenordner, nicht dort, wo das Programm installiert ist:

Ordner	Wofür
`K1520emu/Disketten`	die Abbilder (`.hfe`, `.dmk`, `.img`, `.cqm`, `.td0`, `.imd`)
`K1520emu/Dateien`	was von den Disketten geholt und auf sie geschrieben wird

Dort gehen die Dateidialoge auf, und die rechte Hälfte zeigt beim Start den Dateiordner. Beim ersten Start einer Fassung werden die mitgelieferten Beispieldisketten dort in einen eigenen Ordner ausgepackt (Beispieldisketten_v03, bei einer Vorabversion mit Zusatz wie …_v03-beta.2); Vorhandenes bleibt unberührt.

Verschieben lässt sich das mit K1520_DATA (beide Ordner) bzw. K1520_DISKS (nur die Abbilder). Wo das Werkzeug gerade sucht, sagt k1520disktool --paths auf der Kommandozeile.

Das Fenster

Kopfbereich — was dauerhaft über die geöffnete Diskette gilt: Datei, Format, erkanntes Dateisystem, Zahl der Seiten. Rechts das Auswahlfeld, mit dem sich die Erkennung übersteuern lässt.

Meldungsstreifen — erscheint nur, wenn es etwas Dauerhaftes zu beachten gibt („nicht eindeutig erkannt", „Altbestand im Medium"). Er lässt sich wegklicken.

Statuszeile — links das Ergebnis der letzten Aktion, rechts der Zustand: Zahl der Dateien, freier Platz je Seite, der Prüfbefund, die Übertragungsart und der Schreibschutz.

Protokoll (F8) — alles, was das Werkzeug gemeldet hat, mit Uhrzeit. Es ist beim Start zugeklappt und sammelt trotzdem mit; wer nachlesen will, klappt es auf.

Symbolleiste — die Abkürzung für die häufigen Wege. Sie lässt sich unter Ansicht ▸ Symbolleiste ausblenden; im Menü steht immer alles.

Dateien übertragen

Vier Knöpfe zwischen den Listen — außen die Stapel, innen die Auswahl:

Knopf	Wirkung
`→→	`
`→	`
`	←`
`	←←`

Dasselbe geht mit der Maus: Dateien von einer Hälfte in die andere ziehen. Und über Bearbeiten mit Strg+→ und Strg+←.

Ziehen und Ablegen aus dem Dateimanager. Die Fensterhälften nehmen auch Dinge von außen an — und sonst nichts (überall sonst zeigt der Mauszeiger „verboten"; die Statuszeile nennt den Grund):

Links (Diskette): ein Abbild (.hfe, .dmk, .img, .cqm, .td0, .imd, Groß-/Kleinschreibung egal) wird geöffnet, genau wie Datei ▸ Öffnen (mit Rückfrage bei ungespeicherten Änderungen). Es darf nur ein Abbild auf einmal sein, und nicht zusammen mit anderen Dateien. Andere Dateien und Ordner werden wie bisher auf die Diskette geschrieben.
Rechts (Ordner): ein Verzeichnis wird zum Arbeitsordner, wie über die Ordnerwahl. Dateien oder mehrere Verzeichnisse werden abgelehnt. Das Ziehen von der Diskette in den Ordner holt weiter Dateien heraus.
Vorrang der Abbild-Endung: eine Datei mit Abbild-Endung, die von außen auf die linke Seite fällt, wird nie als Datei geschrieben. Will man eine solche Datei auf die Diskette bringen, wählt man sie in der Ordneransicht (rechts) aus und benutzt |← bzw. dem entsprechenden Menüpunkt (Strg+←).
Leere tar-Diskette: Sie nimmt Dateien und Ordner an wie jedes Archiv (Schreibschutz aufgehoben). Eine einzelne abgelegte oder in der Ordneransicht gewählte .tar-Datei kann auf einem LEEREN Archiv als Archiv selbst gelten (Rückfrage Als Datei / Fertiger Container); Näheres bei den tar-Disketten.

Binär oder Text? Im Menü Übertragung. Bei Text werden die Zeilenenden umgesetzt (CR LF ↔ LF) — richtig für Quelltexte und Dokumente, falsch für Programme. Was gerade gilt, steht rechts in der Statuszeile. Einzelne Dateien mit den üblichen Textendungen (.txt, .asm, .mac, .doc …) werden auch im Binärbetrieb als Text behandelt.

Passt es nicht, wird gar nicht erst geschrieben. Vor dem Einfügen eines ganzen Ordners prüft das Werkzeug den Platz; reicht er nicht, bleibt die Diskette unberührt und die Meldung sagt, woran es lag.

Schreibschutz und Arbeitskopien

Der Schutz ist beim Öffnen gesetzt — beim bloßen Lesen soll nichts kaputtgehen können. Ihn aufzuheben ist ein bewusster Schritt.

Bei einer unersetzlichen Diskette lohnt der Umweg: Datei ▸ Speichern unter… legt eine Kopie an und arbeitet ab dann an der Kopie. Das geht auch bei gesetztem Schutz; das Original bleibt, wie es war. Dabei lässt sich auch der Behälter wechseln — aus .img wird .hfe, aus .hfe wird .dmk.

Eine Diskette, deren Geometrie nur gemessen und nicht aus dem Katalog erkannt wurde, bleibt dauerhaft schreibgeschützt: was geraten ist, wird nicht beschrieben.

UDOS-Disketten haben zwei Seiten

Bei UDOS ist jede Seite ein eigenes Dateisystem — für den Anwender aber eine Diskette. Deshalb stehen beide Seiten in einer Liste, nach Side0 und Side1 gruppiert.

Beim Extrahieren entstehen zwei Unterordner Side0/ und Side1/; beim Einfügen eines ganzen Ordners werden sie verlangt. Eine einzelne Datei landet auf der Seite, auf die man sie zieht (oder auf der, in der gerade etwas markiert ist).

UDOS lässt sich nicht als .img ablegen: die Dateiverkettung steht dort hinter der Daten-Prüfsumme, ein rohes Sektorabbild verlöre sie. Das Werkzeug lehnt das darum ab, statt stillschweigend eine unbrauchbare Datei zu schreiben.

SCP1700 — das CP/M-86 des A7100

Disketten des 16-Bit-Rechners A7100 erkennt das Werkzeug von selbst und nennt sie scp1700. Für die Bedienung gibt es dort nichts Besonderes: das Dateisystem ist gewöhnliches CP/M, Attribute und Nutzerbereich verhalten sich wie bei einer CP/A-Diskette.

Die Diskette selbst ist allerdings ungewöhnlich gebaut — ihre erste Spur ist mit halber Geschwindigkeit in einem anderen Aufzeichnungsverfahren geschrieben als der Rest. Das Werkzeug führt das mit, auch beim Zurückschreiben; zu sehen ist es im Diskeditor und in der Formatzeile.

SIOS 1526 — die Etikettendisketten von A5120, A5130 und K8924

Disketten des Betriebssystems SIOS 1526 erkennt das Werkzeug von selbst und nennt sie sios_ss40 (40 Spuren) bzw. sios_ss80 (80 Spuren): einseitig, 26 Sektoren zu 128 Byte, MFM. Erkannt werden sie nur am positiven Nachweis — die Fehlspurkarte ERMAP in Spur 0 Sektor 5 und der Volumenetikett-Satz VOL1 in Sektor 7. Das ist Absicht: auch fremde Systeme (BCU 880, MUTOS 8000) sind nach demselben IBM-Schema initialisiert und behalten ihr eigenes Profil.

Wie die Diskette gebaut ist. Kein Dateiverzeichnis wie bei CP/M, sondern Spur 0 als Etikettenspur im IBM-Schema (Text in DKOI, der Robotron-Abwandlung von EBCDIC): VOL1 trägt den Datenträgernamen, jede Datei hat einen HDR1-Satz mit Anfang und Ende (BOE, EOE, EOD). Eine physische Datei ist ein zusammenhängender Spurbereich; eine Bibliothek (PHASELB für Programme, SOURCELB, RELOCLB) ist eine physische Datei mit eigenem Verzeichnis darin.

Im Fenster und auf der Kommandozeile erscheinen die Bibliotheken als Datei (Typ B), ihre Objekte darunter als PHASELB/INIT (Typ O); eine gewöhnliche physische Datei hat den Typ F. Der Schrägstrich ist Teil des Namens, kein Ordner. Beim Herausholen entsteht daraus PHASELB_INIT. Die Spalte Kz zeigt das Kennzeichen aus dem Etikett (P Schreibschutz, E Austausch, C Fortsetzung auf der Folgediskette).

Was geht

Auflisten und Herausholen (ls, get): physische Dateien und Objekte, byteweise roh. Die Größe einer Datei ist der Bereich bis EOD (belegte Sektoren).
Hineinlegen (put): als physische Datei (Name 1–8 Zeichen) in die erste freie Spurlücke ab Spur 1 bis Spur 37, oder als Objekt (PHASELB/NEU, Name 1–5 Zeichen) hinten an eine Bibliothek.
Löschen (rm): eine Datei wird zum gelöschten Etikett (DDR1) — die Daten bleiben. Ein Objekt verliert seinen Namen; sein Platz in der Bibliothek kehrt nicht zurück.
Leere Datendiskette anlegen (Neue Diskette, create --fs sios_ss40 oder sios_ss80, wahlweise --label NAME): so, wie SIOS-INIT sie anlegt, mit Etikettenspur und gelöschten Datenmarken in den freien Etikettensektoren.
Prüfen (fsck, beim Öffnen die Schnellprüfung): Befunde sios.hdr1.ungueltig (Fehler), sios.hdr1.ueberlappt (Fehler: zwei Dateien teilen sich Sektoren) und sios.hdr1.eod (Warnung: Dateiende liegt außerhalb des Bereichs; es gilt dann EOE); dazu bei Bibliotheken sios.bib.aadr, .reihenfolge, .nd (Warnung) und .doppelt (Fehler: zwei benannte Objekte am selben Anfang; gelöschte zählen nicht), sios.ermap.fehlt und sios.vol1.fehlt (Fehler) sowie die Hinweise sios.marke.aktiv/sios.marke.frei: die Datenmarke eines Etikettensektors (aktiv FB, frei F8) passt nicht zum Inhalt — Reparatur: Marke setzen, ohne Datenverlust. Gemeldet wird nur, was belegt ist.
Bibliotheken als Ordner: PHASELB, SOURCELB und RELOCLB erscheinen als aufklappbare Ordner, ihre Objekte darunter (INIT, FGEN …). Holen und Löschen gehen wie bei allen Dateien; Ablegen auf eine Bibliothek (oder bei angeklickter Bibliothek bzw. angeklicktem Objekt Schreiben) macht aus der Datei ein Objekt dieser Bibliothek (Name 1–5 Zeichen). Ohne Ordner bleibt es eine physische Datei.
Eigenschaften (Doppelklick): bei einer Datei die Felder des Dateikennsatzes — Satzlänge, BOE, EOE, EOD, Kennzeichen P/E und das Mehrdisketten-Kennzeichen (C = die Datei wird auf der Folgediskette fortgesetzt) —, bei einem Objekt AADR und ML, dazu die Felder des Datenträgerkennsatzes VOL1 (Name, Zugriffskennzeichen, Aufzeichnung, Etikettenstandard). Nur Anzeige: Etiketten schreibt man nicht von Hand um.
Diskeditor, Textspalte: neben der CRC wählen Sie Text: ASCII / EBCDIC/DKOI. Auf Spur 0 einer SIOS-Diskette steht EBCDIC von selbst (dort lesen Sie VOL1, HDR1 im Klartext), auf den Datenspuren ASCII. Eine ausdrückliche Wahl wird je Diskette gemerkt. DKOI ist EBCDIC mit fünf Abweichungen ([ ! ] ^ /).
Retten (Gelöschtes retten…, recover): gefunden werden gelöschte Dateien (Name, Größe und Bereich bleiben im Etikett stehen) und gelöschte Bibliotheksobjekte (nur der Name ist verloren). In den Ordner holen geht immer. Auf der Diskette wiederherstellen: eine Datei nur, wenn kein lebendes Etikett den Bereich inzwischen berührt; ein Objekt nur mit einem von Ihnen vergebenen Namen. Die 17 Platzhalter DATA10… der SG1 (Bereich hinter dem Diskettenende) sind kein Fund.
Spur 0 als Ganzes (boot-get): holt die Etikettenspur samt Lader heraus.

Was abgelehnt wird — jeweils mit Grund

Bootfähige Diskette anlegen (create --boot, boot-put): noch nicht möglich.
Bibliothek mit mehr als 14 Einträgen und alles mit Fehlspurkarte-Einträgen: das Format dahinter ist nicht belegt, es würde geraten.
Satzlänge ≠ 128: eine Datei auf dem Wirtsrechner sagt sie nicht.
Objekt größer als der freie Rest der Bibliothek, leere Objekte, eine zwanzigste Datei, ein beschädigtes Etikett.
Kein Verdichten: gelöschten Platz in einer Bibliothek holt nur das Original-Programm COPY zurück.

Container. .hfe und .dmk sind die richtigen Abbilder für den Emulator. .img (und .cqm, .td0, .imd) lassen sich zwar verwenden, verlieren aber die gelöschten Datenmarken (F8), die SIOS in den Etikettensektoren ab Sektor 9 setzt; das Werkzeug liest sie nicht aus, ob SIOS selbst darauf besteht, ist offen. Für den Emulator .hfe/.dmk.

Eine Besonderheit: die Systemdiskette SYSARE09 (SIOS 0.9) ist eine 40-Spur-Diskette, die im 80-Spur-Laufwerk zweiseitig ausgelesen wurde; sie passt zu keinem Katalogformat und wird nur erkannt, wenn Sie im Kopfbereich das Dateisystem sios_ss40 wählen (Kommandozeile: --fs sios_ss40).

Das Format im Einzelnen: doc/sios_diskettenformat.md; Bedienung des Systems im Emulator: Handbuch des Emulators, Abschnitt „SIOS 1526".

OS/M-Disketten — das CP/M des P8000

OS/M ist das 8-Bit-Betriebssystem des P8000 — und es ist CP/M 2.2. Auf der Diskette benutzt es genau die SCP-Formate des PC 1715: Format 5 (16 × 256 Byte je Sektor, 640K) und Format 7 (5 × 1024 Byte, 800K), Zylinder 0 und 1 für das System, das Verzeichnis ab Zylinder 2. Lesen, Schreiben, Löschen und Attribute verhalten sich wie bei jeder CP/A- oder SCP-Diskette.

Erkannt wird OS/M am Urlader. Eine Systemdiskette trägt im ersten Sektor den OS/M-Urlader; dann heißt sie osm640 bzw. osm800. Eine Datendiskette ohne System ist von einer SCP-Diskette nicht zu unterscheiden und erscheint deshalb als scpx640 bzw. cpa_auto — gelesen wird sie genauso richtig, nur der Name sagt nicht „OS/M“.

Eine leere 800K-Diskette — auch eine frisch unter OS/M formatierte — sieht aus wie eine leere CP/A-Datendiskette, deren Verzeichnis schon auf Zylinder 0 beginnt. Wer sie für OS/M füllen will, wählt im Dateisystem-Menü osm800 (oder legt sie gleich als osm800 an); sonst landen die ersten Dateien dort, wo OS/M sein System erwartet, und OS/M sieht sie nicht. Die Erkennung erinnert daran mit „ebenso gut osm800“ — in der Meldung über der Dateiliste und, im vollen Wortlaut, im Protokoll. Unter Neue Diskette heißen die Einträge „osm640 — OS/M (P8000) 640K, Format 5 …“ und „osm800 — OS/M (P8000) 800K, Format 7 …“. Eine Bootdiskette entsteht wie bei den anderen Systemen: Systemspuren einer OS/M-Diskette herausholen und beim Anlegen mitgeben. Das Werkzeug prüft dabei, dass es wirklich ein OS/M-Urlader für dasselbe Format ist.

Die Prüfung meldet osm.fdconf, wenn der Laufwerkstyp im Urlader nicht zum Format der Diskette passt — sie sähe heil aus und startete am P8000 falsch. Die Statuszeile zeigt sie als Warnung, das Protokoll nennt sie, und der Prüfdialog (Strg+F) führt sie mit den übrigen Befunden.

Namen mit / wie GW/ZSID.DOC stammen aus Übertragungen vom WEGA-Teil des P8000. CP/M erlaubt den Schrägstrich im Namen nicht; die Prüfung nennt ihn deshalb als Warnung. Beim Herausholen wird daraus GW_ZSID.DOC.

tar-Disketten — ein Archiv statt eines Dateisystems

Viele P8000-Lieferdisketten tragen kein Dateisystem: jemand hat mit tar direkt auf die rohe Diskette geschrieben. Das Werkzeug erkennt das als tar720 (immer als letzter Versuch hinter allen echten Dateisystemen; bearbeitbar ist ein abgeschlossenes Archiv, siehe unten) und zeigt Modus, Besitzer und Zeit wie bei WEGA. Mehrere Disketten eines Satzes sind ein Strom: die letzte Datei einer Diskette ist dann abgeschnitten (tar.abgeschnitten, in der Liste [DEFEKT], das .fileinfo trägt teilstueck=ist/soll), und Diskette 2…n beginnt mitten in einer Datei (tar.fortsetzung, das Anfangsstück liegt als _fortsetzung_anfang.bin bei). Vollständig werden die Dateien mit k1520disktool tar-satz abbild1 abbild2 … --to ordner (Reihenfolge wie in den Namen, ariane1, ariane2).

Im Fenster heißt der Weg Datei ▸ tar-Satz öffnen… (ohne Tastenkürzel): man wählt alle Abbilder des Satzes (.cqm oder .img), ordnet sie in der Liste mit Auf und Ab — der Vorschlag sortiert nach den Zahlen in den Dateinamen, ariane2 vor ariane10 — und bekommt EINE Diskette mit den vollständigen Dateien. Wie jedes Abbild ist er beim Öffnen schreibgeschützt (Schreibschutz aufheben, dann lässt er sich bearbeiten, siehe den nächsten Abschnitt). Öffnet man dagegen ein einzelnes Teilstück (die letzte Datei abgeschnitten, der Anfang mitten in einer Datei, keine Endmarke), zeigt der Meldungsstreifen den Weg mit einem Knopf tar-Satz öffnen…; ein solches Stück bleibt allein nur lesbar. Das Dateisystem heißt in der Anzeige „tar-Archiv (UNIX)“, bei einem Satz aus mehreren Abbildern „tar-Satz (UNIX)“; die Befunde tar.fortsetzung (die Diskette beginnt mitten in einer Datei) und tar.abgeschnitten (die letzte Datei setzt sich auf der nächsten Diskette fort) stehen im Protokoll.

tar-Sätze und -Archive im Fenster bearbeiten

Ein abgeschlossenes tar-Archiv (Kopf bei Sektor 0 und Endmarke) und jeder tar-Satz lassen sich im Fenster wie eine große Diskette bearbeiten, sobald der Schreibschutz aufgehoben ist (Strg+R). Der Satz liegt dabei als EIN Strom im Speicher; geschrieben wird erst beim Speichern.

Dateien und Ordner hinein: ziehen auf die Diskettenansicht, Auf die Diskette schreiben (|←, Strg+←) oder Alles einfügen. Auch ganze Ordner gehen (samt leerer Unterordner). Eine daneben liegende <datei>.fileinfo (Modus, uid, gid, mtime) wird übernommen, sonst gelten 0644 bzw. 0755, uid/gid 0 und die Zeit „jetzt“. Herunterladen schreibt diese .fileinfo.
Löschen, Ordner, Eigenschaften: Löschen, Bearbeiten ▸ Ordner im tar-Archiv anlegen… und Eigenschaften (Modus, uid, gid, mtime) wie bei einer WEGA-Diskette.
Eine einzelne .tar-Datei ablegen (ziehen, |←, Strg+←): ist das Archiv leer — ein neuer Satz, eine neue oder die leere Diskette tar720_leer, auch ein leer geräumtes Archiv —, fragt ein Fenster: Als Datei im Container ablegen (sie wird ein Eintrag) oder Ist ein fertiger tar-Container (ihr Inhalt wird das Archiv; über eine Diskette hinaus entsteht ein Satz aus mehreren Abbildern). Auf einem Archiv mit Inhalt, bei mehreren abgelegten Dateien oder einem Ordner wird eine .tar immer eine Datei. Eine Datei ohne tar-Kopf am Anfang (Folgeteil) ist kein Container. Die Diskette bleibt danach ganz normal bearbeitbar.
Eine tar-Diskette ist ein Satz mit einem Abbild: der Inhalt darf über eine Diskette hinaus wachsen (das Protokoll sagt es), es gibt keine Rückfrage beim Einfügen. Gespeichert wird beim Speichern.
Speichern (Strg+S): passt der Inhalt noch auf EIN Abbild, geht er ohne Rückfrage in dasselbe Abbild zurück (Container und Format bleiben; vor dem ersten Schreiben entsteht eine Sicherung <name>~). Sonst — und bei Speichern unter… — zeigt ein Fenster, was geschieht: die Zahl der Abbilder, ihre Namen, welche Dateien schon da sind und überschrieben werden und welche höheren Nummern liegen bleiben (gelöscht wird nie etwas). Die Nummer steht am Ende des Namens vor der Endung (name1.hfe, name2.hfe; abschließende Ziffern des alten Namens entfallen); die Endung bestimmt den Container.
Datei ▸ Neue tar-Diskette / tar-Satz… legt etwas Neues an: Format (alle einheitlichen Katalogformate, nicht nur 720K) und Art — Einzelne Diskette (die Datei entsteht sofort, wächst bei Bedarf zum Satz) oder Satz (nichts entsteht bis zum Speichern; name1, name2 …).
Greaseweazle: ein Satz lässt sich nicht direkt auf EINE echte Diskette schreiben; Physische Diskette überschreiben… ist gesperrt, der Tooltip nennt den Weg: Satz speichern, die Einzelabbilder öffnen, jedes für sich schreiben.

tar-Archive herausholen, bearbeiten und zurückschreiben

Ein Archiv, das sich über mehrere Disketten erstreckt, zeigt jede Einzeldiskette nur abgeschnitten. Wer es bearbeiten will, holt die Rohinhalte als .tar heraus, setzt sie mit cat zusammen, ändert das Archiv, teilt es mit split wieder und schreibt die Teile auf leere Disketten:

Diskette ▸ Diskette als .tar exportieren… (ohne Tastenkürzel; in der Kommandozeile tar-export). Ausgabe sind die 512-Byte-Blöcke des Stroms unverändert. Beginnt die Diskette mit einem gültigen tar-Kopf, endet der Export hinter der Endmarke (zwei Nullblöcke an einer Kopfposition); ohne Endmarke — auch mitten in einer Datei — wird bis zum Diskettenende ausgegeben. Eine Folgediskette (sie beginnt mitten in einer Datei) wird immer ganz ausgegeben, auch wenn in den Dateidaten zwei Nullblöcke stehen: das wäre keine Endmarke, und Abschneiden zerstörte das Archiv beim cat. Das gilt für jeden Container (.cqm, .hfe, .img, .dmk) und auch für eine Diskette, an der gar kein Dateisystem erkannt wurde (ein Folgeteil ohne einen einzigen Kopf). Ein geöffneter tar-Satz ist schon EIN Strom und wird nicht exportiert — die Disketten des Satzes einzeln öffnen.

Zusammensetzen, bearbeiten, teilen (Beispiel mit den sieben Disketten w11data1…7):

k1520disktool tar-export w11data1.cqm teil1.tar          # … bis w11data7.cqm
cat teil1.tar teil2.tar teil3.tar teil4.tar teil5.tar teil6.tar teil7.tar > w11data.tar
tar tvf w11data.tar                                      # bearbeiten: tar rf / tar --delete …
split -b 737280 -d w11data.tar neu_                      # neu_00 … neu_06, je höchstens 720 KiB

Datei ▸ Neue Diskette… mit dem Dateisystem tar720_leer (Kommandozeile create x.cqm --fs tar720_leer) legt eine leere tar-Diskette an: 720 KiB (80 × 2 × 9 × 512), ganz Null, in jedem Container (.img, .hfe, .dmk, .cqm). Sie wird beim Öffnen als leeres tar-Archiv erkannt (nur wenn alle Bytes Null sind; eine mit Nullen gefüllte CP/A-Diskette erscheint ebenfalls so — Diskette ▸ Dateisystem übersteuern ▸ cpa_auto stellt es richtig). Wie jede tar-Diskette ist sie ein Satz mit einem Abbild und nimmt Dateien, Ordner und .tar-Dateien an.
Das fertige Archiv zurück: das bearbeitete w11data.tar legt man (ziehen, |←) auf einen leeren neuen Satz (Datei ▸ Neue tar-Diskette / tar-Satz… ▸ Satz) und wählt Ist ein fertiger tar-Container; beim Speichern wird es auf nummerierte Abbilder GLEICHEN Formats verteilt (split ist nicht mehr nötig). Auf der Kommandozeile: tar-satz-neu --format k5601_9x512 neu.hfe --tar-container w11data.tar (Abbilder neu1.hfe, neu2.hfe, …) bzw. für ein Archiv, das auf EIN Abbild passt, tar-put diskette00.cqm archiv.tar (die Datei wird das Archiv der leeren Diskette; mit --dry-run nur beurteilen). Auf einer Diskette mit Inhalt kommt eine .tar nur als Datei hinein (put). Die Diskette ist danach nicht schreibgeschützt. Beurteilt wird vorher: ein Vielfaches von 512 Byte und ein tar-Kopf am Anfang. Ist der erste Kopf nicht V7 (ustar-Magic, also GNU- oder POSIX-Format; pax-Kopf; GNU-Langname; Name mit 100 Zeichen; binäres Größenfeld), steht ein Hinweis im Rückfragefenster (in der Kommandozeile eine Warnung auf stderr, abgelegt wird trotzdem): die P8000-/WEGA-Werkzeuge verstehen nur V7. tar --format=v7 erzeugt ein solches Archiv (Namen bis 99 Zeichen).
```
k1520disktool create diskette00.cqm --fs tar720_leer
k1520disktool tar-put diskette00.cqm archiv.tar          # passt auf eine Diskette
k1520disktool tar-satz-neu --format k5601_9x512 neu.hfe --tar-container gross.tar   # neu1.hfe, neu2.hfe …
```

Passende tar-Dateien unter Linux erzeugen und entpacken

Archiv für WEGA erzeugen (V7-Format, in Teile zu je einer Diskette geschnitten):

tar --format=v7 -b 20 -cf wega.tar -C /ihre/daten .
split -b 737280 -d -a 2 --additional-suffix=.tar wega.tar wega_part
                                # wega_part00.tar, wega_part01.tar, … je höchstens 720 KiB

--format=v7 ist wichtig: das Standardformat von GNU tar (gnu) und posix/ustar tragen die Kennung ustar im Kopf, und WEGA versteht sie nicht. V7 erlaubt Pfadnamen bis 99 Zeichen; längere lehnt tar ab.
-b 20 ist der übliche Blockungsfaktor (10 KiB); er füllt nur das Ende des Archivs mit Nullen auf.
Geteilt wird mit split, nicht mit tar -M -L 720K. Der Aufruf tar --format=v7 -M -L 720K … bricht mit „GNU features wanted on incompatible archive format“ ab, weil GNU-Mehrbandarchive ein GNU-Format brauchen. Mit einem GNU-Format (--format=oldgnu -M) beginnt jedes Folgeteil mit einem GNU-Fortsetzungskopf (Typ M), den WEGA nicht kennt. split schneidet dagegen den einen V7-Strom nur an den Diskettengrenzen; die Teile ergeben, hintereinandergelegt, wieder genau das V7-Archiv.
Die Teile 2 bis n beginnen mitten in einer Datei und sind einzeln für tar tf nicht lesbar („This does not look like a tar archive“). Das ist richtig so; erst zusammen ergeben sie das Archiv.
Das ganze Archiv auf nummerierte Disketten verteilen lässt man das DiskTool (tar-satz-neu --tar-container, siehe oben); es teilt an den Diskettengrenzen wie split. Einzelne Teile als Container auf eine leere Diskette zu legen geht nicht mehr — ein Folgeteil hat keinen Kopf am Anfang. Das DiskTool beurteilt nur, ob ein Kopf am Anfang V7 ist.

Mehrere .tar-Teile zu einem Archiv zusammensetzen und in ein Verzeichnis entpacken:

mkdir ziel
cat wega_part*.tar | tar -xvf - -C ziel          # in der Reihenfolge der Namen: part00, part01, …
# oder erst zusammensetzen und ansehen:
cat wega_part*.tar > wega.tar
tar -tvf wega.tar                                # Inhalt auflisten
tar -xvf wega.tar -C ziel                        # in das Verzeichnis „ziel“ entpacken

Die Teile müssen in der richtigen Reihenfolge stehen. Bei zwei oder mehr Ziffern mit festen Stellen (part00 … part10) sortiert die Shell richtig, bei part1 … part10 nicht.
Die Nullauffüllung am Ende der letzten Diskette stört nicht, tar hört an der Endmarke auf.
Als normaler Benutzer setzt tar Besitzer nicht um, Rechte nur mit -p. Mit sudo oder --numeric-owner bleiben die Besitzer der Diskette erhalten.
Bearbeiten im zusammengesetzten Archiv: tar --format=v7 -rf wega.tar datei hängt an, tar --delete -f wega.tar pfad entfernt. Danach wieder mit split teilen. Beim Anhängen --format=v7 mitgeben, sonst mischt tar GNU-Köpfe hinein.

Rundlauf. tar-export einer mit tar-put (bzw. als Container abgelegten) beschriebenen Diskette liefert: bei einer Datei mit Kopf und Endmarke genau die Datei; bei einer Datei mit Kopf ohne Endmarke die Datei plus zwei Nullblöcke (die Auffüllung der Diskette hat dann eine). Die Teile eines Satzes exportiert man einzeln (ein Folgeteil immer ganz, bis zum Abbildende). Nach dem cat der exportierten Teile bleibt daher höchstens Nullauffüllung am Ende des Archivs übrig, die tar ignoriert.

tar-Disketten von MUTOS 8000 (A5120.16)

Das tar von MUTOS 8000 schreibt seinen Strom nicht ab Zylinder 0 und nicht in Sektorfolge, sondern auf das Rohgerät des MUTOS-Treibers: ab Zylinder 1, bei 26 × 128 Byte verschränkt (Verschränkung 2, 6 Sektoren Spurversatz je Zylinder), bei 8 × 512 Byte linear. Das Werkzeug erkennt das selbst und zeigt es als eigenes Dateisystem:

Angezeigt als	Diskette	Blöcke je Diskette
`tar_mutos8k_26x128_mfm`	K5601 (5¼″, MFM), 26 × 128	494 (252 928 Byte)
`tar_mutos8k_26x128_fm`	MF3200 (8″, FM), 26 × 128	494
`tar_mutos8k_8x512_mfm`	K5601, 8 × 512 (DISK-Satz)	608 (311 296 Byte)

Mehrere Disketten eines Satzes (MUTOS kennt keine Folgedisketten, man teilt den Strom mit dd auf) öffnet man wie jeden tar-Satz: Datei ▸ tar-Satz öffnen…. Das Layout wird an der ersten Diskette erkannt. Lesen, Dateien hinzufügen und löschen, Speichern (auch über eine Diskette hinaus als Satz) gehen wie oben beschrieben; das Ergebnis liest MUTOS selbst mit tar tvf/tar xvf. Datei ▸ Neue tar-Diskette / tar-Satz… und Neue Diskette (…_leer) bieten die Formate an; eine neue Diskette trägt im Datenbereich Nullblöcke, damit MUTOS sie als leeres Archiv liest (eine nie beschriebene E5-Diskette endet bei tar tvf nicht sauber). Als Container gehen .hfe, .dmk, .img (immer MFM), .td0 und .imd; .cqm nicht beim 8 × 512-Format (gemischte Geometrie). Auf der Kommandozeile:

k1520disktool create leer.hfe --fs tar_mutos8k_26x128_mfm_leer
k1520disktool tar-satz-neu --format tar_mutos8k_26x128_mfm satz.hfe --put datei1 --put ordner
k1520disktool tar-satz v1.hfe v2.hfe -l           # Satz lesen; --to ORDNER holt alles heraus
k1520disktool tar-export v1.hfe teil.tar          # Strom als .tar

Kein Dateisystem im üblichen Sinn: die Diskette ist ein Archiv. Das UNIX-Dateisystem derselben Disketten (mkfs unter MUTOS) heißt mutos8k_26x128_mfm bzw. …_fm und mutos8k_8x512_mfm; die früheren Namen mutos8k_mfm, mutos8k_fm, mutos77 gelten weiter als Alias. Anleitung für den Gast (Befehle, Fallstricke, Disketten wechseln): Handbuch des Emulators, Abschnitt MUTOS 8000 (A5120.16).

P8000-Platten (WEGA)

Ein Plattenabbild des P8000 (.img oder gepackt .img.gz, etwa …k5504.img.gz) öffnet man wie eine Diskette: Datei ▸ Abbild öffnen… oder die Datei auf die linke Hälfte ziehen. Ob es eine Platte ist, entscheidet ihr Plattenkopf, nicht der Name — und es erscheint kein Formatdialog: Format und Dateisystem (WEGA) stehen fest.

Ansicht. Die Partitionen md0, md2, md3, md4 stehen als oberste Ordner (mit Verwendung, Datenträgername und freiem Platz), darunter der Verzeichnisbaum. Je Zeile: Art, Größe, Rechte (wie ls -l), uid, gid und Änderungszeit.
Eigenschaften (Doppelklick, Alt+Return) zeigen und ändern Modus, Besitzer und Zeit wie bei einer WEGA-Diskette.
Holen legt Datei oder Ordner mit ihrem Pfad in den Ordner (md2/etc/passwd) und schreibt neben jede Datei ein .fileinfo (Modus, uid/gid, Zeit). Alles extrahieren holt alle Partitionen.
Hinzufügen (Auf die Platte schreiben, Strg+←, oder Ziehen) legt in den angeklickten Ordner der Platte — beim Ziehen in den Ordner unter dem Mauszeiger. Ein .fileinfo neben der Datei liefert Modus, Besitzer und Zeit; sonst gelten 0644/0755, uid/gid 0 und „jetzt“. Ist kein Zielordner bestimmt, wird nichts geraten. Löschen entfernt Dateien und Ordner (keine Partition); Ordner auf der Platte anlegen… (Menü Bearbeiten, auch im Kontextmenü) legt einen Ordner im angeklickten Ordner an.
Schreibschutz. Wie bei jedem Datenträger ist er beim Öffnen gesetzt; Diskette ▸ Schreibschutz (Strg+R) hebt ihn auf. Geschrieben wird erst beim Speichern (Strg+S), und zwar in der Art der Quelle (.img.gz bleibt gepackt). Vor dem ersten Zurückschreiben entsteht einmalig eine Sicherung <abbild>~.
Gesperrt sind Aktionen, die an einer Platte keinen Sinn haben — mit Begründung im Tooltip: Diskeditor, Bootabbild, Dateisystemwahl und Spurschnitte (die Platte hat keine Spuren, Seiten oder Systemspuren), Greaseweazle, Diskettenangaben, Dateisystemprüfung, Wiederherstellen, Archivieren, Speichern unter (für eine Arbeitskopie die Datei im Dateimanager kopieren) und Alles einfügen (dafür Ziehen oder Auf die Platte schreiben).

CopyQM-Abbilder

Viele Abbilder alter Rechner liegen als .cqm (Programm CopyQM). Das Werkzeug liest und schreibt sie wie ein .img: Öffnen, Dateien holen, Speichern, Löschen, Alles einfügen, Reparieren, Dateiangaben ändern und der Schreibschutz-Schalter arbeiten wie bei jedem anderen Abbild. Speichern unter… und Neue Diskette bieten .cqm als Ziel an. Nur tar-Disketten bleiben gesperrt (auch in einer .cqm; der Tooltip nennt den Grund).

Bezeichnung, Etikett, Interleave/Skew, Prüfwert und der Kommentar des Abbilds stehen unter Diskettenangaben…; der Kommentar außerdem als Tooltip am Dateinamen. Beim Zurückschreiben und bei Speichern unter… nach .cqm bleiben sie erhalten, solange die Geometrie gleich bleibt (Kommentar und Etikett auch sonst); der Umweg über .hfe und zurück erzeugt einen neuen Standardkopf („Image file created by k1520emu“). Datei → Medium → Datei ist inhaltsgleich, aber nicht byteidentisch (anderer Packschnitt).

Was abgelehnt wird. Ein Medium, das CopyQM nicht darstellen kann, wird vor dem Schreiben abgewiesen; die Datei bleibt unverändert, die Meldung nennt den Grund:

„CopyQM unterstützt keine gemischten Formate: die Spuren haben unterschiedliche Sektorgrößen oder Sektorzahlen“ — z. B. CP/A-Bootdisketten (128-Byte-Systemspuren),
„CopyQM kann die Sektorkontrollblöcke von UDOS nicht speichern“ — UDOS/ZDOS (die Verkettung steht hinter der Daten-CRC),
„CopyQM kennt nur MFM mit voller Datenrate“ — FM-Spuren,
„CopyQM kann unformatierte Disketten/Spuren nicht speichern“.

Dasselbe gilt in der Kommandozeile (save-as, create, export). Beim Archivieren liegt das Abbild als .hfe im Archiv (wie bei jeder Quelle); das Inhaltsverzeichnis nennt die .cqm als Quelle samt Kommentar, das maschinenlesbare Verzeichnis führt unter source_container die Angaben und die Prüfsumme der .cqm-Datei. Beispiel Konvertieren (Aufnahme → CopyQM, wo es passt): k1520disktool save-as scheibe.hfe scheibe.cqm.

TeleDisk- und ImageDisk-Abbilder

Abbilder des Programms TeleDisk (.td0) und der ImageDisk (.imd) werden wie ein .cqm gelesen und geschrieben (Öffnen, Dateien holen, Speichern, Speichern unter…, Neue Diskette, Schreibschutz-Schalter). Diskettenangaben… zeigt Version, Datum, Datenrate (.td0), Spuren, Sektoren, den Kommentar und Warnungen (z. B. beschädigte Sektorprüfsummen). Fehler- und Löschmarken der Sektoren bleiben erhalten. Nicht darstellbar sind UDOS/ZDOS (Sektorkontrollblock hinter der Daten-CRC) und unformatierte Disketten; ein .imd kennt außerdem nur eine Sektorgröße je Spur. Ein .td0 wird immer unkomprimiert („TD“) geschrieben; Pseudosektoren der Datei bleiben nur beim Speichern in .td0 erhalten. Auch hier gilt: tar-Disketten bleiben gesperrt.

Containerformate im Vergleich

Dasselbe Dateisystem kann in vier Behältern liegen. Sie unterscheiden sich darin, wie nah an der Scheibe sie sind:

	`.img`	`.cqm`	`.dmk`	`.hfe`
speichert	nur Sektorbytes	Sektorbytes, RLE-gepackt	Spurbytes + Tabelle der Adressmarken	Bitzellen der ganzen Spur
Geometrie	nicht in der Datei: kommt aus dem Formatkatalog (`formats.yaml`)	im Kopf, eine (Sektorgröße, -zahl, Seiten, Zylinder)	je Spur	je Spur
selbstbeschreibend	nein	ja	ja	ja
gemischte Geometrie (128-B-Systemspuren)	ja, über das Katalogformat	nein	ja	ja
Lücken, Sync, Daten hinter der CRC (UDOS)	nein	nein	ja	ja
FM / MFM	je Katalogformat	nur MFM	beides	beides
unformatierte Spuren	nein	nein (Enden nur als „nicht gespeichert“)	ja	ja
Kommentar / Etikett	nein	ja	nein	nein
Komprimierung	nein	ja	nein	nein

Daraus folgt:

Bootdisketten (CP/A: 128-Byte-Systemspuren, sonst 512 B): gemischte Geometrie — als .cqm nicht darstellbar. UDOS auf A5120 und PRG 710: Sektorkontrollblöcke und Gap-Verkettung hinter der CRC — weder als .cqm noch als .img. FM-Disketten und unformatierte Leerdisketten: nicht als .cqm (.img kennt „unformatiert“ ebenfalls nicht). UDOS1715/NDOS (Zeigersektoren) geht in jedem Behälter.
Empfehlung: Bootdisketten und UDOS als .hfe (verlustfrei, auch physisch schreibbar); Austausch und Archiv einheitlicher Disketten als .cqm (klein, trägt Kommentar) oder .img; .dmk für Werkzeuge, die es erwarten.

UDOS1715 — dasselbe UDOS, anderes Dateisystem

Disketten vom PC 1715 tragen UDOS mit dem Treiber NDOS statt ZDOS. Das Werkzeug erkennt sie von selbst und nennt sie udos1715.

Dieselben Disketten schreiben auch der EAW P8000 (dort UDOS 2.2, z. B. seine WEGA-Startdiskette) und der A5120 unter UDOS 5.0. Die Rechner haben nichts miteinander zu tun — sie legen ihre Disketten nur gleich an. Das Werkzeug zeigt trotzdem, von welchem Rechner eine Diskette stammt: udos1715 (PC 1715), udos_p8000 (P8000) oder udos50 (A5120, UDOS 5.0). Erkannt wird das an einer einzigen Stelle, der Füllung hinter dem Belegungsplan (Spur 17H, Sektor 0, Bytes 158H–176H: 00, 77 bzw. FF). Für die Bedienung macht es keinen Unterschied.

Drei Dinge sind dort anders als bei den A5120-Disketten:

Die Diskette ist ein Datenträger, nicht zwei Seiten — es gibt kein Side0 und Side1, und beim Extrahieren entstehen keine Unterordner.
Sie lässt sich sehr wohl als .img ablegen. Der Floppycontroller des PC 1715 kann nichts hinter die Prüfsumme schreiben, also steht dort auch nichts: die Verkettung liegt in eigenen Zeigersektoren innerhalb der Diskette. (Eine einzelne Aufnahme kann trotzdem .img verweigern — dann trägt sie die Schreibnaht eines überschriebenen Sektors hinter einer Prüfsumme.)
Ein Dateiname muss mit einem Buchstaben beginnen.

Dateityp, Eigenschaften und der ganze Rest des Kopfsektors sind dieselben wie bei UDOS/ZDOS; Eigenschaften-Dialog und Beiblatt gelten unverändert.

Angelegt wird eine solche Diskette mit dem Dateisystem udos1715 (80 Spuren beidseitig, 640 KB), udos1715_ss80 (320 KB) oder udos1715_ss40 (160 KB); udos_p8000 und udos50 legen dieselbe 640-KB-Diskette mit der Füllung des jeweiligen Rechners an. Für UDOS 5.0 gibt es ein hinterlegtes Bootabbild: mit „Bootdiskette erstellen“ und danach den Dateien der Beispieldiskette a5120_udos50/a5120_udos50_k5601_system.hfe (mindestens OS, DDOS, ZDOS, OS.INIT) entsteht eine startfähige Diskette.

Was eine Datei außer ihren Bytes hat

Rechtsklick auf eine Datei ▸ Eigenschaften (oder Doppelklick, oder Alt+Eingabe) zeigt die Angaben, die ein Linux-Dateisystem nicht tragen kann:

UDOS — den ganzen Kopfsektor: Dateityp, Eigenschaften (W/E/L/S), Satzlänge, Einsprungadresse, Speichersegmente, Lade- und Endadresse, Stapelgröße, Datum. Bei einer Programmdatei steuern diese Angaben, wie UDOS sie lädt — falsche Werte ergeben ein Programm, das nicht startet. Das Feld Segmente trägt sie alle, durch Leerzeichen getrennt (4000+06A7 62A7+0002 …): ein Programm kann mehrere Speicherbereiche belegen.
CP/M — Nutzerbereich (0–15) und die Attribute R/O, SYS, ARC.
tar — wie bei WEGA Modus, uid, gid und mtime (aus dem tar-Kopf); in der .fileinfo steht fs=tar.
WEGA (UNIX des P8000) — die Inode: Dateiart, Modus (als Kästchen für Besitzer/Gruppe/Andere, die Sonderbits setuid/setgid/sticky und als Oktalzahl wie bei chmod), Besitzer (uid), Gruppe (gid), Änderungszeit (mtime, GMT), dazu als reine Anzeige Inode-Nummer, Links, Zugriffs- und Inode-Zeit und die belegten Blöcke. Änderbar sind Modus, uid, gid und mtime; Dateiart, Inode, Größe und Links sind Struktur. Das Übernehmen ist eine Transaktion im Dateisystem. Die Inode-Zeit (ctime) setzt jede Änderung auf „jetzt“, wie im echten System.

Der Nutzerbereich gehört zur Identität einer CP/M-Datei: ihn zu ändern benennt die Datei um (3:PIP.COM).

Wo diese Angaben bleiben, wenn eine Datei den Ordner erreicht

Beim Herausholen legt das Werkzeug neben jede Datei eine gleichnamige Textdatei mit der Endung .fileinfo — ACTIVATE und ACTIVATE.fileinfo. Darin steht alles, was oben im Eigenschaften-Fenster zu sehen ist. Schreibt man die Datei später wieder auf eine Diskette, wird sie von selbst gelesen; die Datei ist damit für sich genommen vollständig, gleich wohin man sie kopiert. Beim Herausholen des ganzen Inhalts entsteht zusätzlich ein Sammelbeiblatt (udos-dateiangaben.txt bzw. cpm-dateiangaben.txt) — es bleibt bestehen, aber man ist nicht mehr darauf angewiesen.

Ein .fileinfo ist Zubehör, keine Datei der Diskette: schreibt man einen ganzen Ordner zurück, wird es ausgewertet und nicht mitkopiert (im Protokoll steht dann „… (24 .fileinfo ausgewertet)"). Wählt man dagegen nur eine .fileinfo aus, fragt das Werkzeug nach — das ist fast immer die falsche der beiden gleichnamigen Zeilen.

Bei UDOS entsteht das .fileinfo immer. Dort ist es der Unterschied zwischen einem lauffähigen Programm und einem, das mit MEMORY PROTECT VIOLATION abgewiesen wird: ohne die Angaben wüsste UDOS nicht, dass es ein Programm ist, wohin es geladen gehört und wo es anfängt. Fehlen sie beim Zurückschreiben, wird deshalb gefragt statt geraten — ein Fenster erhebt Typ, Satzlänge und, bei einem Programm, Einsprung und Speicherangaben. Bei mehreren Dateien genügt „Für alle übernehmen".

Bei WEGA entsteht es immer (fs=wega_mutos): mode (oktal, samt Dateiart), uid, gid, mtime, dazu zur Auskunft art, nlink, inode, atime, ctime und bei Geräten rdev. Beim Zurückschreiben gelten Modus (untere 12 Bit), uid, gid und mtime; Links und Inode-Nummer vergibt das Dateisystem neu. Auch jedes Verzeichnis bekommt eines (usr.fileinfo neben dem Ordner usr) — ohne Rechte wäre /tmp danach nicht mehr für alle beschreibbar. Das Sammelbeiblatt heißt wega-dateiangaben.txt und führt alle Inodes, auch Gerätedateien, die als Datei nicht existieren können; sie werden nicht ausgelesen. Ein .fileinfo anderer Herkunft (UDOS/CP/M) wird bei WEGA überlesen.

Bei CP/M entsteht es nur auf Wunsch — Übertragung ▸ Bei CP/M je Datei ein .fileinfo anlegen. Dort gibt es nichts zu retten, was sonst verloren ginge: Nutzerbereich 0 ohne Attribute ist der Normalfall, den auch das echte CP/M erzeugt, und beides lässt sich jederzeit über Eigenschaften nachtragen. Wer eine Sammlung führt und jede Datei für sich vollständig haben will, schaltet es ein.

MS-DOS-Disketten (FAT12) — PC, A7150/DCP, PC 1834

Das DiskTool liest und schreibt die Disketten, die ein PC-DOS, MS-DOS, DCP (A7150, PC 1834) oder Windows angelegt hat: 160K bis 1,44M (und 2,88M). Die Lage steht im Bootsektor (BPB); das Dateisystem heißt in der Titelzeile dos720, dos360 … je nach Größe.

Ordner erscheinen als aufklappbare Zeilen. Auf einen Ordner geklickte oder gezogene Dateien landen darin; Neuer Ordner legt ihn an (ohne angeklickten Ordner in der Wurzel). Alles holen/einfügen nimmt den ganzen Baum mit, auch leere Ordner.
Lange Namen (Windows ab 95) werden gelesen und geschrieben; im Tooltip steht der 8.3-Kurzname. Eine DCP-Diskette bekommt beim Schreiben Kurznamen — ein DOS 3.3 kennt keine langen. Verboten sind \ / : * ? " < > | und DOS-Gerätenamen (CON, NUL …).
Angaben (Doppelklick): R/O, versteckt, System, Archiv und Datum/Uhrzeit. Das Datum der Datei geht beim Holen auf die Linux-Datei über und kommt beim Einfügen von ihr zurück. DOS kennt keine Zeitzone; gerechnet wird mit der Ortszeit.
Platz: Cluster werden aufgerundet, die Wurzel hat eine feste Zahl Einträge; passt etwas nicht, bleibt die Diskette unverändert. Die Prüfung (Strg+F) findet Kreuzverweise, verlorene Cluster und beschädigte FAT-Kopien.
Hochdichte-Disketten 1,2M und 1,44M lassen sich in allen Dateiformaten anlegen und speichern (.img, .hfe, .dmk, .cqm, .td0, .imd); 2,88M nur als .img. Der Emulator nimmt sie nicht an (kein Laufwerk kann 500 kbit/s).

Bootfähige DOS-Diskette: Datei ▸ Neue Diskette, Dateisystem dos720, Haken „Bootdiskette erstellen" und einen hinterlegten Lader wählen (DCP 3.3, DCP 3.20, DCP 3.2/PC 1834, MDISK). Dann Diskette ▸ Systemdateien übernehmen (DOS SYS) und eine Systemdiskette wählen — der Bootsektor und IO.SYS/DCDOS.SYS (bzw. BIO.COM/DOS.COM) kommen mit Attributen und Zeit auf die leere Diskette; die Lader suchen sie an den ersten Verzeichnisplätzen. Der Bootsektor trägt dabei den BPB der neuen Diskette: ein Lader einer 720K-Diskette taugt auch für 360K.

MicroDOS — das CP/M der Rostocker Anpassung

MicroDOS 1526 (A5120/A5130) und MicroDOS 1715 (PC 1715) sind CP/M-2.2-Abkömmlinge: Dateien mit Nutzerbereich, R/O-, SYS- und ARC-Attribut wie gewohnt (Eigenschaften, attr --arc; das Archivieren packt sie samt Beiblatt cpm-dateiangaben.txt). Besonderheiten: Das Verzeichnis beginnt gleich auf der ersten Spur, den Lader trägt der Anfang des Verzeichnisses (er erscheint nicht als Datei und wird nie überschrieben), und die Systemdatei MicroDOS.SYS liegt an festen Sektoren (Spuren 1–4; bei 128-Byte-Sektoren Spuren 1–5) — sie ist deshalb Teil des Bootabbilds (Lader + System, 16 KB), nicht eine Datei zum Einfügen. Erkannt wird eine Diskette nur mit Lader (microdos800, microdos200, microdos128, microdos1715); eine Datendiskette gleicher Geometrie heißt cpa800. Eine neue Systemdiskette entsteht über Neue Diskette ▸ Bootdiskette mit einem der mitgelieferten Abbilder. Das System ist fest auf Tastatur und Laufwerke eingestellt (Generierung MSYSG): die Auswahl nennt sie — 800K: Tastatur K7637 (seriell) oder K7636 (parallel), vier Laufwerke K5601; 200K: dieselben Tastaturen, zwei Laufwerke K5600.10 (nicht K5600.20); 100K mit 128-Byte-Sektoren (microdos128): K7637, zwei Laufwerke K5600.10, bootet mit Lade-ROM V0.6 und V0.9_2. Im Emulator muss die Bestückung dazu passen, sonst bleibt das Laden bei den Punkten stehen. Die Prüfung meldet, wenn MicroDOS.SYS nicht dort liegt, wo der Lader sie holt (die Diskette würde nicht starten).

Neue Disketten und Bootdisketten

Datei ▸ Neue Diskette (Strg+N) legt eine formatierte, leere Diskette an. Im Auswahlfenster wählt man das Dateisystem und — falls gewünscht — das Bootabbild; erst nach Diskette anlegen fragt das Werkzeug nach der Datei (neuer Name oder eine vorhandene zum Überschreiben) und nach dem Datenträgernamen.

Bei den UNIX-Dateisystemen (WEGA, MUTOS 8000, MUTOS 1700) steht im Auswahlfenster unter dem Dateisystem der Haken Abweichende Anzahl von Inodes. Das Zahlenfeld zeigt zunächst die Vorgabe (Blöcke ÷ 25 Blöcke für die Inode-Liste, wie mkfs) und ist gesperrt; mit dem Haken lässt sich eine andere Zahl eintragen (zum Beispiel 272 für die Diskette ROOT1_D). Jede Datei, jedes Verzeichnis und jedes Gerät braucht eine Inode — die Zahl begrenzt also, wie viele Dateien auf die Diskette passen; die Inode-Liste selbst belegt Blöcke, die für Daten fehlen. Kleiner gewählt bleibt mehr Platz für Daten, größer lassen sich mehr (kleine) Dateien ablegen. Auf der Kommandozeile heißt es create --inodes N.

Darunter steht der Haken Bootdiskette erstellen mit einem Auswahlfeld daneben. Das Feld bietet die hinterlegten Bootabbilder des gewählten Dateisystems an — die Systemspuren aller mitgelieferten Systemdisketten (CP/A, SCPX, UDOS 4.3, BCU 880, SCPX 8915, PRG 710, SCP 1715, CP/Z, SCP 3.0, OS/M, UDOS 5.0). Der erste passende ist vorgewählt; mehrere gibt es, wo dasselbe Dateisystem auf verschiedenen Rechnern bootet (scpx640: A5120, PRG 710/710-1, PC 1715). Der letzte Eintrag, Eigene .bin-Datei auswählen…, fragt sofort nach einer Datei — etwa einem Abbild, das man mit Diskette ▸ Bootabbild sichern aus einer vorhandenen Bootdiskette geholt hat. Gibt es für das Dateisystem keinen hinterlegten Eintrag (Datendisketten wie cpa800, aber auch udos1715 und udos_p8000, für die der Weg noch nicht geprüft ist), ist der Haken grau. Passt ein eigenes Abbild nicht in die Systemspuren, wird gar nichts angelegt und die Meldung nennt beide Größen.

Die Auswahl steht in der Datei bootsektor.yaml neben dem Formatkatalog, die Abbilder im Ordner bootsektoren/ daneben (Hilfe bzw. --paths nennt den Ort). Eigene Einträge gehören in eine Datei gleichen Namens im Konfigurationsordner — sie kommt zu den mitgelieferten hinzu und übersteht ein Update:

version: 1
bootsektoren:
  - description: "Mein CP/A mit Sondertreiber"
    filesystem:  cpa780
    file:        meine_abbilder/cpa_sonder.bin

filesystem ist ein Name aus der Dateisystemliste des Dialogs, file ein Pfad relativ zu dieser Datei. Ein Eintrag, der nicht taugt, erscheint nicht im Feld; den Grund nennt das Protokoll.

Für den K8915 (SCPX 8915) heißt das Dateisystem scpx8915; das Bootabbild muss den Ladekopf einer K8915-Systemdiskette tragen — ein A5120-Abbild wird abgewiesen, bevor etwas angelegt wird.

Für den PC 1715 und den 1715W (SCP 3.0) heißt es scp1715; CP/A 1715 hat keine Systemspuren, sein Bootkopf steht in den ersten Verzeichnisplätzen (cpa1715, Bootabbild = 128 Byte) — dort muss @OS.COM die erste Datei sein. Ein Abbild ohne den 1715-Kopf (A5120-Lader) wird abgewiesen.

Eine bootfähige Diskette braucht danach noch die Systemdateien: bei CP/A @OS.COM und die Dienstprogramme, bei UDOS mindestens OS und ZDOS.

Eine echte Diskette am Greaseweazle

Diskette ▸ Physische Diskette laden (Strg+Umschalt+O) öffnet keine Datei, sondern eine echte Diskette in einem echten 5,25″- oder 8″-Laufwerk, das über einen Greaseweazle-Adapter am USB hängt. Ab dann arbeitet das Werkzeug wie mit einem Abbild — Dateien holen, schreiben, löschen, Diskeditor.

Im Dialog stehen dabei drei Angaben, die nur Sie kennen können:

Zylinder (80 oder 40) — wie weit nach innen gefahren wird. „40" an einem 80er-Laufwerk liest genau die äußeren 40 Zylinder.
Doppelschritt erzwingen — Spur 1 liegt dann auf Zylinder 2, Spur 2 auf Zylinder 4 und so fort. So beschreibt ein 40-Spur-Laufwerk (K5600.10) eine Diskette; ein 80-Spur-Laufwerk erreicht dieselben Spuren nur mit doppeltem Schritt.
Nur Seite 0 — die Rückseite wird gar nicht angefahren.

Das ist mehr als eine Zeitersparnis. Wer eine 40-Spur-Diskette einliest, die früher einmal zweiseitig mit 80 Spuren formatiert war, schleppt sonst den alten Bestand mit: auf den ungeraden Spuren und auf der Rückseite steht noch das frühere Format, und die Erkennung sieht eine Mischung, die es nirgends gibt. Wird dort gar nicht erst gelesen, kommt eine saubere einseitige Diskette herein.

Beim Schreiben entscheidet der Doppelschritt, in welchem Rechner die Diskette danach läuft: mit Haken auf jedem zweiten Zylinder — dann liest sie ein K5600.10; ohne Haken dicht hintereinander — dann liest sie ein K5601.

Aufzeichnung: Datenrate und Drehzahl

Das Feld Aufzeichnung sagt, wie die Diskette beschrieben ist und wie schnell das Laufwerk dreht:

Eintrag	Diskette	Laufwerk
250 kbit/s — 5,25″ doppelte Dichte	250 kbit/s, 300 U/min	300 U/min
500 kbit/s — 8″ MFM	500 kbit/s, 360 U/min	360 U/min
417 kbit/s — 5,25″ HD 1,2M im 300-U/min-Laufwerk	500 kbit/s, 360 U/min	300 U/min
500 kbit/s — 5,25″ HD 1,2M (IBM-PC-Laufwerk)	500 kbit/s, 360 U/min	360 U/min
500 kbit/s — 3,5″ HD 1,44M	500 kbit/s, 300 U/min	300 U/min

Eine 1,2M-Diskette ist für 360 U/min geschrieben. Dreht das Laufwerk nur mit 300 U/min, kommen ihre Daten mit 417 kbit/s am Lesekopf an — das rechnet das Werkzeug selbst um. Das gespeicherte Abbild ist in beiden Fällen dasselbe, und was ein 300er-Laufwerk schreibt, liest ein 360er-PC-Laufwerk und umgekehrt (am Gerät geprüft).

Auf der Kommandozeile: --rate und --rpm beschreiben die Diskette, --drive-rpm das Laufwerk (Vorgabe = --rpm), z. B. --rate 500 --rpm 360 --drive-rpm 300.

TEAC FD-55GFR (5,25″ HD) fest auf 300 U/min: dafür müssen die drei Jumper I, IS und LG gesteckt sein. So eingestellt ist das Laufwerk kompatibel zum K5601 (Datenrate 250 kbit/s) und liest und schreibt zugleich HD-Disketten von PC-Laufwerken (1,2M, im Laufwerk 417 kbit/s) — im Dialog den Eintrag „417 kbit/s — 5,25″ HD 1,2M im 300-U/min-Laufwerk" wählen.

Dasselbe auf der Kommandozeile

k1520disktool --physical ls -l
k1520disktool --physical save-as sicherung.hfe
k1520disktool --physical --write put NEU.TXT

Befehle: ls, info, check, get, put, rm, save-as, rewrite; die Laufwerksangaben aus dem Dialog heißen dort --drive, --cyls, --heads, --rate, --rpm, --drive-rpm, --double-step. Ohne --write wird nichts verändert — das ist Absicht: an der Kommandozeile fragt niemand nach.

Drei Unterschiede, die man kennen muss:

Das Öffnen dauert einen Moment. Die Formaterkennung liest ein paar Spuren quer über die Diskette — rund zehn Sekunden. Ein Fortschrittsfenster zeigt, wo es steht, und lässt sich abbrechen. Passt keines der bekannten Formate, sieht sie doch die ganze Diskette an; dann dauert es gut anderthalb Minuten.
Geöffnet wird schreibgeschützt, bis man widerspricht. Ein Fehler kostet hier nicht eine Kopie, sondern die einzige noch existierende Diskette.
Gespeichert ist erst, was zurückgelesen wurde. Speichern schreibt jede geänderte Spur und liest sie sofort wieder ein, um sie zu vergleichen. Erst dann gilt sie als geschrieben. Das dauert, findet aber Schadstellen, die ein Schreiben ohne Gegenprobe verschweigt.

Der Diskeditor lässt sich dabei jederzeit öffnen, auch wenn die Diskette erst zum Teil gelesen ist. Spuren, von denen das Werkzeug noch nichts weiß, sind schwarz — das ist etwas anderes als grau („unformatiert"): grau ist ein Befund, schwarz heißt nur, dass noch keiner vorliegt. Die Ansicht füllt sich, während im Hintergrund weitergelesen wird; ein Klick auf eine schwarze Spur holt sie sofort.

Wenn kein Dateisystem erkannt wird

Dann ist die Diskette trotzdem offen — nur ungedeutet. Sie liegt im Speicher, der Diskeditor geht, das Abbild lässt sich mit Speichern unter sichern; gesperrt ist nur, was Dateien braucht. Im Hintergrund wird weitergelesen.

Warum nicht? Das Protokoll (F8) sagt es: die Erkennung probiert jedes in Frage kommende Dateisystem durch, und jede Probe nennt, woran sie sich gestoßen hat — „Verzeichnisplatz 0 trägt Nutzerbereich 0xDC", „Belegungskarte Spur 23: der Zählerabgleich scheitert". Dieselbe Liste steht unter Diskette ▸ Dateisystem prüfen und reparieren… (Strg+F), der auch ohne erkanntes Dateisystem aufgeht; zu reparieren gibt es dort nichts, aber oft ist die Liste schon die ganze Auskunft darüber, um was für eine Diskette es sich handelt.

Danach gibt es zwei Wege:

Dateisystem im Kopfbereich wählen — die Deutung wird am Speicherabbild wiederholt, die Diskette wird dafür nicht noch einmal gelesen.
Diskette ▸ Speicherabbild ändern — zwei Schnitte, die eine Diskette lesbar machen können:
- Ungerade Spuren entfernen — für eine 40-Spur-Diskette, die im Doppelschritt beschrieben, aber einfachschrittig gelesen wurde. Auf den ungeraden Spuren steht dann noch das frühere Format.
- Seite 1 entfernen — wenn die Rückseite nur Altbestand trägt.
Beide arbeiten am Abbild, nicht an der Diskette. Danach ist die Verbindung zum Laufwerk beendet: die Spurnummern stimmen nicht mehr mit den Kopfpositionen überein, es wird also nicht weitergelesen und nichts mehr zurückgeschrieben. Das Abbild bleibt vollständig — zurückschreiben lässt es sich mit Physische Diskette überschreiben und gesetztem Doppelschritt-Haken.

Nach jedem Schnitt wird die Erkennung erneut versucht.

Trägt die Diskette eine Spur nicht mehr, sagt das die Meldung mitsamt Spurnummer — das Abbild im Speicher ist dann noch heil. Der Ausweg steht im Streifen und unter Diskette ▸ Diskette neu beschreiben: neue Diskette einlegen, alles noch einmal wegschreiben. Nur bereits gelesene Spuren können dabei geschrieben werden; was nie gelesen wurde, ist keine Aussage über den Inhalt und bleibt deshalb weg.

Eine Diskette beschreiben

Diskette ▸ Physische Diskette überschreiben geht den umgekehrten Weg: was gerade geöffnet ist — auch eine .hfe-Datei — wird auf eine echte Diskette geschrieben. So bringt man ein Abbild zurück auf einen Datenträger.

Zuerst kommt die Rückfrage, denn hier geht kein Abbild verloren, sondern eine Diskette: ihr bisheriger Inhalt ist danach fort. Dann wird das Laufwerk gewählt — und dann läuft es im Hintergrund: die Statuszeile zählt die geschriebenen Spuren mit, der Streifen meldet das Ende. Man kann derweil weiterarbeiten; nur das Laufwerk ist belegt, und die Diskette darf bis zum Ende nicht entnommen werden. Jede Spur wird geschrieben und zurückgelesen. Passt das Abbild nicht in die eingestellte Laufwerksgeometrie (mehr Spuren oder Seiten, als das Laufwerk hat), wird gar nichts geschrieben; eine halb überschriebene Diskette wäre das schlechteste Ergebnis.

Der Menüpunkt ist gesperrt, wenn die Greaseweazle-Hosttools fehlen; sein Kurzhinweis sagt dann, was zu tun ist:

pip install "git+https://github.com/keirf/greaseweazle.git@v1.23"

Die Diskette wird beim Öffnen geprüft

Sobald eine Diskette offen ist, sieht sich das Werkzeug ihr Dateisystem an — das Verzeichnis und, wo es eines gibt, den Belegungsplan. Das kostet nichts: es sind genau die Spuren, die zum Öffnen ohnehin gelesen wurden. Das Ergebnis steht

in der Statuszeile rechts: ohne Befund oder etwa ⛔ 2,
im Meldungsstreifen, wenn etwas Ernstes dabei ist — mit dem Knopf Befund ansehen…,
im Protokoll (F8) vollständig, mit Uhrzeit,
unter Diskette ▸ Diskettenangaben… als Abschnitt „Prüfbericht".

Es gibt vier Schweregrade. Drei davon sind Auskunft; auf den vierten kommt es an:


Hinweis	bemerkenswert, aber nicht falsch
Warnung	in sich widersprüchlich, ohne Folgen
Fehler	etwas ist schon jetzt unerreichbar oder falsch
Gefahr	der nächste Schreibvorgang zerstört Daten

Bei Gefahr ist die Antwort immer dieselbe: den Schreibschutz gesetzt lassen, erst ein Abbild sichern (Speichern unter…), und die Diskette nicht beschreiben. Der häufigste Fall ist, dass zwei Verzeichniseinträge denselben Bereich der Diskette beanspruchen — wer als Zweiter schreibt, überschreibt den Ersten.

Die volle Prüfung steht unter Diskette ▸ Dateisystem prüfen und reparieren… (Strg+F) und, nur zum Lesen, unter Diskette ▸ Diskettenangaben… als Schaltfläche Vollprüfung. Sie fasst jede Spur an und findet dadurch, was beim Öffnen nicht zu sehen war: Kettenbrüche, doppelt belegte Bereiche, den Abgleich zwischen Belegungsplan und Dateien und Sektoren mit falscher Prüfsumme.

Sie läuft, sobald das Fenster aufgeht — wer es öffnet, hat die Prüfung verlangt; an einer Datei dauert sie den Bruchteil einer Sekunde. Der Knopf Noch einmal prüfen wiederholt sie, etwa nach einem Eingriff im Diskeditor. Nur wenn eine echte Diskette noch nicht vollständig gelesen ist, bleibt es bei der Schnellprüfung.

Oben im Fenster steht die Checkliste: eine Zeile je Arbeitsschritt, mit Haken und Ergebnis. Sie beantwortet die Frage, die „ohne Befund" offenlässt — worauf wurde denn gesehen. Ein Schritt, der nicht gelaufen ist, steht mit dazu und nennt den Grund (etwa „nur bei der Vollprüfung").

Bei einer echten Diskette am Greaseweazle kostet das die ganze Scheibe (0,5–0,8 s je Spur). Deshalb lädt das Werkzeug die fehlenden Spuren vorher nach und zeigt dabei einen Fortschrittsbalken mit „x von y Spuren geladen" — abbrechbar. Danach liegt die Diskette vollständig im Speicher, und jeder weitere Lauf ist so schnell wie an einer Datei.

Die Prüfung ändert nie etwas. Dasselbe geht auf der Kommandozeile mit k1520disktool check <abbild> --full; das fasst jede Spur an und findet zusätzlich Sektoren mit falscher Prüfsumme — und sagt dazu, welche Datei darauf liegt.

Stimmt die angegebene Größe? Ja, das wird geprüft — und zwar für jede Datei. Bei CP/M steht die Länge im Verzeichnis, die Daten stehen dort, wohin die Blockzeiger des Eintrags weisen; die Prüfung rechnet nach, ob die Zeiger die angesagte Länge überhaupt decken. Das ist wichtiger, als es klingt: fehlt ein Zeiger, kommt die Datei beim Herausholen trotzdem in voller Größe heraus — der Fehlbetrag besteht dann aus Nullen. Die Prüfung sagt es genau: „14464 Byte angesagt (113 Sätze), aber nur 4096 Byte durch Blockzeiger gedeckt — beim Herausholen kämen 10368 Byte Nullen heraus." Der Vorschlag dazu setzt die Satzzahl auf das, was wirklich dasteht; er ist als Datenverlust gekennzeichnet und deshalb nicht vorausgewählt, denn die Datei wird dadurch kürzer.

Bei UDOS und NDOS gibt es dieselbe Nachrechnung schon länger — dort steht die Satzzahl im Kopfsektor und die Kette der Sätze ist die zweite Auskunft darüber („Der Kopfsektor sagt 11 Sätze an, die Kette hat 7").

Ist die Prüfung ohne Befund, dann ist die Datei beim Herausholen byte-genau so groß, wie sie angegeben ist — im Übertragungsmodus binär. Im Modus Text werden Zeilenenden umgesetzt (CR LF ↔ LF), und dabei ändert sich die Bytezahl gewollt.

Bei UDOS-Disketten (beide Ausprägungen) kann die volle Prüfung mehr als bei CP/M: dort steht die Verkettung der Dateien in den Daten selbst und daneben ein Belegungsplan — zwei Angaben über dieselbe Sache. Widersprechen sie einander, sagt die Prüfung genau, welche Datei betroffen ist. Der ernste Fall heißt „ein Sektor gehört zu einer Datei, steht aber als frei": die Datei ist heil, und der nächste Schreibvorgang überschreibt sie.

Die volle Prüfung sieht dort außerdem in die freien Bereiche. Ein Sektor mit falscher Prüfsumme, der zu keiner Datei gehört, ist nämlich nicht nichts: dort liegen die gelöschten Dateien, und dorthin schreibt UDOS als nächstes. Es ist kein Datenverlust — aber ein Grund, die Diskette zu kopieren, solange es noch geht.

Von der Datei zu ihren Bytes: ein Rechtsklick auf eine Datei in der linken Liste bietet Im Diskeditor öffnen an — das schlägt ihren ersten Sektor auf (bei UDOS den Kopfsektor mit Typ, Länge und Segmenten). Im Diskeditor sind bei UDOS die Zeilen zurück: und vor: anklickbar: so folgt man der Kette einer Datei von Satz zu Satz, ohne Spur und Sektor abzutippen.

Reparieren

Diskette ▸ Dateisystem prüfen und reparieren… (Strg+F) zeigt denselben Befund noch einmal — diesmal mit dem, was sich daran tun lässt. Jede Zeile trägt links den Befund, rechts den Vorschlag; unten stehen die Einzelheiten mitsamt Ort. Ein Doppelklick auf eine Zeile — oder der Knopf Im Diskeditor zeigen — schlägt genau den Sektor auf, den der Befundtext nennt, nicht bloß die Spur.

Drei Dinge sind daran fest verabredet:

Vorausgewählt ist nur, was keine Daten verwirft. Ein Vorschlag, der etwas wegwirft — eine gebrochene Kette kürzen, einen doppelt beanspruchten Bereich einer der beiden Dateien wegnehmen —, steht da, ist aber nicht angekreuzt. Er trägt die Marke Datenverlust.
Ein Befund ohne Vorschlag hat kein Ankreuzfeld. Er ist eine Auskunft, kein Versäumnis: ein Sektor mit falscher Prüfsumme lässt sich nicht ausrechnen.
Manche Vorschläge sind gesperrt, solange die Diskette nicht vollständig gelesen ist oder noch ein Kettenfehler offensteht. Der Grund steht daneben. Einen Belegungsplan aus halbem Wissen neu aufzubauen hiesse, die ungelesene Hälfte für frei zu erklären — und beim nächsten Schreiben zu überschreiben.

Ausgeführt wird alles Angekreuzte in einem Zug und in der richtigen Reihenfolge (Verzeichnis → Ketten → Belegungsplan → Zähler); geht etwas schief, bleibt die Diskette unverändert. Danach wird sofort neu geprüft, und das Protokoll (F8) trägt die Bilanz: vorher 3 Befunde (1 Gefahr) → nachher 0 Befunde (0 Gefahr).

Die Sicherung entsteht von allein: beim ersten Schreiben legt das Werkzeug <name>~ neben das Abbild. Bei einer echten Diskette gibt es die nicht — dort ist Speichern unter… vor dem Eingriff die einzige Umkehr.

Dasselbe auf der Kommandozeile:

k1520disktool fsck <abbild> [--full] [--repair[=alle|<kennung>,…]] [--dry-run]

Ohne --repair wird nur geprüft. --repair führt die empfohlenen Reparaturen ohne Datenverlust aus, --repair=alle auch die übrigen, und --repair=cpm.zeiger.streichen,… genau die genannten. --dry-run sagt nur, was geschähe.

Gelöschte Dateien suchen

Diskette ▸ Gelöschte Dateien suchen… holt hervor, was ein Löschen übriggelassen hat. Und das ist überraschend viel — keines der Dateisysteme überschreibt beim Löschen die Daten. Nur was übrigbleibt, ist verschieden:

	Was das Löschen tut	Was übrigbleibt
CP/M	setzt ein Byte — den Nutzerbereich des Verzeichnisplatzes auf 0xE5	Name, Typ, Satzzahl und alle Blockzeiger stehen unverändert da
UDOS / ZDOS / NDOS	schneidet den Verzeichniseintrag heraus und löscht die Bits im Belegungsplan	Der Kopfsektor vollständig und die ganze Kette. Verloren ist allein der Name

Daraus folgt der Unterschied, der beim Bedienen auffällt: bei CP/M kennt der Fund seinen Namen, bei UDOS nicht. Dort heißt er GERETTET.001 — es sei denn, im Verzeichnis steht noch ein Namensrest, dann wird der vorgeschlagen (nie als Tatsache ausgegeben; er lässt sich in der Liste ändern).

Gesucht wird sofort beim Öffnen des Fensters, und zwar über die ganze Oberfläche — an einer Datei kostet das den Bruchteil einer Sekunde. Wie bei der Prüfung steht oben eine Checkliste mit den Schritten des Laufs und dem, was jeder gefunden hat.

Zwei Suchtiefen stehen oben im Fenster:

Verzeichnisreste — bei CP/M nur die gelöschten Verzeichnisplätze, und das kostet nichts: das Verzeichnis ist ohnehin gelesen.
Ganze Oberfläche — zusätzlich jeder freie Bereich der Diskette. Das findet die Bruchstücke ohne Verzeichnisplatz (Verzeichnis neu aufgesetzt, Diskette halb neu beschrieben).

Bei UDOS kosten beide Tiefen gleich viel. Nach dem Löschen steht im Verzeichnis nichts Gesuchtes mehr — gesucht wird nach der Signatur des Kopfsektors, und dafür müssen die Datenspuren angesehen werden. Die beiden Tiefen unterscheiden sich dort nur darin, welche Sektoren als Kandidat gelten und ob Rohbereiche gesammelt werden. An einer echten Diskette wird vorher geladen, mit Fortschrittsbalken; danach ist es so schnell wie an einer Datei.

Jeder Fund trägt eine Güte, und die ist keine Schätzung, sondern eine Aussage mit Belegen — sie steht als Tooltip und unter der Vorschau im Klartext:

Güte	heißt
✔ sicher	kein Block des Fundes gehört einer lebenden Datei — der Inhalt ist der von damals
≈ wahrscheinlich	vollständig, aber mit benannten Vorbehalten (falsche Prüfsumme, zweiter Anspruch)
✂ Bruchstück	ein Teil ist neu vergeben oder die Struktur bricht ab — nur der Anfang ist zu retten

Drei Wege stehen unten:

In den Ordner retten… ist der Vorgabeweg und geht immer — auch an einer schreibgeschützten Diskette, auch bei einem Bruchstück. Der übliche Fall ist „einmal alles retten, was noch da ist, dann die Diskette in Ruhe lassen". Fehlende Bereiche werden mit Füllbytes aufgefüllt, damit die Offsets der übrigen stimmen; daneben entsteht dann ein Beiblatt <datei>.rettung.txt, das genau das festhält. Für ein Textdokument ist das brauchbar, für ein Programm nicht.
Alles Sichere retten… schreibt alle Funde der Güte sicher in einen Ordner.
Auf der Diskette wiederherstellen trägt den Fund wieder ins Verzeichnis ein und verlangt Schreibrecht. Das gibt es nur bei CP/M — dort ist es ein einziges Byte, und der Name stimmt. Es geht nur, wenn kein Block des Fundes inzwischen einer lebenden Datei gehört — sonst entstünde genau die Kreuzbelegung, die die Prüfung als Gefahr meldet. Steht der Knopf still, sagt die Zeile darüber, warum. Der ursprüngliche Nutzerbereich ist übrigens nicht zu retten: er stand in ebendem Byte, das beim Löschen überschrieben wurde — wiederhergestellt wird nach Bereich 0.

Bei UDOS führt der Weg zurück über den Ordner, und er ist vollwertig:

Fund in den Ordner retten.
Der Datei dort den passenden Namen geben — und die .fileinfo daneben mitbenennen (aus GERETTET.001 und GERETTET.001.fileinfo werden NOTE.TO.SD und NOTE.TO.SD.fileinfo); im Sammelbeiblatt udos-dateiangaben.txt steht der Name ebenfalls.
Mit Einfügen wieder auf die Diskette bringen.

Dass das trägt, liegt am Kopfsektor: er überlebt das Löschen ganz. Typ, Eigenschaften, Startadresse, Satzlänge, alle Speichersegmente und beide Datumsvermerke sind noch da, und das Werkzeug schreibt sie beim Retten in die .fileinfo und ins Beiblatt. Verloren ist wirklich nur der Name — die Attribute kommen von selbst mit.

Erst ansehen, dann handeln

Neben der Vorschau steht die Sektorliste des Fundes, und Im Diskeditor zeigen schlägt den gewählten Sektor auf. Damit lässt sich vor jeder Aktion nachsehen, was da wirklich steht.

Das ist keine Bequemlichkeit, sondern bei UDOS die einzige Handhabe: es gibt keinen Namen zum Wiedererkennen, und die Sätze einer Datei liegen nicht hintereinander. NOTE.TO.SD der Referenzdiskette belegt auf Spur 21 die Sektoren 6, 7, 12, 23, 1, 8, … — verkettet und physisch verschränkt. Wer nur den ersten Sektor kennt, findet den zweiten nicht. Der erste Eintrag der Liste ist bei UDOS der Kopfsektor; dort stehen Typ, Startadresse und die Segmente — also genau das, woran sich eine namenlose Datei erkennen lässt.

Zwei Funde mit demselben Namen

Bei CP/M kann derselbe Name zweimal in der Liste stehen. Das ist kein Fehler: es sind zwei nacheinander gelöschte, verschiedene Dateien. Der Nutzerbereich, der sie unterscheiden würde, ist ja das gelöschte Byte — auseinandergehalten werden sie an der Extentnummer. Der Text sagt es dazu („es gibt 2 gelöschte Einträge dieses Namens"), und der zweite bekommt den Speichervorschlag NAME.2, damit Alles Sichere retten den einen nicht mit dem anderen überschreibt.

Funde ohne Namen (die Bruchstücke) heißen fragment_c12h0_b40-b47.bin, bei UDOS fragment_c12h0_s6-s26.bin; der Name lässt sich in der Liste ändern, bevor man rettet.

Dasselbe auf der Kommandozeile:

k1520disktool recover <abbild> [--full] [--to ordner] [--list] [--restore N[=NAME]]

Ohne --to wird nur aufgelistet; --full ist die Oberflächensuche, und --restore 0=ALT.COM trägt Fund 0 unter dem Namen ALT.COM wieder ein — nur bei CP/M; bei UDOS lehnt es ab und nennt den Weg über den Ordner. --json gibt dieselbe Liste maschinenlesbar aus, samt der Sektoren jedes Fundes.

Archivieren

Datei ▸ Archivieren (Strg+Umschalt+A) packt in eine .zip:

das verlustfreie Abbild als .hfe (auch wenn die Quelle ein .img war),
alle Dateien einzeln, nach Seiten sortiert,
ein lesbares Inhaltsverzeichnis mit allen Dateiangaben und einer Legende,
ein maschinenlesbares Verzeichnis diskarchive.yaml,
die maschinenlesbaren Beiblätter.

Vorher wird nach der Beschriftung der Diskette gefragt — dem Text auf dem Aufkleber. Daraus entstehen der vorgeschlagene Dateiname und die Namen der Dateien im Archiv, und sie steht im Kopf des Inhaltsverzeichnisses. Bei einer physischen Diskette ist das die einzige Auskunft darüber, welche Diskette archiviert wurde: sie hat keine Abbilddatei, von der sich ein Name ableiten liesse. Vorgeschlagen wird der Dateiname der offenen Diskette, sonst ihr Datenträgername.

Ein tar-Satz (mehrere Disketten, EIN Strom) lässt sich ebenso archivieren. Das Archiv enthält dann statt EINES .hfe alle Abbilder des Satzes im Ordner abbilder/ (nummeriert wie beim Speichern, name1.hfe, name2.hfe, unverändert), alle Dateien mit ihrer Ordnerstruktur und .fileinfo unter dateien/ und die Satzangaben (Basisname, Format, Abbildreihenfolge mit Prüfsummen) im Abschnitt tar_satz: der diskarchive.yaml und im Inhaltsverzeichnis. Archiviert wird der Stand der gespeicherten Abbilder: hat der Satz ungespeicherte Änderungen (oder wurde er noch nie gespeichert), fragt das Programm, ob es ihn erst speichern soll — „Nein“ bricht das Archivieren ab, es entsteht nichts Halbes. Zurück zum Satz kommt man mit python3 -m app.disktool.archive archiv.zip --satz-entpacken ORDNER: die Abbilder werden gegen ihre Prüfsumme geprüft und in den Ordner gelegt (vorhandene Dateien nur mit --force ersetzt); dann Datei ▸ tar-Satz öffnen…. Auf der Kommandozeile archiviert python3 -m app.disktool.archive satz1.hfe archiv.zip --satz satz2.hfe (jedes weitere Abbild mit --satz, in Stromreihenfolge).

Gedacht als Langzeitablage: aus dem Textteil allein lässt sich in zwanzig Jahren noch nachvollziehen, was auf der Diskette stand. Archivieren ist eine reine Leseoperation und geht auch mit gesetztem Schreibschutz.

Herkunft und Beschreibung (optional). Im Archivieren-Dialog klappt der Bereich Herkunft und Beschreibung auf: Quelle/URL, Satz/Titel, Version, Etikett und eine Bemerkung, dazu eine Tabelle Weitere Angaben (freie Schlüssel aus Kleinbuchstaben, Ziffern und Unterstrich) und die Liste Beschreibungsdateien. Die Angaben stehen im Inhaltsverzeichnis und unter provenance: in der diskarchive.yaml; die Beschreibungsdateien (Text, höchstens 4 MiB, Latin-1 oder UTF-8 wird erkannt und nach UTF-8 übernommen) liegen an der Wurzel der .zip – nicht unter dateien/ und damit nie auf der Diskette. Leere Felder erzeugen nichts; bleibt alles leer, ist das Archiv wie ohne den Bereich. Die zuletzt benutzten Angaben (nicht die Dateien) merkt sich das Programm; Zurück auf leer vergisst sie. Auf der Kommandozeile: python3 -m app.disktool.archive abbild.img archiv.zip --herkunft-datei meta.yaml --herkunft version=2 --beilage beschreibung.txt.

diskarchive.yaml — für die Inventur einer Sammlung. Dieselbe Auskunft für Programme: je Datei ihr Pfad im Archiv, Verzeichnis und Name, die Größe und eine SHA-256-Prüfsumme, dazu die Prüfsumme des Abbilds als Kennzeichen der Diskette selbst. Damit lässt sich über einen Stapel Archive auszählen, wie viele Fassungen von XYZ.COM es gibt und auf welchen Disketten sie liegen — ohne eine einzige .zip auszupacken:

import zipfile, yaml, collections
fassungen = collections.defaultdict(set)
for archiv in Path("archive").glob("*.zip"):
    with zipfile.ZipFile(archiv) as z:
        for f in yaml.safe_load(z.read("diskarchive.yaml"))["files"]:
            fassungen[f["name"].upper()].add((f["sha256"], archiv.name))

Archive auf der Kommandozeile

Das C++-Werkzeug k1520disktool hat keinen eigenen archive-Befehl für Abbilddateien. Archive entstehen auf zwei Wegen, beide mit demselben Ergebnis wie Datei ▸ Archivieren:

# 1. eine Abbilddatei (.hfe .dmk .img .cqm)
python3 -m app.disktool.archive abbild.hfe archiv.zip "CP/A Arbeit 7"

# 2. die Diskette im echten Laufwerk (Greaseweazle)
k1520disktool --physical archive archiv.zip --label "UDOS 4.3 Nr. 7"

Der erste Weg läuft im Quellbaum bzw. mit dem Python der Installation. Beim zweiten ist --label der Aufkleber (ohne ihn gilt der Datenträgername). Ein vorhandenes Archiv wird nicht überschrieben — Ausgang 2, es sei denn, man gibt --force an.

Schalter von python3 -m app.disktool.archive:

Schalter	Wirkung
`abbild archiv.zip [beschriftung]`	Quelle, Ziel, optional der Aufkleber als dritter Wert
`--bezeichnung TEXT`	dasselbe wie die Beschriftung; benennt die Dateien im Archiv
`--ohne-abbild`	kein `.hfe` ins Archiv, nur Dateien und Verzeichnisse
`--text`	Zeilenenden umsetzen (Textauszug)
`--force`	vorhandenes Archiv ersetzen
`--herkunft-datei DATEI`	YAML- oder JSON-Datei mit Herkunftsangaben → `provenance:`
`--herkunft SCHLUESSEL=WERT`	einzelne Angabe, mehrfach möglich, überschreibt die Datei; `hinweise=…` hängt eine Zeile an
`--beilage DATEI[=NAME]`	Beschreibungsdatei an die Wurzel der `.zip`, mehrfach möglich
`--beilage-kodierung K`	Kodierung der Beilagen; Vorgabe `auto` (UTF-8, sonst Latin-1)

Herkunft und Beschreibung — ein vollständiges Beispiel. Die Datei meta.yaml:

source_url: http://www.pofo.de/P8000/arch/
set_name: Ariane
version: "2.0"
web_label: ARIANE I 20.12.89
note: Von der Webseite geladen, CQM-Abbild unverändert.

python3 -m app.disktool.archive ariane1.cqm ariane1.zip "ARIANE I" \
    --herkunft-datei meta.yaml \
    --herkunft version=2.0b \
    --beilage ReadMe.txt=beschreibung_ariane.txt

Die Angaben stehen danach im lesbaren Inhaltsverzeichnis und unter provenance: in der diskarchive.yaml; bei einer .cqm-Quelle ergänzt das Werkzeug selbst source_container (Kommentar, Bezeichnung, Prüfsumme der .cqm), ohne die eigenen Angaben zu überschreiben. Die Beilage beschreibung_ariane.txt liegt an der Wurzel der .zip, nicht unter dateien/ und kommt deshalb nie auf eine Diskette, wenn man den Ordner dateien/ später mit put zurückschreibt.

Regeln, die das Werkzeug prüft (bei einem Verstoß Ausgang 2, bevor die Diskette oder das Laufwerk angefasst wird):

Schlüssel bestehen nur aus Kleinbuchstaben, Ziffern und Unterstrich und beginnen mit einem Buchstaben.
Beilagennamen haben keine Pfadanteile und kein .., kollidieren nicht mit Namen, die das Archiv selbst vergibt (diskarchive.yaml, <name>.txt, <name>.hfe, dateien/) und sind untereinander verschieden (Groß-/Kleinschreibung zählt nicht).
Beilagen sind Text bis höchstens 4 MiB; eine Datei mit NUL-Bytes gilt als Binärdatei und wird abgewiesen.

Eine ganze Sammlung archivieren — ein Archiv je Abbild, mit einer Schleife:

for f in discs/*.cqm; do
    n=$(basename "$f" .cqm)
    python3 -m app.disktool.archive "$f" "archive/$n.zip" "$n" \
        --herkunft quelle=pofo.de --herkunft datei="$n.cqm"
done

Zur Inventur dient danach die diskarchive.yaml jedes Archivs (siehe oben).

Mehrdisketten-Sätze (tar). Gehören mehrere Disketten zu einem tar-Strom (ariane1, ariane2), sind die Dateien an den Diskettengrenzen abgeschnitten. Vollständig herausholen lassen sie sich mit k1520disktool tar-satz ariane1.cqm ariane2.cqm --to ordner; ein komplettes Satzarchiv samt Einzelarchiven je Diskette erzeugt das Skript tools/p8000/pofo_archive.py (--quelle, --meta, --ziel, --nur NAME, --trocken). Es verwendet dieselben Prüfregeln wie die Kommandozeile.

Angaben des Dateisystems stehen dort bewusst nicht — die führen das Inhaltsverzeichnis und die Beiblätter. Der Kopf der Datei erklärt jedes Feld; diskarchive: 1 ist die Fassung des Formats, künftige Erweiterungen kommen als zusätzliche Felder hinzu.

Der Diskeditor

Diskette ▸ Diskeditor (Strg+E) zeigt die Diskette eine Ebene unter dem Dateisystem: zwei Scheiben, Spur 0 außen, Sektor 0 auf zwölf Uhr, Seite 1 gespiegelt. Grün ist ein gültiger Sektor, rot ein defekter, orange die Lücke dazwischen, grau eine unformatierte Spur. Schwarz heißt „noch nicht gelesen" (nur bei einer physischen Diskette).

Dunkel- oder hellgrün? Hellgrün ist ein Sektor, der zwar formatiert, aber nie beschrieben wurde — sein Datenfeld trägt nur das Füllbyte des Formats. So sieht man auf einen Blick, wie viel von der Diskette wirklich benutzt ist. Der UDOS-Anhang hinter den Nutzdaten zählt dabei nicht mit: er ist auch auf einer leeren Diskette belegt.

Ein Klick auf einen Sektor — oder die Wählerzeile darunter — zeigt seinen Inhalt als Hexdump mit mitlaufender Textspalte, dazu die Prüfsumme. Save Sektor schreibt bis in die Datei. Sektoren lassen sich anlegen und löschen; die Prüfsumme ist absichtlich mitschreibbar, damit sich eine schadhafte Diskette originalgetreu nachbilden lässt.

Ganze Spuren lassen sich löschen und einfügen: Spur löschen wirft die gewählte Spur mit beiden Seiten heraus (alles dahinter rückt auf), Spur einfügen fragt beim Einfügen nach Spurnummer und Verfahren (FM oder MFM) und setzt dort eine unformatierte Spur ein, in der sich anschliessend mit Neuer Sektor von Hand formatieren lässt.

Beides ist wählbar, weil es in der K1520-Welt gemischte Formate gibt: eine FM-Spur lässt sich auch vor alle bestehenden MFM-Spuren setzen (Spurnummer 0), oder eine MFM-Spur hinter eine FM-Spur. Die neue Spur bekommt die eingegebene Nummer; alles ab dort rückt nach hinten — aus 42 wird 43. Damit stutzt man ein Abbild zurecht — etwa von 82 auf 80 Spuren oder auf 77, damit es auf eine 8″-Diskette passt. Bei einer physischen Diskette endet damit die Verbindung zum Laufwerk, denn die Spurnummern stimmen danach nicht mehr mit den Kopfpositionen überein.

Trägt ein Sektor hinter den Nutzdaten einen UDOS-Anhang (4 Byte), zeigt der Editor ihn und übersetzt ihn: die Verkettung zum vorigen und nächsten Satz. Das entscheidet der Sektor selbst — auch auf einer gemischten oder gar nicht erkannten Diskette wird er angezeigt. Wo stattdessen nur Füllbytes stehen (CP/M), bleibt die Angabe weg.

Wenn eine Diskette nicht erkannt wird

Das Werkzeug rät nicht. Es geht der Reihe nach vor:

Katalogformat — passt eine Geometrie aus formats.yaml, wird sie benutzt.
Abgeleitet (cpa_auto) — passt kein Dateisystemprofil, rechnet das Werkzeug den Aufbau nach derselben Regel aus, mit der auch das CP/A-BIOS beim LOGIN arbeitet. Über das Auswahlfeld im Kopfbereich lässt sich das erzwingen.
Gemessen — passt gar keine Katalogsgeometrie, wird sie an der Diskette selbst vermessen. Ein so geöffneter Datenträger ist unaufhebbar schreibgeschützt.
Ergibt auch das keinen zusammenhängenden Sektorraum, bleibt die Liste leer und die Meldung nennt die gemessenen Werte — sie taugt als Vorlage für einen neuen Katalogeintrag.

Steht im Streifen „nicht eindeutig erkannt", passen mehrere Dateisysteme gleich gut. Dann hilft ein Blick in die Dateiliste: das falsche Profil zeigt Unsinn. Über das Auswahlfeld im Kopf lässt sich das andere ausprobieren.

Die Prüfung nimmt einem diese Arbeit weitgehend ab: sie probiert die übrigen Profile still durch und sagt es, wenn eines besser durchkommt — „mit scp1700 kommt diese Diskette besser durch: 46 statt 43 sichtbare Dateien". Die Wahl ändert sie nie, sie sagt sie nur an; entschieden wird im Auswahlfeld. Der zweite Teil dieser Auskunft ist der wichtigere: ein Profil mit einem zu kleinen Verzeichnisbereich mountet anstandslos, prüft ohne Befund — und verschweigt einen Teil der Dateien. An der Zahl der Befunde ist das nicht zu erkennen, an der Zahl der Dateien schon.

Die anderen Werkzeuge

Im Menü Werkzeuge stehen A5120 Emulator starten und K8915 Emulator starten: die Emulatoren des Bürocomputers A5120 bzw. des Arbeitsplatzcomputers K8915, die von einer Diskette booten und das Betriebssystem wirklich laufen lassen. Jeder startet als eigenes Programm und läuft neben dem Diskettenwerkzeug weiter.

K1520 Kermit starten öffnet das Kermit-Werkzeug: Dateien mit der WEGA des P8000-Emulators (oder einem anderen Kermit) über Telnet bzw. RFC 2217 austauschen. Es hat ein eigenes Handbuch.

Beide Emulatoren lesen dieselbe Datei, aber jedes für sich. Hat die Diskette hier ungespeicherte Änderungen, wird vor dem Start danach gefragt — der Emulator sieht sonst den Stand der Datei, nicht den auf dem Bildschirm. Und umgekehrt: was der Emulator auf die Diskette schreibt, kommt hier erst an, wenn das Abbild neu geöffnet wird — Aktualisieren (F5) baut nur die Ansicht aus dem Speicherabbild neu auf und liest die Datei nicht noch einmal.

Tastenkürzel

Kürzel	Wirkung
Strg+O	Abbild öffnen
Strg+N	Neue Diskette
Strg+Umschalt+N	Neuen Ordner anlegen (rechte Hälfte)
Strg+Umschalt+O	Physische Diskette laden
Strg+S	Speichern
Strg+Umschalt+S	Speichern unter
Strg+Umschalt+A	Archivieren
Strg+W	Diskette schließen
Strg+Q	Beenden
Strg+A	Alles auswählen
Strg+→	In den Ordner holen
Strg+←	Auf die Diskette schreiben
Entf	Löschen
Alt+Eingabe	Eigenschaften
Strg+R	Schreibschutz
Strg+E	Diskeditor
Strg+F	Dateisystem prüfen und reparieren
F2	Umbenennen (rechte Hälfte)
F5	Aktualisieren
F8	Protokoll
F1	Dieses Handbuch

Was das Werkzeug zusichert

Beim Lesen kann nichts kaputtgehen. Geöffnet wird schreibgeschützt.
Passt es nicht, wird gar nicht erst geschrieben. Stapeloperationen werden vorher geprüft; ein Fehler mittendrin wird zurückgenommen.
Sicherungskopie. Beim ersten Zurückschreiben entsteht <name>~.
Kein Raten — und wo gerechnet wird, steht es dabei. Was abgeleitet oder gemessen wurde, sagt der Kopfbereich; Gemessenes bleibt schreibgeschützt.
Die Ansicht ist immer frisch. Nach jeder schreibenden Aktion wird das Verzeichnis neu aus dem Medium gelesen — es gibt keinen Zwischenspeicher, der etwas anderes behaupten könnte.

Bugs, Wünsche und Anregungen

Fehler, Wünsche und Anregungen bitte über das Ticketsystem des Projekts auf GitHub melden: https://github.com/olliy78/k1520emu/issues. Ein neues Ticket legt man dort mit New issue an; dafür braucht es ein (kostenloses) GitHub-Konto. Bevor Sie eins schreiben, lohnt ein Blick, ob dasselbe schon gemeldet ist.

Hilfreich in einer Fehlermeldung sind:

die Version (Hilfe ▸ Über … bzw. oben in diesem Handbuch),
das Betriebssystem des Rechners, auf dem der Emulator läuft,
was Sie getan haben, was Sie erwartet haben und was stattdessen geschah,
bei Problemen mit einer Diskette nach Möglichkeit das Abbild selbst (als Anhang am Ticket, falls seine Weitergabe erlaubt ist),
bei „wird nicht gefunden“ die Ausgabe von --paths (siehe oben).

Dokumentation

DiskTool Handbook

k1520DiskTool — Kurzhandbuch

Der übliche Weg

Wo die Dateien liegen

Das Fenster

Dateien übertragen

Schreibschutz und Arbeitskopien

UDOS-Disketten haben zwei Seiten

SCP1700 — das CP/M-86 des A7100

SIOS 1526 — die Etikettendisketten von A5120, A5130 und K8924

OS/M-Disketten — das CP/M des P8000

tar-Disketten — ein Archiv statt eines Dateisystems

tar-Sätze und -Archive im Fenster bearbeiten

tar-Archive herausholen, bearbeiten und zurückschreiben

Passende tar-Dateien unter Linux erzeugen und entpacken

tar-Disketten von MUTOS 8000 (A5120.16)

P8000-Platten (WEGA)

CopyQM-Abbilder

TeleDisk- und ImageDisk-Abbilder

Containerformate im Vergleich

UDOS1715 — dasselbe UDOS, anderes Dateisystem

Was eine Datei außer ihren Bytes hat

Wo diese Angaben bleiben, wenn eine Datei den Ordner erreicht

MS-DOS-Disketten (FAT12) — PC, A7150/DCP, PC 1834

MicroDOS — das CP/M der Rostocker Anpassung

Neue Disketten und Bootdisketten

Eine echte Diskette am Greaseweazle

Aufzeichnung: Datenrate und Drehzahl

Dasselbe auf der Kommandozeile

Wenn kein Dateisystem erkannt wird

Eine Diskette beschreiben

Die Diskette wird beim Öffnen geprüft

Reparieren

Gelöschte Dateien suchen

Erst ansehen, dann handeln

Zwei Funde mit demselben Namen

Archivieren

Archive auf der Kommandozeile

Der Diskeditor

Wenn eine Diskette nicht erkannt wird

Die anderen Werkzeuge

Tastenkürzel

Was das Werkzeug zusichert

Bugs, Wünsche und Anregungen

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally