Benötige Hilfe mit CP/M Images (mit Skew >1)

Hallo Robert,

kannst Du programmieren ?

Weil ich hätte da was: https://github.com/kkaempf/hxc…/blob/main/hxc_xml_gen.rb

Ein kleines Ruby Skript, welches ein XML File für HxC erzeugt. Mit HxC kann man das dann in beliebige andere Image-Formate wandeln.

Einen Skew habe ich noch nicht eingebaut ...

Grüße

Klaus

Ich haette hier 2 Programme, die aus einem "Linear"-Image ein geskewtes Images machen und umgekehrt.

Wenn's dir hilft.

Es werden 2 unterschliedliche Skews verwendet. Das ist eine Eigenart der VectorGraphics CP/Ms.

Schau mal, bei Fragen fragen.

Zitat von robert_99

Diese soll diverse "alte" Diskettenformate erkennen und interpretieren können.

Derzeit funktionieren: FLEX1, FLEX2 (SD und DD), FDOS, CP68, es65 und zum Großteil auch CP/M. Ich möchte die Darstellung jedoch verbessern und alle Sektoren die im Binary aufeinanderfolgen auch hintereinander darstellen.

Hallo Robert,

da hast Du Dir ja eine ganze Menge vorgenommen.

Zuerst sollten wir uns über den Begriff "Skew" unterhalten. Im Zusammenhang mit Disketten tauchen immer wieder zwei Begriffe auf: Skew und Interleave.

Diese werden auch öfters verwechselt, bzw. unterschiedlich gebraucht. Beide beziehen sich auf die Reihenfolge der Sektoren auf der Diskette. Der Sinn der Änderung der Sektorreihenfolge liegt in der schnelleren Zugriffszeit (gibt schon eine Menge Artikel zu dem Thema). Manche Systeme waren zu langsam, nach einem Sektor sofort den nächsten zu lesen. So kam es dazu, dass eine ganze Umdreheung abgewartet werden musste bis man zum gewünschten Sektor kam. Um das zu verhindern baute man eine kleine "Pause" zwischen den Sektoren ein und so konnte der nächste Sektor bereits nach kurzer Zeit gefunden werden (z.B. 1, 2, ... Sektoren dazwischen).

Ich für meinen Teil, benutze die Begriffe folgendermaßen ...

Skew bezieht sich für mich auf die physische Sektorreihenfolge. Auf üblichen Disketten wird zu jedem Sektor ein Sektorheader geschrieben (schon beim Formatieren), der eine physische Sektornummer enthält. Der Hardware-Controller greift über diese Nummer auf den jeweils richtigen Sektor zu. Das Programm merkt davon eigentlich nichts, da der Controller die Suche übernimmt. Das heißt die gelesenen Daten liegen in der aufsteigenden Reihenfolge der Sektoren vor, egal mit welchem Skew auf der Diskette gespeichert wurde.

Anders verhält es sich mit dem Interleave. Dieser wird hauptsächlich von CP/M verwendet. CP/M geht davon aus, dass die Daten linear vorliegen (Sektorreihenfolge nach physischer Nummerierung) und vertauscht dann die Sektoren je nach "Interleave-Tabelle", damit sie wieder der Reihe nach lesbar werden.

Eine Kombination von Skew und Interleave ist zwar denkbar, bringt in der Praxis jedoch nichts, da eine der beiden Methoden reicht, um die entscheidende Pause zwischen den Sektoren zu schaffen. Bei manchen Computern war die Pause nicht nötig, da sie schnell genug waren, unmittelbar nach einem Sektor den nächsten zu lesen.

Die Kombinationen des Interleave bei CP/M sind sehr vielfältig (je nach Hersteller). Einen kleinen Einblick kannst Du mit SAMCONV.xls gewinnen (läuft allerdings nur mit Windows EXCEL). SAMCONV.xls

Dort gibt es auch den OSBORNE. In der Spalte "Interleave" sieht man die softwaremäßige Sektorreihenfolge. In Kombination mit SAMconv (von Simon Owen), läuft auch nur unter Windows, könnte man physische Disketten in einem bestimmten Format erstellen und wieder einlesen (ohne Format, also linear).

Zitat von robert_99

