TrapThem64 - WIP

Es gibt 1.096 Antworten in diesem Thema, welches 187.975 mal aufgerufen wurde. Der letzte Beitrag (25. Februar 2020 um 20:49) ist von Vernunftmensch.


  • ich fürchte die CPU emulation ist durchaus korrekt und auch viele "offizielle" demos und programme stürzen mal ab. ansonsten nenne doch mal ein konkretes beispiel, dann liesse sich diese behauptung leicht überprüfen.


    Das sollten wir dann aber in einem eigenen Fred machen.

  • Du kannst lesen ? O_0

    Ihr habt beide zwei unterschiedlich große Augen? o_O

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: 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.

  • Das sollten wir dann aber in einem eigenen Fred machen.


    noch lieber auf dem Bitte melde dich an, um diesen Link zu sehen.


  • ich fürchte die CPU emulation ist durchaus korrekt und auch viele "offizielle" demos und programme stürzen mal ab. ansonsten nenne doch mal ein konkretes beispiel, dann liesse sich diese behauptung leicht überprüfen.


    Ich weiß, dass es nicht die CPU Emulation sein muss, das war nur so 'ne grobe Richtung um sich das vorstellen zu können 'was passiert.
    Demos stürzen nicht ab, das passiert bei mir nur auf nicht 100% working Cevis, seltsame Behauptung.. . Es werden ja keine non working Demos etc. released.
    Es passiert zudem jeweils immer genau an den gleichen Stellen, als ob ein Befehl auftritt, den der Emu nicht verarbeiten kann.

    Sobald ich Bsp. habe, werde ich das 'mal posten, das habe ich ja schon gesagt (dass ich da im Moment leider kein Bsp. im Kopf habe), brauchst das also nicht extra noch vorwerfen.

    Kann aber auch sein, dass das ganze nur an abgeschalteter "true Floppy Emulation" lag und beim bzw. nach dem Nachladen auftritt.
    Normalerwise merkt man ja, ob ein Prg. bei abgeschalteter Floppy Emulation startet und läuft aber wenn manches erst normal durchstartet und erst später abstürzt, schiebt man es erstmal nicht sofort auf die nicht eingeschaltete Floppyemulation.
    Wie auch immer, ich werde beim nächsten Fall 'mal diese paar Eventualitäten durchprobieren.. und berichten.

  • $00ff bis $0400 Erweiterte Zeropage (1kb)

    Dir ist klar, dass bei $100-$1ff der Hardwarestack der CPU liegt? Den Bereich kannst du nur nach Belieben benutzen, wenn du in deinem Programm auf Befehle wie pha, php etc. und jegliche Form von Interrupts komplett verzichtest.

    Edit: und JSR/RTS geht natürlich auch nicht.

    Kann aber auch sein, dass das ganze nur an abgeschalteter "true Floppy Emulation" lag und beim bzw. nach dem Nachladen auftritt.

    Da heutzutage praktisch alle Nachladedemos einen Schnelllader eingebaut haben funktionieren die ohne Truedrive-Emulation so gut wie nie, und selbst mit TDE je nach sonstigen Einstellungen auch nicht immer (wenn man z.B. Vice so konfiguriert hat, dass noch n zweites Peripheriegerät am IEC-Bus hängt).

  • Zitat

    Dir ist klar, dass bei $100-$1ff der Hardwarestack der CPU liegt?

    Jupp, sonst hätte ich geschrieben, wozu ich den Bereich selbst direkt nutze. :) Aber der Bereich heißt Erweiterte ZP, das habe ich nur einfach brav übernommen.

    Zitat

    Ich weiß, dass es nicht die CPU Emulation sein muss, das war nur so 'ne grobe Richtung um sich das vorstellen zu können 'was passiert.

    Ich bin über die Warp-Funktion des Vices sehr froh. So, kann ich gezielt nach "zufälligen" Bugs suchen und finden. Aber da bin ich übrigens auch nicht bedingungslos naiv. Ich habe öfters den Fall, daß ich ohne Zufallsgenerator einen Bug durch Menüführung nur in einen von drei Fällen bekomme. Das kann ich mir dann programmtechnisch nicht 100% erklären. Man müßte meinen, daß durch die Vorbestimmtheit immer alles immer reproduzierbar sein müßte.

  • Zitat

    Kann aber auch sein, dass das ganze nur an abgeschalteter "true Floppy Emulation" lag und beim bzw. nach dem Nachladen auftritt.


    ... oder ein sonstiger bedienfehler vorliegt. richtig, das ist wesentlich warscheinlicher als das ein bug im emulator das problem wäre.

    Zitat

    Aber der Bereich heißt Erweiterte ZP, das habe ich nur einfach brav übernommen.


    $0200 bis $03FF ist die sogenannte "erweiterte zeropage" - der stack gehört nicht dazu

  • Jupp, sonst hätte ich geschrieben, wozu ich den Bereich selbst direkt nutze. :)


    Dann ist ja gut, ich dachte nur es könnte nicht schaden, da zur Sicherheit nochmal drauf hinzuweisen :)

  • Danke für die Hilfe. Hier der endgültige Speicherbelegungsplan:

    Speicherbelegungsplan TrapThem64

    $fffe bis $ffff IRQ-Vektor (2 Bytes)
    $fec0 bis $fffd Frei (62 Bytes)
    $fcc0 bis $febf Feste Blöcke für die acht Sprites. (64*8 Bytes)
    $fa40 bis $ffbf Explosionsspriteanimation (10 Einzelbilder).
    $f950 bis $fa3f Kleine Spritesanimationen (30 Einzelbilder).
    $f550 bis $f94f Zeitzündersprites (256 Kleinzahlen)
    $f470 bis $f54f Erw. Viechdatenblöcke (7 reale Sprites).
    $f000 bis $f46f Markierungsstack (1.136 Bytes)
    $e800 bis $efff Bildzeichensatz (2kb)
    $e400 bis $e7ff Einfrierbildschirm mit Anhang (1kb)
    $e000 bis $e3ff Sichtbarer Bildschirm mit Anhang (1kb)
    $dc00 bis $dfff Spezialleveldaten (1.024 Bytes)
    $d800 bis $dbff Beißeraufwachfeld mit Zusatzinformation (1.024 Bytes)
    $d400 bis $d7ff Drehervierrichtungsfeld mit Zusatzinformation (1.024 Bytes)
    $d000 bis $d4ff Diamantenanzahlfeld mit Zusatzinformation (1.024 Bytes)
    $cbe8 bis $cfff cc65-Stack (1.048 Bytes)
    $c800 bis $cbe7 Zustandsfeld (1.000 Bytes)
    $1b00 bis $ctff Oberer Spielcode (44.288 Bytes)
    $0ffe bis $1aff Musik (2.818 Bytes)
    $07ff bis $0ffd Unterer Spielcode (2.047 Bytes)
    $0400 bis $07fe Startfeld mit Auswahlspriteanhang (1kb)
    $0200 bis $03ff Erweiterte Zeropage
    $0100 bis $01ff Prozessorstack
    $001c bis $00ff Zeigerspeicher (227 Bytes)
    $0000 bis $1b cc65-ZP (28 Bytes)

    $e000 bis $ffff Kernal (Über $1 zu schalten)
    $d800 bis $dbe7 Zusätzlicher Farbspeicher (IO)
    $d000 bid $dfff IO (Über $1 einzuschalten)
    $0ffe bis $1aff Levelstart (Codeein u. -auslagerung über Diskette)
    $0400 bis $07ff Sichtbarer Bildschirm (Im Tausch mit $e400 während Menüführung)

  • Der Trick ist, diesen Plan nicht dem Forum, sondern Deiner Entwicklungsumgebung beizubiegen!

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ich habe das schon mal gefragt:

    $1b00 bis $ctff Oberer Spielcode (44.288 Bytes)

    Wie kann das sein?

    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. ~ 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.

  • Der Tippfehler war mir jetzt nicht so wichtig. Ich möchte wissen, wie man 2/3 des Speichers mit dem Spielcode voll bekommt - zumal für das, was man bis jetzt sehen kann.

    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. ~ 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.

  • Zitat

    Der Tippfehler war mir jetzt nicht so wichtig. Ich möchte wissen, wie man 2/3 des Speichers mit dem Spielcode voll bekommt - zumal für das, was man bis jetzt sehen kann.

    Achso, das ist ganz einfach erklärt. Wenn Du in C erstmal alles schreibst, dann wunderst Du Dich, wie wenig Platz das wirklich ist.

    Sind dann die Grenzen erreicht, dann wandelst Du nach und nach alles um in ASM, um in den Grenzen zu bleiben.

    Deswegen haben meine Programme alle immer die maximal mögliche Anzahl von Blöcken. Deine Frage ist berechtigt, wurde immer schon gefragt, wie ich das mit den vielen Blöcken auf der Diskette hinkriege.

    Die Menüführung (die aktuell ein SEI/CLI Bug irgendwo hat und zu zufälligen Bugs führt) ist immer noch komplett in C, weil ich auch in ASM nur etwas umwandel, wenn ich genau weiß, daß ich es so lassen möchte.

    Danke der Nachfrage wegen. :)

  • Ich habe öfters den Fall, daß ich ohne Zufallsgenerator einen Bug durch Menüführung nur in einen von drei Fällen bekomme. Das kann ich mir dann programmtechnisch nicht 100% erklären. Man müßte meinen, daß durch die Vorbestimmtheit immer alles immer reproduzierbar sein müßte.

    Sobald Benutzereingaben hinzukommen, nicht mehr. Du kannst ja die Zeit, zu der der Benutzer eine Taste drückt, nicht zyklusgenau nachstellen. Deshalb ist der Füllgrad des Tastaturpuffers nicht reproduzierbar, und somit auch nicht die Stellen im Programm, an denen der nächste Timer-Interrupt zuschlägt.
    Und wenn Du dann noch Fehler im Interrupt-Handler hast, oder im Zusammenspiel von Interrupt und Hauptprogramm, kann sonstewas passieren.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..