Mitarbeiter für C128-CPU-Upgrade-Projekt gesucht

Hallo,

der erste Post und gleich sowas Ja, als Besitzer einer SuperCPU 128 kann man zwar stolz sein, aber so richtig viel hat man nicht davon. Es gibt außer GEOS und Metal Dust keine Software, und einfach programmieren kann man das Ding auch nicht. Verbreitet ist das Ding auch nicht, und die 20 MHz braucht man auch kaum. Deshalb geht mir schon seit langem ein Projekt durch den Kopf, wie man günstig den C128 pushen kann. Und das ist machbar.

Also, die Anfangsidee ist es, den 8502 durch eine Kombination durch 65C816 und einem 6526 zu ersetzen, Ruud Baltissen hat eine Schaltung dazu gemacht. Vielleicht geht auch ein 8520 vom Amiga, das wäre praktisch, da es den und auch den 65C816 in PLCC-Bauweise gibt. Das spart Platz. Anschließend müssen noch die Adressleitungen demultiplexed werden, dann hat man schon mal die Möglichkeit für bis zu 16 MB RAM, ROM und zusätzliche Hardware. Tja, wenn man nun den 8502 durch einen 65C816 ersetzen kann, dann geht das doch auch mit einem 6510? Im C64-Modus wird doch viel mehr programmiert. Stimmt. Allerdings eignet sich der C64 nicht so gut für die Aktivierung des 16bit-Modus, da es im Kernal-ROM keinen Platz mehr gibt. Man muß also erst herumpoken. Im Kernel-ROM und im Basic-ROM des C128 ist so viel Platz frei, da kann man sinnvolle Systemroutinen wie die Umschaltung in den 8- oder 16bit-Modus oder neue 24bit-Laderoutinen direkt mit integrieren. Beim C64 müßte man erst manuell in den 16bit-Modus schalten, die neuen Routinen müßten dann im Bereich über $FFFF liegen.

Der 65C816 hat einige interessante Anschlüsse, z.B. den Emulation-Pin, mit dem angezeigt wird, ob er sich im 8- oder 16bit-Modus befindet. Also könnte man durch eine Duo-Power-LED sofort den Modus erkennen. Für die Breite der Register gibt es ähnliche Ausgänge. Besonders erwähnenswert ist der ABORT-Pin - wenn dieser auf Low gelegt wird, springt er im 8bit-Modus zu einer Adresse, die in $FFE8 und $FFE9 abgelegt ist, für den 16bit-Modus liegt die Adresse in $FFF8 und $FFF9. Damit kann der ABORT-Pin als eine Art interner Freezer verwendet werden. Im 8bit-Kernel des C128 sind diese Adressen aber glaube ich belegt, keine Ahnung, ob man das ROM so umprogrammieren kann, daß diese Adressen wieder frei werden. Bei einem abgeschalteten 8bit-Kernel kann man diese Adressen aber wieder belegen, und ein Programm per Hardwaretaste steuern. Das kann eine Rückkehr in ein Hauptmenü sein oder für Programmierer ein Sprung in den Maschinensprachemonitor oder den Assembler. Das ist halt der Vorteil, wenn man viel Speicher hat und das System von Grund auf neu aufbaut - man kann sich Programmierhilfen einbauen, die der normale C128 nie hatte.

Die Entwicklung des neuen Kernels wird übrigens die Hauptarbeit sein, denn mit diesem Board soll der C128 das bekommen, was die SuperCPU nie hatte - einen 16bit-Kernel und ein 16bit-BASIC. Ich habe mir schon einige Gedanken dazu gemacht. Der Bereich in der zweiten echten 64K-Bank ab $10000 beginnt mit der 'HighPage', einer Zeropage, die sich im hohen Bereich abspielt. Sie ist allerdings nicht wie im C128 angeordnet, sondern wie im C64, das macht es Programmierern vielleicht leichter. Allerdings müssen sämtliche Adressangaben auf einen 24bit-Adressraum erweitert werden. 64K RAM sind für die HighPage vermutlich zuviel, also könnte man ein 32K-RAM nehmen und die zweite Häfte für sinnvolle Hardware verwenden, z.B. ein dauerhaft vorhandener zweiter oder dritter SID, einen Massenspeicher oder evtl. für einen zusätzlichen Videocontroller - mir gefällt der Yamaha V9990, der Nachfolger des Grafikchips der MSX-Computer. Für einen Retro-Rechner wäre er gut geeignet, er hat mehrere Textmodi, viele Grafikauflösungen, hat jede Menge Sprites und bietet in den meisten Modi 64 Farben aus 32.768 an. Zwei Modi mit 640x400 und 640x480 in 16 Farben ohne Interlace gibt es auch. Klar, 64 Farben hört sich etwas wenig an, aber das sind immerhin vier mal mehr als man beim VIC hat. Der V9990 unterstützt glaube ich 512 KB VRAM, Zeichensatz-ROM's und einen Extra-Zeichensatz für einen Kanji-Font. Der Ausgang ist RGB-Analog, eine Genlock-Funktion und einige andere Sachen bietet der Chip auch noch.

