Easyflash Games - Echte Anpassungen

Es gibt 2.489 Antworten in diesem Thema, welches 484.143 mal aufgerufen wurde. Der letzte Beitrag (13. November 2025 um 11:34) ist von He-Man1982.

  • Ich glaube ich muss mal wieder einen Grundkurs Internet Suchmaschinen geben....

    Ja, mein Google Fu ist leider nicht das beste. :schande:

    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.

  • Ich glaube ich muss mal wieder einen Grundkurs Internet Suchmaschinen geben....

    Wieso?

    Die Suche hat doch perfekt funktioniert --> gHost hat hier gepostet (=Suchanfrage) und die Suchmaschine (=Du) hat das Ergebnis präsentiert :-).

  • Ich habe mal X-Men an das Easyflash angepasst. Beim testen bin ich leider nicht sehr weit gekommen.

    Folgendes gibt es noch zu sagen. Die Easyflash Routine befindet sich ab $0334 bis etwa $03EA und von $0100 bis $0160 im Stack. Leider war überhaupt kein RAM

    mehr frei. Falls es wegen der Adressen, wo der Easyflash Code liegt, zu Probleme kommt, mir hier Bescheid geben, mit einen Snapshot von WinVice v3.2.:)

    Ich werde dann einen anderen Platz im RAM suchen müssen.

    Ach ja, die Save-Funktion läuf leider nur mit einer Diskette in Laufwerk 8 aufgrund üblen RAM-Magel

  • Übrigens ich versuche das Spiel auch an das Magic Desk anzupassen. Habe die Quellcodes von Jokers Magic Desk Anpassungen untersucht und analysiert.

    Wie ich feststellen musste, werde die zusammengelinkten Dateien von $000000 bis Ende durchadressiert. Laut Direktory gibt es nach 64kb einen Bankwechsel.

    Der wird intern auf eine 8kb Adresse beginn ab $8000 bis $9FFF umgerechnet. Muss das so sein oder kann ich gleich die 8kb Adressen im Magic Desk Directory angeben.:)

    Oder habe ich die totale Kontrolle, wie ich das Directory, mit welchen Einträgen, gestalte. Und auch wo es im ROM liegt?


  • Übrigens ich versuche das Spiel auch an das Magic Desk anzupassen. Habe die Quellcodes von Jokers Magic Desk Anpassungen untersucht und analysiert.

    Wie ich feststellen musste, werde die zusammengelinkten Dateien von $000000 bis Ende durchadressiert. Laut Direktory gibt es nach 64kb einen Bankwechsel.

    Der wird intern auf eine 8kb Adresse beginn ab $8000 bis $9FFF umgerechnet. Muss das so sein oder kann ich gleich die 8kb Adressen im Magic Desk Directory angeben.:)

    Oder habe ich die totale Kontrolle, wie ich das Directory, mit welchen Einträgen, gestalte. Und auch wo es im ROM liegt?



    Not sure what you are trying to do, but changing your EasyFlash to MD should be easy. Things to remember:

    8kb banking instead of 16kb, so swap bank at $9fff instead of $bfff

    MD doesn't have $de02 register, so you can't easily turn on/off the cartridge over $8000. Use $01 as #$36 if possible instead

    If you set $de00 to #$80 you permanently disable the cartridge (except in special cirumstances at a harder jumper level)

    You can't save back to the cartridge at all

    Always build a 512kb binary and use cartconv otherwise the smaller images have different banking methods

  • Ich habe mal X-Men an das Easyflash angepasst. Beim testen bin ich leider nicht sehr weit gekommen.

    Folgendes gibt es noch zu sagen. Die Easyflash Routine befindet sich ab $0334 bis etwa $03EA und von $0100 bis $0160 im Stack. Leider war überhaupt kein RAM

    mehr frei. Falls es wegen der Adressen, wo der Easyflash Code liegt, zu Probleme kommt, mir hier Bescheid geben, mit einen Snapshot von WinVice v3.2.:)

    Ich werde dann einen anderen Platz im RAM suchen müssen.

    Ach ja, die Save-Funktion läuf leider nur mit einer Diskette in Laufwerk 8 aufgrund üblen RAM-Magel


    Nah, there is always memory available. Think differently. You have some bytes available in $df00 that never get smashed by the eAPI call this LEVER (IN/OUT). Find a constant static area, or use constant screen ram call this BUFFER. In your LOAD/SAVE routines:

    . Call LEVER IN to move your LOAD/SAVE code to BUFFER.

    . Do the magic

    . Call LEVER OUT to move your constant static area back to BUFFER


    BUFFER cannot be between $8000-$BFFF as it will vanish as soon as you activate the cartridge

  • I know all the registers for a long time. $DF00 $01 to $07 = 8 KB banks and $80 MD off. I was referring to the MD module "Alien Storm."

    At the beginning of the card is a directory used by the routine. In the directory, the bank is changed from $00 to $01 after 64 KB.

    See code window.

    File "S3" at MD to find at $48 $0A $01 low, high, bank

    File "SC" at MD to find at $88 $1A $01 low, high, bank

    File "SS" at MD to find at $48 $77 $01 low, high, bank

    File "T1" at MD to find at $48 $A5 $01 low, high, bank

    to

    File "T4" at MD to find at $80 $EB $01 low, high, bank

    File "VA" at MD to find at $6F $17 $02 low, high, bank

    You see, the addressing has 64kb. What I just wanted to know is whether there is another way to do it.

  • Thank you very much for the tips.:thumbsup:

    I set $01 to #$33. This means I can write to the entire 64KB of RAM without changing much of $01. I don't know if your tips works with $01 set to #$33

    Let me know if your tips work then.:)

  • Übrigens ich versuche das Spiel auch an das Magic Desk anzupassen. Habe die Quellcodes von Jokers Magic Desk Anpassungen untersucht und analysiert.

    Wie ich feststellen musste, werde die zusammengelinkten Dateien von $000000 bis Ende durchadressiert. Laut Direktory gibt es nach 64kb einen Bankwechsel.

    Der wird intern auf eine 8kb Adresse beginn ab $8000 bis $9FFF umgerechnet. Muss das so sein oder kann ich gleich die 8kb Adressen im Magic Desk Directory angeben.:)

    Oder habe ich die totale Kontrolle, wie ich das Directory, mit welchen Einträgen, gestalte. Und auch wo es im ROM liegt?


    Lieber Stephan, das basiert auf dem T64 File Format und ich war zu faul, Tools zu schreiben, die das in was sinnvolleres konvertieren, sondern hab lieber Code geschrieben, der das T64 Directory versteht.

    Bitte melde dich an, um diesen Link zu sehen.

  • Ahhh, da muss man erstmal drauf kommen. Ich habe mich gewundert, als ich das sah.:lol33:

    Vielen Dank für die Aufklärung. Dann kann ich ja en Direcltory nach meinen Wünschen kreieren. Zum Beispiel Filename 16 Zeichen, wenn benötigt, sonst kleiner, low byte, high byte, bank byte adresse im MD.

    low byte und high byte c64 adresse und dateilänge in low und high byte. Ist jetzt nur ein Beispiel.:)

  • Ich hätte es auch nett gefunden (war aber auch nicht verlangt) wenn The Joker in seinen Sourcen einen Verweis auf meine Webseite gepackt hätte. Dann hättest du das früher gefunden.

    Wenn du bei deinen Optimierungen ein Tool baust, das dir das "bessere" Directory baut, lass von dir hören. Dann kann man das alles weiter optimieren und noch mehr MD Module erstellen. Theoretisch kann man damit alle D2EF Sachen recht flott umbauen, richtig lohnen tut sich das aber nur wenn nicht komprimierte Dateien "nachgeladen" werden, die Dekompression ist ja nur nötig um alles auf eine Diskseite zu packen, und diese Grenze haben Module (fast) nicht (bis auf Vice 2.X, siehe mein Text).

    Viel Vergnügen, Boris!

  • Da bin ich die ganze Zeit bei. Wenn das Tool fertig ist, lade ich es hier im Forum selbstverständlich hoch, wie alle meine Quellcodes.:)

    Wäre es nicht auch pfiffig, die sourcen auch in einzelen öffentliche github/gitlab repositories zu veröffentlichen?

    Dann gäbe es einen zentralen Ort, an dem alle die zu finden sind (inkl. der Möglichkeit der Kollaboration). Bei Veröffentlichung hier im forum "gehen die unter", denn da ist mal hier an einem Post ein Archiv mit dran oder an einem anderen post, also quasi "scattered all over the place" und man muss es sich mühsam zusammen suchen.

    just my 2 złoty.

  • Da bin ich die ganze Zeit bei. Wenn das Tool fertig ist, lade ich es hier im Forum selbstverständlich hoch, wie alle meine Quellcodes.:)

    Dazu gehören auch ausgiebige Tests. Das Testen und Debugen, dauert meistens am längsten. Wenn alle Tests bestanden sind, wird es Zeit das Tool hochzuladen.:)

  • Ich hätte es auch nett gefunden (war aber auch nicht verlangt) wenn The Joker in seinen Sourcen einen Verweis auf meine Webseite gepackt hätte. Dann hättest du das früher gefunden.

    Wenn du bei deinen Optimierungen ein Tool baust, das dir das "bessere" Directory baut, lass von dir hören. Dann kann man das alles weiter optimieren und noch mehr MD Module erstellen. Theoretisch kann man damit alle D2EF Sachen recht flott umbauen, richtig lohnen tut sich das aber nur wenn nicht komprimierte Dateien "nachgeladen" werden, die Dekompression ist ja nur nötig um alles auf eine Diskseite zu packen, und diese Grenze haben Module (fast) nicht (bis auf Vice 2.X, siehe mein Text).

    Viel Vergnügen, Boris!

    Das denke ich auch. Und ich hätte meinen Monitor, aufgrund der Verwunderung, nicht mit Kaffee vollgemacht.:)

  • Ich hoffe der Kaffee ging wieder rückstandsfrei runter. Cheers!

    Wegen Github: Theoretisch kann man das da einfach hochpacken, aber da ich keine Build-Tools nutze die Github irgendwie supporten wäre das halt auch nur ein File-Archiv.

    Cheers, Boris

  • Ich hoffe der Kaffee ging wieder rückstandsfrei runter. Cheers!

    Wegen Github: Theoretisch kann man das da einfach hochpacken, aber da ich keine Build-Tools nutze die Github irgendwie supporten wäre das halt auch nur ein File-Archiv.

    Cheers, Boris

    Ein File-Archiv reicht auch völlig aus. Danke für die Info.

    Und nein, ich habe den Monitor mit einem nassen tuch abgewischt. Unbemerkt lief Wasser in den unteren Rand, da wo das LCD-Panel verschwindet.

    Nach einer kurzen Zeit began sich dort ein Fraßloch zu bliden, auf dem keine Bildinformation mehr dargestellt werden konnten. Ich denke mal, das hat was mit der Beschichtung zu tun.

    Tija, man sollte den Monitor immer abschalten, wenn man selbigen reinigt. Hinterher ist man immer schlauer. Das aber hat nichts mit schläue zu tun, eher mit Faulheit.

    Ich habe dann ein dünnes Stück Pappe zwischen Monitor und LCD-Panel geschoben, und schon war die Beschädigung fast verschwunden.:puhh:

  • Ich hoffe der Kaffee ging wieder rückstandsfrei runter. Cheers!

    Wegen Github: Theoretisch kann man das da einfach hochpacken, aber da ich keine Build-Tools nutze die Github irgendwie supporten wäre das halt auch nur ein File-Archiv.

    Cheers, Boris

    Versionierung ist doch unabhängig vom build Prozess: Es geht ja bei Versionierung darum, dass Du (für Dich z.B. nach einem halben Jahr) noch nachvollziehen kannst, was Du warum gemacht hast.

    Also z.B. ein commit mit "Ergänze zusätzliches NOP, weil 2 extra Taktzyklen auf $DING gewartet werden muss" oder irgendwas in der Art. (Ob jetzt DE oder EN ist erstmal Latte). Die Verwendung von Versionierung/commits erspart einem so einen fröhlichen Dateihaufen ala "fast_routine-01", "fast_routine-02", "fast_routina-02b" wo man nach einer Zeit keinen Überblick mehr hat, was denn der Unterschied zwischen den einzelnen Dateien ist :)