8" Diskette mit SISYPHUS CP/M 2.2

    Hallo PAW,


    ich habe mit deiner alten Exceldatei (für Testausgaben) mal eine 10KB Textdatei erstellt. Diese habe ich mit 22DISK auf eine Sisyphus Diskette kopiert. Die Testdatei beinhaltet 160 Textzeilen.


    Ergebnis:


    1) ctype /sis1 a:


    Code
    00001 --- Testtext ---
...
00144 --- Testtext ---

Und das war es; die Zeilen 145 bis 160 fehlen!

    1) ctod /sis1 a:test010.txt test010.sis


    Hier die beiden Dateien:


    TEST010.TXT


    TEST010-SIS.TXT

    Ich verwende diese 22DISK Parameter:


    Code
    BEGIN SIS1  Sisyphus CP/M 2.2 - SSDD 8"
DENSITY MFM ,HIGH 
CYLINDERS 77 SIDES 1 SECTORS 48,128
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
 25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
END

    Hiermit scheint es (besser?) zu funktionieren. Ich habe die Werte für den Interleave aus IMD übernommen. Auch ANADISK ermittelt einen Interleave von 1:3, siehe Bild


    Code
    BEGIN SIS2  Sisyphus CP/M 2.2 - SSDD 8"
DENSITY MFM ,HIGH 
CYLINDERS 77 SIDES 1 SECTORS 48,128
SIDE1 0 1,17,33,2,18,34,3,19,35,4,20,36,5,21,37,6,22,38,7,23,39,8,24,40,
 9,25,41,10,26,42,11,27,43,12,28,44,13,29,45,14,30,46,15,31,47,16,32,48
BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
END


    Zitat von haglebu

    Hiermit scheint es (besser?) zu funktionieren. Ich habe die Werte für den Interleave aus IMD übernommen. Auch ANADISK ermittelt einen Interleave von 1:3, siehe Bild

    Für Track 2 ist das ja richtig. Aber mach mal einen Screenshot von Track 3 oder danach (von einer Originaldiskette)!


    Dort müsste man einen Skew von 2 sehen.


    Anmerkung: Wie ich den Unterschied zwischen Skew und Interleave sehe ...


    Skew ist für mich die Reihenfolge wie die Sektoren physisch auf einem Track geschrieben sind. Also bei FLUXDUMP sieht man genau die Sektornummern in der Reihenfolge wie sie im Fluxstrom auftauchen.


    Interleave ist für mich eine logische Reihenfolge der Sektoren innerhalb von CP/M. Hierbei wird von einer linearen Speicherung der physischen Sektoren ausgegangen. Anschließend wird die Reihenfolge durch CP/M laut Interleave-Liste vertauscht. Macht natürlich nicht das CP/M sondern das BIOS.


    Beides dient zur Beschleunigung des Lese-/Schreibvorganges, da früher die Rechner oft nicht schnell genug waren die Daten des nächsten Sektors zu bearbeiten. So wurde quasi eine Pause zwischen den Sektoren eingelegt und es musste nicht eine komplette Umdrehung der Disk abgewartet werden.


    Im Prinzip lassen sich beide Möglichkeiten kombinieren, bringt aber nichts für die Geschwindigkeit.


    FLUXDUMP mit BIN-Ausgabe rechnet bei der Option BIN-Sort den Skew bereits heraus, sodass danach die Sektoren bereits in physikalisch linearer Form vorliegen. Bei BIN-unsort werden die Sektoren in der Reihenfolge gespeichert, wie sie tatsächlich auf der Diskette stehen.


    PAW

    Hier mal mehrere Textdateien 1 bis 10KB im Original und dann jeweils mit SIS1 und SIS2 (CPMDISKS.DEF) auf Diskette kopiert und wieder ausgelesen. SIS1 funktioniert flott und SIS2 mit einem Interleave von 3:1 entsprechend länger.


    Merkwürdigerweise werden jetzt sowohl bei SIS1 und SIS2 die Textdateien korrekt kopiert.


    sis.zip

    Aber auch die SIS2 Definitionen für den Interleave scheinen nicht korrekt zu sein. Sowohl CTOD macht Probleme als auch die kopierten Dateien sind nicht in Ordnung. Die Versuche mit einem Interleave von 1:1 waren zwar auch nicht in Ordnung, aber besser als 3:1. Schade.

    Code
    BEGIN SIS2  Sisyphus CP/M 2.2 - SSDD 8"
