Hello, Guest the thread was called1.2k times and contains 24 replays

last post from zrs1 at the

mkd64 - Weiterentwicklung

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

    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!

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

  • 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/)?


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

  • 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 ;)