Hello, Guest the thread was viewed4k times and contains 26 replies

last post from Gold Beaver at the

BIN-Files als PRG starten

  • Hallo, ich hab gerade einen Knoten im Kopf.


    Ich habe von der Cartidge (Wizard of Wor 16KB Modul) ein BIN-File. Also wirklich nur das, was in den Eproms steht. Jetzt war meine Überlegung: Wenn ich mir ein Programm schreibe, in dem die BIN-Daten ab $1000 liegen, diese dann nach $8000 kopiere und dann ein JMP $8000 mache, müsste doch der Code vom BIN-File ausgeführt werden. Vorher wurde RAM bis auf $D000 definiert. Aber irgendwie klappt das nicht.
    Ich habe mal den Speicher vor und nach dem Kopieren kontrolliert. Das läuft richtig.


    Hier mal mein ugly Code:

  • Ungewöhnlich diese Form der Kopieraktion. Wenn das nicht wirklich arg zeitkritisch ist, würde ja auch so etwas eher in der Art reichen: (Zeropage $fb bis $fe ist üblicherweise frei)

    Beim Modulcode muss man sich freilich darauf verlassen, dass dieser davon ausgeht sich nicht selbst überschreiben zu können. Denkbar wäre ja auch, dass das Programm sich komplett oder in Teilen ins RAM kopiert und da ROM dann bei Bedarf ein-/ausblendet, um vielleicht das darunterliegende RAM zu nutzen. Wollte nur sagen, dass man sich nicht darauf verlassen kann, dass ein ins RAM (auch an der richtigen Stelle) kopiertes Modul zwangsläufig funktionieren muss. ;)

  • Ungewöhnlich diese Form der Kopieraktion. Wenn das nicht wirklich arg zeitkritisch ist, würde ja auch so etwas eher in der Art reichen: (Zeropage $fb bis $fe ist üblicherweise frei)

    warum so kompliziert ?
    einfach mit einem HEX-Editor die Bytes 00 80 vor das BIN-File bauen und als PRG speichern.
    Bei der Gelegenheit gleich mal schauen, welche Werte die ersten beiden Bytes des BIN-File ursprünglich haben .
    wenn Die z.B. 0A 80 lauten, ist der Einsprung JMP $800A


    Jetzt nimmst Du irgendeinen Packer und nimmst als Quelldatei die PRG-Datei, Status von $01 auf #$34 und Startjump den oben herausgefundenen (in dem Beispiel oben $800A ).
    Dann bekommst Du ein PRG, welches mit RUN startbar ist.


    Falls Du das Ganze z.B. mit exomizer machen willst, sieht die Kommandozeile so aus:

    Code
    1. exomizer.exe sfx '$800A' INPUTFILE.PRG -o STARTBARES.PRG -t 64 -n -s 'SEI LDA#$0B STA$D011 LDA#$34 STA$01' -f 'LDA#$37 STA$01 LDA#$1B STA$D011 cli'
  • im Zweifelsfall würd ichs per sys64738 starten, das deckt auch noch die seltenen Fälle ab, in denen sich ein Cartridge über den Basic-Restartvektor starten will.

    oder einfach ,8,1 laden und mit einem Hardware-RESET starten ;)
    aber merkt man sich das oder will man sich das merken ?

  • oder einfach ,8,1 laden und mit einem Hardware-RESET starten ;) aber merkt man sich das oder will man sich das merken ?

    Ja eh, aber offensichtlich ist ein simples Programm mit Start per RUN gewollt. Muss ja nicht jeder einen Reset-Taster haben.
    Man will sich nicht bei jedem Programm merken, dass man es "speziell" auf diese Art starten muss. :D

  • Ich benutze für Speicher-Kopieraktionen meist die Verschiebefunktion des Basic-Interpreters. Hat ein paar Nachteile, reicht aber meistens.

    Ich meine dies hier:

    Ich habe das jetzt mal als <cbm/c64/memmove.a> der ACME-Library hinzugefügt.

  • Die BASIC-Verschiebe-Routine ist wirklich prima.

    the source block must be below $a000 so it can be read

    Zur Not kann man sich den Code von $a3bf-a3fa ja auch kurz woanders hinschieben (Kass.puffer/Screen):


    Code
    1. ldx #$3b
    2. - lda $a3bf,x
    3. sta $033c,x / sta $0400,x
    4. dex
    5. bpl -

    Das ist ja zum Glück mal eine der wenigen Routinen, die mal nicht wild im ganzen Speicher rumspringen.

  • Quote from Mac Bacon
    Code
    1. ; source and target blocks are allowed to overlap.


    Da bin ich nicht ganz überzeugt von. Die Routine ab $A3BF kopiert nur von hinten nach vorne. Wenn Ziel- und Quellblock überlappen, geht das in Ordnung solange der Zielblock bei der höheren Adresse liegt - was im gegebenen Fall auch dazu genutzt wird, um Platz für eine neue Programmzeile zu schaffen.


    Überlappen Ziel- und Quellblock aber, und liegt der Zielblock bei der niedrigeren Adresse, dann gibt's Datensalat.


    Leider ist die 'spiegelbildliche' Routine im Interpreter, die von vorne nach hinten kopiert und genutzt wird um eine Zeile zu löschen, nicht für eigene Zwecke nutzbar, da der Interpreter direkt im Anschluß noch CLR und den Re-linker aufruft und dann über den Warmstart ins READY-Prompt geht.

  • $A3BF ist nett, aber das Befüllen der Parameter und ein eventuelles Kopieren in den Kassettenpuffer (wenn das BASIC wegeblendet sein soll etc.) und sonstige Zirkusnummern sind freilich innovativ, aber für den im Eingangsposting erwähnten Fall mit 64 Pages auf Pagegrenzen befindlich ohne Überlappung zu kopieren zu müssen schon fast zu viel des Guten und nur noch mit marginalem "Mehrwert" (aber natürlich allgemein ein guter Ansatz, zumindest für eine C64-Umgebung). Aber wie auch immer man der "LDA von,X STA nach,X"-Orgie Herr werden möchte... :D

  • Da bin ich nicht ganz überzeugt von. Die Routine ab $A3BF kopiert nur von hinten nach vorne. Wenn Ziel- und Quellblock überlappen, geht das in Ordnung solange der Zielblock bei der höheren Adresse liegt - was im gegebenen Fall auch dazu genutzt wird, um Platz für eine neue Programmzeile zu schaffen.


    Überlappen Ziel- und Quellblock aber, und liegt der Zielblock bei der niedrigeren Adresse, dann gibt's Datensalat.

    Urks, das kommt davon, wenn man sich auf sein Gedächtnis verlässt. Danke für den Hinweis, wird korrigiert.

  • Ich habe von der Cartidge (Wizard of Wor 16KB Modul) ein BIN-File. Also wirklich nur das, was in den Eproms steht. Jetzt war meine Überlegung: Wenn ich mir ein Programm schreibe, in dem die BIN-Daten ab $1000 liegen, diese dann nach $8000 kopiere und dann ein JMP $8000 mache, müsste doch der Code vom BIN-File ausgeführt werden. Vorher wurde RAM bis auf $D000 definiert. Aber irgendwie klappt das nicht.
    Ich habe mal den Speicher vor und nach dem Kopieren kontrolliert. Das läuft richtig.

    Bei den 16k-Standard Cartridges muss man natürlich zusätzlich noch ein paar Bytes ($01 Passagen) im bin-file anpassen, um ein lauffähiges PRG zu bekommen.
    Sonst liest du z.B. im Bereich $a000-$bfff aus dem Basic-ROM und nicht wie jetzt gewünscht aus dem RAM. (Es steckt ja kein Cartridge mehr im Expansionsport)


    --> Bankswitching Tabelle

  • jo.
    das wollte ich auch mal bemerken. Der Basicinterpreter muss ausgeblendet werden. Sonst gehts nicht.
    Ist schon ne Weile her bei mir. Hab früher immer E.C.A. Compacker genommen und dann nen Cruncher hinterher.
    Beim ECA konnte man glaube ich 36 in Adresse 01 einstellen während entpackt wird.
    Weiß nicht mehr ob der Wert bleibt wenn die Entpackroutine abgearbeitet war.
    Später gabs dann mal den Sledgehammer. Weiß garnicht mehr wie das DA war ?(
    Das ist alles schon soooo lange her :cry:
    Nimm ne Diskettenversion und gut ist :thumbsup:

  • 36 in Adresse 01

    Räusper...

    Code
    1. SEI
    2. LDA #$36; KERNAL ON / BASIC-ROM OFF
    3. STA $01

    evtl. noch vor Decrunching

    Code
    1. jsr $fd15; reset I/O
    2. jsr $fda3; Reset Interrupt / CIA etc.


    und bei $8000 kann man natürlich auch hinter das CBM Gedöns hinschreiben, was man will, um die Reset-Vektoren zu verbiegen

  • Hi Jungs,
    danke für die ganzen Antworten. Das hat mich im Verständnis schon recht weit gebracht. Ich weiß, ich kann das mit Crunchern machen, aber ich wollte es gerne von Hand lernen.


    Ich hab den Kopierteil geändert. Meiner war halt nur zum Ausprobieren gedacht. Hab halt gedacht das ganze Projekt ginge einfacher :roll2:


    Aber irgendwie läuft es nicht.


    Ich hab in die Anhänge mal das BIN-File der Cartridge und meine veränderte Version gepackt. Die Veränderung betrifft eigentlich immer nur die Aufraufe sta $01 (85,01). Hab die HEX-Kombination gesucht und jeweil das Byte davor auf $36 (bei Original $57) bzw. auf $32 (bei Original $53) geändert.
    Aber irgendwie hängt er sich auf. Mach ich grundlegend was falsch oder hab ich was vergessen? Ich glaube nicht, dass der Code von WoW gepackt ist. Sprites und Charset lassen sich im BIN-File finden und viele Passagen aus dem Speicher - wenn das Spiel als CRT gestartet wird - auch..


    Hier nochmal der neue Kopieraufruf (hübsch selbst gekopiert ;) )



    wizard_of_wor.bin wizard_of_wor2.bin