Hallo allseits,
abermals danke für Eure Antworten. Die Informationen sind sehr hilfreich!
Zum Thema IRQ: Für mein Vorhaben wäre am ehesten der 50 Hz getaktete "Timer"-IRQ sinnvoll. Defakto brauche ich aber keinen IRQ. Das Spiel läuft in einer Hauptschleife und IRQs würde vermutlich sogar eher stören. Gut auch, dass praktisch nichts einen NMI auslösen kann. Dann kann auch der nicht stören.
Dass ich mich vom Double Buffering verabschieden muss, ist schade. Um dann ein flackerfreies Bild darzustellen, das nicht vom Bildaufbau "zerrissen" wird, wäre es gut zu wissen, wo sich der Rasterstrahl jeweils in etwa befindet. Einen Register mit der aktuellen Rasterzeile wie beim VIC scheint es nicht zu geben, geschweige denn einen Raster-IRQ. Der CRTC zeigt aber in seinem Statusregister an, wann der Rasterstrahl in seiner "vertical blanking time" ist. Nicht ganz klar ist mir, ob damit der Strahlenrücklauf von rechts nach links (für die nächste Zeile) und von rechts unten nach rechts oben (für das nächste Bild) gemeint ist. Außerdem kann ich noch nicht beurteilen, wie lange der Rasterstrahlrücklauf dauert. Von Zeile zu Zeile wohl nur einige Taktzyklen. Von Bildschirmende zu Bildschirmbeginn aber ggf. auch nicht viel länger, da der CRTC ja keinen "Rand" zeichnet, wie dies der VIC tut, oder?
Ansonsten würde ich versuchen, mir die Welt so einfach wie möglich zu machen. Kompliziert wird's beim CBM II ja vor allem dann, wenn man aus einer anderen Bank den Kernel nutzen möchte. Davon verabschiede ich mich. Den einzigen Nutzen, den der Kernel bringen würde, ist die Abfrage der Tastaturmatrix. Das macht er wiederum im IRQ und somit ist auch das nur bedingt tauglich. Ich frage die Tastaturmatrix einfach selbst ab. Das sollte kein Hexenwerk sein.
Ansonsten würde ich soviel wie möglich in Bank 1 laufen lassen. Ob ich auf Bank 15 und somit den I/O-Bereich und den Bildschirmspeicher ausschließlich indirekt indiziert zugreife, bin ich mir noch nicht ganz sicher. Das wäre wohl am einfachsten, aber ggf. auch etwas langsam.
Evtl. packe ich in die 2 K RAM in Bank 15 ein paar zeitkritische Routinen, die dann etwas schneller auf den Bildschirmspeicher zugreifen können. Damit das Bankswitching unkompliziert funktioniert würde ich den identischen Code an der identischen Adresse auch in Bank 1 ablegen. So kann ich die Execution Bank ändern, ohne dass die CPU plötzlich in der Leere landet. Natürlich muss ich zuvor indiziert indirekt alle nötigen Parameter in die jeweils andere Bank schreiben, damit diese dort verfügbar sind, wenn ich wechsle. Und dann gibt's noch das Problem mit dem Stack. Auch dessen Inhalt "verschwindet" ja beim Bankwechsel. Das heißt für mich: In den Routinen, die in Bank 15 arbeiten, einfach keinen Stack zu benutzen. Also kein PHA/PLA, kein JSR/RTS. Auf diese Weise baut sich der Stack in Bank 1 auf und wird durch Code in Bank 15 auch nicht berührt. Auch der Stackpointer bleibt unberührt und zeigt nach Rückkehr in Bank 1 wieder dorthin, wo er soll. Da dort auch der Steckinhalt wieder da ist, kann ich sogar per "RTS" dorthin zurückspringen, wo ich hergekommen bin.
Und dann stellt sich noch die Frage: Wie kriegt man das alles zu Beginn geladen und initialisiert. Ich dachte da in meinem jugendlichen Leichtsinn an einen Basic-Leader, der den Objektcode jeweils per BANK XX:BLOAD "xxx" an die entsprechenden Adressen in den Banks lädt. Über eine möglichst kurze Initialisierungsroutine im 2K-Bereich in Bank 15 springe ich dann in den Code in Bank 1 ein und los geht's. Das müsste eigentlich funktionieren, oder?
Hab ich noch irgendwas vergessen?
Viele Grüße
CK
