Beiträge von HobbyProgrammer

Guten Morgen,

die Arbeit am Cife geht im Hintergrund, wenn auch langsam, weiter. Dabei habe ich einen kleinen konzeptionellen Fehler meinerseits entdeckt.

Und zwar geht es um die Funktion, das die CP/M-Tools auch sogenannte Amstrad Disk-Images lesen können. Dabei werden die Driveparameter aus den ersten 512Byte (Sektor 0 und Track 0) gelesen.

Leider habe ich keinerlei solcher Images. Habt Ihr mir eine Adresse von wo ich solche Images herunterladen kann, oder kann mir jemand solch ein Image zur Verfügung stellen. Ich würde diese Funktion gerne überprüfen.

Vielen Dank,

HobbyProgrammer

Ja ich weis, unter Windows schaut die Sache nicht wirklich gut aus.

In der nächsten Version will ich versuchen den ganzen File-Dialog neu zu schreiben.

Bis wann diese allerdings fertig wird kann ich zum jetzigen Zeitpunkt leider nicht sagen.

Zitat von guidol

Zitat von HobbyProgrammer

Ausserdem wurde die Auswahl des Imagetyps in den Open-Dialog (für Image Open) bzw. in den Save-Dialog (für Create new emtpy Image) verschoben.

HobbyProgrammer

Kann man dies evtl. so anpassen, dass das "Oeffnen" des Image ausgegraut ist, solange man keinen Image-Type ausgewaehlt hat?

Nicht so wirklich. Die Dialoge sind eigentlich Standard Dialoge denen die Combobox zur Auswahl des Imagetyps über einen Hook untergeschoben wird. Von daher reagiert die Combobox leider mehr oder weniger Eigenständig.

Ich plane aber die GUI ein wenig zu ändern und werde dann evtl. auch diese Dialoge neu schreiben.

Hallo,

ich habe die Version 0.0.9 des CP/M Image-File Explorers fertig.

In dieser Version können nun auch einzelne oder mehrere Dateien mittels Cut/Copy aus einem image herauskopiert oder ausgeschnitten werden. Das ist zwar noch nicht ganz das was ich wollte, aber zumindest kommt man nun an die Dateien in einem Image heran.

Ausserdem wurde die Auswahl des Imagetyps in den Open-Dialog (für Image Open) bzw. in den Save-Dialog (für Create new emtpy Image) verschoben.

Die History zweigt nun neben dem Imagefile-Namen auch den Imagetyp an mit welchem das Image geöffnet wird.

Auch gibt es einen weiteren Menüeintrag Options->General Settings. Dort kann z.B. eingestellt werden ob das zuletzt geöffnete Image beim nächsten Start wieder geladen werden soll.

Der CP/M-Tools Kern wurde auf die Version 2.23 von Michael Haardt aktualisiert.

PeterSieg

Ich habe Dir hier eine bearbeitete diskdefs angehängt. Damit kannst Du die einzelnen Laufwerke in dem Multicomp-Image ansprechen. Du kannst die 4 Laufwerke nacheinander öffnen und hast diese dann in der History zum Umschalten.

Zu finden ist der CP/M Image-File Explorer 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

diskdefs.zip

PeterSieg

Guten Morgen Peter,

ich habe mir das Image nun mal im Hex-Editor angesehen, und da startet das Verzeichnis gleich beim ersten Byte. Somit muß boottrack auf 0 sein.

Bist Du sicher das Du nicht ausversehen die falsche diskdefs oder das falsche Image erwischt hast?

Ich habe auch versucht das Multicomp Image von der Webseite die, Du genannt hast, herunterzuladen, bin aber leider an dem Google-Drive Account gescheitert.

Kannst Du das mal zur verfügung stellen? Dann kann ich den CIFE in einer der nächsten Versionen evtl. auf solch ein Multicomp Image anpassen.

Michael Haardt hat geschrieben:

Zitat

