Krill Loader

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

  • Crunchen und Diskimages erzeugen sind ja nur Aufrufe von externen Programmen nach einem Build. Das geht also auf jeden Fall. Den Emulator aufrufen geht natürlich auch, wenn das per kommandozeile geht. Die Frage ist, ob man das will. Wie gesagt, ich persönlich finde bei C64/C128 Programmen den Aufwand zu hoch, weil die Projekte meistens so klein sind dass sie in ein paar Sekunden compiliert sind. Das ist nicht wie bei grossen Bibliotheken wo man mehrere Minuten warten muss und deshalb einen Mechanismus benötigt um die Zeit zu reduzieren.

    Wenn ich gcc neu compiliere dann dauert das u.U. Stunden. Da bin ich natürlich froh, wenn ich bei einer kleinen Änderung nur das eine Teil neu compilere das sich verändert hat. Bei C64 Programmen dauert es vielleicht 2-3 Sekunden wenn ich alles compiliere, also finde ich es Overkill da noch zu optimieren. Da bin ich mit einer einfachen Batchdatei genauso zufrieden und muss keine komplizierten Tools lernen.

  • Wie gesagt, ich persönlich finde bei C64/C128 Programmen den Aufwand zu hoch, weil die Projekte meistens so klein sind dass sie in ein paar Sekunden compiliert sind. Das ist nicht wie bei grossen Bibliotheken wo man mehrere Minuten warten muss und deshalb einen Mechanismus benötigt um die Zeit zu reduzieren.

    YMMV, aka "bei Dir vielleicht." :)

    Ich habe schon einige C-64-Projekte gesehen, bei denen es mehr als 30 Sekunden und bis zu Minuten gedauert hat, die ganze Welt neuzubauen und vor allem per Cruncher (Exomizer, ZX0) die Luft rauszuquetschen.

    Und schon 3 Sekunden Bauzeit können beim Debuggen nerven, wenn es ein Sekundenbruchteil sein kann.

    Inkrementelle Builds ergeben eigentlich immer Sinn.

  • Ich habe schon einige C-64-Projekte gesehen, bei denen es mehr als 30 Sekunden und bis zu Minuten gedauert hat, die ganze Welt neuzubauen und vor allem per Cruncher (Exomizer, ZX0) die Luft rauszuquetschen.

    Das kann schon sein und dann macht es vielleicht auch Sinn. Das hängt ja vom Projekt ab.

    Zitat

    Und schon 3 Sekunden Bauzeit können beim Debuggen nerven, wenn es ein Sekundenbruchteil sein kann.

    Inkrementelle Builds ergeben eigentlich immer Sinn.

    Das sehe ich halt anders, vor allem mit so einer Generalisierung. ;)

  • inkrementelle builds sehe ich auch sinnvoll...

    Gibt es ein guitool wo ich die pakete anklicke und ein Makefile rauskommt das dann auch auf Win / *nix funktioniert ohne stress ?
    Habe immernoch im Makescript für den Loader nicht herausgefunden wo der IMEDIATE order erzeugt wird...

    Oder macht das das Make intern ?

  • Geht es denn nativ unter Linux auch immer noch nicht?

    Die Verzeichnisse sind normale Abhängigkeiten:

    Code
    # directory targets
    
    $(BUILDDIR):
        $(MKDIR) $(BUILDDIR)
    
    $(INTERMDIR):
        $(MKDIR) $(INTERMDIR)
  • Makros sind in Make was anderes. :)

    Hier werden Verzeichnisse einfach wie normale Dateien behandelt, die als Abhängigkeiten der Dateien, die da reinkommen, auftauchen.

    Wenn es das Verzeichnis nicht gibt, greift so ein Baurezept wie oben, um es anzulegen, eben "mkdir ausführen".

  • noch ne Frage wäre über: Wo finde ich den Pointer der auf das letzte Byte zeigt wenn ich etwas geladen habe ?

    so wie früher 45/46 Register (bei CBM load)

  • was soll ich sagen sowas von cremig in einer Ubuntu Edition.

    hat stressfei durchassembliert ...

    Der einzige Stress war es die Ubuntu VirtualBox zu bauen damit ich das auf meinem Windose Laptop drauf bekomme :wink:

  • noch ne Frage wäre über: Wo finde ich den Pointer der auf das letzte Byte zeigt wenn ich etwas geladen habe ?

    so wie früher 45/46 Register (bei CBM load)

    Dafür ist diese Option:

    Code
    .define END_ADDRESS_API           0 ; during and after loading, the file's current and then final end address (address of last file byte + 1) is stored in
                                        ; endaddrlo and endaddrhi. for loading compressed files using loadcompd, the end address of the compressed data is stored.
                                        ; the file's loading address can be found in loadaddrlo/loadaddrhi during and after loading, so polling the current
                                        ; difference of endaddrlo/hi and loadaddrlo/hi can be used to implement progress displays (take care for update race conditions).

    anzuknipsen.

    Der Pointer zeigt dann aber auf das erste Byte nach der geladenen Datei.

  • schon aber zu generisch. Welche Variable ist es denn exact wenn ich die Default Einstellungen in der Ini verwende ?

    bzw bei Deinem Vorkompilierten Build "loader-C64.prg" ?

    aka : endaddrlo and endaddrhi ??

    Moment: Anknipsen ? also per default abgedreht - Nicht da ? nada ? Brauche das für meinen Exomizer als Startadresse fürs Entpacken der Parts (welche ich mit -f forwärts packte)

  • schon aber zu generisch. Welche Variable ist es denn exact wenn ich die Default Einstellungen in der Ini verwende ?

    bzw bei Deinem Vorkompilierten Build "loader-C64.prg" ?

    aka : endaddrlo and endaddrhi ??

    "Zu generisch"? Aber es gibt keine Variablen für die Endadresse im vorgebauten Binary. Diese Information ist da nirgendwo im Loadercode vorhanden.

    Moment: Anknipsen ? also per default abgedreht - Nicht da ? nada ? Brauche das für meinen Exomizer als Startadresse fürs Entpacken der Parts (welche ich mit -f forwärts packte)

    Wenn Du vorwärts packst-/entpackst, brauchst Du eher die Startadresse. Die gibt's auch vorgebaut, in loadaddrlo/hi.

    Aber Du kannst auch gleich den Loader mit Exomizer-Decruncher bauen, indem Du "DECOMPRESSOR" auf "DECOMPRESSORS::EXOMIZER" stellst.

    Zum Entpacken von Speicher nach Speicher gibt es dann

    Code
    .define MEM_DECOMP_API            0 ; include a routine for memory decompression, that is, loading and decompression can be separated.
                                        ; C-64: decompression to $D000..$DFFF need not have LOAD_UNDER_D000_DFFF enabled,
                                        ; just enable 64 kB of RAM before jsr memdecomp.
                                        ; requires DECOMPRESSOR != DECOMPRESSORS::NONE
                                        ; this option does not implicitly turn on the LOAD_RAW_API

    Erst laden und dann entpacken ist aber langsamer, als per "loadcompd"-Call gleich beim Laden zu entpacken.

    Exomizer ist aber generell eher langsam, es gibt fixere Decruncher, die auch nicht so viel schlechter als Exomizer packen.

  • Nee, die Dekompressor-Option ist eine Auswahl, da kann man nur einen aus ner Liste (oder keinen) auswählen, aber nicht mehrere auf einmal.

    (Wobei das indirekt geht, aber dafür braucht man nen guten Grund.)

  • nix verstanden. Aber "DECOMPRESSORS::EXOMIZER" als Enable habe ich so nicht verstanden.

    Also gebe ich das beim Make auf der Commandline mit ?

    ich miuss smal die Samples anschaun... vielleicht erleuchtet es mich :smile:

  • In der v184-Default-config.inc

    Code
    DECOMPRESSOR                    = DECOMPRESSORS::TINYCRUNCH

    durch

    Code
    DECOMPRESSOR                    = DECOMPRESSORS::EXOMIZER

    ersetzen.