Mahlzeit,
als Retro-Donald mit Frau und Kind letztens hier zu Besuch war, haben wir darüber geredet, doch evtl. das bisher wenig in der Öffentlichkeit besprochene Projekt G-Mod wieder zu beleben. Gestartet hatte ich das im Sommer 2006, hatte aber wegen Kompatibilitätsproblemen mit diversen C64 die Entwicklung gestoppt. Seit dem liegen die Platinen hier und warten darauf, irgendwann mal verschrottet zu werden (Goldschrott wird auch mehr wert...).
G-Mod sollte zunächst ein möglichst günstiges 512k-Flash Cartridge werden. Das G steht für "game" und die Platine ist bewusst *sehr* klein gehalten, damit sie günstig zu produzieren ist. Es ist nur ein CPLD und das 512k Flashrom drauf. Ursprünglich wollte ich das so bauen, dass die Daten getrennt für den Videochip und für die CPU eingeblendet werden können, aber dafür müsste man eine Patch-Leitung auf der Platine ziehen - das würde ich gern vermeiden, speziell weil man nur einen 4k großen Bereich für den VIC einblenden kann. Das könnte man nur für Zeichensatz oder Sprites nutzen, aber immerhin würden damit große Animationen möglich sein, wenn man das Banking-Register entsprechend oft umprogrammiert.
Von diesen Banking-Registern hat G-Mod drei Stück:
$df00: CPU Bank Register
$df01: VIC Bank Register
$df02: control register
Das CPU Bank register ist 8 Bit breit und ist doppelt benutzt. Die unteren 6 Bits sind für die Auswahl der Bank, die bei $8000 eingeblendet wird. Mit einer anderen Einstellung im control register kann man auch Flash bei $e000 einblenden. Die gesamten 8 Bit des Registers werden für einen "schnellen Tabellenzugriff" genutzt. Die Tabelle kann dabei 128kbyte groß sein und hat 16 input- sowie 16 output-Bits. Sowas könnte man z.B. für schnelle Multiplikation 8x8=16 Bit, wilde Sinustabellen oder Prioritäts-Geschichten nutzen, von denen ich keine Ahnung habe. Natürlich kann man nur maximal drei solcher Tabellen ablegen, denn irgendwo muß auch Code liegen 
Man wählt also im Kontrollregister mit 2 Bits die Tabelle und legt dann in A und X den 16-Bit Pointer ab. Der Zugriff auf die Tabelle läuft dann so:
- STA $df00 ;erste acht Bits des 16-Bit Wertes im CPU Bank register ablegen und
- ;ersten Tabellenzugriff ankündigen (Toggle-Status auf 0 setzen)
- LDA $df00,x ;zweite acht Bits werden in der Adresse übertragen, und die ersten 8 Bit Ergebnis
- ;landen im Akku. Dieser Zugriff schaltet im Modul automatisch den Toggle-Status um,
- ;damit der folgende Zugriff aus einem anderen Teil der 128k-Tabelle kommt
- LDY $df00,x ;hier werden die nächsten 8 Bits abgeholt und der Toggle-Status wieder genullt
Man könnte sogar die Ergebnisbreite der Tabelle vergrößern, indem man eine zweite Tabelle anlegt und diese ausliest, ohne nochmals den Schreibzugriff auf $df00 zu machen, denn der Registerinhalt bleibt bestehen, und der interne Status toggelt immer zwischen den zwei Tabellenbereichen hin- und her. Es könnte also weitergehen mit:
Ebenso wäre eine doppelt-indirekte Adressierung denkbar: Falls die ersten 8 Bit als Index für die nächsten 8 Bit dienen sollen, ist nur ein TAX notwendig, und kostet demnach extrem wenige Zyklen, weil das eine Bit im Modul bei jedem Lesezugriff toggelt.
Das funktioniert schon ganz gut, aber die Programmierer mit denen ich damals (tm) gesprochen habe, hatten wenig Anwendung für diese Tabellen-Modes. Offenbar geht es gegen die Ehre verschiedener Programmierer, Dinge abzulegen, anstatt sie auszurechnen. Ich würde es hingegen als hervorragenden Kopierschutz sehen, denn es macht Dinge auf einem C64 möglich, die mit keinem anderen Cartridge möglich sind. Jeder Crack wäre sinnlos, weil die Hardware eben "mitrechnet".
Probleme hat es in der Entwicklung gegeben, als ich das Cartridge mit den vielen C64- und C128-Versionen ausprobiert habe. Da das Cart wirklich *nur* den Ultimax-Mode nutzt, konnten nur ganz wenige Timing-Signale an den CPLD gelegt werden, was letztlich der Tod für spezielle VIC-Modi war. Außerdem konnte man nur mit bestimmten C64-Boards auf das Flash schreiben, so dass das Abspeichern eines Spielstandes nicht drin war.
Das Modul ist also jetzt reduziert auf ein Cart, das ein Modul starten kann, und das einen schnellen Tabellenzugriff hat. Für den Käufer eines Spiels sicher ausreichend, aber für mich persönlich so enttäuschend, dass ich die Entwicklung damals aufgegeben habe. Ich gebe das hier zur Diskussion, weil Retro-Donald gern Spiele produzieren möchte, und Platinen+Bauteile für kleines Geld an ihn gehen könnten.
Eventuell lässt sich an der Funktionalität noch ein wenig schneiden bzw. etwas anpassen, damit man eine Easyflash-ähnliche API realisieren kann - auch wenn es mir weh tun würde, den Tabellenzugriff zu streichen. Wenn Ihr aber keine sinnvolle Anwendung (aka "killerfeature in coolem Spiel") für eben diesen Tabellenzugriff findet, muss es wohl so sein.
Jens