Die diskdefs stimmen nicht. Das Verzeichnis fängt direkt ab Byte 0 an,
d.h. boottrk von hd0 muss 0 sein.



Die Angabe von boottrk sieht nach Partitionen aus. Ich empfehle da eher
"offset" zu benutzen, damit man nicht verwirrt wird:

diskdef hd0
seclen 512
tracks 512
sectrk 32
blocksize 4096
maxdir 512
skew 1
boottrk 0 <-- geändert
os 2.2
offset 0 <-- zur Klarheit
end

diskdef hd1
seclen 512
tracks 1024 <-- nicht mehr 512?
sectrk 32
blocksize 4096
maxdir 512
skew 1
boottrk 0
os 2.2
offset 8388608 <-- fängt hinter hd0 an
end

Bei glatten Grenzen geht auch "offset 8M". In den diskdefs wird jedebPartition größer als der Vorgänger. Ist das so gewollt? CP/M 2.2 kann nur 8 MB. Nur P2DOS kann wie CP/M 3 32 MB.

Michael

Alles anzeigen

PeterSieg

Michael Haardt hat sich bei mir gemeldet. Er vermutet einen Bug in den neueren Versionen und wird dieses Prüfen. Ich habe Ihm dazu, Dein Einverständnis vorausgesetzt, Peter, die diskdefs und die Imagedatei zugesand.

Wenn es dann wirklich ein Bugfix geben sollte werde ich dieses natürlich in CIFE einpflegen.

PeterSieg

Kannst Du evtl. mal versuchen die Version der von Dir verwendeten CP/M-Tools herauszubekommen?

Ich habe zwischenzeitlich Michael Haardt angeschrieben. Evtl. hat er noch ältere Quelltexte der CP/M-Tools. Falls ja, hätte ich dann eine Idee wie wir für solch alte Image Files eine Lösung schaffen können.

Vielen Dank.

Die Version 0.0.9 ist gerade in Arbeit. Diese wird keine neuen Funktionen enthalten. Sondern eher kleine Fehler beheben, das neu Erstellen von Images sowie das Laden von Images etwas anpassen. Auch habe ich vor den CP/M Filesystem Kern auf die Version 2.23 von Michael Haardt zu aktualisieren.

Denke so Mitte bis Ende Januar werde ich diese dann Online stellen.

Ok, dann scheinen Deine CP/M-Tools evtl. wirklich älteren Datums zu sein.

Was für ein System hast Du? Linux oder Windows? Evtl. könnte Deine Vermutung mit einer älteren CP/M-Tools Version passen. Ich hab noch eine 2.20 . Da kann ich es auch mal damit versuchen.

Hallo Peter,

hier treffen 2 Ursachen aufeinander. Zum einen, ein Bug im CIFE, der den beim Programmstart und keinem zu ladenden Image den in dem Auswahlfeld angezeigten Imagetyp nicht richtig aktiviert. Abhilfe ist duch auswählen eines anderen Imagetyps und dann nochmaliges auswählen des entsprechenden Imagetyps möglich. Die Behebung des Fehlers habe ich mir schon ganz oben auf die TODO-Liste gesetzt.

Außerdem scheint die diskdefs nicht zu dem Image zu passen. Selbst mit den neu kopilierten CP/M-Tools 2.23 von Michael Haardt wird kein vernünftiges Inhaltsverzeichnis angezeigt.

Hm komisch. Ich hab hier auch 8MB Images, ohne Fehler.

Ich auch habe gesehen, das Michael Haardt mittlerweile die Version 2.23 der CP/M-Tools herausgebracht hat. Beim kurz drüberschauen scheint es Änderungen im Modul CP/M-Filesystem zu geben. Evtl. hat das etwas damit zu tun.

Ich werd mir Dein Image bei mir mal anschauen.

Zitat von PeterSieg

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.

