Hallo Besucher, der Thread wurde 5,5k mal aufgerufen und enthält 33 Antworten

letzter Beitrag von the_cky am

mkd64 - Weiterentwicklung

    Danke! :) Bin fleißig am weiterbasteln ...

    Zitat von the_cky

    Meine Idee war damals ja auch, die DiskImages als ein Objekt zu behandeln - frist ja wirklich kaum Speicher.

    Ja, also auf dem C64 wird mein Code nicht laufen obwohl die library reines C ist, denn da ist "kaum Speicher" deutlich mehr als vorhanden ist :D Bei mir ist nicht nur ein DiskImage ein Objekt, es ist dazu aufgebaut aus Track- und Sector-Objekten. Dazu kommt ein "CbmdosVfs"-Objekt als "logisches Dateisystem" (bzw "virtual filesystem", beinhaltet eben Dateien, natürlich sind auch die Objekte) und als Bindeglied ein "CbmdosFs"-Objekt als "physikalisches Dateisystem", das dafür zuständig ist, das Vfs auf das Diskimage zu "mappen". Klingt jetzt vielleicht overengineered -- ich hoffe das zahlt sich noch aus!

    Zitat von the_cky

    Btw, Du kannst bei github auch private Repositories einrichten ... nur so aus Backupsicht :)

    Habe ich für die library längst ;) Das GUI ist noch recht neu, das liegt bisher nur auf meinen Rechnern, aber immerhin auf zwei verschiedenen mit jeweils einem git clone. Gerade heute habe ich es endlich geschafft, einen statisch gelinkten Build für Windows zu produzieren -- also auch hier geht es voran :)

    Zitat von zrs1

    Ja, also auf dem C64 wird mein Code nicht laufen obwohl die library reines C ist, denn da ist "kaum Speicher" deutlich mehr als vorhanden ist :D Bei mir ist nicht nur ein DiskImage ein Objekt, es ist dazu aufgebaut aus Track- und Sector-Objekten. Dazu kommt ein "CbmdosVfs"-Objekt als "logisches Dateisystem" (bzw "virtual filesystem", beinhaltet eben Dateien, natürlich sind auch die Objekte) und als Bindeglied ein "CbmdosFs"-Objekt als "physikalisches Dateisystem", das dafür zuständig ist, das Vfs auf das Diskimage zu "mappen". Klingt jetzt vielleicht overengineered -- ich hoffe das zahlt sich noch aus

    Na, das hätte ich auch nicht erwartet, dass es auf dem C64 laufen soll :-)

    Okay, also noch eine "Objektschicht" dazwischen, auch eine Idee. Seinerseits hatte ich den Inhalt als einfachen Vector-Container im Objekt gehalten. Wahrscheinlich würde ich das heute auch noch weiter abstraktieren.


    Verfolgst Du mit dem VFS auch als zusätzliches Ziel *.d64 Images zu mounten (analog dem cbmfs https://llg.cubic.org/tools/cbmfs/)?


    Zitat von zrs1

    Habe ich für die library längst ;) Das GUI ist noch recht neu, das liegt bisher nur auf meinen Rechnern, aber immerhin auf zwei verschiedenen mit jeweils einem git clone. Gerade heute habe ich es endlich geschafft, einen statisch gelinkten Build für Windows zu produzieren -- also auch hier geht es voran :)

    Gut - aus leidiger damaliger Erfahrung habe ich Backups schätzen gelernt. Git nutze ich nicht nur als "Backup" gerne, sondern auch wegen den ganzen Branchmöglichkeiten etc.

    Zitat von the_cky

    Verfolgst Du mit dem VFS auch als zusätzliches Ziel *.d64 Images zu mounten (analog dem cbmfs https://llg.cubic.org/tools/cbmfs/)?

    An sowas hatte ich nicht gedacht. Aber in der Tat, das sollte sich mit der lib theoretisch machen lassen, man muss ja "nur" einen Adapter an das FUSE API programmieren. Auf der anderen Seite finde ich solche sehr "speziellen" Dateisysteme für FUSE meistens eher weniger nützlich -- und es gibt ja auch schon eine Implementierung :)


    Mein Gedanke bei dieser Aufteilung war eigentlich ganz klassisch "separation of concerns" -- das VFS kümmert sich um die Verwaltung der cbmdos Files, das konkrete FS darum, diese auf die Spuren und Sektoren der (virtuellen) Diskette abzubilden. Ich erhoffe mir dadurch mehr Flexibilität -- würde ja gerne irgendwann Unterstützung für Bitfire hinzufügen, das könnte vielleicht mit lose gekoppelten Komponenten einfacher werden. Etwas losere Kopplung habe ich auch dadurch erreicht, dass vieles über Events geschieht -- ein CbmdosFile löst bei jeder Änderung ein Event aus, das CbmdosVfs tut das ebenfalls. Das CbmdosFs subscribed die Events vom Vfs um direkt das Disk Image zu aktualisieren. Dieser Ansatz hat sich für das GUI schon bezahlt gemacht: Das Model, das die Listview mit dem Directory befüllt, hat ebenfalls die Events vom CbmdosVfs abonniert, so dass die Listview immer automatisch aktualisiert wird.

    Interessanter Ansatz mit den den Events und ich kann mir das in Zusammenhang mit QT auch gut vorstellen.


    So wie Du es schreibst, sollte es möglich sein auch das Bitfireformat einzubetten. Ich habe eben mal kurz das Readme von Bitfire durchgelesen und Dein Ansatz sollte dazu relativ gut passen.

    Ohne die Lib zu kennen, sehe ich den größeren Aufwand in dem Fall beim VFS, das CbmdosFs würde wahrscheinlich mit ein paar minmalen Änderungen dafür fit werden. Quasi mittels Flags steuern das statt Track/Sektor dann Datenbytes geschrieben werden, die Track/Sektor Daten müssen dann natürlich für Bitfire anderweitig verarbeitet werden.

    Vom Prinzip sollte sich mit dem Ansatz dann auch ein Konvertierung von "normal d64" nach "bitfire d64" machen lassen (wenn nicht zu viele Files vorhanden sind).

    Ich hatte mir gedacht, Bitfire als separates VFS zu implementieren, so dass das CbmdosVfs davon nichts wissen muss. Das CbmdosFs müsste dann aber das BitfireVfs "kennen", und zunächst die Bitfire-Files beim schreiben auf das D64 berücksichtigen, dann erst die Cbmdos Files. Damit wäre das CbmdosFs genaugenommen "falsch" benannt. Das ist aber ohnehin Zukunftsmusik, erstmal müssen alle jetzigen Features der Library über das GUI verfügbar sein, so dass vernünftig getestet werden kann :)


    Aktuell sieht es so aus (komplett statisch gelinkter Windows-Build, also nur eine .EXE):

    Im hinteren Fenster hab ich ein "kaputtes" Disk Image geöffnet, deshalb die Log-Meldungen von der Library ;)

    Dank der Feiertage geht's mal wieder ein bisschen voran :) Das GUI-Tool kann jetzt ein minimales Featureset um mit Standard CBM DOS Images umzugehen:


    - Neues Image erzeugen (momentan nur 35-Track ohne erweiterte BAM)

    - Bestehendes Image öffnen (35 oder 40 Track, Speeddos und/oder Dolphindos BAM) und bearbeiten

    - Titel, ID (bis 5 Zeichen) und DOS-Version bearbeiten

    - Files hinzufügen, löschen und umsortieren

    - Fileinhalt im-/exportieren

    - Filename bearbeiten

    - Filetyp ändern

    - Fileflags "closed" und "locked" bearbeiten

    - "fake" Filegröße setzen


    Was noch fehlt ist support für REL Files .. die Lib erkennt sie und kann diesen Typ auch setzen, aber dabei passiert wahrscheinlich ziemlicher Mist ;) -- im GUI ist das momentan ausgeblendet, damit man es nicht benutzen kann. Ich habe kein Disk-Image mit korrekten REL Files drauf, also kann ich im Moment nicht selbst testen, was passiert, wenn man so ein Image öffnet ...


    Jetzt muss natürlich viel getestet werden, aber ich hoffe ich kann bald mal eine erste Version veröffentlichen!

    Im Screenshot mal testweise eine neue Disk angelegt :)

    Die library wächst und gedeiht und ist inzwischen öffentlich verfügbar: https://github.com/excess-c64/lib1541img


    Das urprünglich mal zum testen gedachte GUI ist als eigenständiges Tool released: V1541Commander -- Tool für 1541 disk images (D64)


    Für die nähere Zukunft geplant ist ein Dateiformat nur für "DirArt" und im GUI ein entsprechend bequemer Editor -- wenn das erreicht ist geht es dann mal an mkd64v2, unter Nutzung der neuen Library :)

    Vielleicht ist das hier ja das völlig falsche Forum für so ne Frage, vielleicht habe ich aber auch Glück und jemand hat Ideen dazu ...


    Im Moment biete ich offizielle, statisch gelinkte Builds vom V1541Commander an für Windows (ab Version 7), Linux (ab 3.2 glaube ich) und so "halboffiziell" mit nem älteren Qt auch für Windows XP und Vista. Auf diversen Unix-Systemen kann es sich auch jeder selbst aus dem Source bauen, sollte nicht so das Problem sein.


    Um das ganze abzurunden wäre aber ein Paket für OS X, für die Mac-User, noch recht wünschenswert :)


    Leider ist das mit dem cross-compilieren nicht ganz so einfach .. habe zwar dieses Projekt gefunden: https://github.com/tpoechtrager/osxcross -- aber um an die notwendigen SDK-Files für OS-X zu kommen muss man, wenn ich das richtig verstehe, X-Code installieren, und dafür braucht man erst mal ein laufendes OS-X. Selbst wenn ich mir jetzt eines kaufen würde, es läuft ja nur auf Apple Rechnern, und da hört es dann wirklich auf, ich kaufe doch keine überteuerte Hardware, nur um für dieses System Pakete bauen zu können :o


    Die Frage ist, was sind die Alternativen...

    • Eventuell kriegt man das SDK aus dem X-Code "dmg" auch ohne OS-X extrahiert? Wenn ja, wie?
    • Oder lieber travis-ci integrieren, wenn ich das richtig sehe kann das ja auch Pakete für OS-X bauen? Hat da jemand Erfahrung damit?

    Und dann stellt sich natürlich noch die Frage, wie man das Ergebnis testet. Ich nehme an sowas ähnliches wie Wine gibt es wohl nicht, um OS-X binaries auf anderen Plattformen auszuführen, sonst hätte ich sicher schon davon gehört? Läuft wahrscheinlich darauf hinaus, einen Tester zu finden, der einen Mac hat -- oder seht ihr Alternativen?

    MacOS ist da in der Tat etwas sperrig. Ich baue cc1541 mit osxcross, aber da das eine Kommandozeilenapp ist, brauche ich das SDK dafür nicht. Ich vermute, für Qt wirst Du um das SDK nicht herumkommen (hast Du das mal probiert?). Generell ist es wohl so, dass man ohne Apple Hardware kaum weiterkommt. Nicht zuletzt muss man Mac Apps ja auch eigentlich zertifizieren, damit man sie ohne Gehampel verwenden kann. Cloud-Lösungen gibt es auch nicht allzuviele, und m.W. keine kostenlosen.


    Mein Tipp: in die Doku schreiben, dass macOS User Wine verwenden sollen (und das ggfs. testen, vermutlich reicht es, das unter Linux zu tun).

    Zitat von Claus

    Ich vermute, für Qt wirst Du um das SDK nicht herumkommen (hast Du das mal probiert?)

    Hab ich nicht, aber da hab ich wenig Hoffnung, da Qt für OS-X ja ein eigenes "Backend" hat, das das native Grafiksystem verwendet (und eben nicht X11). Ist allerdings schonmal sehr interessant zu wissen, dass man den Krempel für Console-Programme nicht braucht (vermutlich also für alles, was nur eine standard C library braucht?).

    Zitat von Claus

    Cloud-Lösungen gibt es auch nicht allzuviele, und m.W. keine kostenlosen.

    Naja, travis-ci ist für Opensource Projekte kostenlos und scheint das zu können. Vielleicht probiere ich das doch einfach mal aus.


    Danke für die Antwort :)

    Interessant, Travis-ci kannte ich noch nicht. Bin gespannt, wie Deine Erfahrungen sind.

    Travis-CI ist eigentlich ganz gut, gerade wenn Du viel merge oder push Aktionen hast.

    Dann wird Travis einfach getriggert, der Code durchläuft einmal den Buildprozess und Du weißt sofort ob die Codeänderung Dein Projekt zerschießt oder nicht.


    Travis sollte Linux (iirc Ubuntu-Basis), macos und eine Windows Buildenvironment bieten.