Beiträge von Claus im Thema „mkd64 [2014-01-02, v0.1b] -- Tool zur Erstellung von D64 Images“

    Hm, bzgl. MSVS meine ich gelesen zu haben, dass 2010 die älteste Version ist, die problemlos aufwärts-kompatibel ist. Aber vielleicht sollte man einfach die neuste Version nehmen, die ist dann vielleicht am zukunftsichersten?

    Jou, mein Patch ist schon ein bisschen reingefriemelt, ich wollte nur, dass es mal schnell bei mir geht ^^ . Du weißt sicher am besten, wo die Funktionalität gut aufgehoben ist. Und \x ist vermutlich die bessere Wahl (obwohl man den Backslash natürlich auch praktisch überall escapen muss). So konnte ich halt meinen cc1541-Patch eins zu eins übernehmen :whistling:

    Gibt es noch weitere Pläne mit dem Tool außer dem eigenen Dateisystem? Was ist denn da genau der Plan, ein echt inkompatibles Dateisystem, oder nur andere Strategien für die Block-Allozierung?

    Letzteres fände ich noch ganz interessant: ich frage mich, ob es was bringt, das Allozieren der Blöcke von der Reihenfolge der Dateien im Directory zu entkoppeln. So könnte man z.B. kleine Dateien möglichst nah an Track 18 positionieren, um die Zugriffszeiten auf den ersten Track/Sektor zu optimieren (die bei größeren Dateien weniger ins Gewicht fällt, weil das Laden selbst länger braucht). Oder eine "Priorität" pro Datei angeben, die die Datei entsprechend nah oder weit von Track 18 positioniert. So könnte man Dateien, auf die häufiger zugegriffen wird, näher an Track 18 positionieren. Ob sich das lohnt, weiß ich nicht, aber ein Experiment wärs vielleicht wert...

    So, ich habe mich mal bei github angemeldet und mich mit git rumgeschlagen, man muss ja mal mit der Zeit gehen. Ich habe Dir einen Pull-Request geschickt:

    Bitte melde dich an, um diesen Link zu sehen.

    Das macht die Sache vielleicht einfacher für Dich...

    Ich habe den stat-Patch noch nicht ausprobieren können, da ich grade nur auf Linux Zugriff habe. Ich schau heute abend mal, obs unter Windows jetzt geht.

    So, ich habe mich mittlerweile abgeregt, sorry für die Beschwerden von vorgestern :whistling:. Mittlerweile habe ich die passenden Pakete in MinGW gefunden (mingw32-base enthält alles, was man so am Anfang braucht), eine Suchfunktion im Paketmanager wäre aber echt praktisch gewesen :böse . Dann konnte ich auch schon fast was bauen, allerdings nur fast:

    src\diskfile.c: In function 'DiskFile_readFromHost':
    src\diskfile.c:128:24: error: storage size of 'st' isn't known
    static struct stat st;

    Ein Blick in <sys/stat.h> zeigt, dass stat nur deklariert wird, wenn __STRICT_ANSI__ nicht definiert ist. Ich habe einfach mal -std=c99 aus dem Makefile geschmissen, weil mir das am ehesten damit zu tun haben schien, dann hat es mit ein paar c90-bezogenen Warnings gebaut.

    Ich habe dann mal die Sache mit dem $-Escape reingefriemelt. Ich bin nicht total glücklich mit der Lösung, weil das Kommandozeilen-Parsing der Module scheinbar keine Fehler zurückgeben kann, sondern nur Warnings und dann mit Fallback-Werten weiterarbeiten muss. Fallback für einen Fehler beim Parsen ist jetzt einfach mal, einen String der Länge 0 zu nehmen. Eigentlich hätte ich eher gesagt, dass man in dem Fall abbrechen sollte, aber das hätte zu größeren Umbauten geführt. Ich hab meine Änderungen mal attached, vielleicht kannst Du ja mal einen Blick drauf werfen (hab keine Lust, einen GitHub-Account anzulegen). Ist jetzt nicht wahnwitzig gut getestet, aber sollte eigentlich gehen.

    Insgesamt mag ich Deine Software ganz gerne, ich denke, ich werde jetzt darauf umsteigen :dafuer:

    Habe noch nicht in Deinen Code reingeschaut, daher kann ich noch nichts versprechen


    Oh mann, ich habe mir das ganze zu Gemüte geführt und es ist mir zu mühselig. Was ist denn das für eine MSVC-Version, für die die Solutions sind? MSVC2010 will alles konvertieren und scheitert scheinbar daran. Ich habe versucht, auf die Schnelle ein eigenes Projekt damit aufzusetzen, aber blicke grade nicht, was da jetzt wo in welche DLL und in welches Executable gehört. Die buildid.h fehlt, die müsste dann wohl mit dem buildid-Binary erzeugt werden?

    Danach wollte ich eine Build-Umgebung mit MinGW aufsetzen, aber da ich das noch nie benutzt habe, komme ich da grade auch vom Hölzchen aufs Stöckchen, weil ich nicht weiß, welche Pakete man da jetzt genau braucht. Und wenn dann will ich auch gescheit debuggen, und dann müsste ich mir noch entweder Eclipse installieren oder mir eine andere Entwicklungsumgebung einrichten. Hab jetzt 1h investiert und bin dem Ziel, das ganze mal aus den Sourcen zu bauen keinen Millimeter näher gekommen. Also die Hemmschwelle für einen Wald- und Wiesen-Windowsentwickler erscheint mir doch reichlich hoch... Ich hab jetzt keinen Bock mehr. Für den Moment bleibe ich dann mal bei CC1541 und bastele mir das nach meinen Bedürfnissen zurecht.

    Ein $ müsste man dann als Hex-Code eingeben, also als "$24". Ich dachte, es wäre eine Spitzenidee, das $ als Escapezeichen zu nehmen, weil es intuitiv auf eine Hexzahl hindeutet. Allerdings bin ich inzwischen unschlüssig, ob es die beste Wahl ist, weil es in Makefiles, Bash-Skripten etc. auch schon als Escapezeichen für Variablennamen verwendet wird. In meinem Makefile musste ich also dann statt "AUTOSTART$0a,8,1" schon immer "AUTOSTART$$0a,8,1" schreiben. Das alleine wäre vielleicht noch nicht so tragisch, aber man findet den Fehler nicht so leicht, da das Makefile aus "AUTOSTART$0a,8,1" erstmal den C64-Filenamen "AUTOSTARTa,8,1" macht, weil es $0 durch einen leeren String ersetzt. Hm, ideal wäre irgendein ASCII-Zeichen, das es nicht als PETSCII gibt. So viel Auswahl gibt es da wohl nicht, denn es sollte auch ein Zeichen sein, das man auf jeder Tastatur leicht eingeben kann (womit Dinge wie ä,ö,ü etc. wegfallen). Vielleicht ^ oder ~. Oder halt doch bei $ bleiben...

    Fänd ich auf jeden Fall prima, wenn Du die Idee übernehmen würdest, so spart man sich Hacks wie sauhund's. Ich könnte mir den Spaß auch mal anschauen und Dich vielleicht mir einem Patch-Vorschlag versorgen. Habe noch nicht in Deinen Code reingeschaut, daher kann ich noch nichts versprechen :)

    Weil ich es gerade in cc1541 reingepatcht habe (natürlich bevor ich diesen Thread gesehen habe :böse :sad: kann Dein Tool mit beliebigen Character-Codes für die Filenamen im D64 umgehen? CC1541 nimmt ja 1 zu 1 die ASCII-Zeichen, die man ihm auf der Kommandozeile gibt, was es z.B. für Shift-Space (PETSCII $a0 und auch ASCII $a0) quasi unmöglich macht. Weiß vermutlich jeder, aber mit $a0 kriegt man ja so Eintrage wie diesen hin:

    1 "AUTOSTART",8,1 PRG

    Und auch sonst will man ja vielleicht mal PETSCII-Sonderzeichen benutzen.

    Die Lösung, die ich mir für meinen Patch ausgedacht habe, ist übrigens, das $-Zeichen als Escape-Zeichen zu interpretieren und die beiden Zeichen danach als Hex-Code zu lesen, also z.B.:

    cc1541 -f "AUTOSTART$a0,8,1" -w autostart.prg