DENSITY MFM ,HIGH 
CYLINDERS 77 SIDES 1 SECTORS 48,128
SIDE1 0 1,17,33,2,18,34,3,19,35,4,20,36,5,21,37,6,22,38,7,23,39,8,24,40,
 9,25,41,10,26,42,11,27,43,12,28,44,13,29,45,14,30,46,15,31,47,16,32,48
BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
END
    Zitat von PAW

    Für Track 2 ist das ja richtig. Aber mach mal einen Screenshot von Track 3 oder danach (von einer Originaldiskette)!


    Dort müsste man einen Skew von 2 sehen.

    Hallo PAW, du hast Recht. Ich habe ANADISK mal in einem anderen Modus benutzt und hier werden genau deine Angabe bestätigt.


    Track 2 hat 3:1 aber Track 3 ff hat 2:1.


    ACHTUNG! HAT SICH MIT DEINER LETZTEN ANTWORT ÜBERSCHNITTEN!


    Zitat von haglebu

    Hier die Informationen aus ANADISK für die Spuren 0, 1, 2, 3, 5 und 30.


    Spur 3, 5, 30 haben alle den Interleave 3:1. Dies sind auch die Ergebnisse aus IMD. Die Sektoren sind immer 1, 17, 33, 2, 18, 34, ... angeordnet.


    Welche Diskette war das?

    Sicher nicht diese (die ganz zu Beginn):

    Zitat von haglebu

    Hier ein Dump der ersten 10 Spuren mit Fluxcopy.


    sisyphus-cpm22.zip


    Wie man im Dump sieht ... Track2 ... Sektoren 1, 17, 33, 2, 18, 34, 3, ... SKEW = 3


    Wie man im Dumpt sieht ... Track3 ... Sektoren 1, 25, 2, 26, 3, 27, 4, ... SKEW = 2


    Sonst stimmt was nicht mit ANADISK.


    PAW

    Zitat von haglebu

    Aber auch die SIS2 Definitionen für den Interleave scheinen nicht korrekt zu sein. Sowohl CTOD macht Probleme als auch die kopierten Dateien sind nicht in Ordnung. Die Versuche mit einem Interleave von 1:1 waren zwar auch nicht in Ordnung, aber besser als 3:1. Schade.


    Habe mir vorhin die 22DISK-Doku durchgelesen. Es gibt dort keinen Hinweis darauf, dass auf einer Seite zwei verschiedene Skews möglich sind. Das wirft das Problem auf, wie 22DISK die Daten richtig lesen soll, wenn man die Unterschiede zwischen Track2 und den nachfolgenden nicht in der DIskDef spezifizieren kann.


    Vielleicht kann da fritzeflink was dazu beitragen?


    Geht eigentlich um die Frage, ob 22DISK grundsätzlich in der Lage ist so ein Format zu handhaben?


    PAW

    Zitat von PAW

    Geht eigentlich um die Frage, ob 22DISK grundsätzlich in der Lage ist so ein Format zu handhaben?

    Ja, ich starte gerade eine diesbezügliche Anfrage im VCF. Dort ist auch Chuck Guzis Mitglied; 22DISK ist ja von ihm. Mal abwarten.


    Sisyphus CP/M 2.2 and 22DISK
    On a 8" single-sided floppy disk from Germany "Regionales Rechenzentrum Erlangen, RRZE) I discovered a CP/M called Sisyphus 2.2. The first two tracks are in FM…
    forum.vcfed.org


    Soweit ich verstehe dient der SKEW in 22DISk nur bei der Formatierung dazu die Sektorreihenfolge vorzugeben.


    Zum Lesen sollte die Reihenfolge in der Sektorangabe eingetragen sein.


    Beispiel:


    BEGIN VG02 EACA VideoGenie I 80 DSDD 96 tpi 5.25"

    DENSITY MFM ,LOW CYLINDERS 80 SIDES 2

    SECTORS 5,1024

    SKEW 3

    SIDE1 0 0,2,4,1,3

    SIDE2 1 5,7,9,6,8

    NOTE 3 systemspur

    BSH 3 BLM 7 EXM 0 DSM 165 DRM 63 AL0 0C0H AL1 0 OFS 6

    END

    Mit freundlichen Grüßen


    fritz

    Zitat von fritzeflink

    Soweit ich verstehe dient der SKEW in 22DISk nur bei der Formatierung dazu die Sektorreihenfolge vorzugeben.


    Zum Lesen sollte die Reihenfolge in der Sektorangabe eingetragen sein.


    Das ändert nichts am Problem ... wie können zwei verschiedene Strukturen für die gleiche Seite definiert werden?


    Entweder stimmt das Verzeichnis (Track 2) oder es stimmen die Daten (ab Track 3)!


    Nachtrag: Würde man auf den Skew beim Lesen nicht Rücksicht nehmen müssen, dann wäre der logische Interleave mit 1, 2, 3, 4, 5, ... zu definieren. Dies wurde aber schon ausprobiert, siehe: RE: 8" Diskette mit SISYPHUS CP/M 2.2


    PAW

    Ja, Chuck hat geantwortet, aber er gibt seine Informationen immer nur tröpfchenweise weiter. Das ist immer recht ermüdent.


    Er unterscheidet bei ANADISK (wie auch bei FLUXCOPY) zwischen dem physikalischen Interleave und dem logischen Interleave bei 22DISK. Mir ist der Unterschied aber nicht klar.


    Ich frage weiter und hoffe auf Antworten.

    Zitat von PAW

    Nachtrag: Würde man auf den Skew beim Lesen nicht Rücksicht nehmen müssen, dann wäre der logische Interleave mit 1, 2, 3, 4, 5, ... zu definieren. Dies wurde aber schon ausprobiert, siehe: RE: 8" Diskette mit SISYPHUS CP/M 2.2

    Ich habe mir den nachfolgenden Track nochmals angeschaut und stimme PAW zu, dass der logische Interleave tatsächlich 1:1 mit 1, 2, 3, 4, 5, ... ist. Anders kann es nicht sein. Während der physikalische Interleave aber 2:1 mit 1, 25, 2, 26, 3, 27, ... ist.


    Somit macht auch die Aussage von Chuck Guzis Sinn: Es gibt den physikalischen (FLUXCOPY, ANADISK, IMD) und den logischen (22DISK) Interleave. Wieder was dazugelernt.

    Diese Reihenfolge entspricht bei mir SIS1 in der Definitionsdatei:


    Code
    BEGIN SIS1  Sisyphus CP/M 2.2 - SSDD 8"