Ich benötige speziell angefertigte Floppy Images in einem Format mit einem Skew > 1 mit den Records (128 Byte) gefüllt mit EINER 16 bit Zahl die pro Record um 1 inkrementiert wird. Der Sinn ist das ich somit aufeinanderfolgende Records (und auch Sektoren) leicht identifizieren kann.

Die Erstellung von solchen Testdaten ist meist ein Problem, bzw. kompliziert.

Ich habe mich 2020 mit einem ähnliche Problem befasst: Standard Testdisk

Die Idee war, auch dem Quellsystem mit einem kleinen BASIC-Programm eine Diskette zu beschreiben, bei der die einzelnen Sektoren eindeutig identifizierbar sind.

Eine Möglichkeit bestünde noch darin, mittels 22DISK oder ähnlich, einen definierten Inhalt auf eine Diskette in einem bestimmten Format zu Schreiben (z.B. OSBORNE) und dann mit Imagedisk zu lesen, um eine Binärdatei zu bekommen. Diese sollte dann in der "CP/M-Reihenfolge" sein. 22DISK schreibt ja anhand der Formatdefinitionen für OSBORNE, etc. auf die Diskette.

Grüße, PAW

Zitat von PAW

Skew und Interleave

Das seh ich genau anders rum. CP/M benutzt den Skew. Das steht auch in den meisten BIOSen drin.

Skew:

Die Sektorreihenfolge ist fest. Nimm am besten eine hardsectored Disk, hier kannst du die Sektorreihenfolge nicht aendern.

Mit dem Skew kriegst du Platz zwischen 2 logischen Sektoren.

Bleistift:

Das ist beim Skew = 3. Es wird fruehstens der physikalische Sektor n+3 fuer den naechsten logischen Sektor benutzt.

An dem Beispiel sieht man auch, des es mehr phys. Sektoren sein koennen, bei den log. Sektoren 3 und 4.

Aus dem Grund ist im CP/M BIOS auch eine Tabelle kodiert und keine Berechnung. Wenigstens i.a.

Interleave:

Beim Interleave werden die phys. Sektoren nicht linear angeordnet. Das geht logischerweise nur bei softsectored Disks.

Man sieht das ganz gut bei Imageprogrammen wie IMD, die die Sektoren anzeigt und die Reihenfolge nicht linear ist.

Bleistift:

Hier ist es eben ein Interleave von 3.

Zitat von funkenzupfer

Das seh ich genau anders rum. CP/M benutzt den Skew. Das steht auch in den meisten BIOSen drin.

Ich richte mich weitgehend nach 22DISK.

Zitat von Handbuch

SKEW specifies the physical interleaving of sectors .. This specification is optional; if omitted

a 1-to-1 physical interleave is assumed.

Zitat von Handbuch

SIDE1, which must come after the SECTORS specification, specifies the sector ordering on

the first cylinder surface. CP/M 2.2 allows a software interleave of sectors on a diskette; the

terms given there reflect that interleave.

Dort wird beim Parameter SKEW der Sprung beim Formatieren, also der physischen Reihenfolge der Sektornummern angegeben. Beim SIDE1-Parameter wird von "software interleave" gesprochen und gemeint ist die sector translation table von CP/M.

Weiter hinten wird von "interleave or skew" gesprochen. Offenbar sind die Begriffe gleichwertig, jedoch erst in Verbindung mit "physisch" oder "logisch" eindeutig. Das war unter anderem der Grund, warum ich Skew für den physischen Skew verwende und Interleave für den logischen.

In anderen Publikationen zu CP/M und SECTRAN ist wiederum folgendes zu finden:

Zitat von http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch6.htm#Section_6.10

Logical-to-physical sector translation is
performed to improve the overall response of CP/M.
Standard CP/M systems are shipped with a skew
factor of 6, where six physical sectors are
skipped between each logical read operation. This
skew factor allows enough time between sectors for
most programs to load their buffers without
missing the next sector. In particular computer
systems that use fast processors, memory, and disk
subsystems, the skew factor might be changed to
improve overall response. However, the user should
maintain a single-density IBM-compatible version
of CP/M for information transfer into and out of
the computer system, using a skew factor of 6.

In general, SECTRAN receives a logical sector number relative to zero in BC and a translate table address in DE. The sector number is used as an index into the translate table, with the resulting physical sector number in HL. For standard systems, the table and indexing code is provided in the CBIOS and need not be changed.

