Krill Loader

Es gibt 113 Antworten in diesem Thema, welches 19.172 mal aufgerufen wurde. Der letzte Beitrag (30. Juli 2025 um 10:24) ist von TD1334.

  • nein passt schon danke !

    Und GROSSES Danke !! für deine Geduld.

    Ich hoffe ich war ein gutes Beispiel für einen typischen Anwender deiner Programme falls du die nächste Readme schreibst :wink:

    Ich säubere den Code und stelle ihn für andere hier online damit die sich den Weg den ich / wir gingen nun sparen können.

    >>> Fazit: Ich hatte den falschen Vice zum Entwickeln, und die Reihenfolge nicht gecheckt in der die Teile kopiert werden mussten .... bevor ich aufrufe <<<


    Ich muss sowieso erst eine Linux VM aufsetzen da ich UNBEDINGT diese cc64 / Makefile sachen auch können sollte .....

    denn das was ich heute habe rennt nicht richtig auf GNUWin32 (siehe Pfadcharacterproblem)

    dann ziehe ich mir den Tinycruncher auch noch rein... ist ja schon egal :smile:

  • Du bist ja echt on top IT mässig ! Denke mir du bist sicher Admin...

    Ich bin leider seit 10 Jahren weg von der IT und das wird so bleiben....

  • Heute morgen ne Tirade, jetzt Lobhudelei? :)

    Bin kein Admin, aber baue auch beruflich Software.

  • Du kannst dur eine VM oder das MSYS-Zeug auch sparen, wenn du das WSL benutzt. Da kann man dieses unsägliche makefile-Gebastle auch direkt in einem echten Linux-Kernel machen.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: 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.

  • Das war vor 30 Jahren schon doof, zum Glück hat sich die Welt großteils weitergedreht :)

    Ich kann damit umgehen, aber ich bin einfach kein Fan davon. Aber allein eine Debug und Release-Config zu basteln ist schon ein übles Gewürge.

    Bevor das jetzt in einen Rant ausartet, bleibe ich lieber ruhig.

    Agree to disagree ;)

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: 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.

  • Das war vor 30 Jahren schon doof, zum Glück hat sich die Welt großteils weitergedreht :)

    Was ist denn eine bessere/modernere Lösung, um Bau-Rezepte zu beschreiben?

    Also wenn man schon C/C++ machen muss dann finde ich CMake recht pfiffig. Das nutzen wir auf der Arbeit auch und es erzeugt je nach Wunsch VS Solution, makefile, Ninja build script, XCode Projekt oder... Also sehr flexibel.

    Ansonsten bin ich großer Fan von Maven / Leiningen je nachdem. Aber das kannst du in der C-Welt vergessen.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Bitte melde dich an, um diesen Link zu sehen.

  • Eine C Umgebung für einen Fastloader... echt jetzt ?

    Das muss doch anders gehen ?

    Einfach 6502 ASM Datei , einige Variablen im Source setzen und durchassemblieren ... (dachte ich mir)

    So geht das halt auch in cc65, da hier ja auch ein Assembler dabei ist. Den benutze ich auch. Man muss halt nur das C Paket runterladen. Ich bin zu faul festzustellen was man alles braucht wenn man nur den ASM benutzen will, aber den C compiler habe ich noch nie benutzt. Vermutlich kann man das Meiste davon löschen, ist aber den Aufwand nicht wert.

    Für C64/C128 Projekte habe ich bisher einfach nur ein Batchfile benutzt. Makefile oder CMake ist IMO dafür Overkill, weil die Programme so winzig sind dass die in Nullkommanix durchcompiliert sind.

  • Also wenn man schon C/C++ machen muss [...]

    (Sorry, die Frage ging eigentlich direkt an Endurion den Make-Meider.)

    Vielleicht gibt es ja etwas geeigneteres für Assembler usw., also dem Target C-64 inklusive Ressourcen (was über die Tools ja auch C und weitere Hochsprachen beinhaltet), das ich für das Loader-Projekt benutzen könnte.

    Etwas besseres ist mir bisher aber nicht bekannt.

    Das, was Make tut, geht auch kaum einfacher/weniger komplex so generisch in Rezepten zu beschreiben.

    Alle modernen Lösungen, die ich bisher gesehen habe, waren für bestimmte Use-Cases (Sprachen, Plattformen) konzipiert (mit magischen Schlüsselwörtern) und nicht so generisch wie Make.

    Wenn man dann mal etwas vom Default abweichendes tun will, muss man irgendwo das Druiden-Geheimwissen auftun, um es dem Tool beizubringen.

    Und Make ist hervorragend dokumentiert und so weitverbreitet, dass irgendwann irgendwo irgendwer genau das aktuelle Problem schon mal gelöst hat.

  • Ich finde make auch super... bei größeren Projekten und vielen Target Plattformen würde ich es nicht nutzen, aber für simple Projekte mit klar definierter Zielplattform ist es toll.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Bitte melde dich an, um diesen Link zu sehen.

  • habe makefiles immer für Mist empfunden.... aber jedem das seine...
    habe das Makefile vom Loader eh nicht zum laufen bekommen auf Win32 GNU umgebung wegen den fehlenden " im Source...

    Habe nicht herausgefunden wo der Ordner imediate im SRC erzeugt wird.

    deshalb mix dem Schrott nicht weitergemacht. Ich ziehe mir ein Kali Linux runter und versuche es damit..

  • Sorry, ich wollte hier den Thread nicht zernichten!

    >Off Topic
    Gefühlt muss es etwas Angenehmeres als Makefiles geben, man kann zwar fast alles damit machen, aber es ist halt ein Gefummel. Mich stört es, wenn bei einem C/C++-Projekt dann für das Makefile erst nochmal ein bis zwei zusätzliche Sprachen reingezogen werden, die dann ggf. erst die echten Makefiles generieren, oder ausprobieren, welche C-Befehle zur Verfügung stehen, etc. OpenSSL, I'm looking at you! Das muss man doch alles im Code abwickeln können.

    Ich habe halt auch auf unterschiedlichen Plattformen leichte Abweichungen im Verhalten von make gefunden, das macht es nicht angenehmer.

    Blöd, wenn man eine IDE gestellt bekommt (Oracle Developer Studio), und dann trotzdem wieder in den Makefiles basteln muss. Da ist die IDE nicht viel mehr als ein besserer Text-Editor.

    >Off Topic Ende!

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: 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.

  • Sorry, ich wollte hier den Thread nicht zernichten!

    >Off Topic
    Gefühlt muss es etwas Angenehmeres als Makefiles geben, man kann zwar fast alles damit machen, aber es ist halt ein Gefummel. Mich stört es, wenn bei einem C/C++-Projekt dann für das Makefile erst nochmal ein bis zwei zusätzliche Sprachen reingezogen werden, die dann ggf. erst die echten Makefiles generieren, oder ausprobieren, welche C-Befehle zur Verfügung stehen, etc. OpenSSL, I'm looking at you! Das muss man doch alles im Code abwickeln können.

    Ich habe halt auch auf unterschiedlichen Plattformen leichte Abweichungen im Verhalten von make gefunden, das macht es nicht angenehmer.

    Blöd, wenn man eine IDE gestellt bekommt (Oracle Developer Studio), und dann trotzdem wieder in den Makefiles basteln muss. Da ist die IDE nicht viel mehr als ein besserer Text-Editor.

    >Off Topic Ende!

    Ebenfalls GANZ KURZ offtopic: Das ist ein relativ C-spezifisches Problem. VStudio, gcc, clang, ... es gibt viele Compiler, viele Plattformen, aber keine einheitlichen Linker, Buildtools etc. C ist portabel und gleichzeitig auch nicht. Historischer Unfall. In der JVM Welt ist da alles deutlich standardisierter. Da gibt es einen de facto Standard (maven) für Build Tooling, auf dem andere Tools aufsetzen oder kompatibel sind (gradle, lein, ...). Alle Sprachen können sich untereinander unterhalten (Java, Clojure, Scala, ...), während C++ zum Beispiel ohne gigantischen Aufwand nicht von anderen Sprachen aufgerufen werden kann, dank nicht standardisiertem Linker und Name Mangling.

    In der C-Welt hat sich für alles, was NICHT Windows ist, make und seine Ableger als Standard etabliert (autotools, CMake, ...). Unter Windows selber hängt es davon ab wie neu oder alt ein Projekt ist...

    Das Hauptproblem mit C-Projekten ist daher, dass es keinen standardisierten Weg gibt die Abhängigkeiten zum Bauen zu beschaffen. In der JVM Welt schreibe ich das alles in meine maven files rein, und es wird automatisch alles heruntergeladen. So etwas gibt es leider in der C-Welt nicht. Daher das "gefummel". Daher ja dann auch der ganze Tanz mit docker und Co. Dort kann man relativ kompakte Beschreibungen einer Maschine ablegen, die schon alle Abhängigkeiten mitbringt. Vielleicht können wir mal ein cc65 Dockerfile entwerfen, was jeder verwenden kann...? :) VSCode kann ja auch ganz gut mit Prozessen in Docker Containern sprechen...

    Oops, war doch nicht so kurz. Gerne auch den Teilfaden abtrennen in ein eigenes Topic zur Entwicklung von C64 Software auf PCs.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Bitte melde dich an, um diesen Link zu sehen.

  • Gefühlt muss es etwas Angenehmeres als Makefiles geben, man kann zwar fast alles damit machen, aber es ist halt ein Gefummel. Mich stört es, wenn bei einem C/C++-Projekt dann für das Makefile erst nochmal ein bis zwei zusätzliche Sprachen reingezogen werden, die dann ggf. erst die echten Makefiles generieren [...]

    So off-topic ist das ja nicht, weil es ja um potenzielle Alternativen für C-64-Projekte im Allgemeinen und Loaderbau im Speziellen geht. :)

    Aber jegliche Meta-Makes (autoconf usw.) sind was anderes als reine statische Makefiles, und auch nicht gut.

    Aber wirkliche Alternativen zu letzterem für den konkreten Zweck habe ich noch nicht entdeckt.

  • Wenn man selbst Make verwendet, hindert einen ja niemand daran sehr simple Makefiles zu schreiben.

    Das mache ich zum Beispiel so - zumindest fuer C64 Projekte.

    Ich nutze fast keine der schlauen Features, aber die Aufloesung von Abhaengigkeiten allein ist unersetzbar.

    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.

  • Leider ist halt Make unter Windows nicht verbreitet, und was es da gibt ist meist ein Gehampel mit Forward/Backward-Slashes usw. Ich habe eine zeitlang Jam verwendet, was zumindest explizit Plattformübergreifend ist, aber das kennt ja kein Mensch und wird m.W. auch nicht mehr maintained. Daher bin ich wieder zurück zu Makefiles.

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

  • Also ich verwende schon lange keine Makefiles mehr selbst. Wenn ich was bauen will, dann mit CMake, das ja auch makefiles erzeugen kann, einwandfrei funktioniert und dabei auch verständlich bleibt. Makefiles sind halt sehr systemspezifisch. Und wenn man das nicht brauchen kann, dann muss man mit autconf oder ähnichem rumbasteln was ich auch nicht gerade für intuitiver halte, wenn auch flexibler.