DENSITY MFM ,HIGH 
CYLINDERS 77 SIDES 1 SECTORS 48,128
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
 25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
END

    Aber auch hier traten manchmal Ungereimtheiten auf. Vielleicht lag es aber auch an der Diskette bzw. Datei. Auf jeden Fall haben die Definitionen SIS2 (Interleave 3:1) und SIS3 (2:1) nahezu unbrauchbare Ergebnisse geliefert. Ich habe hierzu die Datei EXAMPLES.MAC mit allen drei Definitionen kopiert, d.h. ausgelesen.


    Auf jeden Fall funktioniert der Weg über FLUXCOPY und die BIN (bzw. IMG) Datei. Diese kann mit den CPMTOOLS ausgelesen werden; Kryoflux und HxC geht auch. SAMDISK habe ich noch nicht getestet.

    Zitat von haglebu

    Er unterscheidet bei ANADISK (wie auch bei FLUXCOPY) zwischen dem physikalischen Interleave und dem logischen Interleave bei 22DISK. Mir ist der Unterschied aber nicht klar.


    Ich habe im Thread Unterschied SKEW und Interleave bereits was dazu geschrieben. Ich persönlich habe den "physikalischen Interleave" als SKEW bezeichnet, da dieser auch bei 22DISK als Parameter in der DiskDef steht. Den "logischen Interleave" habe ich "nur" als Interleave bezeichnet. Den SKEW sieht man direkt im Dump von der Diskette oder auch bei ANADISK, etc. Er bezieht sich auf die Reihenfolge der Sektoren, wie sie auf der Diskette stehen. Jeder Sektor (zumindest bei Softsektor-Formatierung) ist auf der Diskette mit einer Sektor-ID versehen, aus welcher die Sektornummer hervorgeht.


    Der "logische" Interleave (von CP/M) geht davon aus, dass die physischen Sektoren bereits in der richtigen (aufsteigenden) Reihenfolge eingelesenen wurden. Die Sektoren werden dann anhand der Interleave-Liste entsprechend vertauscht und dem CP/M zugeführt. Das ist nötig, da sie beim Schreiben ebenfalls laut der Liste vertauscht wurden. Danach stehen sie wieder in der ursprünglichen Reihenfolge zur Verfügung.


    Sinn und Zweck ist es, dem System mehr Zeit zu lassen, die Daten zu verarbeiten. Wäre die Zeit zu kurz, dann müsste das Programm beim lesen des nächsten Sektors eine fast ganze Umdrehung der Diskette abwarten, bis wieder der gewünschte Sektor gelesen werden kann. Darum lässt man 1 oder 2 Sektoren Abstand. Dann hat das Programm genügend Zeit zur Verarbeitung und ist insgesamt schneller, obwohl es eine gewolllte Verzögerung gibt. Im schlimmsten Fall kann es vorkommen (ohne Interleave), dass pro gelesenem Sektor eine ganze Umdrehung benötigt wird!


    Zitat von haglebu

    Diese Reihenfolge entspricht bei mir SIS1 in der Definitionsdatei:

    ...

    Aber auch hier traten manchmal Ungereimtheiten auf. Vielleicht lag es aber auch an der Diskette bzw. Datei. Auf jeden Fall haben die Definitionen SIS2 (Interleave 3:1) und SIS3 (2:1) nahezu unbrauchbare Ergebnisse geliefert. Ich habe hierzu die Datei EXAMPLES.MAC mit allen drei Definitionen kopiert, d.h. ausgelesen.


    Könntest Du bitte die erste Diskette (die mit EXAMPLES.MAC) nochmal komplett mit SIS1 einlesen und die Dateien hochladen, damit ich sie vergleichen kann.


    Zitat von haglebu

    Auf jeden Fall funktioniert der Weg über FLUXCOPY und die BIN (bzw. IMG) Datei. Diese kann mit den CPMTOOLS ausgelesen werden; Kryoflux und HxC geht auch. SAMDISK habe ich noch nicht getestet.

    SAMCONV.xls ist noch nicht ganz fertig. Musste ja einen Umbau für die vielen Sektoren (mehr als 29) vornehmen. Wenn verfügbar, gebe ich Bescheid.



    PAW

    Zitat von PAW

    Könntest Du bitte die erste Diskette (die mit EXAMPLES.MAC) nochmal komplett mit SIS1 einlesen und die Dateien hochladen, damit ich sie vergleichen kann

    22DISK: sis1.zip

    Code
    BEGIN SIS1  Sisyphus CP/M 2.2 - SSDD 8"
