Beiträge von the_cky im Thema „mkd64 - Weiterentwicklung“

    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.

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

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

    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 Bitte melde dich an, um diesen Link zu sehen.)?

    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.

    Sieht doch schon einmal gut aus :)

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

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

    Moin,

    ich hatte vor Jahren auch mal etwas in dieser Richtung gebastelt, aber auch irgendwann aufgehört und heute würde ich den Code wahrscheinlich heute auch anders schreiben :wink:

    Meine Idee war damals auch eine Library zu bauen und passend dazu eine Konsolentool und ggf. später eine GUI Variante.

    Da es damals für meine Testzweck gereicht hatte, habe ich auch nicht weitergemacht. Auch mein Zeug ist auf Github (Bitte melde dich an, um diesen Link zu sehen. und Bitte melde dich an, um diesen Link zu sehen.).

    Du hast geschrieben, das Du jetzt auf eine andere Architektur wechseln möchtest - welche denn?

    Gruß

    Thomas