Alles anzeigen

Hier ist bei SKEW offenbar der logische SKEW gemeint.

Zitat von PAW

Ich richte mich weitgehend nach 22DISK.

Ich versuche mich da immer am Hersteller zu orientieren bzw dessen Definitionen zu verwenden.

Anderes Beispiel: Breite eines WORD

Intel 16bit, Motorola 32bit

Solche Wortspiele können dann in Dokumentationen schnell zu Verwirrung führen.

An der Stelle würde ich mich an SECTRAN (SECtor TRANSlation) halten, die Funktion kümmert sich darum.

Und wie gesagt, Interleave geht nur bei softsectored Disketten, zu den CP/M Anfängen waren die nicht üblich.

Zitat von funkenzupfer

Das seh ich genau anders rum

Sehe ich auch so. Interleave bedeutet tasächlich, dass physikalisch hintereinander liegende Sektoren nicht fortschreitend durchnummeriert sind, sondern z.B, bei einem Interleavefaktor von 2 folgendermaßen 0,5,1,6,2,7,3,8,4. Damit hat der Diskettencontroller bzw. das System jeweils 1 Sektor "Pause, in dem es den zuvor gelesenen Sektor verarbeiten kann oder den nächsten zu schreibenden Sektor vorbereiten kann. Bedeutet auch, die ganze Spur ist nach 2 Umdrehungen eingelesen. Interleave-Faktor 3 wäre 0,3,6,1,4,7,2,5,8. Bei Skew liegen die Sektoren immer als 0,1,2,3,4,5,6,8 durchnummeriert vor, aber das System muss immer erst in einer Tabelle nachsehen, welchen Sektor es als nächstes vom Floppycontroller anfordern muss, das macht es etwas aufwändiger und langsammer. Mehr als Ein Faktor 3 kommt in der Realität eigentlich nicht vor.

Da aus der Literatur die Zuordnung Interleave und Skew nicht eindeutig hervorgeht und ich auch keine Doktorarbeit zu dem Thema erstellen möchte, bleibe ich bei meinen Definitionen, werde aber nach Möglichkeit in Zukunft die Begriffe wie folgt ergänzen:

physischer Skew ... Versatz wie er bei der Formatierung verwendet wird

logischer Interleave ... Versatz durch CP/M

Damit ist jedenfalls klar was gemeint ist!

Zitat von 1ST1

Mehr als Ein Faktor 3 kommt in der Realität eigentlich nicht vor.

Diese Aussage kann ich nicht bestätigen!

Hier eine Auswahl von CP/M-Formaten entweder mit einem logischen Interleave größer 3 oder mit einem physischen Skew größer 3: Auswahl Formate mit Interleave oder SKEW größer 3.xls

Physische Skews gibt es hier bis zu 6

Dabei gibt es interessanterweise auch ein Format "ITH1" welches sowohl einen physischen Skew, als auch einen logischen Interleave aufweist.

Zitat von robert_99

Es ist also der Unterschied zwischen der Reihenfolge der Datenblöcke im Disk Image und im Binary wichtig. Ich bin mir nicht sicher wie imageprogramme (Imagedisk, 22Disk, Anadisk,...) das handhaben, aber bei IMD gibt es eine Sektormap die angibt in welcher reihenfolge diese ausgelesen werden.

Ob der physische Skew in die Binärdaten durchschlägt hängt wohl vom Immageprogramm ab. Wird dort der komplette Track auf einmal eingelesen, dann stehen die Sektoren in der physischen Reihenfolge in der Datei (also unsortiert). Möglicherweise gibt es eine Option bei den Immageprogrammen, um eine aufsteigende Reihenfolge nach physischen Sektornummern zu ermöglichen.

Stehen die Sektoren aufsteigend in der Binärdatei, dann kommt der logische Interleave (sector translation table von CP/M) zum Tragen. Diese Reihenfolge findet man z.B. in SAMCONV.xls oder in obigem EXCEL, aber auch in diversen Diskdefinitionen von z.B. 22DISK oder SuperCopy.

Zitat von robert_99

Directories und ev. auch der Bootsector haben KEINEN Versatz im Image. Wer gegenteiliges gesehen hat, bitte melden

So weit ich mich erinnere gilt der Versatz in CP/M auch für Directories.

