Neuer Retro-Computer im 8-Bit Style

Zitat von Retrofan

Mir ist im Gedächtnis geblieben, dass es sich (stark simplifiziert) um einen auf 32 Bit aufgebohrten 6502 @ ca. 3,5 MHz handelt, der von einer Art aufgedoppeltem VIC II (VIC IIx2) unterstützt wird.

Ja, der M. J. labert viel, wenn der Tag lang ist...
Vielleicht noch mal grob zusammengefaßt die ersten Schritte hin zu einer eierlegenden Wollmilchsau:

- Die Grundüberlegung ist, daß es sich um ein weitgehend C64 kompatiblen Rechner handeln sollte. Vollständige Kompatibilität kann nicht erreicht werden, aber sie sollte besser sein als beim C65.
- Ferner sollte die Architektur so gestaltet sein, daß Programmierer Schritt für Schritt neue Features für sich entdecken können. Anders als beim Mega65 oder C128 gibt es daher keine getrennten Modi. Im Grundzustand verhält sich der Rechner einfach erst einmal so wie ein normaler C64, und alle Ergänzungen wie ein zweiter SID muß ein Programm aktiv ansprechen, damit sie in Erscheinung treten.
- Normale Programme des C64 sollten nicht bemerken, daß sie auf einem erweiterten System laufen. Natürlich kann man Programme so schreiben, daß bestimmtes anderes Verhalten (wie z. B. Auslesen eines Registers des zweiten SID) dem Programm zeigt, daß es auf einem C64x2 läuft, doch dies gilt nur für Programme, die mit Wissen um die erweiterten Fähigkeiten absichtlich so geschrieben wurden.
- Sinn der Erweiterungen sollte es sein, zum einen Graphik und Audio behutsam anzuheben, zum anderen dem Prozessor die Möglichkeit zu bieten, über einen reinen 8 Bit-Rechner hinaus mit Adreßräumen und Daten umzugehen, die das Einsatzgebiet erweitern (z. B. für Hochsprachen oder SEUCKs).

Wie lassen sich diese Voraussetzungen erfüllen?
Der Kern des erweiterten C64 (kurz: C64x2) besteht in einer Verdopplung des Datenbus:
- Auf einem klassischen 8 Bit-Rechner werden pro Zugriff auf den Speicher stets 8 Bits geladen oder gespeichert. Bei einer Verdopplung sind dies aber 16 Bits auf einen Schlag. Diese 16 Bits werden aber nicht von 2 verschiedenen Adressen genommen, sondern von derselben Adresse. Hinter jeder Adresse verbergen sich somit 16 und nicht 8 Bits. Der Mindestspeicher besteht somit nicht aus 64kb, sondern aus 64 kw (Kilowort) mit 1 w = 16 Bits. Dies entspricht von der Speichermenge her 128 kb, jedoch ist der Speicher - wie beschrieben - anders arrangiert.
- Jedesmal, wenn Prozessor oder VICIIx2 auf den Speicher zugreifen, werden von einer Adresse die vollen 16 Bits übertragen. Dies ermöglicht es dem VICIIx2, bei gleichem Timing mehr Farben und höhere Auflösungen auszugeben.
- Aus Sicht des Prozessors bestehen die 16 Bits hinter einer Adresse aus 2 Bytes: einem oberen und einem unteren. Im Normalzustand betrachtet der Prozessor nur die unteren Bytes. Daher laufen alle Programme des C64 nahezu identisch weiter, denn das obere Byte wird einfach ignoriert.
- Im Befehlssatz des erweiterten Prozessors gibt es nun die Möglichkeit für Lesen und Schreiben getrennt das obere oder untere Byte auszuwählen. Damit können dann z. B. Farben für die neuen Graphikmodi des VICIIx2 gesetzt werden.
- WIchtig: Beim Schreiben wird nur das per Schalter ausgewählte Byte verändert. Das jeweils andere bleibt unangetastet.
- Wichtig: Unabhängig von den Schaltern zum Lesen und Schreiben werden bei Befehlen stets die ganzen 16 Bits geladen. Davon bestimmt das untere Byte immer den 6502-Befehl. Es ist also nicht möglich, zwei Programme an der gleichen Adresse zu halten (einmal im oberen, einmal im unteren Byte).
- Der Grund hierfür liegt darin, daß bei der Befehlsauswertung das oberste Byte hinzugezogen wird.
Ein Befehl wie "LDA $1234" besteht beim 6502 aus drei Bytes:

Aufgrund der 16 Bits pro Adresse verändert sich beim C64x2 sich dies zu:

Beim Start des Rechners wird das obere Byte zunächst auf 0 gesetzt. Daher macht es für ein normales C64-Programm auch keinen Unterschied. Verändert man jedoch das obere Byte, ergibt sich Folgendes:

Der Befehl, der sich daraus ergibt, lautet "LDA $ABCD1234". Dies entspricht somit einer 32 Bit-Adresse, um direkt auf einen größeren Speicherbereich außerhalb des Adreßraums $0000..$ffff zugreifen zu können.
Diese Erweiterung betrifft auch andere Befehle, z. B.

Bei Zeropageadressen bewirkt die Ergänzung, daß aus der Zeropage-Adresse eine Adresse innerhalb von $0000..$ffff wird.

Damit wird quasi der ganze Speicherbereich von $0000..$ffff zur "Zeropage", was auch bedeutet, daß man bei der indirekten Adressierung Zeiger überall innerhalb von $0000..$ffff plazieren kann.
Zuletzt bietet auch die indirekte Adressierung die Möglichkeit, auf Speicher oberhalb von $ffff zuzugreifen. Folgendes Beispiel:

-Wichtig: Beim Schreiben gibt es eine Ausnahme: Implizite Speicherzugriffe auf den Stapel schreiben immer 16 Bits und nicht ein Byte. Der Befehl PHA speichert den Akkumulatorwert im unteren Byte und den Wert 0 im oberen Byte. Ähnlich verhält sich PHP. (Hinweis: "Implizit" meint hier Befehle, bei denen der Stapelzeiger verwendet wird, z. B. PHA oder JSR, oder das Auslösen eines Interrupts. Zugriffe mittels STA, STX und STY auf den Speicherbereich des Stacks werden weiterhin vom Schalter für Schreiben bestimmt.)
- Damit sich Speicher höher als $ffff auch für Programmcode nutzen läßt, benötigt man einen größeren Programmzähler von 32 Bits anstelle 16. Daraus ergibt sich das Problem, daß bei einem JSR (oder Interrupt) normalerweise nur 16 Bits auf dem Stapel gesichert werden. Die Lösung besteht darin, daß analog zu der oben beschriebenen Adreßaufteilung die oberen Bytes auf dem Stapel den höherwertigen Anteil des Programmzählers aufnehmen. Ein RTS liest folglich 32 Bits (und nicht 16) und rekonstruiert daraus die Rücksprungadresse. Daher benötigt man keine gesonderten Befehle "JSR FAR" und "RTS FAR" wie beim 65816, Mega65 oder 8086.
Aber Achtung: Es gibt bei 6502-Code die Methode, die Rücksprungadresse vom Stapel zu holen, in einem 16 Bit-Zeiger zu sichern und später den Zeiger für den Rücksprung von dort wieder auf den Stack zu schreiben oder per JMP (ind) weiterzuspringen. Dies funktioniert bei Programmen, die erweiterten Speicher für Programmcode verwenden nicht mehr. Für normale C64-Programme ist dies jedoch egal, da die oberen 16 Bits der 32 Bit-Adresse sowieso immer 0 sind. Hier bewirkt ein PHA entsprechend, daß als Wert auf dem Stapel immer die dazugehörige 0 geschrieben wird.
Es ist also möglich, Programmcode außerhalb von $0000..$ffff anzulegen (z. B. für erweiterte Systemroutinen), der auch von Interrupts unterbrochen werden kann, aber man muß vorsichtig sein hinsichtlich des Stackgebrauchs bei der Rücksprungadresse.

Das wäre zunächst mal ein Vorschlag zu einer behutsamen Erweiterung des C64 (C64x2) mit verbesserter Graphik (VICIIx2) und größerem Speicher auf Basis des 6502. Der Vorschlag richtet sich an alle Freunde der 8-Bit-Programmierung. Für diejenigen, die es etwas kraftvoller haben wollen, gibt es eine zusätzliche Prozessorerweiterung, die sich die Erweiterung des Befehlswortes auf 16 Bits zunutze macht, doch dies ist dann der nächste Schritt zur eierlegenden Wollmilchsau und ein Kapitel für sich.

Zitat von oobdoo

Wo bleiben denn da die Flags?

Wie genau meinst Du das? Bei PHP werden die Flags im unteren Byte gespeichert, und das oberste Byte erhält ebenfalls den Wert 0.

Zitat von Unseen

Gratuliere, ich glaube das wäre wohl das erste System mit XNIU-Byteorder in der Computergeschichte.

Öfter mal was Neues. Es soll ja schließlich was Überraschendes und Neues bieten zum Basteln und Spielen (, wenn auch nicht zum Naschen).

Zitat von Unseen

Wäre der Stack immer noch auf 256 Worte an einer fixen Adresse beschränkt?