Solche Formate unterstützt CIFE bis jetzt nicht. Ich habe eine ähnlich aufgeteilte CF-Karte in meinem Z180-System. Ich habe eben jeweils einzelne Images erstellt und diese dann z.b. mit 'copy /b /v CF_Part1.hdd + CF_Part2.hdd + CF_Part3.hdd + CF_Part4.hdd + CF_Part5.hdd + CF_Part6.hdd CF128MB.hdd' zusammenkopiert.

Zitat von JenGun

Unter Linux muss das komplette Verzeichnis .cife gelöscht werden,

Ich habe das nochmals nachvollzogen. Du hast Recht. Um ganz Sicher zu gehen sollte für die Version 0.0.8 die Vorherige Konfiguration entfernt werden.

Unter Linux der Ordner '.CIFE' mit Inhalt im Pfad '/home/<username>' und unter Windows der Ordner 'CIFE' im Pfad ''C:\Users<username>\AppData\Local'.

Hm, Ok. Was hast Du für ein Linux?

Ich werd die Tage nochmal die 0.0.7 mit der "alten" Config Starten und dann die 0.0.8 einfach drüber laufen lassen.

Freut mich das CIFE nun auch bei Dir richtig läuft.

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.

Zitat von Dietrich

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

Danke für die Info. Das werde ich mir morgen genauer anschauen.

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.

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

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?

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

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,

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

#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

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

Ah Ok. Verstehe was Du meinst. Ich habs mir in die TODO Liste geschrieben und sollte dann in der nächsten Version mit drin sein.

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.

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

Zitat von JenGun

wx-config --cxxflags

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

Zitat von JenGun

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

/usr/include/wx-3.0 sind die wxWidgets die sich über die Paketverwaltung von Linux installieren lassen. Sind derzeit aber (soweit mir bekannt ist) bei allen Distros noch die Old Stable Version 3.0.

/usr/local/include/wx-3.2 sind die aktuellen Stable wxWidgets 3.2.

Diese habe ich mit einem Script kompiliert und installiert weil ich damit dann auch statisch gelinkte Programme erstellen kann.

Das generelle Einbinder der jeweiligen 'wx.h' Header-Datei dient im prinzip der Bequemlichkeit, da darüber schon sehr viel Zeugs includiert wird und man nicht für jede wxWidgets Komponente die man verwendet die zugehörende Header-Datei angeben muss.

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

Ich mir werde das genauer ansehen.

Nee, aber habe ich mir vorgenommen. Ich habe so langsam eine Vorstellung was da anders läuft. Ich denke es liegt an der 'wx.h' Include-Datei.

JenGun

Verrate mir bitte einmal was für eine Linux Konfiguration Du genau hast.

Ich habe mir die Mühe gemacht und ein Debian 11 (11.5.0) 64bit in einer VirtualBox VM aufgesetzt. Und dort dann die komplette Umgebung wie ich diese auch in meiner KUbuntu VM verwende installiert (also sämtliche Tools wie z.B. Clang, Git, Valgrind, libcurl, libwxgtk, Eclipse 2022-6 CDT usw.) und dann die aktuellen wxWidgets 3.2.1 komplett neu kompiliert.

Mein CIFE kompiliert auch dort ohne Änderungen am Source-Code einwandfrei durch. Sowohl in der wx3.0 Shared Version als auch in der wx3.2.1 Static Version.

Edit:

Was ich mir vorstellen kann ist, in meiner Programmierumgebung (Eclipse CDT) werden folgende 2 Header-Dateien standardmäßig immer mitgelesen, diese brauche ich daher im Quellcode nichtmehr extra mit includieren.

für wxWidgets 3.0

- /usr/include/wx-3.0/wx/wx.h

- /usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0/wx/setup.h

für wxWidgets 3.2

- /usr/local/include/wx-3.2/wx/wx.h

- /usr/local/lib/wx/include/gtk3-unicode-static-3.2/wx/setup.h

Vielleicht haben die etwas damit zu tun.