TD0 Disketten Images öffnen

    Hallo liebe Leute,

    ich habe da ein paar TD0 Images von CP/M68k Disketten.
    Die möchte öffnen, d.h. schauen welche Files enthalten sind und auch Files entnehmen.

    Leider stelle ich mich gerade etwas an und finde kein passendes Tool dafür :(

    Quelle der Disketten: NDR-NKC, CP/M System, Disketten


    Vielleicht habt ihr einen Tip für ein gutes "Windows Tool"

    mfG. Klaus Loy

    TD0 das klingt nach Teledisk. Kenne ich nur als DOS-Tool.

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

    Du kannst diese Dateien auch mit HxCFloppyEmulator Software (Windows) öffnen und als "raw" Dateien wieder abspeichern.


    Allerdings sind manche der TD0 Dateien von recycleten Disketten gezogen worden, sodass dann Sektorgrößen von 128, 256 und 512 Bytes gemischt vorkommen, die so nicht in einem sauberen Original vorhanden waren.

    Das kommt wohl daher, dass manche der Disketten vormals MS-DOS oder anderweitig formatiert waren und dann auf einem HP System neu formatiert und mit Daten beschrieben wurden.

    Dann kann es vorkommen, dass auf dem von HP unbenutzten Bereich die alten Sektoren "durchscheinen".

    Teledisk macht brav und korrekt eine saubere Kopie von diesem Sammelsurium und wenn man das wieder mit Teledisk auf eine reale Diskette zurückschreibt werden auch die Bogus-Sektoren mit geschrieben.

    Eine HP System stört das nicht, aber in einem daraus erzeugten linearen Image sind diese Bogus-Sektoren dann aber enthalten und müssen manuell entfernt werden.


    Dazu kann man sich mit HxCFloppyEmulator sehr schön ein Bild der Spuren und Sektoren auf den Diskettenseiten anzeigen lassen, wo man schnell sehen und mit der Maus analysieren kann, welche Sektoren und Spuren ggf. zu entfernen sind. Dazu kann man sich dann ein kleinews Progrämmschen schreiben oder bei wenigen einzelnen Disketten einen Hex-Editor nehmen, der Bereiche entfernen kann.


    Das ganze Schlamassel ist also kein Fehler in Teledisk oder HxCFloppyEmulator sondern liegt an ehemals schlecht vorbereiteten Disketten.


    Ich meine, dass die CPM/86K Disketten auch dieses Problem haben (ein unnötiger 128 Byte Sektor pro Spur).


    Martin

    Hatte ich beides schon mal kurz probiert ging aber irgendwie nicht.
    Danke, ich schau es mir nochmal an.


    mfG. Klaus Loy

    ... also ich kann bestätigen, HxCFloppyEmulator kann TD0 Images öffnen und z.B. als *.img wiedeer exportieren.
    Und dann sollte das mit z.B. den cpmtools zu extrahieren sein.
    Hatte mich wohl heute Mittag etwas zu blöd angestellt.
    Anke für eure Hilfe.


    mfG. Klaus Loy

    Wieso nehmt Ihr nicht einen älteren PC mit einem 5.25" Floppylaufwerk und nutzt die Originalsoftware TeleDisk ? Stattdessen werden dubiose Konvertierungen vorgenommen und dann wundert Ihr Euch über die (nicht funktionierenden) Resultate?

    Falls Ihr keinen geeigneten PC habt, andere hier im Forum helfen bestimmt aus... oder warte bis zur CC 2022 in Lingen.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    @Peter z80.eu,
    ja, wenn ich gerade echte Disketten erzeugen möchte wäre das ja auch sinnvoll.
    Aber ich möchte im Moment nur an die Dateien ran kommen.
    Da wäre der Weg über Disketten eigentlich unsinnig.


    mfG. Klaus Loy

    Na ja, erst erzeugt Du die Disketten, dann kannst Du die mit einem anderen Tool (also nicht TeleDisk) wieder einlesen.

    Wenn Du nur die Dateien brauchst, kannst Du eine sektorenweises Disk-Image erzeugen, und das mit cpmtools dann extrahieren.

    Manchmal geht das auch direkt mit cpmtools (also bereits die Diskette auslesen), zumindest unter Linux.


    Mir ging's darum, dass das Konvertieren der TD0 Imagedateien nicht immer das gewünschte Ergebnis bringt, aus vorher von Martin genannten Gründen.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Gefällt mir 1

    Falls es nur um CP/M 68K Dateien geht, gibt es u.A. auch im ehemaligen HUMONGOUS Archive, nun auf archive.org, unter https://archive.org/download/H…Collection/core_archives/ in rlee_peters_cpm_archive.tar unter "D/Digital Research/" ein paar Systeme, aber das BIOS ist natürlich nicht für Dein System.

    Martin

    @ngc224,
    ok, samdisk scheint das TD0 konvertieren zu können.
    cpmtools hab ich gerade nicht zur Hand.
    Danke nochmal für den Tip.

    mfG. Klaus Loy

    Mit dem mame floptool kann man das konvertieren.


    floptool flopconvert td0 pc P961OF3.TD0 P961OF3.IMG


    MAME | Latest MAME Release


    das flopdir commando verstehe ich leider nicht.

    Kommt immer Filesystem unknown.


    floptool flopdir td0 auto P961OF3.TD0

    Error: Filesystem 'auto' unknown


    Source ist verfügbar:

    mame/floptool.cpp at master · mamedev/mame
    MAME. Contribute to mamedev/mame development by creating an account on GitHub.
    github.com


    ...aber :nixwiss:

    Zitat von klaly

    ok, samdisk scheint das TD0 konvertieren zu können.

    Hallo klaly,


    SAMdisk konvertiert die TD0 auf DSK-Dateien. Das funktioniert grundsätzlich!

    Leider ist die Hälfte der Images korrupt und dies lassen sich so nicht (einwandfrei) weiter konvertieren.


    MIt SAMCONV.xls kann man die fehlerfreien Images in Dateien zerlegen (unter Windows mit Microsoft Office). Ich habe dazu die DiskDef im Excelsheet mit der Definition für MC68000 ergänzt.


    MC68000 - Diskformat.xls


    Hier die Inhaltsverzeichnisse der fehlerfreien Images







    Die fehlerhaften Images müsste man eventuell reparieren. Das heisst, die fehlerhaften Sektoren/Tracks ind der DSK-Datei durch andere (fehlerfreie) ersetzen. Dadurch sind allerdings die Daten in diesen Bereichen falsch. Die Dateien die sich auf diesen Sektoren befinden sind somit ebenfalls falsch, aber alle anderen können dann gelesen werden.


    Grüße, PAW

    Hallo Leute,
    Danke für diesen Info Schwall, ich komme gerade nicht mehr hinterher.
    Sehr interessant und nützlich, mal schaun.

    Jetzt kommt schon wieder was dazwischen.

    Eine Zeitmaschine müsste man haben.


    mfG. Klaus Loy

    Hallo Leute,
    da bin ich wieder.

    @PAW,
    ich habe zwei Disketten von TD0 nach img konveriert und kann schön mit dem Hexeditor darin herumstochern.
    Leider habe ich null Ahnung, wie einen diskdefs Block für die cpm-Tools erzeugen könnte.

    Interessant ist dein MC68000 - Diskformat.xls, aus #16
    Wie hast du das erzeugt ?
    Zufuß oder mit Hirn, oder mit einem Tool ?

    Leider finde ich nichts darüber, wie ein CPM68k Directory Eintag aufgebaut ist.
    Jetzt muss ich so einen Eintrag mal mit CP/M-2.2 vergleichen.


    mfG. Klaus Loy

    Danke, aber ich verstehe es nicht.

    Zum einen hatte ich das File: NKC1CPM68K.TD0

    Einmal mit HxCFloppyEmulator.exe von TD0 nach IMG (raw) umgewandelt

    Zum anderen mit dem samdisk

    HxC: NKC1CPM68K.IMG.zip <-------------- enthält plausibles Image

    samdisk: NKC1CPM68K.DSK.zip <------- enhält Image aber zusatz Headeren pro Track


    Ich verwende das Cpmtools GUI
    Öffnen von NKC1CPM68K.DSK mit obigem diskdef liefert Unsinn
    Öffnen von NKC1CPM68K.IMG sieht gut aus

    Frage: Warum ?
    Das eigentliche Image ist doch das *.DSK hier passen die Offsets und alles.
    Beim DSK sind pro Track noch Header Daten mit dabei ?
    Ich verstehe es einfach nicht.


    OK, es passt bei beiden nicht.
    erstes zeigt sowieso Quatsch an.
    beim zweiten passen die Inhalte nicht, sorry.

    Was ich bisher zum Format raus gefunden habe:
    Disk mit 80 Spuren, doppelseitig, 5 Sektoren je Track.

    Track 0 und 1 sind Systemtracks.

    Directory beginnt ab Offset 0x5000
    Blocksize = 2048

    Kein Interleave.


    Code
    diskdef mc68k
  seclen 1024      # OK
  tracks 80        # OK
  sectrk 10        # weiß nicht
  blocksize 2048   # OK
  maxdir 256       # weiß nicht
  boottrk 2        # OK
  os 2.2           # weiß nicht
end


    Jetzt hab ich es mit den "echten" cpmtools auch probiert, ls geht,

    aber cp liefert unsinnigen Dateinhalt.


    D.h. der diskdef Block passt so noch nicht ganz.


    mfG. Klaus Loy

    Nachtrag:
    sorry, ich hatte zum Test ein unsinniges *.IMG File genommen.
    Jetzt hab ich nochmal versucht, die File Inhalte sehen nun OK aus.

    Zumindest die Assembler Files scheinen einen plausiblen Inhalt zu haben.


    Danke für den diskdef Block


    Warum allerdings in den "Images" von samdisk, so "komische" Header vor jedem Track enthalten sind verstehe ich gerade nicht.
    Vermutlich habe ich falsch "exportiert", das muss ich mir nochmal anscauen.


    mfG. Klaus Loy

    Zitat von klaly

    Warum allerdings in den "Images" von samdisk, so "komische" Header vor jedem Track enthalten sind verstehe ich gerade nicht.

    Die Images von SAMdisk haben ein eigenes Format die zusätzlich zu jedem Track noch Struktur-Daten enthalten. Details zu SAMdisk findest du bei Simon Owens.


    Falls du ein MIcrosoft Excel hast kannst du auch mein SAMCONV.xls zum Verarbeiten der DSK-Datei verwenden. Dort trägts du die Diskparameter für MC68000 ein (Zeile aus Parameter-Excel kopieren und in SAMCONV.xls ins Sheet DISKDEF einfügen) und dann kannst du das DSK-Image auf DOS-Dateien umwandeln. SAMCONV erzeugt ein eigenes Verzeichnis mit den gefundenen Dateien.


    Zu SAMCONV findest du alles in unserem Forum: SAMCONV 2.0


    Grüße, PAW

    Zitat von klaly

    Danke für den diskdef Block

    ngc224 war in Posting #10 schneller ... das hatte ganz ich übersehen ...

    Zitat von klaly

    Warum allerdings in den "Images" von samdisk, so "komische" Header vor jedem Track enthalten sind verstehe ich gerade nicht.

    samdisk copy NKC1CPM68K.TD0 NKC1CPM68K.RAW


    Die Datei-Erweiterung ist bei der Konvertierung wichtig. Aus https://simonowen.com/samdisk/cmd_copy/:

    Zitat

    The output file extension determines the disk image type created, as well as the method used to read the disk.

    @PAW und @JenGun, danke.

    Beim Umwandeln hatte ich nur *.IMG gesehen, ok und da sind die Track noch Struktur-Daten mit dabei.
    *.RAW könnte ich noch probieren.

    Aber gestern hab ich dann mit HxC rum gemacht, der konnte es auch.


    @PAW,
    Excel hab ich nur auf der Arbeit, zuhause hab ich nur Libre.



    mfG. Klaus Loy

    Weil ich mit meinem 68000 Computer gerade auch nicht wirklich voran komme brauche ich wie was für Urlaub zum rumspielen. Da hab ich einen schönen CP/M-68k Emulator gefunden cpmsim CP/M-68k Emulator

    Da wollte ich nun in das Filesystem Image mit cmtools was rein und zum Test wieder raus kopieren.
    Aber das scheint nicht zu gehen, irgendwie passt der diskdef Block nicht.
    Evtl gibt es ja hier einen Spezialisten, der mit den cpmtools gut umgehen kann.


    Hier die zugehörigen Files: Files.zip


    mfG. Klaus Loy

    Kann ich bestätigen; lesen ist ok aber schreiben beschädigt das Filesystem !

    Habe ich schon vor längerer Zeit festgestellt und hier

    Beitrag
    RE: CP/M-68k Emulator
    Ich habe nach wie vor das Problem, daß das Schreiben von Dateien mit cpmtools (V2.20) auf
    Drive C (diskc.cpm.fs) das Filesystem beschädigt !
    Lesen von diskc.cpm.fs mit den cpmtools ist ok.
    Ich kopiere deshalb Dateien mit cpmtools auf Drive B,
    starte den Emulator und kopiere die Dateien mit pip.68k von Drive B nach Drive C.
    ngc224

    auch schon mal erwähnt.


    Vor dem Kopieren ist es noch ok

    Code
    # fsck.cpm -f cpm68ksim diskc.cpm.fs
Phase 1: check extent fields
Phase 2: check extent connectivity
diskc.cpm.fs: 334/4095 files (0.0% non-contigous), 1497/8176 blocks
#

    Nach dem Kopieren ist Filesystem beschädigt.

    Code
    # cpmcp  -f cpm68ksim diskc.cpm.fs errno.h 0:
# fsck.cpm -f cpm68ksim diskc.cpm.fs
Phase 1: check extent fields
Error: Bad record count (extent=334, name="ERRNO   .H  ", record count=7)
Remove file [Y]? n
Phase 2: check extent connectivity
#

    Ich kopiere derzeit die Dateien mit cpmtools auf Drive A: (oder B:), starte den Emulator und

    kopiere dann mit pip die Dateien von Drive A (bzw. B) auf c:

    Das funktioniert.

    aber welche Images nimmst du da für Drive A ...
    Da ist einImage DSON00.DSK dabei, würde das passen ?
    Ich hab damit noch nicht rum gemacht.
    Da müsste man dann auch den diskdef Block erstmal finden

    Ich habe diskb.cpm so erstellt.

    ecb800 wird vom simbios.s unterstützt !

    Code
    diskdef ecb800
    seclen 1024
    tracks 160
    sectrk 5
    blocksize 2048
    maxdir 192
    skew 2
    boottrk 2
    os 2.2
end




    Emulator starten:


    2 Mal editiert, zuletzt von ngc224 ()

    ... also, was der ngc224 schreibt, bzw. wie er mit Linux die DiskA.CPM erzeugt, funktioniert bei mir auch.
    Leider sind aber die "Diketten" mit 20KB etwas arg klein. Mal schaun.

    Mir war nicht klar das Linux sowas kann:
    mkfs.cpm -f ecb800 diskb.cpm


    Vermutlich nur, weil ich die cpmtools installiert habe.

    @kkaempf,
    ich werde mir das auch anschauen, danke für Euere Bemühungen.

    mfG. Klaus Loy