Was notwendig ist, ist ein 24bit-Dateiformat und entsprechende Laderoutinen. Da habe ich auch schon einige Ideen, vor allem, daß es nicht möglich ist, sie mit einem Standard-LOAD-Befehl zu laden. Das ist auch wieder ein gutes Beispiel, weshalb der C128 besser geeignet ist - die Laderoutinen können direkt im 8bit-Kernel eingebaut werden, da er genug Platz dafür hat, und auch für neue Kommandos im BASIC-ROM ist Platz. Das wären dann z.B. HLOAD und HSAVE.

Der 16bit-Kernel soll sehr umfangreich sein und den originalen C128-Kernel komplett ersetzen können. Dann kann man ihn und das BASIC im 8bit-Adressraum abschalten und hat so viel Platz für VIC- und SID-Daten. Dafür ist der 65C816 natürlich bestens geeignet - durch seine Block-Copy-Befehle lassen sich schnell Daten in den 8bit-Adressraum jagen. Richtig gut wären Kernel-Routinen, die man in einem 8bit-Rechner nie erwarten würde, z.B. fraktale Routinen, mit denen man Objekte oder 3D-Grafik wie in Rescue on Fractalus oder The Eidolon erstellen kann. SID, VIC und VDC sollten am besten Routinen bekommen, wie sie in heutigen Demos vorkommen. Dazu sollte auch der erweiterte VIC-IIe des C128 ausgenutzt werden, mit dem 1.3 MHz-Modus, dem Öffnen des Borders ohne Sprites, dem Trick mit den 11 neuen Farben und natürlich die Nutzung des Interlace-Modus mit 160x400 oder 320x400 Punkten. Auf Basis des neuen Kernels wird dann das 16bit-BASIC entwickelt. Ob es nun kompatibel zum 8bit-BASIC ist oder ob Dateien konvertiert werden müssen, muß man sehen. Programme und Variablen des 16bit-BASIC sollten aber auch nur im hohen Bereich liegen, damit man die untersten 64k für Grafik und Sound frei hat. Durch die Ausnutzung der neuen Befehle des 65C816 wird man sicher etwas Geschwindigkeit herausholen - und heutzutage kann man die Rechner ja besser programmieren als vor 30 Jahren.

Die Entwicklung einer 65C816-Upgrade-Karte für den C128 könnte funktionieren. Wenn man den originalen Prozessor rauswirft und dafür einen 65C816 nutzt, ohne auf mehr Geschwindigkeit Wert zu legen, hat einen ziemlich kompatiblen Computer. Illegale Opcodes kommen ja nur in wenigen Programmen vor. Die neue Hardware dürfte sich in Grenzen halten, die Größe der Platine auch, den 65C816, 8520 und 65C22 gibt es auch als PLCC-Versionen. Ich habe auch FlashRAM's und S-RAM's in DIP-Bauweise gefunden. Also könnte man sich die ganze Sache noch selbst löten, und es müßten nur die Platinen produziert werden. Der Hauptaufwand liegt halt in der Programmierung des neuen Kernels und des BASIC, aber das wird das wichtigste daran sein. Denn nur Hardware zu liefern, aber keine Möglichkeit, sie zu nutzen, bringt nichts. Das kennen wir ja von der SuperCPU und der Flash8.

