Beiträge von PAW

    Diese Diskette musst du dir jetzt mal per Greaseweazle/Kyroflux+HXC-Tool anschauen und mit einer 1.44er Disk vergleichen, wegen der Datendichte. Der Unterschied ist ja 16 statt 18 Sektoren pro Spur. Sind jetzt die 16 Sektoren um die komplette Spur herum, oder gibts hinter Sektor 16 noch Platz für 2 weitere Sektoren, oder sind sogar welche da (von der vorigen Formatierung mit 1.44 MB)) die nur nicht genutzt werden?


    Wenn Du meinen Beitrag RE: IBM PS55 mit 3,5" Floppy mit 1,44/1.2MB ???

    gelesen hättest, wüßtest Du die Antwort!


    Außerdem hat das 1.2MB Format der 5.25" Disketten 15 x 512 Bytes Sektoren und nicht 16 !


    PAW

    Mit meinem IBM/Teac FD05PUB Floppylaufwerk kann ich unter Win7 und Win10 eine gebrauchte 1,44 Diskette problemlos als 1,2MB oder 1,23MB formatieren. Ich brauche sie nicht vorher mit einem Magneten zu löschen.

    Das Problem war ja auch nicht, eine bereits formatierte Diskette mit 1.2 zu formatieren, sondern eine Leere (Gelöschte),

    Erst wenn ich sie wieder mit 1.44 formatierte, dann ging es auch mit 1.2


    PS: PAW vielleicht ist dein Laufwerk nicht geeignet?

    Das kann leicht möglich sein. Wurde ja auch nur für 1.44 und 720 angeboten.

    Du musst CMD in Syswow64 benutzen, dann geht das.

    Es reicht, wenn Du "format.com" aus dem Ordner C:\Windows\SysWOW64\ startest. Dies kann auch von einer "normalen" Eingabeaufforderung aus geschen. Diese verweist aber standardmäßig auf ein anderes "format.com.". Daher funktioniert es nicht.



    Am Westlichen PC brauchst du ja für 1,2mb diesen floppy 3 Mode.


    Geht aber auch unter Window 10 :


    C:\Windows\SysWOW64\cmd.exe

    format A: /f:1.23m


    Damit kann ich via USB Floppy an Win10 Disketten formatieren und bespielen.

    Ich habe folgendes versucht:


    Test mit WIN10 und USB-Floppylaufwerk (BASETech Modell No. GEN-144 distributed by Conrad Elektronic SE). Dieses sollte 1.44MB und 720KB 3.5" Disketten können.


    Habe zuerst die Diskette mit einem Magneten gelöscht.


    Dann Aufruf von C:\Windows\SysWOW64\cmd und format a: /f:1.2



    Das funktioniert offenbar nicht, wie man sieht!


    Hinweis: der Parameter /F:1.2 kann in verschiedenen Schreibweisen angegeben werden: 1.2 oder 1.2M oder 1.2MB oder 1.23M und noch andere. Sieht man, wenn man format.com mit einem Hex/ASCII-Editor ansieht.


    Anschließend mit format a: /f:1.44 läuft. (Standard Format für 3.5" HD)


    Dann noch mal mit format a: /f:1.2 ... läuft soweit, bis auf Fehlermeldung am Ende "Formatierung fehlgeschlagen".



    format a: /f:1.2 lässt sich beleibig oft wiederholen, soferne die Diskette nicht mit einem Magneten gelöscht wird.



    Die so erstellte Diskette ist unter WinXP nicht lesbar:




    Habe die Diskette mit SAMdisk eingelesen und einen Scan durchgeführt:


    Wie man sieht, ist diese auch hier nicht lesbar.


    Jetzt stellte sich natürlich die Frage, ob auf der Diskette etwas steht oder nicht?



    Als nächsten Schritt habe ich die Diskette mit FLUXCOPY eingelesen.

    Beim FLUXDUMP ergab es sich, dass man nicht MFM 3.5" HD auswählen durfte (sonst ebenfalls Schrott), sondern MFM 5.25" HD


    Dump sieht dann so aus:


    Das sieht ja ganz gut aus. Auch der Volumename "TEST12" ist zu sehen.



    Ich habe das Image noch in HxC betrachtet (FLX-Dateien auf raw-Kryo-Dateien konvertiert), welches aber keinerlei Daten gefunden hat.



    Wenn die 3 Mode Laufwerke tatsächlich, wie angenommen, bei 1,2 MB mit 360 RPM laufen, ist ja die Datenrate eine andere.

    Diese Frage lässt sich im Moment nicht beantworten, da kein Flux-Image von einer originalen Diskette vorliegt.


    Zu der von mir unter WIN10 erstellten Diskette kann ich aber sagen, dass die 15 Sektoren (je 512 Byte) über die ganze Spur verteilt sind (wie bei einer 5.25" 1.2MB Disk), also nicht einfach die letzten 3 Sektoren (1.44MB hat 18 Sektoren) weggelassen wurden. Das bedeutet, dass die Fluxwechsel entsprechend dem Verhältnis 360 zu 300rpm länger sind. Ob jetzt das Laufwerk schneller dreht, oder die Datenrate gegenüber einr 1.44MB Disk verlangsamt wurde, kann ich nicht mit Sicherheit sagen, kann mir aber nicht vorstellen, dass das USB-Laufwerk die Umdrehungsgeschwindigkeit ändert. Ich tippe eher auf eine angepasste Datenrate. Müsste man aber näher untersuchen, wozu ich aber keine Zeit habe.



    Grüße, PAW

    Keine Ahnung. Wenn ich es dazu bekomme eine Diskette mit 1,2MB zu formatieren, werde ich mir das mal genauer anschauen...

    Laut Prospekt sollte das Laufwerk ja 1.44MB / 1.2MB und 720KB können: Prospekt




    Hast Du schon versucht 1.44er oder 720er Disketten zu formatieren? Das sollte ja zumindest funktionieren.

    (Eventuell die Disketten vor dem Formatieren mit Magnet löschen, damit das BIOS nicht in die Irre geführt werden kann, falls noch andere Formatierung drauf ist.)


    Läuft das dann bei 1.2MB mit 360 RPM?

    Das ist eine berechtige Frage!



    vossi Solltest Du es schaffen eine 3.5" 1.2MB Diskette zu erstellen, bitte um ein Kryoflux- oder Fluxcopy-Image (raw- oder FLX-Dateien).


    Viel Erfolg!


    PAW

    aber mir ist nicht ganz klar, was das gerade bezweckt. Die Dateien habe ich doch mit 22DISK auch?

    Ja, 22disk und SAMCONV sollten die gleichen Dateien liefern.


    Ich habe mir aber die Dateien (von SAMCONV) angesehen. Bei einigen Dateien scheinen die Inhalte nicht plausibel, z.B. bei Wordstar.

    Vielleicht ist aber auch die Konvertierung mit SAMCONV falsch.


    WS.CPM sieht bei mir so aus. Ist das auch bei Deinen 22Disk Dateien so?

    Code
     Adresse   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F    0123456789ABCDEF
    0000.0000  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0010  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0020  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0030  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0040  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0050  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0060  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
    0000.0070  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6   │................│
     Adresse   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F    0123456789ABCDEF


    Am Anfang sollte doch wohl ein ausführbarer Code stehen, wie z.B. ein Sprungbefehl C3 ...


    Wenn das auch bei 22disk der Fall ist, dann sollte man die Möglichkeit in Betracht ziehen, das da was nicht stimmt.


    Grüße, PAW

    gnupublic Danke für die Images!

    Beide Lesevorgänge gaben Fehler, die noboo hatte aber nur 3.


    Die Bootdiskette hatte mehrere Fehler, deshalb habe ich sie nicht weiter angesehen.

    Die NOBOOT sieht besser aus und hat nur in der Bootspur 0 einen Fehler. Der Rest dürfte OK sein.


    Habe die TD0 mittels SAMdisk_GUI.exe auf DSK umgewandelt und mit SAMdisk gescannt:


    Ich habe dann Deine 22disk-Definition in SAMCONV eingetragen (die vorhandene war ähnlich, hatte aber keinen Sektorversatz). Damit ließ sich die Diskette auslesen. Ob die Dateien stimmen kann ich nicht sagen. Einige Dateien sahen plausibel aus (z.B. PIP.CPM), bei andern bin ich mir nicht sicher (z.B. STAT.CPM). Müsste man mit einem STAT von einem anderen System vergleichen. Die DOK-Dateien sahen nach Wordstar aus. Müsste man auch in einem CP/M-Simulator mit Wordstar lesen, um die Reihenfolge der Sektoren zu überprüfen.


    Hier die mit SAMCONV konvertierten Dateien: ###DOS###.zip


    Die Endungen .COM wurden auf .CPM geändert, wie in 22disk üblich.


    Grüße, PAW

    Der letzte Stand meiner 22Disk Definition für die Taylorix von damals sieht so aus:

    Hast Du ein Image (TD0 oder IMD) zur Verfügung, mit ein paar lesbaren Text-Daten drauf? Könnte ich mir mit SAMCONV ansehen.


    Grüße, PAW

    Möglicherweise ist die Formatierung auf Track 0 beschädigt. Dann lassen sich die Sektoren nicht mehr einzeln schreiben. Es müssen die ganze Spur neu formatiert und die Daten wieder aufgespielt werden (macht imageDisk).


    Boot Sektor = 1 Sektor und zwar der Erste auf der Spur 0 Seite 0

    FAT = 4 Sektoren und zwar die nächsten 4 Sektoren auf Spur 0 Seite 0, wobei jeweils 2 Sektoren für die beiden FAT's belegt sind

    Directory = 7 Sektoren auf Spur 0 Seite 0

    Wie auch schon 1ST1 weiter oben erwähnte, sind auf Track 0 nicht nur der Bootsektor, sondern auch andere Daten vorhanden. Deshalb wird es vermutlich nicht möglich sein, den ganzen Track durch einen von einer anderen Disk zu ersetzen (wie ich weiter oben vorgeschlagen hatte). Daher muss auch der defekte Track 0 mittes Imagedisk (oder ein anderes geeignetes Imageporgramm) gelesen und dann nur die defekten Sektoren im Image geändert werden. Das korrigierte Image auf eine leere/gelöschte Diskette zurückschreiben.


    Grüße, PAW

    Er wird mir diese Disketten entmagnetisieren.

    Wenn Du einen Magneten zur Hand hast, kannst Du das auch selber machen, siehe Diskette mit Magnet löschen


    Wenn Du die Diskette löscht, dann musst Du natürlich vorher die Daten als IMD-Image sichern. Soweit ich gesehen habe, gibt es einen Parameter für ImageDisk, um Tracks zu ignorieren (X-Parameter). Damit sollten sich die benötigten Datentracks von der "defekten" Disk lesen lassen und auf eine andere Diskette übertragen (Boottrack ausblenden). Die Bootspur dann extra von einer "guten" Diskette einlesen und ebenfalls auf die Zieldiskette übertragen (auch mit dem X-Parameter). Dann solltest Du eine komplette funktionsfähige Diskette haben.




    Ich bin in den nächsten Tagen verhindert, melde mich gegen Ende der Woche.


    Grüße, PAW

    Also, für mich steht abschliessend fest, dass im DOS Umfeld kein Programm es schafft, defekte Disketten wie Defekte im Bootsektor,

    zu reparieren.

    Ich glaube nicht, dass es am DOS-Umfeld liegt!



    ich habe mit Image Disk ein Image von der funktionierenden Diskette angefertigt, gespeichert und dann versucht, dieses Image auf eine der defekten Diskette zu schreiben und komme dann zu diesem Ergebnis:


    Hast Du auch auf einer anderen (leeren) Diskette versucht das Image TEST.IMD zu Schreiben? Dort sollte es ja laufen. Falls nicht, dann hat eventuell Dein Laufwerk ein Problem, oder das Image ist nicht brauchbar! (Eventuell beim Erstellen des Images die Option "Full Analyses" verwenden).


    Habe es gerade selbst mit einer 3.5" HD DOS-Diskette versucht. Funktioniert einwandfrei (verwende ImageDisk 1.18, sollte aber keinen Unterschied machen). Die Diskette läßt sich dann auch unter WinXP lesen.


    Wenn der Test mit der leeren Diskette funktioniert hat, dann nochmal mit der "defekten" Disk probieren, aber:


    Die "defekte" Zieldiskette vorher mit einem starken Magneten löschen! Mehrmals im Kreis (spiralförmig) drüberstreichen. Dann erst mit ImageDisk draufspielen. Funktioniert es dann immer nocht nicht mit der "defekten" Disk, dann kann auch die Diskette selbst defekt sein. In dem Fall musst Du eine andere Diskette verwenden.

    Grüße, PAW

    In den letzten beiden Bildern zeige ich den Inhalt der nicht funktionierenden Diskette an.

    Da ich wie bereits geschrieben, vorher die Fehlermeldung "Fehler auf Laufwerk A: Sektor nicht gefunden" bekomme, setzt wohl Disk Editor die Nullen ein.

    Hallo Fred,


    es wäre zielführend, wenn Du ein Image mittels ImageDisk von der defekten Diskette machen könntest und hier hochlädst. Ansonst kann ich Dir nicht weiterhelfen!


    Zusätzlich wäre ein Image von einer funktionierenden Bootsdiskette nötig, damit sich der defkete Track ersetzen lässt.


    Grüße, PAW

    Ich habe bei meinen Versuchen immer mit der gleichen fehlerhaften Diskette gearbeitet und werde einmal auch mit einer

    anderen Diskette arbeiten.


    Am Anfang zeigte der Editor ja lesbare Daten an, ("*** NON-SYSTEM DISK:"). Warum wird dann in ANADISK der Track als leer angegeben? Beim letzten Bild werden Nullen angezeigt. Wurde die Diskette (Track 0) jetzt tatsächlich mit Nullen überschrieben? Wenn Du sie nochmals einliest, zeigt dann der Disk Editor immer noch Nullen an? Wenn ja, nochmal in ANADISK ausprobieren. Müsste dann ja funktionieren, wenn sie vom Disk Editor beschrieben wurde. Wenn noch immer die alten Werte vorhanden sind ("*** NON-SYSTEM DISK:"), möglichst doch mit ImageDisk einscannen.


    Die Diskette ist jedenfalls nicht bootfähig, sonst stünde statt "NFORMAT" der Text "MSDOS..." oder ähnlich!


    Wäre außerdem interessant, wie es mit einer funktionierenden Diskette aussieht. Würde aber den Schreibschutz aktivieren, damit nicht etwas ungewollt überschrieben wird. Wie sieht es dort mit ANADISK, Disk Editor, etc. aus?


    Frage: Um welche Art von Diskette handelt es sich eigentlich? Ich nehme an um eine 3.5" HD Diskette?


    Grüße, PAW

    Unter DOS Umgebung verstehe ich einen separaten Rechner, wo nur MSDOS Anwendungen installiert sind und MS DOS 6.0 läuft.

    Ich habe unter MSDOS diese Programme gefunden und ausprobiert:

    Nachdem nun geklärt ist, dass Du über einen DOS-Rechner verfügst, könntest Du ja bei Gelegenheit das Program ImageDisk runterladen. Findest Du z.B. hier: ImageDisk 1.18 oder 1.19


    Damit kannst Du ein IMD-Image (wie in RE: Bootsektor von einer Diskette lesen und schreiben beschrieben) ziehen, welches dann weiter analysiert werden kann, bzw. auf eine andere Diskette übertragen.


    Ein Image hat auch noch den Vorteil der Datensicherung, falls die Diskette zerstört werden sollte.


    Grüße, PAW

    Mit ANADISK in einer DOS-Umgebung bekomme ich auch die fehlerhaften Sektoren angezeigt.

    Aber hier geht es um den Bootsektor mit der Fehlermeldung "BAD SECTOR 0". Auf DOS Ebene bekomme ich in diesem Fall keinen Zugriff auf die fehlerhafte Diskette , weil mMn DOS eine Prüfung mit dem Interrupt 13 durchführt und mir die Diskette um die Ohren haut.

    Hallo Fred,


    was wird von ANADISK genau angezeigt? Müsste doch ANADISK egal sein, ob Bootsektor oder nicht.


    Hast Du ImageDisk zur Verfügung, wenn ja, dann mach doch bitte mal ein IMD-Image von der Disk und stell es hier rein (oder per PN). Dann kann ich mir das gerne mal ansehen. Eventuell auch zusätzlich von einer funktionierenden Disk ein IMD erstellen. Dann könnte man die Daten für die Bootspur im IMD austauschen und das korrigierte Image mittels ImageDisk wieder auf Diskette bringen.


    Grüße, PAW

    Ich werde im nächsten Schritt mit einem anderen Rechner und eingebautem Floppy Laufwerk weiter machen.

    Falls Du auf diesem Rechner ein Windows (> Win 2000) hast, könntest Du es ja nochmal mit SAMdisk versuchen. SAMdisk zeigt Dir beim Einlesen (Scanfunktion) welche Sektoren defekt sind.


    Falls Du lieber etwas auf Fluxebene machen möchtest, kannst Du Dir FLUXCOPY ansehen. Damit kannst Du unter Windows über eine USB-Schnittstelle die FLUXTEEN-Hardware ansprechen. Daran hängt dann eine (max. 4) Floppy über Shugart Schnittstelle (ähnlich wie im PC). Für FLUXTEEN musst Du allerdings selber Bauteile beschaffen und zusammenbauen. Leere Platine gibt's eventuell noch bei gpospi. Die Leistungsfähigkeit ist ähnlich Kryo und Co. Damit kann man dann praktisch alle 3.5", 5.25" und 8" Disketten einlesen und viele davon auch kopieren (auch soft sektorierte Disketten). Außerdem lassen sich die FLX-Dateien von FLUXCOPY auf raw-Dateien von Kryoflux umwandeln und somit mit HxC weiter verarbeiten.

    Hast Du für das Programm eine Beschreibung hinterlegt, oder die Quelle?

    Habe Dir ja oben den betreffenden Ausschnitt aus dem Sourcecode reinkopiert.


    Ich könnte mir vorstellen, dass es in dem RAM (Bit 6) in der betreffenden Bank ein Probmlem gibt. Deshalb habe ich ja auch den "Adresstest" gemacht. Bei "primitiven" Test wird halt nur in eine Zelle geschrieben und danach gleich gelesen und verglichen. Gibt es Adressierungsproblem innerhalb des RAMs bei den Zellen, dann kann es vorkommen, das beim Schreiben auf einer bestimmten Adresse, (auch) eine andere Zelle überschrieben wird.


    Daher meine Empfehlung: auch Bit 6 in der entsprechenden Bank tauschen.


    Oder es gibt ein Problem mit dem Refresh.

    Eher unwahrscheinlich, weil nur das eine Bit betroffen ist und andererseits durch das sequentielle Schreiben und Lesen des RAMs eigentlich refreshed wird (unabhängig vom "normalen" Refresh).

    Skew, wie oben erklaert. Also die Umrechnung des logischen zum physikalischen Sektor durch SECTRANS.

    Habe mir jetzt nochmals ein Image von Vector Graphics CP/M-Diskette angesehen. Ist hard sektoriert, somit kein physischer Sektorversatz.


    Hat zwei Bootspuren, wo ich aber Aufgrund der Daten einen Sektorversatz nicht überprüfen kann. Das CP/M-Verzeichnis liegt am Track 2 (also 3. Spur). Beginnt bei Sektor 0, Fortsetzung bei Sektor 5, usw. was einen Versatz um 5 Sektoren bedeutet. Das ist aber nichts besonderes, da alle CP/M-Datenspuren (nicht Systemspuren) den gleichen Versatz und somit die gleiche SECTRAN haben. handelt sich also nicht um den von mir gemeinten logischen, trackabhängigen Sektorversatz.


    Zitat
    Zitat von PAW
    Zitat
    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.

    Ich kenne kein CP/M-Format, wo sich der logische Sektorversatz innerhalb der CP/M-Daten (also ab dem Verzeichnis) ändert. Somit wird auch nur eine SECTRAN gebraucht. Dies gilt ja wohl auch für Vector Graphics CP/M-Disketten.



    Nee, ich habe auch noch kein Formatierprogramm unter CP/M gesehen, welches einen Interleave generiert, also eine nichtlineare physikalische Sektorreihenfolge erzeugt.

    Unter DOS mit 22DISK lassen sich CP/M-Disketten mit einer nichtlinearen physikalische Sektorreihenfolge erzeugen. Dazu gibt es in 22DISK den Parameter SKEW ...

    Zitat von 22DISK Handbuch

    SKEW specifies the physical interleaving of sectors.


    ...

    SIDE1, ... CP/M 2.2 allows a software interleave of sectors on a diskette; the terms given here reflect that interleave.


    Gruß, PAW

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

    Hatte ich zuerst missverstanden. Ich dachte es gäbe 5 verschiedene Skew bei den Daten.

    Und was meinst Du jetzt mit Skew? Den physischen oder den logischen Sektorversatz? Da Du die Systemspuren anführst gehe ich davon aus, dass es sich um den Physischen handelt.


    Bei UCSD werden, wie bei manchen CP/M-Formaten, die Sektoren logisch versetzt (bei CP/M mit SECTRAN). Beim UCSD gibt es keine SECTRAN, sondern Allgorithmen die Anhand der Tracknummer einen bestimmten Sektorversatz berechnen. Dies ist offenbar von Hersteller zu Hersteller verschieden.



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

    Die Funktionsweise ist ja bekannt, es ging nur um die unterschiedliche Bezeichnung für einen physischen und einen logischen Sektorversatz. In dem Buch wird noch ein weiterer Begriff ins Spiel gebracht ... Interlace


    Grüße, PAW

    Wenn ich das richtige sehe, sind das Adressierungsfehler?

    Es sind immer die selben Fehler.

    Aber, wie, was?

    Hallo Enrico,


    das Bit 2 dürfte ja jetzt funktionieren, :thumbup:


    Beim AdrTEST geht es darum, die Adresse, die in HL steht in das RAM zu schreiben und wieder auszulesen. Bei hex 4000 sollte also 00 und in 4001 sollte 40 stehen. (low byte first). Statt 00 wird aber 40 eingelesen. Vermutlich hat da das Bit 6 ein Problem, da es dauernd auf 1 steht. (Bit 7 = highbit, Bit 0 = lowbit). Warum das aber bei den vorigen Tests nicht zum Tragen kommt?


    Unterschied zwischen den Tests ist, das vorher jeweils in eine Zelle geschrieben und dann sofort gelesen wurde. Beim AdrTEST wird das ganze RAM beschrieben und danach erst ausgelesen. Könnte sein, dass durch einen Scghreibvorgang weiter hinten, der Wert vorne verändert wird.


    Also eventuell auch Bit 6 tauschen.


    Grüße, PAW


    Code
        ;logical address space
    ROMBEG    EQU    0    ;begin of ROM
    ROMLEN    EQU    00800H    ;length of ROM
    RAMBEG    EQU    01000H    ;begin of RAM-area    <--- must set also to 1000H by L80 !
    RAMEND    EQU    01FFFH    ;end of RAM-area
    RAMWORK EQU    08000H    ;begin of RAM-area for moving code
    
    RAMCOPY EQU    0F800H    ;begin of program in RAM (copy of ROM)

    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.


    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

    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

    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

    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

    Daher mein Gedanke, die Diskette unter einem Windows welches nicht im Hintergrund DOS (ab Windows NT gibt kein DOS, sondern ich vermute ein OS/2 oder was auch immer) verwendet, die Kopie des Bootsectors einer funktionierenden Diskette auf die defekte Diskette zu schreiben. Unter Windows 7 hat es nicht geklappt.

    Hallo Fred,


    wenn Du unter Windows (ich glaube ab Win2000 geht das) Disketten oder einzelne Tracks kopieren möchtest, dann schau Dir SAMdisk von Simon Owen an (Gratissoftware im Netz, siehe SAMdisk). Man muss dazu nur einen Treiber installieren und kann dann mit SAMdisk auf die Diskette zugreifen. Ich verwende dazu WinXP. SAMdisk erstellt ein Image, von dem man dann auf andere Disketten zurückschreiben kann (z.B. den Boottrack).


    Gruß, PAW

    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!



    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.


    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.


    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.



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


    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

    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:

    Hier ist bei SKEW offenbar der logische SKEW gemeint.

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


    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

    Aber ist das nur für hard-sektorierte Disketten?

    Schon lange nicht mehr. FLUXCOPY kann inzwischen auch softsektorierte Disketten lesen und die meisten auch schreiben.

    Natürlich brauchst Du dazu die FLUXTEEN-Platine. (Bei Interesse gpospi fragen). Übrigens FLUXCOPY kann die raw-Dateien von Kryoflux in FLX-Dateien (von FLUXCOPY) konvertieren und umgekehrt.



    Mit dem Kyroflux konnte ich auch schon testweise Disks auslesen, beim Greazeweazle habe ich bisher nur geschafft, die RPM des Laufwerks zu lesen, wenn ich Disks auslesen will, bekomme ich aber einen Fehler wegen Quellformat, allerdings hab ich natürlich auch gleich den schlimmsten Fall genommen, nämlich weder Kyroflux noch Greazeweazle haben fertige Definitionen für das Diskettenformat (Olivetti ETS 2010).

    Wenn Du ein Image von der Olivetti-Disk gemacht hast (ein raw-File pro Track) dann stell es doch mal hier rein. Dann kann ich es mir ansehen.


    Ansonsten kannst Du die Images, wie schon kkaempf sagte, mit HxC weiter ansehen. HxC kann die raw-Files einlesen und in verschiedenen Formaten darstellen. HxC läuft bei mir unter Windows und braucht nicht installiert zu werden. Du kopierst einfach die drei Dateien (HxCFloppyEmulator.exe, libhxcfe.dll und libusbhxcfe.dll) in ein Verzeichnis und startest die EXE). Die raw hast Du in einem Unterverzeichnis. Dann auf LOAD klicken und die erste der raw-Dateien auswählen. HxC liest dann alle ein. Dann auf Track-Analyzer klicken und diverse Dartstellungen aufrufen.


    Wurden die Daten von HxC erkannt, dann kann man diese auch in anderen Formaten exportieren.


    Gruß PAW