Sofern jemanden eine gute Lösung einfällt, wie sich die Beschränkung umgehen läßt, soll es mir recht sein. Bei der am Ende erwähnten Befehlserweiterung existiert bereits ein von S getrennter Stack, welcher den gesamten Adreßraum verwenden kann.

Zitat von Markaine

Ein Tenor in diesem Thread war nicht noch einen kompatiblen C64 zu erschaffen. Davon gibt es bereits genug (Turbo Chameleon [-> MK3], Ultimate 64, Mega 65). Weiterhin wird man sich so nicht von den Restriktionen eines C64 lösen können. Die Entwicklungszeit die in die C64 Kompatibilität gesteckt werden muss fehlt um etwas neues zu erschaffen.

Weder das Turbo Chameleon noch das Ultimate 64 erweitern die audiovisuellen Fähigkeiten, und der Mega65 kreiert einen VIC IV, der mit dem VICII nicht mehr viel gemein hat. Der Vorschlag beschreibt ein Modell, das die Grundstruktur des C64 nimmt und kräftig ausbaut. Daß die Restriktionen des C64 bestehen bleiben, kann ich bei einem Adreßraum von 0..$ffffffff und neuen Graphikmodi (640x200, 80 Zeichen sowie deutlich mehr Farben in allen anderen Modi) nicht erkennen. Die Frage ist doch immer, wo man die Grenze zieht, und hier vertraue ich den Graphikern, die sagen, daß Auflösungen oberhalb von 320x200x16 schwerer zu pixeln sind, bzw. eine andere Arbeitsweise erfordern und daher nicht mehr attraktiv sind.

Zitat von Markaine

Ein weiterer Tenor war es soll einfach zu benutzen und einfach zu programmieren sein, es soll Spaß machen und nicht eine ewig hohe Lernkurve erfordern um Ergebnisse zu erzielen. Alles das was der C64 [auf der Entwicklerseite] nicht ist.
[..]
Foenix C256

Was den C256 oder den Rechner des 8 Bit-Guys anbelangt, so sind diese alle deutlich schwerer zu programmieren als der C64. Der 65816 ist nicht nur einfach ein 16-Bit-6502, sondern mit einhergeht auch eine andere Art der Programmierung, die komplizierter ist als das, was man vom C64 so kennt. So gesehen halte ich das Projekt des 8 Bit-Guys im Ansatz schon für falsch ausgelegt. Der 65816 ist kein leicht zu programmierbarer Prozessor.
Vor kurzem hatte ich ein (im Verhältnis) sehr leicht zu bedienendes System vorgestellt, welches aber abgelehnt wurde, weil es (angeblich) zu wenig Fähigkeiten bietet. Leider gibt es eine Kluft zwischen "einfach zu programmieren" und "komplexe Videodarstellung mit zig Tiles in verschiedenen Größen und Bitmaps und Farben und Sprites und...", und man muß sich irgendwann mal entscheiden, was man eigentlich will.

Zitat von Markaine

V9990

Hab mir mal die Specs angesehen. Das Ding ist doch superkompliziert, überhaupt nichts für Einsteiger. Und mal ehrlich... Auflösungen von 256x212, 192x240, 512x212 usw. Wer braucht das? Dazu Auflösungen mit bis zu 32768 Farben (5:5:5) pro Pixel. Das ist doch weit, weit entfernt von allem, was man von Homecomputern der 80er kennt. Da kann man doch gleich einen PC nehmen (486er mit VGA-Karte). Klar, das ist für einige heute auch schon Retro, aber mit 8 Bit-Style hat das nach meinem Geschmack wirklich nichts mehr zu tun.

Zitat von Markaine

So wird es nur eine weitere C64 kompatible Kiste die etwas mehr kann und doch nicht wirklich aufregendes bietet.

Ich hatte in dem Post absichtlich erst einmal nur den ersten Schritt beschrieben, der sich gezielt an diejenigen wendet, die eher auf 8 Bit stehen. Am Ende hatte ich erwähnt, daß es eine Prozessorerweiterung gibt, die kraftvoller ist, sprich: Da gibt es dann das Aufregende für Leute, die mehr als 8 Bit haben wollen. Der Vorschlag ist nun einmal die Quadratur des Kreises: Vereinigung von 8 Bit-Welt mit "Mehr". Momentan gestaltet es sich doch so:
- Macht man einen Vorschlag zu einem Rechner mit mehr Power, sagen die einen: Nein, nein, das ist aber nicht mehr 8 Bit.
- Macht man einen Vorschlag zu einem Rechner mit 8 Bit-Power, sagen die anderen: Nein, nein, das ist uns aber zu wenig.
Dieses Pingpong-Spiel kann man natürlich unendlich lange spielen. Es führt aber zu nichts.
- Daß ein reines 8 Bit-System Leute mit Anspruch auf Hochsprachen, SEUCK und Programmierung auf dem Rechner selbst nicht zufrieden stellen kann, wissen wir jetzt.
- Daß ein System oberhalb von 8 Bit Leute mit Anspruch auf 8 Bit-Style nicht zufrieden stellen kann, wissen wir auch.
Vielleicht sollte man mal Vorschläge zu einem Bereich jeweils mit Kritik/Meinungen/Kommentaren/Ergänzungen... zu eben jenem Bereich begleiten und nicht ein System aus einem anderen Bereich dagegensetzen.