Zitat von robert_99

CP/M hat für meinen Anwendungsfall "nur" einige Schrauben an denen man drehen kann (C, H, S, Byte/Sec, Bootsektor, Directory Entries, Blocksize, Allocation Table 8 oder 16bit und eben Skew). Alles andere ist irrelevant für das lesen bzw extrahieren der Daten. Auch hier sind gegenteilige Beispiele willkommen.

Es gibt noch die Möglichkeit, dass die Daten INVERS sind, d.h. Nullen und Einsen auf Binärebene vertauscht. Siehe Spalte mit "Data Mode" im EXCEL = "INV".

Zitat von robert_99

Den von mir angesprochenen Versatz gibt es NUR bei CP/M, ich habe ihn noch nirgendwo anders gesehen. Falls wer ein Beispiel hat wo das doch so ist bitte sagen.

Das Betriebssystem UCSD verwendet auch einen Sektorversatz. Siehe Philips und Altos. Diese wurden in SAMCONV aber fix im Programm verdrahtet und sind hier nicht parametrisierbar. Der Versatz ist außerdem trackabhängig, d.h. ist auf jedem Track anders (bis sich die Reihenfolge wiederholt).

Schönen Abend!

PAW

Zitat von PAW

physischer Skew ... Versatz wie er bei der Formatierung verwendet wird

logischer Interleave ... Versatz durch CP/M

Nö, eben nicht, weil es genau falsch herum ist. Sonst müsste man ja zwischen Disketten-Skew und Interleave beim Lowlevel-Formatiereren von MFM/RLL-Festplatten das Funktionsprinzip brechen.

Interleave ist immer physisch, weil physische Sektoren nicht fortschreibend durchnummeriert werden.

Die Logik ist das, was auf die Physik (Interleave) drauf setzt, also entweder "1:1" oder was anderes.

Ein Interleave von 6 macht nur bei sehr vielen Sektoren pro Spur Sinn, mit 9 Sektoren/Spur bekommt man den garnicht hin. Da musst du schon 18x 256 Byte Sektoren haben, oder 36 Sektoren mit 128 Bytes. Sehr sehr exotisch...

Du kannst das natürlich für dich und deine Software anders definieren, aber dann wurd niemand außer dir damit auf Anhieb zurecht kommen, alle anderen werden erstmal den Kopf schütteln.

Zitat von PAW

physischer Skew ... Versatz wie er bei der Formatierung verwendet wird

logischer Interleave ... Versatz durch CP/M

Ich find's auch falsch herum.

Vor allem weil ich in der CP/M Literatur noch nie den Begriff Interleave gesehen habe.

Zitat von funkenzupfer

Vor allem weil ich in der CP/M Literatur noch nie den Begriff Interleave gesehen habe.

Den Begriff Interleave findet man beim physischen Format von Disketten und Festplatten sehr oft. Ich erinnere an den Interleave-Faktor bei MFM und RLL-Platten, da hat sicher jeder damals damit auf seinem PC experimentiert, um die Kiste schneller zu machen, wenn man aus Interleave 3 Interleave 2 umformatieren kann, dann wird das Lesen/Schreiben aufeinanderfolgender Sektoren um 30% beschleunigt. Und wer gar 1:1 hinbekommt (weil der Controller schnell genug ist) der kann die Geschwindigkeit sogar nochmal verdoppeln.

Zitat von 1ST1

Den Begriff Interleave findet man beim physischen Format von Disketten und Festplatten sehr oft.

Gar keine Frage, aber in der CP/M Literatur habe ich es nicht gesehen. Weder bei Digital Research noch in vielen Buecher ueber CP/M.

Das wirst du wahrscheinlich auch nicht in allgemeiner Literatur finden, weil das die Hardwarehersteller selbst entscheiden müssen, nur die wissen, wie schnell der Floppycontroller nach einem Sektor wieder bereit ist, um sich um den nächsten Sektor zu kümmern. Das passt der Hersteller dann in seinem Formatier-Befehl an, das muss er wegen der CHS-Anpassung und des spezifischen Floppycontrollers eh machen, und an anderer Stelle muss sich da niemand darum kümmern.

