CP/M Image File Explorer

  • Da die Angabe dieser Datei im Entwicklungssystem erfolgt und daher in Deinem Makefile nicht auftaucht kann es schon sein das daher die Fehler kommen.

    wx-config --cxxflags im GNUmakefile liefert die notwendigen #include-Pfade ... und wx/wx.h wird ja in main.cpp eingebunden. Der Patch verändert da nichts ... es fehlen nur ein paar Standard-"Header" für C++, wie z.B. cstdarg und cstring ...

  • Richtig, wx.h steht in der main.cpp, aber auch nur dort. In den anderen Source-Code Files hat das keine Auswirkung.


    wx-config --cxxflags

    liefert die nötigen Include Pfade, aber includiert nicht die wx.h.


    ... es fehlen nur ein paar Standard-"Header" für C++, wie z.B. cstdarg und cstring ...

    Aber genau das könnte sein das diese durch die wx.h mit includiert werden und ich deshalb innerhalb der Entwicklungsumgebung keinen Compilierungsfehler bekomme.


    Wenn ich dann jetzt Änderungen an meinem Projekt mache, dann will ich das so Ändern das die Buildumgebung aus Sicht des Compilers / Makefiles gleich ist, egal ob der CIFE über das Entwicklungssystem oder über die Konsole per Makefile compiliert wird. ;)


    Lass mich das mal genau ansehen.

  • Das stimmt. Die wx.h includiert ne ganze Menge zeugs. Erstaunlicherweise gibt es mit der includierten wx.h auch keine Probleme mit den defines in der cpmdefs.h .


    Ich habe mal angefangen in einer Kopie des CIFE die wx.h komplett raus zu lassen. Vielleicht schaffe ich es nächste Woche das komplett fertig zu machen und kann dann mehr berichten.

  • Dietrich Ich hatte heute kurz Zeit und habe mir den CIFE nochmals angesehen. Bei mir wird der Pfad des aktuell bearbeiteten Image wie gewollt gespeichert und beim nächsten Start wieder hergestellt. Hab das auch unter Windows mit einem User der nur Benutzerrechte hat nochmals getestet.

    Da habe ich mich etwas unklar ausgedrückt. CIFE merkt sich das zuletzt aktive Image. Wenn man aber ein neues Image aufrufen will, wird einem ein ganz anderes Verzeichnis angeboten, in meinem Fall \Onedrive\Dokumente und ich muss mich mühsam in das Verzeichnis meiner Images hangeln. Da ich ein bequemer Mensch bin, wäre es schön, wenn sich CIFE dieses Verzeichnis merken könnte.


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Klasse :)


    Mach weiter so


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Hallo,


    gerade eben habe ich das Github Repository aktualisiert. Die Sourcen von CIFE sind nun so angepasst, der CIFE mittels einfachem makefile unter Linux kompiliert werden kann. Dazu habe ich auch ein passendes GNUmakefile mit in das Repository übernommen.


    Ursprünglich hat JenGun das makefile erstellt. Ich habe dieses noch etwas angepasst. Nun sollte es möglich sein sich den CIFE auf seine jeweilige Linux Version hin zu kompilieren. Eine kleine Anleitung dazu habe ich in der readme.md mit untergebracht.


    JenGun

    Im Prinzip waren nicht allzuviele Änderungen nötig. Aber es machte schon einen kleinen Unterschied in der Compilierungszeit. Die wx.h Header-Datei ist zwar sehr bequem, allerdings wird auch wirklich sehr viel includiert was nicht wirklich gebraucht wird, und da muß sich der Compiler erstmal durchhangeln.

    Interessant war das sich die wxWidgets3.0 an folgender Zeile gestört haben.


    cpmdefs.h

    Code
    #define T1 'E'


    diese wurde in der wxWidgets Header-Datei 'wx/strvararg.h' angemahnt.


    Die wxWidgets3.2 haben sich dann zusätzlich noch an folglender Zeile gestört:


    cpmdefs.h

    Code
    #define P1 ((char)(T6^PB))

    diesmal mit der Header-Datei 'wx/scopeguard.h'.


    Nach umbenennen der #defines läuft das makefile nun mit wxWidgets3.0 als auch mit wxWidgets3.2. :)

  • Die wx.h Header-Datei ist zwar sehr bequem, allerdings wird auch wirklich sehr viel includiert was nicht wirklich gebraucht wird, und da muß sich der Compiler erstmal durchhangeln.

    Die Fehlermeldungen wurden dadurch zwar verhindert, allerdings ist -include in einem Makefile auch eigentlich für das Einbinden von anderen Makefiles gedacht, nicht für "Header"-Dateien: 3.3 Including Other Makefiles ... auf Wx-Config steht auch nicht, dass wx.h immer extra includiert werden muss ... und bis CIFE Version 0.07 war es ja auch nicht notwendig ... ;)


    Wo auch immer die Macros T1 und P1 außerhalb von CIFE definiert wurden: es compiliert jetzt ohne Fehler ... :)


    Verwendet man clang++ als C++-Compiler ist allerdings noch ein kleiner Patch notwendig:

    ... sonst kommt es zu dieser Fehlermeldung:

    Code
    CIFE/Sources/CpmFs.cpp:1001:70: error: cannot pass object of non-trivial type 'std::string' (aka 'basic_string<char>') through variadic method; call will abort at runtime [-Wnon-pod-varargs]
            fserr = msgFormat("Failed to read Amstrad superblock  (%s)", cpmdevice->getErrorMsg());
                                                                         ^
  • =O ooops, da ist mir was durchgegangen. Eigentlich müssten die Parameter für msgFormat alle mit .c_str() übergeben werden. Der GCC scheint da etwas toleranter zu sein.

    Wobei ich sagen muß das ich mich mit clang noch nie wirklich beschäftigt habe.


    Werd den Patch sowie ich Zeit habe ins Repo mit aufnehmen. :)

  • Hallo,


    ich habe soeben die CIFE-Version 0.0.8 bei Github hochgeladen.

    CIFE hat nun eine History, welche die 10 zuletzt geöffneten Images zusammen mit dem Imagetyp speichert.

    Der File -> Open Dialog verwendet nun auch den Ordner der zuletzt geöffneten Imagedatei als Vorgabe.

    So nebenbei habe ich auch den von JenGun gefundenen Fehler mit dem .c_str() Parameter behoben.


    Zu finden ist CIFE wie immer unter:

    GitHub - ProgrammingHobby/CPM_Image-File_Explorer
    Contribute to ProgrammingHobby/CPM_Image-File_Explorer development by creating an account on GitHub.
    github.com


    Grüße

    HobbyProgrammer

  • Danke für die Verbesserungen.

    Leider merkt sich CIFE die Pfade nur bis zum Beenden des Progrmms. Nach einem neuen Aufruf ist alles weg. Lässt sich das ändern?


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Das kann fast nicht sein. Bei mir wird beim Beenden alles sauber gespeichert und beim nächsten Start wieder hergestellt. Hab das auch noch unter WinXP 32bit und Win7 64bit getestet.

    Ebenso unter Linux Mint, Ubuntu, KUbuntu und Debian.


    Was verwendest Du? Windows oder Linux? Welche Version?

  • Servus HobbyProgrammer , ich verfolge diesen Thread schon eine Weile und wollte Dein Utility ausprobieren. Ich finde es eine klasse Idee!


    Gibt es eine Anleitung für Dummies, wie ich die Anwendung unter Windows kompiliere und dann mit den cpmtools zum Laufen bringe?


    Danke und Gruß


    Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

  • Hallo rfka01,

    im Github Projekt liegen fertige Windows Binarys zum herunterladen. Eine 32bit Version welche auf allen Windowsversionen ab WinXP läuft, und eine 64bit Version, welche dann eben ein 64bit Windows braucht (ab Windows 7 64bit). :)

  • Quote

    im Github Projekt liegen fertige Windows Binarys zum herunterladen. Eine 32bit Version welche auf allen Windowsversionen ab WinXP läuft, und eine 64bit Version, welche dann eben ein 64bit Windows braucht (ab Windows 7 64bit).

    Ich find's nicht angst ... in welchem Unterverzeichnis sind sie?

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

  • rfka01 die Binarys sind nicht in einem Unterverzeichnis, den er hat sie ordentlich unter den Releases abgelegt ;)

    Release 0.0.8 · ProgrammingHobby/CPM_Image-File_Explorer
    Handling der CIFE Konfiguration geändert. CIFE verwendet nun eine History, welche die 10 zuletzt geöffneten Images speichert. Bei File -> Open wird nun der…
    github.com

  • Das kann fast nicht sein. Bei mir wird beim Beenden alles sauber gespeichert und beim nächsten Start wieder hergestellt. Hab das auch noch unter WinXP 32bit und Win7 64bit getestet.

    Ebenso unter Linux Mint, Ubuntu, KUbuntu und Debian.


    Was verwendest Du? Windows oder Linux? Welche Version?

    Ich habe Win 10 Home 64 Bit 22H2 Build 19045.2251


    Folgendes habe ich probiert:

    - starten als Admin --> kein Erfolg

    - starten im Kompatibilitätsmodus Win 8 --> kein Erfolg


    Vermutlich mache ich etwas falsch, nur was?

    Wie legt CIFE solche Konfigurationsdaten denn ab?


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Success! Die 32Bit Windowsversion funktioniert. Warum ist mir schleierhaft, aber egal - es geht. Danke


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Dietrich

    Also wenn ich das richtig verstanden habe, macht die 64bit Version bei Dir Probleme?


    Die Windows Binarys werden unter Windows 10 Professional 64bit erstellt.

    Ich versuche morgen noch mal ein paar extra Tests machen.


    CIFE legt eine cife.xml Datei an in welcher die Einstellungen gespeichert werden.

  • Korrekt

    Ich habe die CIFEs gefunden. Sowohl die 32 Bit-Version als auch die 64 Bit legen diese Datei an, jedoch unterschiedlich. In der 64 Bit fehlt die History

    cife32.txt

    cife64.txt

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Dietrich

    Hallo Dietrich,

    leider kann ich das Verhalten des 64bit CIFE bei mir nicht nachvollziehen. Ich habe mir die beiden Windows Binarys vom Github Release heruntergeladen und in einer Windows 7 Professional 64bit sowie in einer Windows 10 Professional 22H2 VM getestet. Jeweils die 32bit und 64bit Version und jeweils einmal als User mit Admin Rechten und nur mit eingeschränkten Benutzer Rechter. Zusätzlich habe ich diese Tests noch auf dem Notebook meiner Frau (Windows 10 Home 64bit 22H2) durchgeführt. Beide CIFE Versionen (also 32bit und 64bit) haben sauber die cife.xml erstellt und die History ausgefüllt. Jeweils mehrmals gestartet und auch Windows zwischendurch neu gestartet. :/

  • Ich habe das alte CIFE.xml gelöscht und CIFE neu gestartet - funktioniert. Offensichtlich hat sich CIFE an dem alten Konfigurationsfile aufgehängt - stammt vermutlich noch von 0.0.6 oder so - und kein neues geschrieben, warum auch immer.


    Geht jetzt prima. Danke für die Unterstützung


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

  • Zur Info.

    Ich habe 0.0.8 gerade unter WinXP mit einem Multicomp 128MB Image probiert. Diskdefs anbei.

    Programm beendet sich nach Auswahl der IMG Datei ohne Fehlermeldung.

    hd0-4 als Formatdefinitionen wurden erkannt.


    Ich gebe zu, das ist wirklich ein sehr spezielles Format!

    Da sind quasi 8MB Diskimages hintereinander gepackt um die 128MB zu füllen.

    (diskdefs definiert nur die ersten 5 davon).


    Multicomp Image (die ersten 128MB reichen - danach ist nur leerer Platz):

    Multicomp FPGA CP/M Disk Image
    Multicomp FPGA CP/M Disk Image
    obsolescence.wixsite.com


    Multicomp selbst:

    Grant's MULTICOMP pick and mix computer


    VG Peter