Vielleicht hat ja mal jemand Interesse an dem Projekt. Mir spukt die Idee schon seit Ewigkeiten im Kopf herum, aber ich kenne niemanden, die was mit Hardware am C128 machen oder ihn programmieren können. Die Idee, einen neuen Kernel mit den heutigen Programmiertechniken, einem besseren Prozessor mit optimierten Befehlen zu entwickeln, wäre schon interessant. JiffyDOS hat ja aus dem C64 und C128 einen ganz anderen Rechner gemacht, obwohl nur wenig geändert wurde. Was könnte man aus dem Rechner dann erst mit einem komplett neuen Kernel machen, der ohne jede Vermurksung von Commodore und Microsoft auskommt?

Schöne Grüße, RAM.

Also ich schreibe jetzt mal ohne alle Quotes neu zu zitieren.

-trb-

Das JiffyDOS aus dem C64 einen neuen Rechner gemacht hat, meine ich weil man damit kaum noch auskommt. Ich mußte mich mal wieder mit einem C64 ohne JiffyDOS abquälen, allein der Laufwerkswechsel war da Frust.

Zum Dreifach-Quote Neuer Kernel, neuer Videocontroller: Klar, es ist kein C128 mehr, aber wieviel native Software gibt es für den C128? Es läßt sich durch sein größeres ROM allerdings ein 16bit-System so einbauen, daß es direkt nach dem Einschalten zur Verfügung steht. Der Rechner startet im 8bit-Modus (Emulation Mode des 65C816) und ist somit bis auf die illegalen Opcodes zum C64- und C128-Modus kompatibel. Der Modus wird durch zwei Opcodes gewechselt:

16bit:

CLC (Clear Carry)
XCE (Exchange Carry with Emulation)

8bit:

SEC (Set Carry)
XCE (Exchange Carry with Emulation)

Anschließend noch ein RTS. Der 65C816 hat hinter dem Carry-Flag noch das Emulation-Flag, im 8bit 6502-Emulation-Modus ist es gesetzt, im 16bit-Modus nicht. Man muß also das Carry-Flag setzen oder löschen, der Befehl XCE tauscht den Inhalt dann mit dem des Emulation-Flags. Diese Befehle lassen sich ohne Probleme im C128-Kernal-ROM einbauen, dazu im BASIC die Befehle 8BIT und 16BIT. Das ist die Grundlage, um den 65C816 voll zu nutzen. Im C64-Modus ist im Kernal kein Platz für solche Routinen, also müßte man erst ein kleines Programm laden, daß den 16bit-Modus aktiviert. Die Lösung finde ich nicht so toll.

Die SuperCPU hat deshalb nicht funktioniert, weil wenig zur Verfügung stand: Kein BASIC, kein guter 65C816-Assembler, unter GEOS haben nicht allzuviele programmiert, erst recht nicht unter GEOS 128 mit SuperCPU. Da die Dinger zu teuer und kaum zu bekommen sind, kann man die also vergessen. Die 20 MHz nutzen auch nicht viel mit Standardsoftware, da die Kompatibilität nachläßt und eine Geschwindigkeitssteigerung von 2000% eigentlich Quatsch ist. Selbst die 800% der Flash8 waren schon irre, GEOS ging ab wie sonstwas. Aber: Ein Spiel wie Metal Dust könnte man mit einer REU bestimmt auch auf einem normalen C64 programmieren, allerdings ohne Digi-Sound.

Illegale Opcodes mögen in Demos vielleicht vorkommen. Aber die braucht man möglicherweise gar nicht, da der 65C816 ja jede Menge neue Befehle hat. Trotzdem muß man umdenken, da man nun 3-Byte-Adressen verwenden muß. Aber gut 15 MB für Programmcode und Daten, dazu knapp 50K für SID- und VIC-Daten, die per Block-Move-Befehle direkt schnell verschoben werden können, macht das schon interessant. NUVIE's laufen ja schon mit einer REU gut, trotzdem ist sie immer noch langsamer und unkomfortabler/unflexibler als echter, vom Prozessor ansprechbarer Speicher.