Hab jetzt nochmal recherchiert, weil den Begriff Skew findet man bei Disketten (bzw. Festplatten) doch recht selten, und gleich der erste Treffer spricht von Software-Skew, das heißt der versetzte Zugriff auf aufeinanderfolgend fortlaufend nummerierte Sektoren: https://www.seasip.info/Cpm/skew.html - und das sogar im Zusammenhang speziell mit CP/M.

Tausche ich dann in der Suchmaschine den Suchbegriff "diskette skew " durch "diskette interleave" aus, dann kommt z.B. Wikipedia ins Spiel und zeigt, dass hier in der Spur aufeinander folgende Sektoren nicht fortlaufend durchnummeriert werden: https://de.wikipedia.org/wiki/…Disketten_und_Festplatten

Zitat von robert_99

Bezüglich Directory: Ich habe mit IMD einige CP/M Disketten gerippt und da sind die Directory Einträge alle in Folge, die Datenblöcke jedoch nicht.

Beispiel: 003.zip

Hallo Robert,

habe mir Dein Image 003 angesehen.

Es handelt sich dabei offenbar um eine CP/M Disk von "Oettle+Reichler PC 8000 Form. 2".

Die Definition der CP/M-Parameter für SAMCONV findest Du hier: Oettle+Reichler PC 8000 Form. 2.zip

Du kannst die Zeile kopieren und ins SAMCONV.xls kopieren.

SAMCONV konnte damit alle Dateien extrahieren: ###DOS###.zip

Ich habe dafür die IMD-Datei auf eine DSK-Datei mittels SAMdisk-GUI umgewandelt. Ein Scan zeigte, dass die Sektoren physisch in aufsteigender Reihenfolge vorliegen. Die DSK-Datei ist nach Tracks und Sektoren strukturiert, beinhaltet aber auch die Binärdaten. (Beschreibung des DSK-Formates gibt es auch im Netz.) Diese kann man mit einem HEX-Editor ansehen. Dort ist ersichtlich, dass das Inhaltsverzeichnis auf der Diskette NICHT durchgängig ist, sondern ebenfalls den gleichen (logischen) Sektorversatz aufweist, wie die Daten. Das Verzeichnis ist immer nur für 512 Bytes zusammenhängend, danach kommt wohl auch ein Verzeichnisteil, aber von weiter hinten. Nach weiteren 512 Bytes wird der erste Abschnitt fortgesetzt, usw. Das Verzeichnis ist zum Glück alphabetisch sortiert und so kann man das leicht überprüfen.

Falls Du wieder Images reinstellst, dann bitte um eine Info um welches Diskettenformat es sich handelt (außer Du weist es nicht). Hier war es Aufgrund der Textdatei relativ einfach die Definition zu finden.

Grüße, PAW

Zitat von robert_99

Im IMD file ist das directory eindeutig sortiert:

Leider nicht!

Die ersten 16 Einträge (Files) sind richtig, da sie in einem 512 Byte Block Platz haben. Nach dem 16. Filenamen COPYSYS.ASM sollte COPYSYS.CPM folgen! In Deinem Ausdruck steht aber INITDIR.CPM, welcher erst viel später kommen sollte. Das liegt am Sektorversatz! Schau Dir mal das komplette Directory im HEX-Editor genau an, eventuell in der IMG-Datei, dort sind nur die reinen Binärdaten zu sehen, ohne das was "verrutscht".

Hinweis: Bei den Dateinamen von SAMCONV.xls wurden die Endungen .COM auf .CPM verändert, wie es auch in 22DISK gemacht wird. Das hat den Sinn, dass man nicht versehentlich ein Z80-CP/M-Programm unter DOS startet. Mit 22NICE konnte man solche .CPM-Progamme dann unter DOS ausführen. Die Option für .CPM oder .COM läßt sich in SAMCONV.xls aber einstellen.

Grüße, PAW

Zitat von robert_99

Dann sollte es logischerwieis auch im Bottsector sein?

Glaube ich nicht, bin aber nicht ganz sicher.

CP/M Blöcke beginnen grundsätzlich mit dem Directory = Block 0. Die erste Datei liegt im Block nach dem kompletten Directory. Sieht man im jeweiligen Eintrag, ab dem 17. Byte. Dort sind die belegten Blöcke für die Datei angegeben. (Blocknummer 8 oder 16 Bit lang, je nach Geometrie). Es muss aber nicht der erste Eintrag im Directory die erste Datei enthalten. Hier beginnt die Datei "READ.ME" auf Block 0002 (02 00 im Dump). Die Blocknummern sind bei diesem Format jeweils 16 Bit, low Byte first.

