mkd64 [2014-01-02, v0.1b] -- Tool zur Erstellung von D64 Images

Es gibt 77 Antworten in diesem Thema, welches 12.014 mal aufgerufen wurde. Der letzte Beitrag (17. November 2014 um 20:07) ist von Zirias.

  • mkd64 dient als Ersatz für c1541 und cc1541 zur Erstellung von D64-Images. Wie cc1541 beschränkt sich mkd64 darauf, images "from scratch" zu erstellen, und versucht dabei aber, mehr Möglichkeiten zu bieten als c1541. Im Gegensatz zu cc1541 ist mkd64 modular aufgebaut: Das Hauptprogramm beschränkt sich auf ein "rohes" Diskettenformat aus Tracks und Sectors, auf das Files geschrieben werden können. Alles was darüber hinausgeht wird in ladbaren Modulen implementiert.

    In diesem ersten Release ist genau ein Modul enthalten, 'cbmdos'. Dieses Modul implementiert Directory und BAM des originalen Floppy-DOS. Damit kann mkd64 bereits cc1541 für alle 35-Track Images ersetzen und bietet zusätzlich folgende Features:
    - Das Directory wird mit einem sector-interleave von 4 geschrieben
    - Files starten auf Track 17
    - Der Filetyp ist auswählbar
    - Files können "write-protected" (erkennbar an einem '<' nach dem Filetyp) gespeichert werden
    - Ein map-file kann erstellt werden mit einer Liste aller Files inklusive Starttrack und -sector

    Beta

    Dies ist eine beta-Release. Ich habe ausgiebig getestet, kann aber im Moment nicht garantieren, dass sich nicht noch Bugs irgendwo verstecken. Der Hauptgrund für den Zusatz "beta" ist aber ein anderer: Das Interface für Module könnte sich noch inkompatibel ändern. Sobald ich sicherstellen kann, dass neue Versionen abwärtskompatibel sind, verschwindet das beta ;)

    System / Build

    Getestet habe ich mkd64 auf Windows und auf Linux. Das offizielle "build-system" besteht aus GCC (nur der C-Compiler wird benötigt) und GNU make.

    Zum compilieren muss lediglich 'make' eingegeben werden. Alle Module (*.so auf Unix/Linux, *.dll auf Windows) müssen sich im gleichen Verzeichnis wie mkd64 befinden, damit sie geladen werden können.

    Hinweise zu Windows:
    'make' funktioniert mit einer minimalen Installation von MinGW32 im Suchpfad. ACHTUNG: MSYS sollte NICHT im Suchpfad sein, da make ansonsten versucht, sh.exe zu verwenden. Das Makefile erkennt Windows und verwendet in dem Fall eine cmd.exe-kompatible syntax. Auf Windows ist es außerdem möglich, VC++ (Visual Studio) zum compilieren zu verwenden. Der Microsoft-Compiler erzeugt aktuell kleineren Code, ich werde ihn aber nicht offiziell unterstützen, da der Aufwand zu groß ist, ständig zu überprüfen, ob auch in Visual Studio noch alles funktioniert.

    Quellcode

    Bitte melde dich an, um diesen Link zu sehen.

    Windows Binaries

    Bitte melde dich an, um diesen Link zu sehen.

    Hilfe

    Code
    mkd64 -h
    mkd64 -h cbmdos
  • Da war es wohl doch einen Tick zu spät gestern ... ich hatte aus Versehen win64 binaries gebaut. Ist jetzt korrigiert, unter dem Link oben finden sich wirklich win32 binaries. Die win64 binaries sind auch noch da und liegen unter
    Bitte melde dich an, um diesen Link zu sehen.
    Allerdings werde ich die wohl nicht immer aktualisieren, da 64bit für mkd64 auf Windows keinerlei Vorteil bietet.

    Dazugekommen ist jetzt auch minimale Dokumentation (modapi.txt) und ein README.md :)

  • Benutze ich scheinbar nicht richtig:

    Code
    C:\c64\mkd64>mkd64.exe -h cbmdos
    mkd64 0.1b help
    
    
    Module `cbmdos' not found.
  • Update
    Bugfix-Release 0.11b hochgeladen.

    - Korrekter exitcode (Wichtig für Makefiles, mkd64 v0.1b lieferte leider immer einen Fehler, auch wenn alles ok war)
    - Win32 und win64 binaries im richtigen Verzeichnis :)

    --------

    Benutze ich scheinbar nicht richtig:

    Code
    C:\c64\mkd64>mkd64.exe -h cbmdos
    mkd64 0.1b help
    
    
    Module `cbmdos' not found.


    Liegt cbmdos.dll im gleichen Verzeichnis wie mkd64.exe? Falls ja, was für eine Windows-Version und ist das 32 oder 64bit? Getestet habe ich bisher auf Win 2008R2 und Win 7, jeweils x64, sowohl den 32bit als auch den 64bit build -- eventuell kann ich das Problem ja nachvollziehen...

    Das allerdings ist "expected behavior" :) mkd64.exe selbst schreibt kein Directory, das macht cbmdos.dll (Option zum laden: -m cbmdos).

    edit:

    Noch ein Beispielaufruf, der bei mir funktioniert:

    edit2: Screenshot der help-Ausgaben mit dem aktuellen win32 build

  • Aha, das war so nicht klar. Also "mkd64.exe -m cbmdos -o test.d64 -d'TEST' -i'BA'"

    Die cbmdos.dll liegt im gleichen Verzeichnis wie mkd64.exe.

    Ich benutze ein 32bit Windows XP.

  • Hmm ok, sowas hab ich irgendwo noch, ich teste mal bei Gelegenheit in einer vm. Dass das Modul nicht gefunden wird ist seltsam...

  • Ich habe die neuste Version runtergeladen und jetzt findet er die cbmdos.dll
    Ich konnte ein leeres Image anlegen. Allerdings mag er die eingestrichenen Anführungsstriche nicht.
    So gings: mkd64.exe -m cbmdos -o test.d64 -d"TEST" -i"BA"

  • Ich habe die neuste Version runtergeladen und jetzt findet er die cbmdos.dll
    Ich konnte ein leeres Image anlegen. Allerdings mag er die eingestrichenen Anführungsstriche nicht.
    So gings: mkd64.exe -m cbmdos -o test.d64 -d"TEST" -i"BA"


    Das dürfte eine Frage der Shell (auf Win NT CMD.EXE) sein. Auf win7 geht es mit den einfachen Strichen :) Aber gut zu wissen, dann nehm ich in meinen Makefiles doppelte, damit es auch auf XP tut :)

  • "Mag er nicht", war vielleicht keine so gute Beschreibung. Es geht, aber die eingestrichenen Anführungsstriche sind dann Teil des des Namens und der ID.

    Interessant. Rechts und oben, wenn das Image mit DirMaster angelegt wurde. Links und unten, wenn es von mkd64 kommt.

  • "Mag er nicht", war vielleicht keine so gute Beschreibung. Es geht, aber die eingestrichenen Anführungsstriche sind dann Teil des des Namens und der ID.


    Interessant, ich schaue mir das mal an, eventuell ist es ja auch GNU make für windows, das die einfachen Anführungsstriche "korrekt" interpretiert. Solange das Argument keine Leerzeichen hat, ist das sowieso überflüssig ;)

    Interessant. Rechts und oben, wenn das Image mit DirMaster angelegt wurde. Links und unten, wenn es von mkd64 kommt.


    Hmm, das Verzeichnis ist ja leer, daher sollte "00,00" und keine Markierung in der BAM meiner Meinung nach korrekt sein? cbmdos.dll schreibt "00,FF" sobald der erste Eintrag angelegt wird, und markiert den Block auch erst dann als belegt. Ist das falsch?

    Danke schonmal fürs testen :)

  • so, und jetzt muss ich mich korrigieren. :drunk: Entschuldige, aber es passt links oben die Sektoransicht mit der BAM unten links zusammen und rechts die BAM mit der Sektoransicht unten rechts. Das heisst, dass mkd64 nur Track 18 und Sektor Null beschreibt.
    Der DirMaster macht das genau so, wie es VICE macht, wenn man eine Diskette neu formatiert. Ich gehe also davon aus, dass die 1541 es genauso machen würde. Ich glaube es wir dadurch der Track 18 für die Fileeinträge reserviert.

  • Ok, danke für die Infos. Eine leere Diskette ist natürlich ein "Grenzfall" und eigentlich ist mkd64 nicht dazu gedacht, so etwas zu erzeugen ;) Aber ich behalte es mal im Hinterkopf, eventuell kann ich das cbmdos Modul so anpassen, dass auch eine leere Diskette aussieht wie von der original Floppy erstellt.

    edit: Interessant in diesem Zusammenhang wäre auch die Frage, was die originale Floppy nach dem 8. File macht, denn für das 9. wird ein weiterer Directory-Block benötigt. cbmdos.dll belegt auch den erst dann, wenn ein 9. File wirklich angelegt wird. Auch das werde ich dann mal noch testen :)

  • Update: v0.2b

    Neues Feature: Optionen aus einem File lesen.

    win32 binaries: Bitte melde dich an, um diesen Link zu sehen.
    win64 binaries: Bitte melde dich an, um diesen Link zu sehen.

  • mmmh wenn das ding auch noch die directory aus einem template lesen könnte, dann wäre ich sehr versucht meinen frickelkram zu ersetzen :)

  • mmmh wenn das ding auch noch die directory aus einem template lesen könnte, dann wäre ich sehr versucht meinen frickelkram zu ersetzen :)

    Hi sauhund, kannst du das genauer erklären, wie du dir das vorstellst? Eventuell wäre das ja auch als Modul implementierbar.

    Die Planungen für 0.3b sind schon abgeschlossen, Status:
    - "Build ID" um builds zu identifizieren [DONE]
    - Debian packages [DONE]
    - cbmdos: Nur directory entry schreiben, wenn '-n' gegeben wurde [DONE]
    - Versions-Info auch für Module [DONE]
    - Abhängigkeiten zwischen Modulen beim laden berücksichtigen [TODO]
    - Modul 'dolphindos' [TODO]
    - Modul 'speeddos' [TODO]

    Aber wenn du hier eine nützliche Idee hast könnte ich ja ggf. die Modulschnittstelle so erweitern, dass das implementierbar wird (oder, wenn es nicht zu komplex ist, gleich selbst implementieren). Vielleicht für 0.4b dann ;)

  • Mal schnell auf'm Rpi getestet und macht was es soll :smile: :thumbsup:

    --------------------------------------------------------------------------------------------------------
    RapidFire BBS: rapidfire.hopto.org:64128

  • Update: v0.31b

    * Neues modul 'xtracks' für tracks 36-40 und optional DOLPHIN DOS / SPEED DOS bam
    * build id in jedem build

    Windows 32bit: Bitte melde dich an, um diesen Link zu sehen.
    Windows 64bit: Bitte melde dich an, um diesen Link zu sehen.
    Linux (i386, portable): Bitte melde dich an, um diesen Link zu sehen.
    Debian/Ubuntu i386: Bitte melde dich an, um diesen Link zu sehen.
    Debian/Ubuntu amd64: Bitte melde dich an, um diesen Link zu sehen.

    EDIT: v0.3b NICHT verwenden, da hatte sich ein memory corruption bug eingeschlichen

  • Zitat

    Hi sauhund, kannst du das genauer erklären, wie du dir das vorstellst? Eventuell wäre das ja auch als Modul implementierbar.


    also das problem das es zu lösen gibt ist: zb bei einer demo will man oftmals ja irgendwelche directory art haben, also mittels graphikzeichen in den filenamen bildchen malen. selbiges lässt sich nur sehr schwierig mittels pc tools erzeugen. um das ganze automatisiert in meinem buildsystem zu machen hab ich mir ein kleines tool gebastelt welches die fertig präparierte directory von einem template d64 liesst, und dann auf ein zweites d64 (das die aktuelle demo enthält) überträgt. in der praxis birgt das den ein oder anderen fallstrick, daher blieb mein frickeltool auch bisher unreleast =)

    mein tool tut folgendes:
    - interne kopie vom quell d64 erzeugen
    - directory vom template in die kopie schreiben
    - t/s links auf die files in der kopie anpassen, dabei werden jeweils die ersten beiden zeichen jedes files verglichen und bei gleichheit davon ausgegangen das es das selbe file ist (für die gängigen file basierten loader passt das idr). ausserdem werden die ersten N files im directory so wie sie sind übernommen (müssen also zwingend in quelle und template an der selben position stehen), damit erschlage ich die typischerweise am anfang stehenden start- und note- files.

    der letzte schritt ist der etwas frickelige wie man unschwer sehen kann

  • Ok, so verstehe ich das :) Also das erste was mir dazu einfällt, und was wirklich als modul machbar wäre: einfach nur die filenamen aus dem "template" nehmen (z.B. identifiziert per "index" 0 - 143). Könnte dann so aussehen:

    Code
    mkd64 -mcbmdos -md64tmpl -itemplate.d64 -odemo.d64 [...] \
        -freadme -n"README" -w \
        -f -n -e0 -Td -w \
        -fdemo-part1 -n -e1 -Tu -w [...]

    1. File: "README.PRG", Inhalt readme von der Platte
    2. File: DEL mit Filenamen Position 0 vom "Template", kein Inhalt
    3. File: USR mit Filenamen Position 1 vom "Template", Inhalt demo-part1 von der Platte

    Klingt das für dich sinnvoll?

  • Kleine Info:

    Das Modul-Interface steht kurz vor einer Version, die ich als "stabil" betrachten würde. Was mir dafür noch fehlt, und sicher die nächsten Tage kommt:

    Module haben die Möglichkeit, Blocks für sich zu reservieren, die noch nicht belegt sind. 'Cbmdos' tut das für den kompletten Track 18. Damit Disketten wirklich KOMPLETT vollgeschrieben werden können, möchte ich noch eine Möglichkeit schaffen, mit der ein Modul gefragt werden kann, ob es einen bestimmten reservierten Block zurückgeben würde -- was nur passiert, wenn alle nicht-reservierten Blocks bereits belegt sind.

    Also, falls das jemanden interessiert, wäre es nett, wenn ihr mal in die Dateien
    Bitte melde dich an, um diesen Link zu sehen.
    und vielleicht
    Bitte melde dich an, um diesen Link zu sehen.
    schaut.

    Wenn euch noch etwas auffällt, was für ein "vollständiges" Modul-Interface fehlt, bitte hier posten ;)