CP/M Image File Explorer

  • Hallo zusammen,


    hier soll es nun ausschließlich um den CP/M Image File Explorer gehen. In der nächsten Zeit werde ich hier auch den Link zu der dazugehörenden Github Seite einstellen.


    Kurz vorweg, entwickelt wird der CP/M Image File Explorer (CIFE) in C/C++ mit der CodeLite IDE und den wxWidgets als GUI Framework.


    Grüße Hobbyprogrammer

  • Auf der Github Seite ist natürlich das ganze Projekt mitsamt Source Code und Projekt Dateien.

    Super Sache, habe aber eine bitte als nicht Software-Experte: Im Github-Archiv vielleicht eine 32-bit Version bei den Binaries mit hinzufügen (ich nutze seit Jahren eine Linux 32-bit Installation mit einigen recht alten Paketen, die es nicht mehr gibt) oder eine kurze Compilieranleitung im Readme. Ich stecke jedes mal fest, wenn bei C++ das übliche simple 'make <Makefile>' nicht ausreicht.

  • Auf der Github Seite ist natürlich das ganze Projekt mitsamt Source Code und Projekt Dateien.

    Super Sache, habe aber eine bitte als nicht Software-Experte: Im Github-Archiv vielleicht eine 32-bit Version bei den Binaries mit hinzufügen (ich nutze seit Jahren eine Linux 32-bit Installation mit einigen recht alten Paketen, die es nicht mehr gibt) oder eine kurze Compilieranleitung im Readme. Ich stecke jedes mal fest, wenn bei C++ das übliche simple 'make <Makefile>' nicht ausreicht.

    Eine 32bit Version wird es auf absehbare Zeit leider nicht geben. Ich halte hier schon eine Win10-64bit und eine Linux-64bit Programmier VM am Laufen. Die 32bit Frage kam auch schon in Bezug auf Windows. Für mich als Hobbyprogrammierer ist es schon relativ zeitaufwändig die beiden bestehenden VMs zu pflegen.



    Das Ganze basiert auf cpmtools ? Kann man dann die gleichen Disk-Definitionen und Kürzel benutzen ?

    Sorry, das hatte ich wohl vergessen. Werd ich auch bei Gelegenheit in der Read.me noch schreiben.

    Der CP/M Image File Explorer verarbeitet die gleichen diskdefs Dateien wie die CP/M Tools in der Consolen Version.

    Die diskdefs Datei muß im selben Ordner wie die CIFE Programmdatei liegen.


    Grüße HobbyProgrammer

  • Ich stecke jedes mal fest, wenn bei C++ das übliche simple 'make <Makefile>' nicht ausreicht.

    Geht eben nichts über ein "schönes" (Quick'n'Dirty) Makefile ... :)

    Makefile.zip (wegen Tabs ...)


    wx-config --version ist hier mit 3.0.4 auch "zu alt" (Debian 9, 32 Bit), deshalb mal ein:


    sed -i 's/utf8_string/utf8_str/' MainWindow.cpp


    ... compiliert und läuft ... ;)

    Einmal editiert, zuletzt von JenGun ()

  • Ich denke es sollte sich auch ohne die Änderungen mit 'sed' kompilieren lassen.


    Ich werde mal sehen das ich in die Read.me eine Anleitung schreibe wie der CP/M Image File Explorer auch ihne CodeLite kompiliert werden kann. Da das ganze mit CMake als Buildsystem aufgebaut ist, sollte es damit auch nur in der Konsole zu kompilieren sein. Ob ich allerdings diese Woche noch dazu kommen werde, weis ich noch nicht.


    Grüße HobbyProgrammer

  • Ok, hab grad mal schnell mit dem Handy in mein Github geschaut. Die 'utf8_string()' sollten eigentlich nichtmehr nötig sein, da die Methoden die damit versorgt werden ihrerseits einen wxString Parameter haben. Ich habs mir notiert.


    Grüße HobbyProgrammee

  • Geht eben nichts über ein "schönes" (Quick'n'Dirty) Makefile ...

    danke für's makefile. Compiliert bei mir auch anstandslos. Ich mußte allerdings noch die Diskdef's von cpmtools ins build-Verzeichnis kopieren, damit cife sich nicht wegen deren fehlen beschwert.

    Einmal editiert, zuletzt von kmg ()

  • Da das ganze mit CMake als Buildsystem aufgebaut ist, sollte es damit auch nur in der Konsole zu kompilieren sein.

    Die von CodeLite erzeugte CMakeLists.txt-Datei ist wohl nur für das jeweils ausgewählte "Release" in der IDE ... mit codelite-make kann aber automatisch ein Makefile für jede "Konfiguration" des Projekts erstellt werden ...

    Die 'utf8_string()' sollten eigentlich nichtmehr nötig sein, da die Methoden die damit versorgt werden ihrerseits einen wxString Parameter haben.

    Das ist natürlich noch besser. :)

  • Hi,

    entschuldigt die ketzerische Frage, aber sollte man nicht auf Grund der Unzulänglichkeiten der cpmtools gleich anfangs auch die libdsk einbeziehen?

    Bei doppelseitigen Disks auf Images angewiesen zu sein welche die logische (anstatt der physikalischen) Trackreihenfolge bereithalten sehe ich als problematisch. Ich denke nicht, dass es viele Imager gibt die das anbieten - besonders wenn sie auch Kopierschutz berücksichtigen.

    Oder habe ich da etwas grundlegendes bzgl. DS Disks in cpmtools (ohne libdsk) übersehen?

  • Hi,

    entschuldigt die ketzerische Frage, aber sollte man nicht auf Grund der Unzulänglichkeiten der cpmtools gleich anfangs auch die libdsk einbeziehen?

    Bei doppelseitigen Disks auf Images angewiesen zu sein welche die logische (anstatt der physikalischen) Trackreihenfolge bereithalten sehe ich als problematisch. Ich denke nicht, dass es viele Imager gibt die das anbieten - besonders wenn sie auch Kopierschutz berücksichtigen.

    Oder habe ich da etwas grundlegendes bzgl. DS Disks in cpmtools (ohne libdsk) übersehen?

    Was meinst Du mit Unzulänglichkeiten?


    Die Libdsk unterstützung habe ich bis jetzt mal aussen vor gelassen. Ich will erst die eigentliche Funktionalität fertigstellen. Dann kommt evtl. Libdsk noch dazu.


    Wobei Libdsk ist doch eher um vorhandene physikalische Diskettenlaufwerke mit Sonderformaten ansprechen zu können?

  • naja, ich habe gerade mit Erstaunen festgestellt, dass die üblichen .dsk .td0 oder .imd von doppelseitigen Floppys die so im Netz zu finden sind mit den reinen cpmtools nicht zu bearbeiten sind - zumindest konnte ich mangels entsprechender Doku keine Einstellungen finden um die diversen Spielarten der Verteilung (inkl. Nummerierung) der Spuren (und ggfs Sektoren!) auf Vorder- und Rückseite zu konfigurieren; von Formaten mit invertierten Daten ganz abgesehen.

    Das scheint alles Funktionalität der libdsk Erweiterung zu sein. Das SAMconv von PAW ist da sogar noch etwas flexibler.

    Jedes Image erst in ein "lineares" zu wandeln scheint mir doch etwas zu ... untechnisch.

    Natürlich könnte man die "Disk-I/O" Routinen der cpmtools entsprechend erweitern - aber libdsk hätte (auf Windows zusammen mit fdrawcmd) den Charm auch direkt auf ein echtes LW zugreifen zu können.

  • schufti - IMHO gibt es in libdsk keine Konvertierungsfunktionen der verschiedenen Fremd-Disketten-Image-Formate. Da bist Du auf die Konvertierungsmöglichkeiten der jeweiligen Programme angewiesen, bspw. kannst Du ja aus IMD mit Hilfe des IMDU Befehls leicht wieder ein Raw-Image machen. Genauso gibt es auch Möglichkeiten, um aus Teledisk wieder ein Raw-Image zu machen. Bei DSK bin ich mir nicht sicher. Das ist aber keine Schande, erst ein properitäres Format in ein "lineares" Format zu wandeln - was man nicht selbst machen kann, überlässt man anderen Werkzeugen.

    Wobei Du für TD0 (Teledisk) wohl auch einen brauchbaren Source-Code >hier< bekommen kannst, das Archiv dazu kannst Du leider nicht bei archive.org downloaden, wohl aber >hier<.

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

  • Hi, nach meiner Information sind "raw" Images nicht per se "lineare/logische" Images; im raw-Image ist bloß keine zusätzliche "Verwaltungsinfo" (also Track- und Sektorheader) enthalten, was die Verwendung nicht erleichtert.


    Ich habe bei noch keinem "Imager" Befehle gesehen womit man die Reihenfolge des Einlesens steuern kann, sodass die Spuren/Sektoren in der für die CP/M Implementierung logischen Reihenfolge im Image landen. I.A. landen da die Spuren in der Reihenfolge 0V,0R,1V,1R,2V,2R,...39V,39R im Image. Für viele CP/M Implementationen wäre das vermutlich sogar passend (libdsk "alt", samconv "sides") aber wenn CP/M z.B. die Disk 0V,1V,...,39V,39R,38R,...,0R angesprochen hat ist 0V,0R,1V,1R eben nicht linear (=logische Reihenfolge); z.B.janich&klass (libdsk "outback", samconv "cylinders")


    Oder das Kaypro4 Format, welches zwar auch 0V,0R,1V,1R hat aber die Sektoren auf der Rückseite mit 10...19 nummeriert (libdsk "extsurface", samconv "sides+skewtable").


    Die Zuordnung logischer Track - physikalischer Track ist Hersteller spezifisch, muss bekannt sein und geschieht am besten in den Tools die Filesystem spezifische Zugriffe nachbilden.


    Das Disk-Image ist am besten ein echtes "Image" so wie die Disk physikalisch existiert - so läßt sich einfach eine zur HW kompatible Schnittstelle nachbilden, die dann mit Images ebenso wie mit echter HW umgehen kann. Oder Formate mit invertierten Daten - wo berücksichtigt man das sonst?



    Zugegeben, für reine CP/M Images wären "echte physikalische Images" nicht notwendig, da 99.xxx% kein Kopierschutz drauf ist und "logische" Images würden die Zugriffe wesentlich vereinfachen - man müsste die Hersteller spezifische Trackumsetzung nicht wissen, nur die reinen CP/M DPB Werte. Dann wäre es aber sinnvoll ein spezielles Imageformat (.cpm ???) dafür zu definieren - am besten mit den DPB Werten gleich mit drin, dann wären zukünftig alle Images problemlos und einfachst zu "lesen".


    ABER: spätestens beim Zurückschreiben auf ein Medium ist der Vorteil verpufft! Und das ganze widerspricht dem Gedanken der Image Erstellung: einfach Abbild machen, übermitteln und ebenso einfach wieder aufs Medium.


    Zeigt mir eine Methode ein Kaypro4 (.dsk/.img/.imd siehe Anhang) mit reinen cpmtools (ohne libdsk) zu bearbeiten und ich behaupte fortan das Gegenteil.



    P.S.: sorry, dass das jetzt den Thread zum CIFE jetzt etwas bloated ... könnt das gerne in meinen cpmtool thread verschieben

  • Zitat von Peter z80.eu

    Bei DSK bin ich mir nicht sicher.

    Wenn du das DSK-Format von SAMdisk meinst, dann gibt es die Möglichkeit (mittels SAMdisk) dieses von und nach TD0 oder IMD zu konvertieren.

  • GM,

    ich muss meine Aussage im raw-Image ist bloß keine zusätzliche "Verwaltungsinfo" (also Track- und Sektorheader) enthalten, was die Verwendung nicht erleichtert. korrigieren: das ist der einzige Grund, warum für einige Formate das raw Image funktioniert. Nur dadurch, dass die Verwaltungsinformation wegfällt, geht z.B. Track 0, Rückseite als Track 1 durch - es erscheint somit als "lineares". Dadurch funktioniert dann auch das Kayp4 Format, weil nicht mehr evident ist, dass der erste Sektor auf der Rückseite eigentlich die Nummer 10 trägt.


    Aber wie gesagt: das ist eine glückliche Koinzidenz für Formate mit einheitlicher Sektorierung und V0,R0,V1,R1 Trackabfolge.

    Alle Versuche bei Formaten mit etwas exotischer Trackverteilung auf V/R Seite sind zum Scheitern verurteilt.

    Vermutlich auch bei solchen mit unterschiedlicher Sektorlänge auf den Systemspuren oder wo ein HW-Skew auf der Disk vorhanden war; ebenso welche mit invertierten Daten.

  • Eben weil in einem RAW-Image viele Zusatzinfos fehlen, gibt es ja auch die Disk-Definitions-Dateien ... wenn Du die hast, geht doch alles außer hardsektoriert wieder herzustellen (zumindest machen das alle Tools inkl. 22DISK so).

    "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, aber 22disk weiß eben auch um die Problematik mit der Trackabfolge bescheid.

    fritzeflink mit dieser diskdefs funktionieren eben DS Formate nur mit oben genannten Einschränkungen.


    Wenn jemand ein neues Tool schreibt, so kann man natürlich nicht verlangen, dass er mehr als das für ihn notwendige implementiert. Fehlende Funktionalität kann ja bei Bedarf vom "Fragenden" selbst implementiert werden - Sourcen sind ja am github.


    ABER: wenn man auf Bestehendem aufbaut, sollte man sich auch der Unzulänglichkeiten des verwendeten Unterbaues bewußt sein - nichts anderes wollte ich vermitteln. Denn in der "Planungsphase" ist die Berücksichtigung von libdisk (oder eigene Implementation) eventuell noch einfacher als später.


    Sucht euch (oder macht aus den Beispielen im Anhang) ein Janich&Klass, Öttle&Reichler, Kontron PSI 80, Morrow Design CP/M 2.2E, Sharp MZ-800, Sage IV oder Spectravideo SV-328DS RAW Image und schaut wie weit ihr da mit cpmtools kommt.


    Gruß, schufti

  • In erster Linie ist der CP/M Image File Explorer dazu gedacht die CP/M Tools bequem über ein GUI bedienen zu können. Entstanden ist die Idee durch diesen Thread: Lösung für DSK-Images...


    Die Libdsk unterstützung habe ich aus dem Source-Code der CP/M-Tools erstmal weg gelassen. Zum einen weil ich die Tools selbst bis jetzt ohne Libdsk benutzt habe, und zum anderen weil ich mich mit Libdsk bis jetzt noch nicht auseinandergesetzt habe.


    Libdsk kann ich, wenn das Gerüst an sich funktioniert dann später noch nachrüsten. Allerdings wirds es mit dem Testen dann schwierig da ich keine so Sonderformate habe und auch keinen Zugriff auf ein evtl. physisches Diskettenlaufwerk. Da wäre ich dann auf eure Hilfe angewiesen.

  • wie gesagt, im Post über dir sind zwei Images, hier die notwendigen diskdefs:

    sowie für experimentierfreudige die .libdskrc

    und zur Bestätigung, dass die lesbar sind auch die notwendigen Einträge für PAWs samconv

    J&K ZDOS J&K J&K ZDOS CP/M DSK DSDD 96tpi 10x512 790KB 5.25" MFM LOW INV 80 2 0 10 512   1,3,5,7,9,2,4,6,8,10 1,3,5,7,9,2,4,6,8,10 CYLINDERS 4 15 0 394 127 0C0H 0 2T 800 790 2 4 786  
    O&R O&R Öttle und Reichler CP/M DSK DSDD 96tpi 10x512 790KB 5.25" MFM LOW INV 80 2 0 10 512   1,3,5,7,9,2,4,6,8,10 1,3,5,7,9,2,4,6,8,10 EAGLE 4 15 0 394 127 0C0H 0 2T 800 790 2 4 786  


    gruß,

    schufti


    P.S.: ich mache das nicht um jmd zu quälen oder zu nörgeln sondern um es für andere Suchende die an den cpmtools (und deren nicht existenter Doku) verzweifeln fest zu halten. Als nächstes werde ich versuchen eine aktuelle Version der Windowsvariante der cpmtools mit libdsk (+tools?) zu erstellen.


    P.P.S.: es wäre vermutlich nicht einmal viel Aufwand die Trackabfolgemimik und Invertierung in den cpmtools unterzubringen, man müsste bloß eine "kompatible" Parametrierung in der diskdefs finden.

    Einmal editiert, zuletzt von schufti () aus folgendem Grund: P.S. und P.P.S.

  • Alles gut. Habs nicht in den Falschen Hals gekriegt. 😉


    Aber Deine Beispiele sind für mich sehr wertvoll. Werde mir diese speichern und für weiterführende Tests dann benutzen. Wenn das Projekt sinnvoll ergänzt werden kann habe ich kein Problem damit. 🙂👍

  • Allerdings wirds es mit dem Testen dann schwierig da ich keine so Sonderformate habe und auch keinen Zugriff auf ein evtl. physisches Diskettenlaufwerk.

    Hallo @HobbyProgrammer


    Für erste Tests kannst du dir mit SAMCONV (SAMCONV 2.30) diverse Images erstellen. Ein bestimmtes Diskformat auswählen, oder ein neues eingeben und dann DOS-Dateien auf das Image schreiben. Dann hast du ein DSK-Image im jeweiligen Ziel-Format. Mit SAMdisk (von Simon Owen) kannst du das Image auch auf eine physische Diskette schreiben. Für SAMCONV und SAMdisk brauchst du ein Windows (ab XP) sowie ein Microsoft EXCEL (ab 2003) für SAMCONV. Mit SAMdisk kannst du das DSK-Format auch auf TD0 oder IMD konvertieren.


    Gruß

    PAW