Hallo Besucher, der Thread wurde 17k mal aufgerufen und enthält 84 Antworten

letzter Beitrag von sauhund am

Klein anfangen: ESI-artiges Cracktro in ASM nachcoden

    Hallöchen!


    In Freds wie diesem oder auch jenem wird ja über das Coden von Cracktros gesprochen. Sauhund hat irgendwo mal angeregt, meinen Demo-Maker-Pfusch mal einfach in ASM nachzucoden, unter anderem auch, um es nicht als Loader zu belassen, sondern zu lernen, wie man es vor ein Spiel linkt.


    Immerhin habe ich nun mit Relaunch64/ACME schon mal durch Codeschnipsel-Klau hier und dort etwas zusammengestellt, was mir ein Koala anzeigt und dabei eine Musik abspielt. Das meiste verstehe ich auch, aber noch nicht ganz alles. Scroll fehlt noch, dürfte aber auch nicht das Problem sein.


    Paar erklärende Worte vorweg:
    1. Die Sound-Abspiel-Routine habe ich von Herrn Bayliss/Codebase64 übernommen, obwohl ich weiß, dass seine Beiträge nicht unumstritten sind. Ich war einfach faul und habe etwas gesucht, was Musik ab $A000 abspielt, weil meine einfachere SID-Abspielroutine für andere Speicherbereiche wie etwa $1000 sich immer mit der Grafik überschnitten hat im Speicher. Daraus ergab sich dann auch die Wahl des Tracks "I_Was_Bored" von Matt Gray (mit Sid2Play als .DAT gespeichert und später mit Dir-Master-Import wieder zum PRG gemacht). Ich weiß auch noch nicht wirklich ganz genau, weshalb BASIC-Kernal hier an- und ausgeknipst werden muss. Vielleicht kann mir das jemand erläutern oder generell einen besseren Vorschlag machen?


    2. Generell bräuchte ich wohl mal einen Plan, was man tunlichst in welchem Bereich des Speichers machen sollte.


    Hier der Code

    Angehängt habe ich die exomisierte Version "Packtro", weil das cracktro.prg logischerweise durch den unzusammenhängenden Wust ziemlich groß geworden ist, deshalb hat sich auch SYS2061 ergeben.


    Freue mich über jede Form von Kommentar, bitte nicht so doll hauen, bin schließlich SEHR grüner ASM-Anfänger.

    Spontan fällt mir auf:


    -den

    Code
    1. jmp .koala

    kannst du entfernen, der verzweigt eh zum nächsten Befehl (wahrscheinlich hattest Du davor mal was anderes oder .koala lag mal nicht direkt dahinter).
    - der

    Code
    1. jmp .main

    kann auch raus, da er nie aufgerufen wird
    - aus dem jmp $ea31 kannst du ein jmp $febc machen. Die Original IRQ-Routinen brauchst Du bei Demos eigentlich nie.


    Zur Speicheraufteilung bietet sich grundsätzlich an die Speicherbereiche $1000-$2000 oder $9000-$a000 für die Musik zu nutzen, da dort keine Grafik direkt angezeigt werden kann. Aber wenn genug Speicher frei ist (so wie in Deinem Beispiel) ist das erstmal schon ok so. :)


    Für ein ESI-Intro brauchst Du aber mindestens noch einen scroller.

    Hi Ryk,


    Zitat

    Ich weiß auch noch nicht wirklich ganz genau, weshalb BASIC-Kernal hier an- und ausgeknipst werden muss. Vielleicht kann mir das jemand erläutern oder generell einen besseren Vorschlag machen?


    Das macht nur Sinn, wenn der Tune bei bei Axxx-Bxxx oder Exxx-Fxxx liegt, weil die CPU sonst stattdessen das Basic bzw. Kernal "sieht". Aber wenn der Tune wie in packtro.prg von C000-CExx geht, kann das Bankswitching weggelassen werden.


    Was die Speicherbelegung betrifft, geht im Prinzip bis auf die von lubber genannten Einschränkungen fast alles, allerdings ist es für ein Cracktro recht praktisch, alles was zum Intro gehört in einem möglichst zusammenhängenden Bereich am Anfang des Basicspeichers zu haben, weil man die VIC Bank dann nicht umschalten muss und der gepackte Crack leicht in einem Stück anzuhängen ist. Bei Sunday the 15th sollte es aber kein Problem sein, das gepackte Spiel zwischen das Koalabild und die Musik zu quetschen, so groß war das ja nicht :)

    Danke Euch beiden.


    Ich habe die überflüssigen Zeilen gekillt.


    lubber: Klar, am Scroller arbeite ich noch, bloß blöd, dass ich den wahrscheinlich auch wieder verlegen muss, Charset nach E000 vielleicht?


    @Colt: Ah ja, das erklärt es. Der Track liegt laut Sid2Play (Properties) bei $A000-$CE26, so gesehen muss der Bankswitch wohl sein, oder? <-- EDIT: Könnte sein, dass Exomizer das verlegt hat.

    Habe mir mal 'ne Mucke ausgesucht, die bei $9EFA-$CC55 liegt (Credits to Vision/Agile, Track HVSC_51-all-of-them\C64Music\DEMOS\M-R\Oxygen_4.sid), also keinen Bankswitch braucht, damit es nicht unnötig kompliziert wird. Die Musik kann also einfacher abgespielt werden und kommt auch ohne BASIC-Kernal-Kaspereien der Grafik nicht mehr ins Gehege.

    Die Frage ist jetzt, wie mit dem Charset/Scrolltext verfahren werden soll. Das Relaunch64-Beispiel haut das Charset natürlich nach $3800, wo iirc gern Charsets defaultmäßig rumdümpeln. Kollidiert leider mit dem Koala, geht also nicht. In Basic habe ich Charsets mal nach Bankswitch nach E000 geladen. Aber sehe ich nach so einem Switch denn überhaupt noch meine Grafik? Und wie müsste ich den 1x1scroll aus Relaunch64 modifizieren, damit er mit einem bei E000 geladenen Charset arbeitet? Fragen über Fragen, ich weiß :)

    Zitat

    Zur Speicheraufteilung bietet sich grundsätzlich an die Speicherbereiche $1000-$2000 oder $9000-$a000 für die Musik zu nutzen, da dort keine Grafik direkt angezeigt werden kann. Aber wenn genug Speicher frei ist (so wie in Deinem Beispiel) ist das erstmal schon ok so.


    moment mal... der witz bei einem cracktro ist doch das man was dahinter linken kann .... dann musik irgendwo hinten in den speicher zu rotzen ist keine gute idee :)


    die meissten klassischen cracktros dürften $0800 - $4000 benutzen, wenn nicht viel weniger.

    Zitat von sauhund

    moment mal... der witz bei einem cracktro ist doch das man was dahinter linken kann .... dann musik irgendwo hinten in den speicher zu rotzen ist keine gute idee :)


    die meissten klassischen cracktros dürften $0800 - $4000 benutzen, wenn nicht viel weniger.

    Ja, ok, ich dachte, ihm war das vielleicht grundsätzlich nicht bewusst. Wobei die ESI Intros eigentlich immer nachgeladen haben, oder? Also nicht wirklich vor die (OneFile)-Games gelinkt wurden.

    Zitat von TheRyk

    Habe mir mal 'ne Mucke ausgesucht, die bei $9EFA-$CC55 liegt

    Wow eine Musik die fast $3000 bytes benötigt? Da dürfte viel Overhead/Leerbytes drin sein oder eben schlecht gerippt...:)


    Zitat von TheRyk

    Die Frage ist jetzt, wie mit dem Charset/Scrolltext verfahren werden soll. Das Relaunch64-Beispiel haut das Charset natürlich nach $3800, wo iirc gern Charsets defaultmäßig rumdümpeln. Kollidiert leider mit dem Koala, geht also nicht.

    Klar geht das. Es kommt ganz darauf an, wie denn die Koala Grafik aussieht. Wenn der untere Teil vielleicht gar nicht benutzt wird , also viel leerer Bereich (oder zumindest dieselbe Farbe auf einer grossen Fläche) enthalten ist, dann kann man die Bitmap weiter für andere Dinge benutzen (also auch Code) und nur dafür sorgen, dass im Colorram und Videoram immer dieselbe Farbe liegt, sodass man den "optischem Bitmapmüll" gar nicht zu sehen bekommt. Für einen 1x1 Charset brauchst Du bestenfalls nur $0100 Bytes, wenn Du nur 32 Zeichen benutzt. D.h. die Bitmap kann locker bis $3f00 gehen. Da gehen lediglich $40 Bytes flöten also knapp 2 Cursorzeilen. Eine brauchst Du eh für die Darstellung des Scrollers. Du musst dann beim schreiben der Zeichen nicht die "echten" Buchstaben schreiben (also die Chars $00,$01 etc, sondern die letzten $e0,$e1,...)
    Ein ESI-Intro hat doch ansonsten eh meist den CBM Zeichensatz benutzt oder?


    Zitat von TheRyk

    In Basic habe ich Charsets mal nach Bankswitch nach E000 geladen. Aber sehe ich nach so einem Switch denn überhaupt noch meine Grafik? Und wie müsste ich den 1x1scroll aus Relaunch64 modifizieren, damit er mit einem bei E000 geladenen Charset arbeitet? :)

    Durch den Bankswitch per $dd00 betrachtest Du einfach den Bereich $c000-$ffff wie $0000-$3fff. Also wenn Dein Charset ab $e000 liegt, dann muss $d018 dieselben Werte bekommen, als wenn der Char bei $2000 liegen würde.

    @Sauhund: Wo der Hund Recht hat, hat er Recht, (die Sau) :):hammer: Wenn man es VOR-linken will, sollte man nicht unbedingt quer über den Speicher herumspacken, sonst ist der praktische Zugewinn gegenüber dem Demomaker gleich Null. Okay, also zurück auf Anfang mit einer extra-kurzen Mucke bei $1000, welche die Grafik nicht überschreibt und einem Programmstart bei $0801. Diese Musik ist aber viiiel zu cool für Flandertainment, das werden mir die Jungs um die Ohren hauen. Mal sehen, ob ich noch was schrägeres, ähnlich kleines ausgraben kann.


    lubber: Ich habe übrigens mit Deinem Daglish-Relocator mal versucht, die Krakout-Musik aus dem Ursprungswerk (siehe anderer Fred) rauszuziehen und den einzelnen Tune nach $1000 zu legen. Interessant, dass Du Dir mal soviel Mühe gemacht hast. Und: Heieiei, herrliche Sache, scheint zu funktionieren aber herausgekommen ist dabei leider für mich nix. Das ist ohne Doku wohl doch zu hoch für mich. Ich meine zwar, mit Deinem ersten Relocator die Speicheradressen von $E000-$F77F auf $1000 bis 277F verlegt zu haben und Tune $00 isoliert als krakout01dat.prg gespeichert zu haben. Sieht auch kleiner aus, als wenn ich den Tune nicht angebe. Aber die Parameter (außer jetzt Start $1000) für Init und Einsprung... :gruebel Siehe Disk-Image im Anhang (Habe dort krakout-in- und out-files sowie den aktuellen Cracktro-Stand draufgeschrieben). Danke für den Hinweis mit dem Scrolltext. Werde wohl ohne Charset mal irgendwo kurz vor $4000 loslegen.


    Bis dato wie gesagt wenig Neues, aber ich würde mir immer viel Code hier wünschen als Mitlesender (gibt es ja leider viel zu selten hier), deshalb der Vollständigkeit halber:

    Für heute ist erstmal Schicht. Wäre schön, wenn weiter Hilfe kommt, vielleicht ja z.B. in Sachen Krakout, scheint selbst mit entsprechender Soft ein echter Fummelkram zu sein, so ein Mehr-Tune-Sid zu zerlegen und zu relocaten :)


    N8
    Ryk

    Zitat von TheRyk

    sondern zu lernen, wie man es vor ein Spiel linkt.

    Hier schon mal ein kleiner Hint von meiner Wenigkeit:

    Linken:
    Linken bedeutet ja ersteinmal, dass ich zwei unterschiedliche Programme so im Hauptspeicher verteile, dass ich die Programme nacheinander ausführen kann. Bei kleinen ungepackten Programmen ist das zunächst überhaupt kein Problem.


    Nehmen wir zunächst ein Basicprogramm z.B. mit Zeilennummern 10-30. Wenn ich da ein zweites Basicprogramm VOR linken will, packe ich mein Programm z.B. in die Zeilen 40-60 wobei in Zeile 60 dann nach Zeile 10 gesprungen wird und ich mach noch ne Zeile 0 GOTO 40 an den Anfang. Beginnt mein ursprüngliches Basicprogramm bereits mit Zeile 0 muss ich eventuell vorher eine "RENUMBER" Routine drüberlaufen lassen oder alle Zeilennummern und Verzweigungen auf Zeilennummern per Hand ändern.


    Übertragen wir das auf Assembler: Habe ich ein kleines Assemblerprogramm, welches z.B. von $1000-$1fff im Speicher liegt, kann ich mein zweites Programm ab $2000 in den Speicher packen. Am Ende des zweiten Programmes muss ich eben JMP $1000 packen und das Ganze eben anfangs mit SYS 8192 statt SYS 4096 starten. Letzteres macht man ja in der Regel mit einer Basiczeile, damit man das Programm mit RUN starten kann.


    Problematisch wird das ganze Konzept, wenn ich zwei Programme habe, die eben nicht zusammen komplett in den Speicher passen. An dieser Stelle muss ich einen Packer bemühen.


    Packen:
    Was macht ein Packer grundsätzlich? Ein Packer codiert erstmal mit einer Packroutine (unter Verwedung eines Packalgorithmus) ein Programm, was z.B. im Bereich $1000-$1fff liegt so, dass es später gepackt (und zunächst unausführbar) z.B. nur noch im Bereich von $1000-$17af liegt. Mit einer entsprechenden Entpackroutine (welche i.d.R. vom Packer automatisch generiert und dem gepackten Programm hinzugefügt wird) kann dieses später wieder in seine Ursprungsform (und eben der Belegung des Speicherbereiches $1000-$1fff) zurückversetzt werden. Das erklärt auch, warum bei dem Versuch ein kleines Programm zu packen, manchmal das "gepackte Programm" größer sein kann, als das ursprüngliche. Kann der Packalgorithmus nicht mehr Bytes "sparen", als die Entpackroutine im Speicher verbraucht, kann das gepackte Programm auch nicht kleiner werden.


    Für das Introlinking muss man also in mehreren Schritten vorgehen:
    1.) Ich packe zunächst das Programm, vor das ich mein Intro linken will, so dass es zusammen mit meinem ungepackten Intro in den Speicher passt.
    - bei Packern kann man im Normalfall angeben, wo das gepackte Programm im Speicher liegen soll. Liegt mein Intro eben im Bereich $1000-$3fff, dann lasse ich mein Programm "nach" $4000 packen. Auf Basicstart kann ich verzichten.
    2.) Am Ende meines Intros muss ein JMP auf die Adresse stehen, bei der die Entpackroutine beginnt, welche mir mein "Hauptprogramm" entpackt. (z.B. $4000)
    3.) Ich linke mein Intro zusammen mit dem gepackten Hauptprogramm in ein File.
    4.) Ich packe wiederrum das File mit dem gelinkten Intro und dem gepackten Hauptprogramm.
    - Diesmal kann ich die Basicstart-Option des Packers ruhig nutzen, da ich vor meinem Intro ja nichts anderes mehr haben will.


    Nochmal Platz sparen kann man natürlich, wenn man beide male dieselbe Entpackroutine benutzt. Die muss natürlich so im Speicher liegen, dass sie nie überschrieben wird (oder zumindest nicht vor Beendigung des zweiten Entpackvorgangs) und vorallem, muss ich vor dem Entpacken des Hauptprogramms am Ende meines Intro die Möglichkeit haben die notwendigen Variablen für das Entpacken des Hauptprogramms an diese zu übergeben.


    Das klingt jetzt erstmal viel. Ist es im Grunde aber nicht. Bestimmt habe ich auch irgendwas vergessen oder zu allgemein formuliert. Aber ich schätze, der Grundgedanke sollte halbwegs okay sein. Wenn nicht, bitte korrigieren!

    Zitat von TheRyk

    lubber: Ich habe übrigens mit Deinem Daglish-Relocator mal versucht, die Krakout-Musik aus dem Ursprungswerk (siehe anderer Fred) rauszuziehen und den einzelnen Tune nach $1000 zu legen... Wäre schön, wenn weiter Hilfe kommt, vielleicht ja z.B. in Sachen Krakout, scheint selbst mit entsprechender Soft ein echter Fummelkram zu sein, so ein Mehr-Tune-Sid zu zerlegen und zu relocaten :)

    Ok, der Relocator 1.x braucht eigentlich ne Doku. Das war der komplizierteste.
    ...also ich habe mal entsprechend die Files relocated (mit dem tool!) und angehangen. grundsätzlich muss man folgendermassen vorgehen:


    - die gerippte Musik reinladen. Es wird automatisch erkannt, wo Tunes liegen könnten. Da das nicht sicher ist sind es meist viel mehr (ähnliche Bytefolgen) und werden als "fake" gekennzeichnet.
    - jetzt die player mit den möglichen tunes ausprobieren. Im Fall krakout hat der standard player 1 schon geklappt. Man drückt also "P" um den Player zu starten. Dann hört man erstmal nichts. Dann geht man mit "T" jede mögliche erkannte Tune-Stelle durch und erkennt dann akkustisch an manchen Stellen, dass sich eine echte Tune dahinter verbirgt.
    - Bei jeder erkannten echten Tune drückt man "(" und dann steht hinter der Tune nicht mehr "fake" sondern "REAL"
    - Ist man bei allen Tunes soweit durch speichert man das ganze (am besten gleich mit player, bein neu-reinladen im relocator ist das egal, aber natürlich nicht beim späteren abspielen ausserhalb des relocator, da braucht man schon den passenden player)
    - Das eben gespeicherte erneut reinladen. Jetzt wird automatisch die vorher per "REAL" definierte Tune-Liste erkannt und nur noch diese zur Auswahl gestellt.
    - Jetzt hat man auch die Möglichkeit einzelne Tunes separat abzuspeichern (und somit im Falle Krakout das ganze kleiner zu bekommen, wenn man z.B: nur die Titelmelodie nimmt)


    Die Abspielroutine ist prinzipiell ähnlich wie sonst. Es gibt einen INIT-JSR und einen PLAY-JSR. Der Hauptunterschied liegt beim INIT. Normalerweise gibt man da ja im Akku die Tune-Nummer an. Bei den Daglish-Player die separate Datenblocks nutzen muss man hier die Stelle im Datenblock angeben, wo die Tune gestartet wird. Und das ist bei jeder abgespeicherten Musik unterschiedlich!


    Du kannst Dir aber meinen gespeicherten Erkennungsblock zunutze machen (dasselbe, was auch der Relocator macht, wenn er "Cool! Location-List found!" sagt. Die liegt nämlich immer am Ende der gespeicherten Musik und liegt hinter dem String "lbrvarpl" Die Bytes die dahinter liegen bis zum Ende des Files sind die hi und Lo-Bytes der Datenblockstellen..... Dort muss eigentlich nur die Speicherstelle verändert werden, die hinter dem "lbrvarpl" String liegt. Die Anzahl der Bytes hinter dem String ergibt die Anzahl der gespeicherten Tunes (durch 2 teilen und 1 Byte als trenner abziehen)


    ok klingt alles kompliziert ist es aber nicht wirklich...finde ich zumindest ;) Einen fertigen Player habe ich auf die Disk gepackt. (angepasst an die gespeicherten beispiele) Die beispiele kannst Du ja mal direkt im relocator reinladen, dann sieht das schonmal freundlicher aus(und man hört auch gleich etwas)


    Übrigens, wenn Deine Musik bei $1000 liegt, brauchst Du in Deinem Code nicht mehr das Basic ausschalten, das ganze lda #$35/37 sta$01 kann dann raus.

    Zitat von lubber

    ok klingt alles kompliziert ist es aber nicht wirklich...finde ich zumindest ;) Einen fertigen Player habe ich auf die Disk gepackt. (angepasst an die gespeicherten beispiele) Die beispiele kannst Du ja mal direkt im relocator reinladen, dann sieht das schonmal freundlicher aus(und man hört auch gleich etwas)

    Ja zum Spielen hatte ich den Relocator gestern auch schon gekriegt, aber DANN WIRD es kompliziert. Die Beispiele sehen in der Tat freundlich aus nach dem Reinladen, was die "Lage" angeht, aber ein Abspielen der Files außerhalb des Relocators ist mir noch nicht gelungen. Was sind das für 1 Block große PLAYER.PRGs? Was machen die/wo liegen die/wie kann ich die aktivieren bzw. wo kann ich mir ansehen, wie diese Files aufgebaut sind?

    Zitat

    Übrigens, wenn Deine Musik bei $1000 liegt, brauchst Du in Deinem Code nicht mehr das Basic ausschalten, das ganze lda #$35/37 sta$01 kann dann raus.

    Ja, sorry, hatte aus Versehen den falschen/alten Code am Start, will Sound generell ungefähr so ansteuern:

    Zitat von TheRyk

    Was sind das für 1 Block große PLAYER.PRGs? Was machen die/wo liegen die/wie kann ich die aktivieren bzw. wo kann ich mir ansehen, wie diese Files aufgebaut sind?

    Äh, sorry, ich dachte in meinem jugendlichen Leichtsinn :) , Du hast eine Cartrigde verbaut, die Dir anzeigt wohin die Dateien geladen werden. Die Files liegen ab $c000-$c01f und können mit sys49152 aufgerufen werden. Anschauen kannst Du Dir das dann mit einem Maschinensprache Monitor

    Zitat von TheRyk

    Ja, sorry, hatte aus Versehen den falschen/alten Code am Start, will Sound generell ungefähr so ansteuern:

    Dann muss Du es nur ungefähr so erweitern:



    Die Init und Play-JSRs $1004/$1001 gelten nur für Ben-Player 1 aus dem relocator. die anderen 4 player haben unterschiedliche Einsprungadressen. Muss ich mal den alten Source rauskramen.

    Jo, das wird funktionieren. Ich habe mir allerdings angewöhnt beim Init des Tunes auch x-/y- Register zu setzen,
    da einige Player diese Register zur Auswahl des Sub-Tunes verwenden.
    Also nach dem lda#00 z.B. ein tay und ein tax.
    :winke:

    Danke, Danke, schau ich mir heute Abend an :)


    lubber: Ja, so leichtsinnig war das gar nicht. Aber das D64 auf Disk transferieren, C64 anschmeißen usw. umgehe ich faulerweise beim Coden. Nutze zum Programmieren wie gesagt PC und Relaunch64/ACME/VICE, solange es geht.