Krill Loader

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

  • Der Init bei $4000 läuft jetzt ohne carry verzweigt wenigsten daher nicht in den Error..

    aber ich bekomme einen 08 aus dem Akku nachdem ich das mache...

    Code
        ldx #<filename1
        ldy #>filename1
        jsr loadraw; load without decompression
        bcs error2; accu contains error code when carry is set after loading
       
    akku = 08, carry is Set

    Was bedeutet das ? Im Loader.inc steht zwar was von:

    TINYCRUNCH = $08 ; ChristopherJam aka Shrydar's tinycrunch

    aber das stimmt nicht - ich lade eine normale NUF Datei nach $3000....

    Muss ich in der ZP irgendwas setzen ?


    Habe mir den 0200-03f0 Teil aus deinem "loader test.prg" gerippt before der Teil angesprungen wird...

    Den die Demo läuft als einziges auf meinem Vice...

    Die Loader aus dem Archiv jammt immer....

    Man sieht im Demo auf jeden Fall das die Plattenemulation im Vice von Sektor 15 kurz auf 18 geht und dann den Fehler wirft.

  • aber ich bekomme einen 08 aus dem Akku nachdem ich das mache...

    Code
        ldx #<filename1
        ldy #>filename1
        jsr loadraw; load without decompression
        bcs error2; accu contains error code when carry is set after loading
       
    akku = 08, carry is Set

    Was bedeutet das ? Im Loader.inc steht zwar was von:

    TINYCRUNCH = $08 ; ChristopherJam aka Shrydar's tinycrunch

    Gültige Fehlercodes sind in ".scope status" in loader.inc gelistet. $08 ist keiner davon.

    Muss ich in der ZP irgendwas setzen ?

    Nope.

    Habe mir den 0200-03f0 Teil aus deinem "loader test.prg" gerippt before der Teil angesprungen wird...

    Du hast irgendwelche Lowmem-Variablen gerippt und keinen Loader-Code. Der liegt im Testprogramm nicht bei $0200.

    Die Loader aus dem Archiv jammt immer....

    Vermutlich, weil Du erst den Loader-Code nach $0200 kopierst, dann über den Installer KERNAL-Calls abgesetzt werden, während der KERNAL-Interrupt noch läuft, und dadurch der vorher kopierte Code teilweise überschrieben wird.

    Der Installer nutzt KERNAL-Calls und sollte aufgerufen werden, bevor im Lowmem rumgewurschtelt wird.

    Man sieht im Demo auf jeden Fall das die Plattenemulation im Vice von Sektor 15 kurz auf 18 geht und dann den Fehler wirft.

    Diskettenemulation und Spur?

  • ja ich verwende den Vice zum Testen und entwickeln. Ich sehe das die Spuranzeige im VIC unten rechts kurz von 14 auf 18 geht und dann zurück kommt vom laden mit Carry Set und 08 im Akku.

    Ich mache übrigens sei lda#$37 sta 01 bevor ich $4000 aufrufe das funktioniert ja auch mit dem gerippten 0200

    und einem $4000 install aus dem Archiv.

    Leider klappt das laden nicht...

    inzwischen bestätige ich auch den CIA irq mittels :

    Code
    lda $dc0d                          ;sonst
     
    
    exit      PLA
              TAY
              PLA
              TAX
              PLA
              RTI  

    Schön das du mir sagtst im Testprogramm ist der Loader nicht bei $200 aber nicht WO er steht !?

    Was soll ich mit der Antwort genau anfangen ?

    Dann soll ich jetzt raten ? $3000 etwa ?

    Sei mir nicht böse wenn ich das jetzt sage aber , weisst du eigentlich das ich gestern locker 10 Stunden mich mit deinem Projekt beschäftigt habe und bis heute ladet die Lib kein Bild - dabei will ich es gar nicht dekomprimieren , laden reicht schon...

    Also so genial dein Loader auch sein möge - und es ist das beste das ich seit langem gesehen habe, das verwenden hast du ziemlich kompliziert gemacht.

    War es so schwierig einen dokumentieren Source beizulegen mit dem das einbinden und Laden eines Bildes einfach funktioniert ?

    (zb das Test Programm?)

    Dann brauchst du auch keine ellenlangen Readmes schreiben , meine Meinung

    Deine kurzen Antworten sagen mir: Ja gut du möchtest das ich das Programm in und auswendig studiere - habe ich - alles durchgelesen auch die Incs - und nein alles verstehe ich nicht vieles aber schon.

    Anhand meiner Fragen hast du nicht erkannt das ich einfach den Loader Standalone verwenden möchte. Wenn es umgekehrt wäre hättest du schon gestern ein Source schnipsel das lauffähig ist von mir erhalten..

    Oder geht das wegen all der CC65 , make - Abhängigkeiten ncht ?

    Aber dann sag es doch direkt !

    Nur für den Loader mir das alles zu installieren und sitzen bis das dann geht und meine anderen Make/GCC usw zu riskieren

    Ist dir aufgefallen, auf dem gesamten Forum kein Tutorial zur verwendung ? kein PDF, kein Videoclip ? Keiner ? Nada

    Weil es bei allen einfach geht nur bei mir nicht ?

    naja anderen auch siehe :

    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.

    gleicher Fehler (JAM)

    Da bietest du ihm an zu helfen wenn er dir das DiskImage sendet und danach gibts keine Antwort mehr für die Community

    Bitte melde dich an, um diesen Link zu sehen.

    Einfach ?


    Also ich weiß nicht wie andere das sehen aber wenn du das anbietest und kaum support gibst und davon ausgehst das wir

    das Macroconstrukt einfach so durchschauen mit diesen lustigen r2d2/c3po Hinweisen OK

    Oder ist das Geheimwissen das nur an Freunde im Untergrund auf Copy Parties weitergegeben wird ,wie früher als wir 15 waren ?

    auch hat nicht jeder Informatik studiert oder arbeitet in der IT ...

    Das musste ich jetzt mal loswerden. Sorry

  • PS Dein Makefile läuft auch nicht sauber...

    Habe die komplette GNU Win32 umgebung auf einem anderen PC installiert weil ich neugierig bin...

    Pearl (Strawberry)

    cc65

    Zip

    Bzip.dlls

    make (Bitte melde dich an, um diesen Link zu sehen.)

    GNU Win32 (CoreUtils5.3.0.exe)

    alle Pfade gesetzt und bekomme dann

    C:\c64\NuFli\loader-v184\loader>make prg

    Das System kann den angegebenen Pfad nicht finden.

    make -C src prg

    make[1]: Entering directory `C:/c64/NuFli/loader-v184/loader/src'

    mkdir ./../build/intermediate

    Syntaxfehler.

    make[1]: *** [../build/intermediate] Fehler 1

    make[1]: Leaving directory `C:/c64/NuFli/loader-v184/loader/src'

    make: *** [prg] Fehler 2

    C:\c64\NuFli\loader-v184\loader>

    auch im SRC Ordner das Makefile hat Probleme beim erzeugen des Directories (Mkdir)

    C:\c64\NuFli\loader-v184\loader\src>make prg

    mkdir ./../build/intermediate

    Syntaxfehler.

    make: *** [../build/intermediate] Fehler 1

    C:\c64\NuFli\loader-v184\loader\src>

    Hast du das eigentlich mit Windows getestet ?

    Ich schätze du hast LINUX genommen...

    >der MKDIR braucht " " um zu funktionieren - finde den MKDIR im Makefile aber nicht....

  • Schön das du mir sagtst im Testprogramm ist der Loader nicht bei $200 aber nicht WO er steht !?

    Was soll ich mit der Antwort genau anfangen ?

    Dann soll ich jetzt raten ? $3000 etwa ?

    Es gibt zwei Möglichkeiten:

    1. Loader konfigurieren und selber bauen

    2. vorgebaute Binaries und dazugehörige Symboldefinitionsdatei benutzen

    Den Loader-Code aus dem Testprogramm zu rippen (ja, bei $3000) ergibt keinen Sinn, weil dann die Symbole nicht passen, außerdem die NUFLI-Datei bei $2000 beginnt, und der Loader sich beim Laden dieser Datei selbst überschreiben würde.

    das verwenden hast du ziemlich kompliziert gemacht.

    YMMV. Eigentlich ist das alles recht kanonisch für Open-Source-Projekte.

    War es so schwierig einen dokumentieren Source beizulegen mit dem das einbinden und Laden eines Bildes einfach funktioniert ?

    (zb das Test Programm?)

    Der Quelltext des Testprogramms ist in /loader/samples/test zu finden.

    Nebenan liegen noch ein paar weitere Beispiele, z.B. minexample.

    Nur für den Loader mir das alles zu installieren und sitzen bis das dann geht und meine anderen Make/GCC usw zu riskieren

    Ist für Möglichkeit 2 nicht notwendig.

    Und für Möglichkeit 1 sind Docker, virtuelle Maschinen, Dual-Boot oder Zweitrechner erfunden worden, von mingw/Cygwin/WSL mal abgesehen.

    Hast du das eigentlich mit Windows getestet ?

    Nicht, seitdem ich den Windows-Support in Form von NMAKE-Dateien vor Jahren wegerfunden habe.

    Aber:

    [...] mir zugetragen wurde, dass man den Loader nativ unter Windows bauen kann [...]

  • puh. Danke

    Nmake - ok.

    Der Test Source ist mit diesen vielen Macros echt nicht ohne zu lesen.... -> lesbarkeit

    meinte einen C64 Source (ohne diese Plus4 und all die Ausnahmen...)

    und macros in macros die sich aufrufen .... Mann oh Mann ....

    klar muss man das so machen wenn man einen Source machen will der überall läuft ....

    das meinem Acme beizubringen wird ned ohne...

    Sprites sind mir nicht aufgefallen im Demo...

    Wahrscheinlch schrift im Rahmen vermute ich mal...

    ich Schau mal wie weit ich komme den $3000 loader anzupassen..

    Wo wäre der Install.prg im Demo.prg eigentlich zu finden ?

    $3800 sieht vielverprechend aus...

    Wobei mir die spezifischen Block Writes fehlen...

    184 Revision:

    :5a4c 07 07 70 a8 58 07 07 07 70 a8 58 4d ..p.X...p.XM

    >C:5a58 2d 52 00 03 23 00 00 57 2d 4d 00 00 -R..#..W-M..

    >C:5a64 45 2d 4d 0e 05 d7 c1 d2 ce c9 ce c7 E-M.........

    >C:5a70 3a 20 c2 55 47 47 59 20 31 35 34 31 : .UGGY 1541

    >C:5a7c d5 20 46 49 52 4d 57 41 52 45 20 44 . FIRMWARE D

    >C:5a88 45 54 45 43 54 45 44 2e 20 d0 4c 45 ETECTED. .LE

    >C:5a94 41 53 45 20 55 50 44 41 54 45 2e 00 ASE UPDATE..

    >C:5aa0 cb 52 49 4c 4c 27 53 20 cc 4f 41 44 .RILL'S .OAD

    >C:5aac 45 52 2c 20 52 45 56 49 53 49 4f 4e ER, REVISION

    >C:5ab8 20 31 38 34 0d 43 4f 4e 46 49 47 20 184.CONFIG

    >C:5ac4 38 31 45 30 2e 31 32 32 38 31 30 2e 81E0.122810.

    >C:5ad0 31 38 31 30 43 2e 31 31 30 30 30 30 1810C.110000

    >C:5adc 30 30 30 30 30 30 2e 38 36 00 ff ff 000000.86...

    >C:5ae8 ff ff ff ff ff ff ff ff ff ff ff ff


    bei 1300 startet es auf jeden falle und macht dann viele viele Sachen...

    Habe dann beim Tracing "spurious NMI, Memory config Corrupt" und anderes am Schirm gehabt..

  • Warum versuchst Du nicht, den vorgebauten Loader bei $0200 zum Laufen zu bringen?

    Wie schon mehrfach gesagt:

    1. Loader installieren

    2. ROM ausschalten und Interrupts abschalten oder eigene Handler installieren

    3. Loader nach $0200 kopieren

    4. Laden

    Der Test Source ist mit diesen vielen Macros echt nicht ohne zu lesen.... -> lesbarkeit

    /loader/samples/minexample ist vermutlich etwas übersichtlicher.

    das meinem Acme beizubringen wird ned ohne...

    Das Testprogramm für andere Assembler zu portieren ist nicht sehr zielführend, glaub ich.

  • ach jetzt seh ichs : die Reihenfolge

    Habe erst den Loader copiert und obwohl ich sei machte crashed der Vice immer bei 0219

    gleich danach

    oder paar zyklen später (NMI Denke ich mir - den kann ich ja nicht mit sei wegdrücken....)

    Rahmenfarbe war schon 30% geändert (inc $d020 gleich nach dem Copy Loop)


    ich probiere deine Reihenfolge jetzt aus !

  • ja jetzt geht es in der Tat weiter....

    Nach dem Jsr $0200 (loadfile)

    sehe ich am Trackdisplay das er zwischen Track 1 und 2 endlos herumschaltet.

    Im Monitor sehe ich das er nun hier in einer Endlossschleife auf irgendwas wartet....

    0280:

    .C:0280 2C 00 DD BIT $DD00

    .C:0283 50 FB BVC $0280

  • Das macht er auch mit dem $3000 / 3800 Programm teilen.

    Dachte erst könnte am VICE liegen aber....

    dann kam mir NMI ?

    muss ich den NMI auf FFFA/B auch setzen ?

    Auf sinnvollen handler der dann auch richtig abschliesst ...

    OK LIEGT DEFINITIV AM VICE 2.4 .......

    Am 3.6 läuft das $3000 / 3800 Demo wenn ich eine Datei nach $0400 lade ......

    Und das extrem schnell !!!! Unglaublich

    Nachtrag : JAAAAAAAAAAAAAAAAAAAAA auch dein Loader 0200 /install 4000 klappt am Vice 3.6

    mit der obigen REIHENFOLGE

  • gehe ich recht in der Annahme das der wenn ich eine Exomizer gecrunchte NUF habe

    und die mit dem Binary Loader 0200 lade , keinen Exodecompressor drinnen hat ?

    oder etwa doch ?

    Zu deiner Frage Antik ..

    Weil mein C64 studio warum auch immer den Vice 3.6 nicht autmatisch nach dem Assemblieren / Linken aufrufen willl /kann

    habe Pfad gesetzt aber es ladet dann mein Assembly nicht automatisch hinein und startet es mit run. Auch das Source Level Debugging geht nicht im 3.x - keine Ahnung warum... (vergleichbar mit IDA Pro am PC )

    Im Moment assembliere ich, packe das PRG in ein D64 array mit Dirmaster und attach dieses D64 Image

    Lame - ich weiss

  • Der vorgebaute Loader kann mit tinycrunch gepackte Daten laden.

    Exomizer ist für Demos eher ungeeignet, weil recht behäbig beim Entpacken.

  • hat es einen Grund warum das Install so gross ist ? Ich nehme an du hast alle verschiedenen Laufwerke (1541(71/81) usw da reingepackt... gibt es eine 1541 Only Version die dann zb nur 3 blocks lang ist ?

  • Tinycrunch ? Wieder was neues....

    Macht der es auch so klein wie der Exo ?

    Wie müsste ich den verwenden um die NUFS (2000-7a00) richtig zu packen ?

    Ich nehme an ich brauche keinen SFX da das ja dein Loader macht wie oben geschrieben ?

    Also nur den Datenteil

    und (!!)

    Thanks to Krill for much assistance getting the small decrunch down to 100 bytes,

    <=100 bytes Ist echt der WAHNSINN


    -----------------------

    Generating self extracting .prgs only requires python (tested on 2.7 and 3.6)

    Building the tests, or modifying the boot file used by sfx mode requires ca65.

    Rebuilding bmp.prg/bmp.bin (the bitmap displayed by the tests) would require Numpy,

    but the .prg and .bin are included in case you have python and ca65 but don't want

    to install any more python libraries to run the example code.


    Installation Notes

    ==================

    Wherever you put tc_encode.py, make sure it's accompanied by tc_boot.prg


    Usage

    =====

    python tc_encode.py -h for argument descriptions. Note that you must specify

    precisely one of output start address, output end address, in-place compression,

    self extracting, or raw (headerless) mode.

    The data files produced by the first three options can be decoded with either

    of the tc_decode*.s routines by calling decode with A and X set to the low and

    high bytes respectively of the address of the data to decrunch.

    cf SFX notes below for the self extracting option.

    The fifth option (-r) just reads & writes blocks of binary data with no load address.

    The output file contains no header at all, so it's the caller's responsibility to

    set the source and destination zero page pointers to source address and one less

    than destination address respectively. Cf test/testbin.s for example usage, and

    don't forget to define TC_NO_HEADER when assembling.

    In this mode the small decruncher is a mere 79 bytes long. Note that in-place

    decompression is not supported in this instance, as the datastream is null terminated

    and there's no header to save the final byte.


    ------------

  • Aus /loader/include/config.inc:

    Code
    ; this reduces host-side install code
    
    .define ONLY_1541_AND_COMPATIBLE  0 ; reduces host-side install code by omitting any native custom drive code for non-1541 compatible
                                        ; drives, treats any drive as 1541, using an incompatible drive will cause undefined behaviour
  • Wie müsste ich den verwenden um die NUFS (2000-7a00) richtig zu packen ?

    Ich nehme an ich brauche keinen SFX da das ja dein Loader macht wie oben geschrieben ?

    Also nur den Datenteil

    Readme:

    Code
    Also refer to loader/samples/test/Makefile for the corresponding command line
    arguments for each of the supported crunchers.

    Das genannte Makefile:

    Code
    $(INTERMDIR)/%.tc: $(INTERMDIR)/%.prg
        $(TC) --inPlace $< $@

    So langsam werd ich aber müde, auf schon geschriebenen Text im Quelltext-Archiv hinzuweisen.