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

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

  • geb dem gcc mal ein -W -Wall mit. ordentlicher code gibt da keine warning (und das heisst im umkehrschluss das dieses casts auch in den C code gehören)


    Die "fehlenden" Casts von void* auf andere Pointertypen werden von gcc auch mit -Wall -Werror -pedantic nicht angemeckert - die implizite Konversion zwischen void-Pointern und anderen Pointertypen ist in C offiziell so vorgesehen. Wenn man da trotzdem eine Warnung bekommen möchte, kann man z.B. "-Wc++-compat" verwenden.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Code
    CFLAGS= -std=gnu99 -Wall -Werror -W -Wextra -Wmissing-declarations \
     -Wmissing-prototypes -Wcast-align -Wpointer-arith -Wreturn-type \
     -Wformat -Wformat-security -Wnested-externs -Wsign-compare \
     -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline

    Ich nutze obige Daumenschrauben um mir ein sauberen Stil anzugewöhnen. Ist in einer Uni-Projektgruppe mal ausbaldovert worden, wo ich auch mit viel Fremdcode arbeiten musste/durfte der mit Mis-Casts und anderem gespickt war.

  • Die "fehlenden" Casts von void* auf andere Pointertypen werden von gcc auch mit -Wall -Werror -pedantic nicht angemeckert - die implizite Konversion zwischen void-Pointern und anderen Pointertypen ist in C offiziell so vorgesehen


    letzteres ist klar... ersteres verwirrt mich aber jetzt doch etwas... egal. implizit ist immer bäh =P


  • ääääh. watt. meines wissens muss man da bewusst selber hand anlegen um gcc OHNE g++ zu kriegen. ich hab noch kein system gesehen auf dem es gcc gibt, aber g++ nicht.


    Für Windows krieg ich die einzeln, für Debian auch. Für manche exotischen Plattformen existiert kein C++-Compiler. Der Hauptvorteil von "plain C" ist allerdings Binärkompatibilität.

    Ist ja auch ein gängiger "trick" c programme damit zu kompilieren (weil g++ bessere warnings ausspuckt, zb)


    Die sind nicht besser sondern falsch, wenn es wirklich C-Code sein soll.

    du sollst das ja nur so machen das es geht - das binary baut man natürlich mit gcc dann


    Für Plugins schon längst passiert, die können jetzt mit C++ gebaut werden, sollte aber wirklich nur in seltenen Fällen sinnvoll sein.


    geb dem gcc mal ein -W -Wall mit. ordentlicher code gibt da keine warning (und das heisst im umkehrschluss das dieses casts auch in den C code gehören)


    Bitte melde dich an, um diesen Link zu sehen.
    Da steht nicht umsonst -Wall -pedantic. Mein Code gibt keine Warning. Es ist ein gängiger Unsinn, "void *" in C zu casten. "void *" war als generischer Pointer gedacht und lässt sich implizit in jeden Daten-Pointer-Typ konvertieren (nicht in Function-Pointers). Erst C++ hat das ganze verunstaltet.

    der sinn ist wie schon gesagt der das man von g++ viel bessere warnings und fehlermeldungen bekommt als von gcc. und wenn man die warnings konsequent fixt wird der code ganz nebenbei etwas "moderner".


    Siehe oben, die Warnings sind für C falsch. Und ein "T *bla = (T *)malloc(sizeof(T))" ist nicht moderner sondern ein Missbrauch der Sprache C.

    tl;dr "C++isms" kommen mir in den Code nicht rein. In der API isses ok, zwecks Flexibilität.

  • Code
    CFLAGS= -std=gnu99 -Wall -Werror -W -Wextra -Wmissing-declarations \
     -Wmissing-prototypes -Wcast-align -Wpointer-arith -Wreturn-type \
     -Wformat -Wformat-security -Wnested-externs -Wsign-compare \
     -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline

    Ich nutze obige Daumenschrauben um mir ein sauberen Stil anzugewöhnen. Ist in einer Uni-Projektgruppe mal ausbaldovert worden, wo ich auch mit viel Fremdcode arbeiten musste/durfte der mit Mis-Casts und anderem gespickt war.

    Manches davon ist leider etwas praxisuntauglich:
    -Wunused-parameter: Nicht jede Implementierung eines Callbacks braucht jeden Parameter. Man kann die Warnung umgehen, indem man die absichtlich ungenutzten Parameter mit "(void) parameter;" scheinbar benutzt. Halte ich für Mist, bläht nur den Code unsinnig auf.
    -Wmissing-prototypes: Klingt sinnvoll, aber wenn man an static funktionen innerhalb eines Moduls denkt, ist eine forward-deklaration einfach unnötiges boilerplate. Ich verwende stattdessen -Werror=implicit-function-declaration -- das erwischt nur die Fälle, in denen ein prototyp wirklich nötig gewesen wäre.

    Wenn ich das weglasse, was ich nicht sinnvoll finde, kriege ich nur noch ein paar warnungen wegen Vergleichen signed<->unsigned. Die können in der Tat sinnvoll sein, werde eventuell den Code so ändern, dass das explizit gemacht wird, wo es sicher ist.


  • ah aus dem lager bist du - da helfen keine pillen =)


    Müßig das auszudiskutieren, aber C++ ist schon einer der größeren "Sprachunfälle". IMHO zeigt C#, wie man ne objektorientierte Sprache mit C-Grammatik richtig baut.
    edit sagen wir besser richtiger ;) Das Gemurkse "IDisposable" wo Sprache und Klassenbibliothek vermischt werden und explizite Calls an den Garbage-Collector nötig sind hätte wohl nicht wirklich sein müssen.

  • -Wunused-parameter: Nicht jede Implementierung eines Callbacks braucht jeden Parameter. Man kann die Warnung umgehen, indem man die absichtlich ungenutzten Parameter mit "(void) parameter;" scheinbar benutzt. Halte ich für Mist, bläht nur den Code unsinnig auf.


    den code aufblähen sollte das allerdings nur bei extrem karpotten compilern.... also keinem wo potentiell mal dieses tool mit kompiliert wird :) bei GCC gibts für den fall attribute unused oder sowas (nie benutzt, ich nehme immer die klassische variante)

    Zitat

    Müßig das auszudiskutieren, aber C++ ist schon einer der größeren "Sprachunfälle". IMHO zeigt C#, wie man ne objektorientierte Sprache mit C-Grammatik richtig baut.


    ich halte das alles für überflüssigen schnickschnack, aber C++ noch immer für besser als C# oder gar java. ich lasse mich da aber auch nicht belehren, daher in der tat müßig =P


  • den code aufblähen sollte das allerdings nur bei extrem karpotten compilern.... also keinem wo potentiell mal dieses tool mit kompiliert wird :) bei GCC gibts für den fall attribute unused oder sowas (nie benutzt, ich nehme immer die klassische variante)


    Und leider absolut kein Standard, wenn man es also portierbar will ist die nächste preprocessor-magic baustelle offen oder man fügt diese dämlichen (void) foo; Zeilen ein. Nene, lass mal...

    "Aufblähen des code" war auf den Sourcecode bezogen, nicht auf den Binärcode.


    ich halte das alles für überflüssigen schnickschnack, aber C++ noch immer für besser als C# oder gar java. ich lasse mich da aber auch nicht belehren, daher in der tat müßig =P


    Das wird dann aber mit der Zeit schwierig werden :p Ist ja nicht so, dass man aus solchem Mist wie C++ nicht gelernt hätte. Zum Thema Java ... naja, es gibt noch andere Unfälle außer C++ ;)

    Nur damit es keiner falsch versteht, ich halte C auch nicht für eine rundum gelungene Sprache -- weit davon entfernt. Aber C++ hat da einfach "verschlimmbessert". Wen Details interessieren, interessante Quellen findet man genug :)

  • Das wird dann aber mit der Zeit schwierig werden :p


    ich mach zum glück keine anwendungsentwicklung, sondern embedded.... da wird man noch lange mit asm und C weiterkommen :) und wenn das nicht mehr so ist, dann werd ich bäcker. oder so =)

  • Ja gut, das ist ne GANZ andere Baustelle ;) C und ASM mach ich halt nur privat. Trotzdem finde ich C++ Murks ;)

    edit Da es nur ein Dutzend Stellen waren habe ich mich mal auf die dummen "(void) foo;" Zeilen eingelassen -- und tatsächlich EINE Stelle gefunden, an der ein Parameter WIRKLICH überflüssig war. Nun denn. Jetzt compiliert es auch warnungsfrei mit -std=c99 -Wall -Wextra -pedantic ;)

  • Bevor ich an eine Version 2.0 mit dann hoffentlich stabiler API denke würde ich gern nochmal auf Bitte melde dich an, um diesen Link zu sehen. verweisen... Punkt 5 ist ja mittlerweile umgesetzt -- was ist mit dem Rest, bzw, fällt jemandem noch was anderes ein?

    Wer Bedenken bezüglich Sauberkeit des Codes hat möge bitte zuerst einen Blick in denselben werfen ;) Die #ifdef-Hässlichkeit in modrepo.c wird noch beseitigt, da arbeite ich gerade dran...

    Ich rede hier von konzeptionellen Dingen und würde mich über entsprechenden Input freuen!

  • Wer Bedenken bezüglich Sauberkeit des Codes hat möge bitte zuerst einen Blick in denselben werfen ;)


    Der sah bei einem kurzen Blick ziemlich nach "Ich wollte das eigentlich in C++ schreiben, muss aber gerade C nehmen und baue mir deswegen die OOP von Hand nach" aus ;)

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Der sah bei einem kurzen Blick ziemlich nach "Ich wollte das eigentlich in C++ schreiben, muss aber gerade C nehmen und baue mir deswegen die OOP von Hand nach" aus ;)


    Naja nicht ganz. OOP in C ist gar nicht so selten, und weil es in C++ so kaputt ist, kann man sich das subset, das man braucht, durchaus auch mal eben in C implementieren :) Also ich kenne schon ne Menge Projekte, die OOP in C machen, spontan fällt mir da die glib und SDL ein. Der Punkt ist: ich /muss/ nicht C nehmen, ich /will/ es (da es mit der Portabilität von C# leider in der Praxis weniger weit her ist als in der Theorie...)

    Genau die Diskussion ist aber die, die mich konzeptionell leider nicht weiterbringt...

  • Mal eine erste Version einer generierten API Dokumentation:
    Bitte melde dich an, um diesen Link zu sehen.

    Da kommen noch ein paar Sachen bis zur 2.0 ;)

  • Hm, auf Windows wird das Qt Trace Plugin RICHTIG fett, wenn man es statisch linkt ... hab trotzdem mal einen aktuellen test-build mit dem plugin hochgeladen:
    Bitte melde dich an, um diesen Link zu sehen.
    Vielleicht hat ja jemand Lust, damit rumzuspielen ;)

  • Wirklich schade, dass man das Toppost nicht editieren kann :( Also, da jetzt auch die Webseite im repo liegt (ist bei github so Standard) sollte man den Source folgendermaßen ziehen, wenn man wirklich nur den Source will:

    Code
    git clone --single-branch https://github.com/Zirias/c64_tool_mkd64 mkd64
    cd mkd64
    git remote set-branches origin master
  • Update: v1.4b

    Diesmal im Prinzip ein "Maintenance release". Alle geplanten API-Changes für 2.0 sind drin, aber keine neuen User-Features. Da ich gerade versuche, noch Perl über ein Modul anzubinden (und das wohl länger dauern wird), wird dieses Release noch "rausgehauen", vor allem damit andere testen können ;) Insbesondere bin ich daran interessiert, ob irgendwas am API fehlt oder kaputt ist ;)

    Changelog:

    Code
    * New beta release (maintenance release, no new user features)
      * lots of stabilization, better build system
      * core: new object model, let caller allocate memory, provide macros for
        this
      * core: allow multiple instances of a module
      * core: mechanism for passing private options to a module
      * auto-generate API docs using doxygen, integrate these in sdk

    Downloads:

    Binaries:
    Windows 32bit: 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.

    SDK:
    Allgemein: Bitte melde dich an, um diesen Link zu sehen.
    Debian/Ubuntu: Bitte melde dich an, um diesen Link zu sehen.

  • Achja, FALLS mir jemand bei perl helfen mag, die ersten Versuche finden sich hier:

    Bitte melde dich an, um diesen Link zu sehen.

  • 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

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────