In der nächsten Zeit werde ich hier auch den Link zu der dazugehörenden Github Seite einstellen.
"Binary Blobs" sind immer "schwierig": eine Portierung auf andere Systeme ist damit kaum möglich ...
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.
Zu finden unter:
Das Ganze basiert auf cpmtools ? Kann man dann die gleichen Disk-Definitionen und Kürzel benutzen ?
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.
Zu finden unter:
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 ... 
INCS ?= $(shell wx-config --cxxflags --unicode=yes)
LIBS ?= $(shell wx-config --libs)
OBJS := CpmGuiInterface.o
OBJS += CpmTools.o
OBJS += MainWindow.o
OBJS += Ui_MainWindow.o
OBJS += Ui_MainWindow_bitmaps.o
OBJS += main.o
PROG := cife
CLEANFILES := $(PROG) $(OBJS)
CXXFLAGS ?= -O3 -Wall -Wextra
CXXFLAGS += $(INCS)
all: $(PROG)
$(PROG): $(OBJS)
$(CXX) $(CXXFLAGS) -o $@ $^ $(LIBS)
clean:
$(RM) $(CLEANFILES)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 ... 
Vielleicht ist sed -i 's/utf8_string/fn_str/' MainWindow.cpp "besser"? Kenne mich mit wxWidgets nicht so aus ...
Ich denke es sollte sich auch ohne die Änderungen mit 'sed' kompilieren lassen.
utf8_string gibt es erst ab wxWidgets Version 3.1.5 (April 2021) und diese wird als “development version” bezeichnet ... wird für eine "alte Linux-Distribution" vermutlich nicht als "Package" verfügbar sein ...
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.
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.
Compiliert bei mir auch anstandslos.
Welche "Linux 32-bit Installation mit einigen recht alten Paketen" ist das jetzt genau?
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?
Welche "Linux 32-bit Installation mit einigen recht alten Paketen" ist das jetzt genau?
Devuan ASCII - müßte Debian 9 (32-bit) sein. Bin z. Zt. im Dänemark-Urlaub, deshalb die späte Reaktion.
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<.
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
Quote from Peter z80.euBei 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).
Ich nutze die cpmtools nur selten und bei besonderen Gelegenheiten.
Hier eine Auflistung von Diskettendefinitionen (ohne Garantie)
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
wie gesagt, im Post über dir sind zwei Images, hier die notwendigen diskdefs:
# jkzdisk
diskdef jkzdisk
seclen 512
tracks 1600
sectrk 10
blocksize 2048
maxdir 128
skew 2
boottrk 2
os 3
# libdsk:format jkzdisk
end
# orcpm3
diskdef orcpm3
seclen 512
tracks 160
sectrk 10
blocksize 2048
maxdir 128
skew 2
boottrk 2
os 3
# libdsk:format orcpm3
endsowie für experimentierfreudige die .libdskrc
[jkzdisk]
description = Janich&Klass 10x512 inv 96tpi DS DD
sides = outback
cylinders = 80
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
complement = Y
multitrack = N
skipdeleted = Y
[orcpm3]
description = Oettle&Reichler 10x512 inv 96tpi DS DD
sides = outout
cylinders = 80
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
complement = Y
multitrack = N
skipdeleted = Yund 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.
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
