Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 77 Antworten

letzter Beitrag von Zirias am

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

    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


    https://github.com/Zirias/c64_tool_mkd64


    Windows Binaries


    https://github.com/Zirias/c64_…master/win32bin/mkd64.zip


    Hilfe


    Code
    1. mkd64 -h
    2. 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
    https://github.com/Zirias/c64_…master/win64bin/mkd64.zip
    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 :)

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


    --------


    Zitat von Dekay

    Benutze ich scheinbar nicht richtig:

    Code
    1. C:\c64\mkd64>mkd64.exe -h cbmdos
    2. mkd64 0.1b help
    5. 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...


    Zitat von Dekay


    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

    Zitat von Dekay

    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.

    Zitat von Dekay

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


    Zitat von Dekay

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

    Zitat von sauhund

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

    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: https://github.com/Zirias/c64_…v0.31b/win32bin/mkd64.zip
    Windows 64bit: https://github.com/Zirias/c64_…v0.31b/win64bin/mkd64.zip
    Linux (i386, portable): https://github.com/Zirias/c64_…v0.31b/lin32bin/mkd64.zip
    Debian/Ubuntu i386: https://github.com/Zirias/c64_…v0.31b/deb32bin/mkd64.deb
    Debian/Ubuntu amd64: https://github.com/Zirias/c64_…v0.31b/deb64bin/mkd64.deb


    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
    1. mkd64 -mcbmdos -md64tmpl -itemplate.d64 -odemo.d64 [...] \
    2. -freadme -n"README" -w \
    3. -f -n -e0 -Td -w \
    4. -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
    https://github.com/Zirias/c64_…64/blob/master/modapi.txt
    und vielleicht
    https://github.com/Zirias/c64_…r/include/mkd64/imodule.h
    schaut.


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