Hello, Guest the thread was called1.6k times and contains 28 replays

last post from enthusi at the

Projekt G-Mod wiederbeleben?

  • 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:


    Code
    1. STA $df00 ;erste acht Bits des 16-Bit Wertes im CPU Bank register ablegen und
    2. ;ersten Tabellenzugriff ankündigen (Toggle-Status auf 0 setzen)
    3. LDA $df00,x ;zweite acht Bits werden in der Adresse übertragen, und die ersten 8 Bit Ergebnis
    4. ;landen im Akku. Dieser Zugriff schaltet im Modul automatisch den Toggle-Status um,
    5. ;damit der folgende Zugriff aus einem anderen Teil der 128k-Tabelle kommt
    6. 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:


    Code
    1. STA <akku-retten>
    2. LDA #$whatever
    3. STA $df02 ;Tabellen-Bank umstellen
    4. LDA $df00,x ;drittes 8-Bit Ergebnis holen
    5. LDY $df00,x ;viertes 8-Bit Ergebnis holen


    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

  • Hey, ein flash-modul was noch billiger als easy-flash wäre fänd ich gut.


    Für schnelle Tabellen fällt mir aber jetzt nichts nützliches dazu ein. Ja, man könnte es als Kopierschutz verwenden. Aber das kann man mit "normalen" ROM-modulen eigentlich auch. Wenn man Lese- und Schreibzugriff hat (Easyflash-compatibel oder nicht), dann ist das ja eigentlich alles was man braucht.
    Entscheident ist dann der Preis denk ich. (und evlt. wie viele Pins man anlöten muss) Vorausgesetzt, man kann das Modul dann überhaupt auch als Bausatz oder "leer" kaufen.

  • Vorsicht: Es wird zwar billiger als jedes andere Flashmodul, aber es kann nur an ganz wenigen C64-Boards auch das Flash beschreiben. Für die meisten anderen Modelle ist es nur als ROM-Cartridge nutzbar - gerade deswegen habe ich doch die Entwicklung abgebrochen! Nützlich wäre es also nur für ein Projekt, das viel Rom braucht. Derjenige, der das Projekt macht, braucht halt ein 469er Board, wenn er das Modul auch beschreiben möchte (Aldi-Board).


    Preislich geht es wohl kaum weiter 'runter, denn die Platine ist extrem klein. Sie ist gerademal so groß, dass sie noch mit Ach und Krach in einem Cartridge-Gehäuse untergebracht werden kann ohne zu wackeln. Die Platinenfläche ist wirkilch minimal, denn die Form greift ineinander und wird erst mit einer zweiten Platine zum Rechteck. So ist kein Quadratmillimeter verschenkt.


    Mehr Flash geht auf keinen Fall. Anstelle des 512k-Chips kann man auch 128k nehmen, was wohl für die allermeisten C64-Spiele ausreichen dürfte. Das spart aber auch nicht viel Geld - vielleicht 50 Cent.


    Selbst bauen ist wohl nicht drin, denn das Projekt ist auf Stückzahl und auf Maschinenbestückung ausgelegt. Das würde ich machen, sobald es ein Projekt gibt. Bis dahin gibt es den Prototypen, der die Chips im Sockel hat und die eine Leitung gefädelt hat - der sollte für eine Entwicklung ausreichen (und noch einen oder zwei kann man sicher auch noch löten, aber halt keine ganze Serie).


    Jens

  • Hm, dass nicht jeder C64 das flash schreiben kann, das ist ja schon eine arge Einschränkung. Kann man da nix machen?


    Der Vorteile gegenüber "normalen" ROM-modulen ist ja eigentlich, dass man Spielstände speichern kann, usw.


    PS: Die Platine ist ja raffiniert geformt. Das nenne ich mal optimale Platzausnutzung!

  • Das FlashROM könnte man auch in einem EasyFlash1 beschreiben ;)


    Könnte man, wenn es in der Serie nicht eingelötet wäre ... ;)


    Außer Du willst es im EF1 proggen bevor es bestückt und gelötet wird :D

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!

  • Es soll ja auch kein EF ersetzen, sondern es soll ein Projekt begünstigen, das ein Spiel auf Modul herausbringen will.


    Die Produktion eines Spielemoduls ist teuer, und allein deswegen muß man schon mit Basiskosten von rund 25,- EUR rechnen. Wer dann noch etwas am Spiel selbst verdienen möchte, muß schon in Richtung 39,- EUR rechnen, und um so viel Geld für ein C64-Spiel zu verlangen, muß man schon echt einen Hammer bringen. Hier beißt sich die Katze aber in den Schwanz, denn einen solchen Hammer kannst Du nicht als 16k-Spiel bringen (16k ist die Maximalgröße eines normalen C64-Cart, welches keine Banking-Logik hat).


    Aus diesem Kreis wollte ich mit G-Mod heraus kommen: Sehr günstig zu produzieren und neben Banking-Funktion auch noch der Tabellenzugriff, der z.B. die Berechnung eines Arcustangens überflüssig machen würde (den braucht man wohl, um hidden lines, Rotationen und Clipping richtig zu berechnen).


    Jens

  • Hm, dass nicht jeder C64 das flash schreiben kann, das ist ja schon eine arge Einschränkung. Kann man da nix machen?


    Jetzt wo ich mit mehr als sechs Jahren Abstand auf die Entwicklung schaue, könnte es eine Möglichkeit geben: Du siehst auf dem Bild ein blaues Drähtchen, das die RomH-Leitung an den CPLD routet. Wenn man ein paar Unbequemlichkeiten akzeptiert, die beim initialen Beschreiben auftreten würden (also nur direkt nach der Produktion beim ersten Flashen, nicht beim User), gäbe es evtl. doch eine Chance. Ich wollte mir diesen Fädendraht eigentlich sparen, aber wenn das Beschreiben so wichtig ist, dann käme gleich noch eine Funktion hinzu, die ich noch gar nicht beschrieben habe, nämlich der VIC-Zugriff auf das Flash:


    Im Ultimax-Mode werden die oberen 4k einer jeden VIC-Bank durch Flash-Inhalt ersetzt. Hier könnte man Zeichensätze oder eine Hires-Bitmap unterbringen, wenn man nur die untere Hälfte des Screens benutzt (obere Hälfte käme aus dem RAM). Zeichensätze wären wohl das Sinnvollste, und wenn man die Hälfte des Flash für Charsets reserviert, könnte man sicher sehr effektvolle 2,5D-Spiele bauen, bei denen sich der Blickwinkel sehr flüssig ändert. Angenommen, die 2,5D-Routine greift für jeden Blickwinkel auf ein Charset zu, das auf diesen Blickwinkel ausgelegt ist, dann müsste es mit sehr hoher Framerate möglich sein, das Spielfeld zu rotieren. Man verbiegt einfach den Charset-Pointer und baut einen neuen Screen auf (max. 1000 Bytes), was ebenfalls mit einem verbogenen Pointer ohne Zeitverlust und mit minimalem Speicheraufwand möglich ist (double-buffering). Sowas wäre sicher ein Knaller, für den die Leute auch Geld ausgeben würden.


    Positiver Nebeneffekt bei Ultimax für den VIC: Das C64-Charset verschwindet aus Bank0 und Bank2. Allein dafür würde es sich doch schon lohnen, oder?


    Jens

  • Nen Versuch ist es wert. Viel Platz und alsbald werden alle anderen "intelligenteren" Supermodule eben noch ein G-Mod Cardprofil unterstützen. Eher unternehmerisches Risiko als Glaubensfrage.

  • Huh Jens,
    wie gesagt, RGCD.co.uk vertreibt Spiele ausschliesslich auf Modul.
    Als 16KB Standard (zum Teil aus der RGCD 16K Compo so es die Teilnehmer denn wuenschen) oder auch 64KB Karte (entsprechend des alten Designs von Hucky).
    Die 64KB Spiele (z.B. Quod Init Exit) werden inklusive Versand und Box und Manual fuer 25 Pfund also ca 32 eur verkauft.
    Da faellt idr sehr sehr wenig fuer RGCD selbst ab versteht sich.
    Glaubst Du, dass Dein G-Mod da interessant ist? Wenn ja, wuerde ich mich freuen wenn Du Dich bei mir oder direkt bei James/HeavyStylus meldest.
    Insgesamt fallen bei RGCD durchaus groessere Stueckzahlen an (relativ gesehen *g*).
    Martin

  • (also nur direkt nach der Produktion beim ersten Flashen, nicht beim User)

    Verstehe... Ich hatte auf eine Schreibmöglichkeit für den User gehofft. Schade schade.


    Wegen dem Ultimax-mode: ob es da jemanden gibt der dafür was programmiert? Das ist dann ja schon ein arg "entarteter" C64... :whistling:

  • Verstehe... Ich hatte auf eine Schreibmöglichkeit für den User gehofft. Schade schade.


    Wieso "schade"? Lies' nochmal genauer, denn ich glaube, dass das Flashen mit dem einen Draht zusätzlich möglich wäre, unabhängig vom Board und evtl. sogar im 128er.


    Zum Speichern von Spielständen ist das aber immer noch nicht richtig toll geeignet, denn bevor man einen Block neu beschreiben kann, muß man beim 29F040 den ganzen Block löschen. An der Stelle ist es halt blöd, dass ein Block 64KByte groß ist. Die Einschränkung hat das EF aber sicherlich auch.


    Enthusi: Habe ich Deine Mailadresse?


    Jens