DENSITY MFM ,HIGH 
CYLINDERS 77 SIDES 1 SECTORS 48,128
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
 25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
END

    Merkwürdigerweise tauchen im Inhaltverzeichnis 22DISK/CDIR einige Dateinamen doppelt auf. Ich kann nicht sagen, ob dies anfangs auch der Fall war. Und genau hier hat 22DISK jetzt Probleme wenn ich mit CTOD (herauskopieren) arbeite.

    doppelt sind:

    Code
    A0:STRUZ80.STR
A0:STRUDEUT.WI

    So sollte es eigentlich aussehen: nur 26 Dateien

    Wer sich auch noch sehr gut mit diesem Thema auskennt ist Larry Kraemer (ldkraemer). Hier sind seine Ergebnisse:


    examplemac.txt


    Mein persönliches Fazit:


    Der Weg über FLUXCOPY und die BIN (bzw. IMG) Datei fuktioniert gut. Danach können die Inhalte mit den CPMTOOLS oder SAMCONV extrahiert werden. Ich kann nur sagen, ich bin rundum zufrieden. Vielen Dank an PAW für FLUXCOPY; einfach nur genial :applaus:

    Chapeau!

    PS: PAW tut mir leid, dass ich dich wieder von einer eigentlich Arbeit abgehalten habe ;)

    Zu meiner Hardware ist noch zu berichten, dass ich unter DOS 6.22 einen AT286 mit der CompatiCard IV und das 8" Mitsubishi M2896-63 verwende. FLUXTEEN verwende ich unter Windows 10 mit dem 8" YD180-1601.


    Das Mitsubishi M2896-63 kann ohne Probleme auch hart-sektorierte Disketten lesen/schreiben.

    Zitat von haglebu

    So, das müsste jetzt passen.


    sis1.zip


    Sieht ja viel besser aus! :thumbup:


    Ein Vergleich ergibt eine gute Übereinstimmung, bis auf 2 Dateien.



    Diese beiden Dateien sind allerdings die größten.


    Habe auch kurz hineingesehen. Es fehlt jeweils der Anfang und das Ende des Textes.


    Warum weiß ich noch nicht.


    Grüße, PAW

    Und genau diese beiden Datei sind problematisch:


    Beitrag
    RE: 8" Diskette mit SISYPHUS CP/M 2.2
    Merkwürdigerweise tauchen im Inhaltverzeichnis 22DISK/CDIR einige Dateinamen doppelt auf. Ich kann nicht sagen, ob dies anfangs auch der Fall war. Und genau hier hat 22DISK jetzt Probleme wenn ich mit CTOD (herauskopieren) arbeite.
    (Quelltext, 14 Zeilen)

    doppelt sind:
    (Quelltext, 2 Zeilen)

    So sollte es eigentlich aussehen: nur 26 Dateien
    haglebu


    Die sind wahrscheinlich defekt; das hat Larry Kraemer auch bemerkt.

    Zitat von PAW

    Habe auch kurz hineingesehen. Es fehlt jeweils der Anfang und das Ende des Textes.

    Habe jetzt auch noch die FLUXCONV-Dateien visuell mit den Dateien von kkaempf verglichen. Hier ist der Anfang gleich, aber bei kkaepf's Dateien fehlt das Ende!


    Zitat von haglebu

    Die sind wahrscheinlich defekt; das hat Larry Kraemer auch bemerkt.

    Das glaube ich nicht! SAMCONV kann die Daten problemlos lesen. Die Daten sind auch plausibel. z.B. ein Stichwortverzeichnis am Ende der Datei. Das fehlt bei den anderen.


    Hier sind die zwei Text-Dateien mit SAMCONV.xls konvertiert:


    STRU von SAMCONV.zip


    PAW

    Hallo haglebu

    Zitat von Chuck(G)


    The SIS1 definition is a bit unusual in that only half of the extent map is used. 2K blocks, but EXM 0, and DSM <256

    EXM sollte per Definition im 22DISK-Handbuch = 1 sein. Hattest Du auch so in Deiner Anfrage (allerdings mit falschem Interleave). Chuck hat den Interleave auf 1:1 gesetzt, aber den EXM auf 0.



    Zitat von haglebu

    Merkwürdigerweise tauchen im Inhaltverzeichnis 22DISK/CDIR einige Dateinamen doppelt auf. Ich kann nicht sagen, ob dies anfangs auch der Fall war. Und genau hier hat 22DISK jetzt Probleme wenn ich mit CTOD (herauskopieren) arbeite.

    Doppelte Dateinamen sind seltsam! Wüsste gar nicht wie man sowas zusammenbrächte, wenn man wollte. Ist der Fehler reproduzierbar? Chuck hat eigentlich nichts davon berichtet. Könnte es an Deiner Maschine liegen?


    Hast Du eigentlich schon die Dateien vom "CP/M Imagefile Explorer" Zwecks Vergleich hochgeladen?

    Würde mich interessieren, wie dort die Dateien aussehen.


    PAW

    Zitat von fritzeflink

    Soweit ich verstehe dient der SKEW in 22DISk nur bei der Formatierung dazu die Sektorreihenfolge vorzugeben.

    Habe das mal verifiziert.


    Folgendes Experiment mit 22DISK:


    Format ALT5 (Altos 5) mit 256 Bytze Sektoren, da die 128 bei mir nicht funktionieren.

    Dieses Format hat einen SKEW von 2.

    Habe damit eine Diskette formatiert und danach die Datei EXAMPLE.MAC raufkopiert.


    Beim anschließendem Lesen sahen das Verzeichnis und die Datei korrekt aus.


    Habe anschließend noch zwei Formate im 22DISK definiert, einmal ohne SKEW und einmal mit SKEW 3.

    Beim Lesen ergaben sich keine Unterschiede.



    Fazit: Der SKEW ist dem 22DISK bei Lesen (und vermutlich auch beim Schreiben) egal. Man kann also davon ausgehen, dass die physischen Sektoren immer in der richtigen Reihenfolge eingelesen werden. Der SKEW wird also, wie Fritz das schon sagte, nur für das Formatieren benutzt.



    Das Ganze funktioniert so:


    Beim Formatieren wird quasi ein Rahmen auf die Diskette aufgespielt, der vorgibt, wo die einzelnen Sektoren plaziert sind. Beim Lesen und Schreiben werden dann nur mehr die Daten (ausgenommen SYNC, etc.) innerhalb dieses Gerüstes transferriert. Das Gerüst selbst bleibt dabei unverändert!


    Da bei manchen Systemen die physischen Sektoren der Reihe nach geschrieben wurden, also ohne Skew, hat man in CP/M einen logischen Interleave eingeführt. Mit diesem war es dann möglich die Daten so zu plazieren, dass genügend Zeit zur Verarbeitung blieb.


    Da die gemeinsame Verwendung von SKEW und Interleave keinen Sinn macht, findet man bei den Formaten entweder einen SKEW oder einen Interleave.


    Grüße, PAW

    Chuck Guzis ist mit der Bezeichnung "Skew" in 22DISK auch nicht so ganz glücklich:

    Zitat von Skew vs. interleave

    22Disk's use of "SKEW" was a late cop-out for formatting only. I probably should have used the word INTERLEAVE, but that had already been used in the documentation. I ran out of synonyms. In any case, unless you're formatting floppies, the keyword doesn't matter--and in fact, is omitted for most of them. Mea maxima culpa.