Mit den neuen Routinen meine ich natürlich Sachen, die zwar vielleicht aus der Demoszene stammen könnten, aber trotzdem in normalen Programmen verwendet werden können. Routinen in der effektiven Programmierweise könnten die Grafikdarstellung wesentlich verbessern oder beschleunigen. Beispiele mit begrenzter Anwendung könnten auch vorkommen, z.B. Kernel-Routinen zur Ausgabe von Digis auf dem SID. Oder Routinen zum Anzeigen von Standard-Bildformaten, Koala, HiRes, FLI-Varianten, BMP, GIF, vielleicht noch IFF vom Amiga. Das hört sich zwar erst unsinnig an, macht aber Sinn: Man kann die Vorteile eines PC-Grafikprogramms oder DeluxePaint nutzen, um C64-Grafiken zu erstellen, und kann sie ohne Konvertierung nutzen. AGA-Amigas bieten dafür ideale Modi an: NTSC ExtraLowRes hat 160x200 Punkte, NTSC LowRes 320x200. Man muß halt bei 16 Farben bleiben und in etwa die VIC-Beschränkungen beachten. Allerdings: Mit 16 MB RAM wäre ein umfangreiches Grafikprogramm auch auf dem C128 möglich, inklusive mehreren UNDO-Stadien und Animationsfunktionen. Die Block-Move-Befehle des 65C816 helfen dabei.

Was Demos angeht - klar, da verläßt man sich nicht auf den Kernel. Muß man ja auch nicht machen. Mit einem neuen Prozessor und wesentlich mehr Speicher hat man aber genug Möglichkeiten, um Sachen auszuprobieren, bei denen weniger als 64K RAM nicht mehr gehen. Die frühen Demo-Restriktionen, daß es nur eine 1541-Disk gehen darf, gibt es ja auch nicht mehr, und BluREU wäre ohne REU gar nicht möglich. NUVIE's benötigen sogar SD-Karten, um vernünftig die Datenmengen laden zu können.

Für Spiele wäre so eine Karte natürlich sehr praktisch, denn viele Routinen für Grafik und Sound sind ja bereits im Kernel. Da es dann auch gute VDC-Routinen gibt, wären Programme mit Dual-Screen-Betrieb leicht machbar. Für Musik auch, ein Tracker oder MIDI-Programm wird komfortabler im 80-Zeichen-Modus laufen, mit 2 MHz. Da der VIC abgeschaltet ist, klingen Digis besser. Ein Softwarebundle wie das MSSIAH-Modul könnte man so natürlich wesentlich besser machen, da die einzelnen Teile des Sequenzers nicht umständlich im Overlay-Verfahren geladen werden müssen. Allerdings wird dann nicht alles auf einmal in den Speicher geladen, sonst dauert das zu lange. Erst wenn ein bestimmter Teil benötigt wird, wird er geladen und verbleibt dann im Speicher - man hat ja genug.

Gikauf:

Das umständliche Bankswitching des C128 war einer der Gründe, weshalb es so wenig Software für den C128 gab. Ganz abgesehen davon, daß kurz danach der Amiga rauskam. Sich für 160 oder 240 Byte mit der MMU rumzuschlagen bringt nun wirklich nicht viel - Und vor allem: kann man das im BASIC V7 vernünftig nutzen?

Klar, so eine Karte müßte sich erst durchsetzen. Aber wenn sie günstig genug bleibt und es gute Möglichkeiten zu einer effektiven Programmierbarkeit auch in BASIC gibt, kann das klappen. Für Assemblerprogrammierer ist auf jeden Fall ein 65C816-Maschinensprachemonitor im ROM, vielleicht sogar ein kompletter Assembler. Dann kann man genauso schnell Assembler programmieren wie BASIC. Außerdem gibt es so einen Standard, unterschiedliche Assemblerformate sind dann vorbei. Da kann der C128 seine Stärke auch ausspielen: Ein Assembler im 80-Zeichen-Modus ist natürlich wesentlich komfortabler, vor allem, wenn er über den ABORT-Pin des 65C816 direkt aufgerufen werden kann. Wenn der Rechner dann mit 1 MHz betrieben wird, ist der Aufbau des VDC zwar langsamer, aber man hat das letze dargestellte Bild des VIC noch sichtbar, das kann hilfreich sein. Der Assembler sollte dann so aufgebaut sein, daß er eigene Daten sehr weit am Ende des 16MB-Adressraums anlegt, damit kollidieren sie nicht mit Programmdaten, die fangen ja vorne an.