Was mir gerade auch noch eingefallen ist, dass bei zweiseitigen Disketten die Füllreihenfolge zu beachten ist! Bei manchen wird immer ein Zylinder gefüllt (also Seite 1 und 2) und dann erst der nächste. Bei anderen wird zuerst auf alle Tracks auf Seite 1 geschrieben und danach die Seite 2. Da gibt es auch noch Unterschiede ... bei Seite 2 wird mit Track 0 begonnen oder mit dem höchsten Track und nach unten gezählt. Siehe Kommentar in Spalte "FILL ORDER" Zeile 3 in SAMCONV.xls

Grüße, PAW

Zitat von robert_99

Das mit Trackabhängigem Skew könnte ich mir ansehen wenn ich mehr Beispieldateien hätte.

Gibt's bei UCSD-Betriebssystem, nicht bei CP/M.

Hier ein Beispiel mit einem Altos-Image: ALTOS UCSD Images.zip

Du könntest versuchen, ob Du die Dateien mittels SAMCONV.xls extrahieren kannst. Format in Tabelle DISKDEF für ALTOS-UCSD auswählen. Dann bekommst Du die Dateien im Verzeichnis ###DOS### (auch im Zip beigelegt). Ursprünglich war das Image als TD0 im Netz. habe es dann mittels SAMdisk-GUI auf DSK konvertiert, was dann SAMCONV.xls lesen kann. Wie Du dann aus einer TD0 oder DSK-Datei ein binäres Image bekommst, musst Du selber sehen.

Zitat von robert_99

Mehr Beispielimages mit skew wären auch super, eventuell auch Images mit unterschiedlicher Füllreihenfolge.

Wenn SAMCONV.xls bei Dir läuft, dann kannst Du damit auch diverse Images (im DSK-Format von SAMdisk) erstellen. Dazu im Verzeichnis ###DOS### diverse Dateien hineinstellen und mit "Start Transfer FROM DOS ==>" das Image erzeugen. Damit kannst Du praktisch alle Varianten erzeugen, da Du ja auch die Formatdefinitionen im EXCEL ändern kannst (soferne SAMCONV.xls fehlerfrei läuft). Bleibt nur noch die Konvertierung auf eine Binärdatei. Hinweis: zum DSK-Format gibt es eine Beschreibung von Simon Owen.

Sollte SAMCONV.xls bei Dir nicht laufen, dann gibt es auch die Möglichkeit unter DOS mit 22DISK diverse Disketten zu Schreiben (ebenfalls in verschiedenen Formaten) und diese Diskette dann wieder mit einem Imageprogramm einzulesen.

Schönen Abend!

PAW

Zitat von PAW

Zitat von robert_99

Das mit Trackabhängigem Skew könnte ich mir ansehen wenn ich mehr Beispieldateien hätte.

Gibt's bei UCSD-Betriebssystem, nicht bei CP/M.

Nicht bei CP/M kann ich nicht bestätigen.

Vector Graphics hat unterschiedliche Skews benutzt, ich meine 3 für die Systemspuren und 5 für die Datenspuren.

Kann man in meinen Sourcen aus Post #4 sehen.

Aber es ist wirklich eine Ausnahme.

Zitat von funkenzupfer

Nicht bei CP/M kann ich nicht bestätigen.

Wir haben von logischem, trackabhängigen Sektorversatz gesprochen, den es bei UCSD gibt.

Wie funktioniert das bei CP/M? Gibt es dazu jeweils eine unterschiedliche SECTRAN?

Ich finde in "The Programmers CP/M Handbook" ist der SKEW schön erläutert.

oldcomputers-ddns.org/public/pub/manuals/a_programmers_cpm_handbook_(1983).pdf

Zitat von PAW

Wie funktioniert das bei CP/M? Gibt es dazu jeweils eine unterschiedliche SECTRAN?

Der Bootloader liest die Systemspuren mit Skew=3, das BIOS mit Skew=5.

Soweit meine Erinnerung. Wer's genauer wissen muss, bitte nachfragen, dann schau ich nochmal in die Sourcen.