welchen genau verwendest du denn ? CIA1 /2 timer ? Ich kann ja nicht wissen was in deinem Code passiert ?
Krill Loader
-
ivettaB -
18. Februar 2022 um 03:39 -
Erledigt
Es gibt 113 Antworten in diesem Thema, welches 19.164 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Der Loader nutzt selbst keinerlei Interrupts.
-
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...
Codeldx #<filename1 ldy #>filename1 jsr loadraw; load without decompression bcs error2; accu contains error code when carry is set after loading akku = 08, carry is SetWas 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...
Codeldx #<filename1 ldy #>filename1 jsr loadraw; load without decompression bcs error2; accu contains error code when carry is set after loading akku = 08, carry is SetWas 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 :
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
-
Transwarp lädt schneller.
(Aber ohne Bild.)Warum so eine antike VICE-Version?
-
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:
-
Tinycrunch ? Wieder was neues....
Macht der es auch so klein wie der Exo ?
Nein, aber in der nächsten Release-Version kommt ZX0 als neuer Goldstandard-Cruncher dazu.
-
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:
CodeAlso refer to loader/samples/test/Makefile for the corresponding command line arguments for each of the supported crunchers.Das genannte Makefile:
So langsam werd ich aber müde, auf schon geschriebenen Text im Quelltext-Archiv hinzuweisen.
-