Kann man nicht von vorherein sagen, da dieses Projekt ja die Fehler der SuperCPU beseitigen soll - Kompatibilität, Preis, schlechte Programmierunterstützung. Allerdings vermute ich eher, daß keiner mitmachen will, das liegt neben der umfangreichen Kernelprogrammierung möglicherweise sogar schon daran, daß es auf dem C128 aufbaut. Der Rechner kommt grundsätzlich zu kurz. Und das finde ich äußerst schade, denn der Rechner ist definitiv besser als der C64 - sogar im C64-Modus. Selbst da kann man den VDC und den 2 MHz-Modus nutzen.

Falls das Teil doch mal existieren sollte, werden möglicherweise gerade die Demo-Programmierer rangehen, weil man keine Speicherknappheit mehr hat. Den 6510 kennen die ja nun auch schon in- und auswendig, aber was bringt der 65C816 an Neuheiten? Der 65C816 hat schließlich 24 Adressmodi (6502: 13), 92 Instruktionen (6502: 56), neue Register und mehr . Also gibt's mal wieder eine kleine Herausforderung, und lästige Inkompatibiliäten durch illegale Opcodes fallen auch weg, weil es einfach keine mehr gibt - alle 256 Opcodes sind belegt. Musiker werden den 80-Zeichen-Modus für den Editor und den großen Speicher für SID-Daten zu schätzen wissen. Was mit den verschiedenen Digi-Programmiermethoden im 2 MHz-Modus zu machen ist, kann man auch ausprobieren. Die Programmierer müssen sich hauptsächlich an die andere Speicherbelegung der C128-Zeropage und der Highpage ab $10000 gewöhnen, dazu gibt es nun noch oft Drei-Byte-Adressen. Das sollte aber machbar sein. Das umständliche Bankswitching des C128 fällt im 16bit-Modus ja weg, die unteren 64K sollen ja ohnehin hauptsächlich für Zeropage, SID- und VIC-Daten verwendet werden.

Zitat von RetroAndMore

Es gibt außer GEOS und Metal Dust keine Software,

Das stimmt so nicht ganz.Es gibt schon einige für das Teil programmierte und auch angepasste Software.

Für Democoder wird das Ding alles andere als interessant - der Reiz vom C64/C128 liegt doch primär im geschlossenen System mit festen Spezifikationen. Weder VDC, noch REU, noch IDE64, noch SCPU, noch TC64 haben bis heute mehr als jeweils 2-3 relevante Demos erhalten und ich seh kein Argument weshalb das bei deiner Entwicklung anders laufen sollte.

Sorry.

Zitat von RetroAndMore

Wenn man den originalen Prozessor rauswirft und dafür einen 65C816 nutzt, ohne auf mehr Geschwindigkeit Wert zu legen, hat einen ziemlich kompatiblen Computer. Illegale Opcodes kommen ja nur in wenigen Programmen vor.

Viele Programme werden selbst wenn sie keine illegale Opcodes enthalten nur funktionieren, wenn sich der Prozessor Taktzyklus für Taktzyklus genau wie ein 6510 verhält, und das ist beim 65C816 nicht der Fall.

Zitat von Schmitti

Warum das aber gleich alles hier so negativ gesehen wird, verstehe ich nicht. Die meisten Erweiterungen sind nicht so stark verbreitet wie das Basisgerät. Das haben Erweiterungen an sich und genau davon lebt die Commodore-Welt.

So negativ wie man meinen Post verstehen kann seh ich das garnicht - neue Hardware-Entwickler sind wirklich etwas was ich der Community wünsche und gönne - allerdings sehe ich für das vorgestellte Projekt keine große Akzeptanz innerhalb dieser (wozu was entwickeln was dann keiner nutzt?) und des weiteren eine derart komplexe Idee mit so vielen Stolpersteinen von jemandem der neu angekommen ist, dass mensch sich fragen muss ob es sich dabei um eine Idee oder eine persönliche Wunschvorstellung handelt.

Commodore lebt von Erweiterungen? Nenn mir mal welche die _wirklich_ verbreitet sind, welche keine Engpässe der Originalhardware (sprich langsame Floppies oder unzuverlässige Kassetten ersetzt [da fallen 1541U, TC64, SD2IEC + diverse Floppy-Speeder schonmal raus]) ausgleicht bzw. den Umgang mit diesen komfortabler macht. Da fallen mir maximal die REU (welche primär 'ne Spielerei ist) und Stereo-SIDs (welche extrem stiefmütterlich behandelt werden) ein.