Zitat von ogd

Mit wieviel Prozent Kompatibilität ungefähr wärst du denn zufrieden?

Ein solches System sollte kompatibel sein auf der Ebene von Taktzyklen, d. h. es kann Jitter geben in allen Vorgängen, die schneller ablaufen als 1 Mhz. Dies könnte sich z. B. dadurch äußern, daß beim Umsetzen eines Farbregisters die neue Farbe einen halben Pixel zu früh erscheint u. ä. Alles ab der Ebene des Taktzyklus sollte identisch ablaufen mit einer Ausnahme: Die Adreßleitungen des IO-Bereichs von $d000..$dfff werden anders dekodiert. Programme, die darauf vertrauen, daß man bei einem "STA $d095" tatsächlich nach "$d015" schreibt, werden nicht funktionieren. Allerdings halte ich persönlich solche Programme für Murks, so daß es mir auch egal ist, ob diese laufen oder nicht. Mit anderen Worten: Alle Software, die regulär innerhalb der offiziellen Spezifikationen des C64 geschrieben wurde, sollte auch auf dem neuen System laufen, so weit es moderne FPGA-Technologie zuläßt. Wie weit das genau ist, kann ich aber nicht sagen. Da müßte man die Experten fragen, die an FPGA-Lösungen für SID, CIA, VIC etc basteln.

Die Ideen von M.J. für den C64X2 gefallen mir außerordentlich gut.

Zitat von Markaine

es ging mir um die Funktionen (Blitter, Hardwarebeschleunigung für Line, Fill...)

Einerseits verstehe ich nicht, wie sich diese Anforderung mit folgendem Punkt auf Deiner Liste verträgt:

Zitat von Markaine

GFX
Kein dedizierter Grafikspeicher, wie beim C64 teilt sich das System den Speicher

Denn genau solch einen Grafikspeicher wie beim V9990 braucht man, wenn man effizientes, hardwarebeschleunigtes Malen möchte.
Anderseits hatte ich bereits darauf hingewiesen, daß es beim Amiga nicht funktioniert hat, und dafür gibt es handfeste Gründe. Daher verzeih bitte die Frage: Weißt Du, welchen programmtechnischen Aufwand es erfordert, um mittels Blitter/Videoprozessor ein gefülltes Polygon auf den Bildschirm zu zeichnen?

Zitat von Markaine

Das Turbo Chameleon bietet aber zumindestens schonmal eine Hardwarebeschleunigung [..] Kaum jemand nutzt diese Beschleunigung.

Erkennst Du den Widerspruch? Beim C64 ist das genaue Timing extrem kritisch (Rastereffekte etc), eine Prozessorbeschleunigung während des Bildschirmaufbaus also problematisch. Da der TC64 aber keine zusätzlichen Fähigkeiten mitbringt, gibt es für den Programmierer zunächst auch keinen Grund, mehr Prozessorpower einzusetzen, denn dann würde man ein Spiel, das quasi auf jedem C64 laufen könnte, nur noch auf eine kleine Menge an Nutzern begrenzen. Das macht nicht viel Sinn. Ist die Software aber auch in anderen Punkten (Audio/Video) so gehalten, daß sie nicht mehr reine C64-Software ist, wird man eine Beschleunigung viel eher einsetzen. Ein weiterer Grund, warum so wenig Programme die zusätzliche Beschleunigung nutzen, liegt in der schlechten Dokumentation. Für meine Programme habe ich Routinen geschrieben, die erkennen, ob TC64, SCPU, DTV oder C128 vorliegen, und den Rasterinterrupt entsprechend einrichten. Das mußte ich aber alles selber schreiben. Wo findet man hierfür vorgefertigten Code?

Zitat von Markaine

Verkaufszahl

Wer will hier was verkaufen? Meine Lösung ist FPGA-basiert. Da kann jeder was drumherumstricken, wie er will. An Verkauf bin ich nicht interessiert.

Korrektur:
Ich hatte Dir fälschlicherweise eine Bemerkung von Freddy zugeordnet. Hiermit gestrichen.