Neuer Retro-Computer im 8-Bit Style

Zitat von RKSoft

Zitat von Unseen

Zitat von RKSoft

Mir würde ein Commodore Plus/4 mit besserem Soundchip, doppeltem Speicher, höhere Taktrate, schnellerem BASIC und, für mich sehr wichtig, einfach zu bedienende Sprites mehr gefallen, als ein komplett neues System.

Klingt ein wenig nach C128?

Der ist mir zuuu langsam - würde der mir min. 8 MHz getaktet sein, könnte man evtl. auch was richtig gutes drauf programmieren (BASIC).

Was willst du denn tolles mit 8Mhz in Basic anfangen? Also auf dem Amiga konnte man damit nichts wirklich schönes anfangen, der war einfach zu langsam für Basic. Mal davon abgesehen dass Basic keine gute Einsteiger Programmiersprache ist, so wie es der Name vielleicht suggeriert.

Zitat von enthusi

https://www.commanderx16.com/forum/index.php?/home/

Die Selbstbaucomputer scheinen ja wie Pilze aus dem Boden zu schießen.

Zitat von Snear

Man stellt sich mal einen Befehl vor, der in einem Taktzyklus A,X und Y auf den internen Stack der CPU legt.

Das ist leider nicht so einfach möglich. Der 6502 braucht für jeden einzelnen Speicherzugriff jeweils einen Takt. Möchte man 3 Werte schreiben, benötigt dies dann mindestens 3 Takte. Das allerdings auch nur, sofern man intern mehrere Prozesse parallel ablaufen läßt. So muß z. B. das Dekrementieren des Stapelzeigers neben dem Schreiben des Registers stattfinden. Nun weiß ich nicht, wie die Register intern angebunden sind. (Da müßte man jemanden fragen, der sich damit auskennt.) Sollte es so sein, daß der 6502 immer nur ein internes Register auslesen kann, also A oder S, ist eine parallele Ausführung nicht möglich. Dafür müßte man das Innenleben des 6502 ziemlich umkrempeln mit der Gefahr, daß dadurch Inkompatibilitäten entstehen

Zitat von RKSoft

für mich sehr wichtig, einfach zu bedienende Sprites

Wäre für Dich anstelle von Sprites auch die Verwendung von Shapes denkbar? Auf größeren Rechnern (ab Amiga/AtariST usw.) geht man so vor, daß man zwei Bitmaps definiert. Die erste Bitmap guckt sich der Benutzer an. Auf der anderen Bitmap wird die Grafik neu gezeichnet. Dabei malt man zuerst den Hintergrund neu und löscht dadurch gleichzeitig alle Figuren. Dann kopiert man die Shapes in die Bitmap. Ist man fertig, werden die beiden Bitmaps vertauscht. Der Benutzer sieht nun die (fertige) zweite Bitmap, und das Programm malt auf der ersten. Sprites sind bei dieser Methode nicht notwendig, und Shapes sind sogar viel flexibler. Sprites haben leider den Nachteil, daß sie a) in der Größe und b) in der Anzahl irgendwie beschränkt sind. Beim C64 z. B. kann man nur maximal 8 Sprites pro Zeile darstellen, was z. B. bei horizontalen Schüssen viel zu wenig ist. Vertikal kann man zwar mehr Sprites anzeigen lassen, doch gibt es da den Aufwand eines Sprite-Multiplexers. Mit Shapes gibt es all diese Probleme und Einschränkungen nicht.

Zitat von Freddy

Immerhin gab/gibt es Pascal, Forth, Fortran, und C auch für den C64/128er

Ich habe mir damals[tm] das Buch "Pascal für den C64" besorgt von Prof. Florian Matthes (es steht heute noch im Regal), und ich bin immer noch beeindruckt davon, wie es ihm in jungen Jahren gelungen ist, den Compiler in dieser Kompaktheit auf den C64 zu portieren. Nichtsdestoweniger würde ich heutzutage auf diese Art nicht mehr Pascal programmieren wollen, da die Handhabung zu umständlich ist, von der eigentlichen Programmierung ablenkt und auch zu viel Zeit kostet. Das gilt ebenso für andere Sprachumsetzungen der damaligen Zeit.

Zitat von RKSoft

Daher war ja mein Gedanke, auf einem bestehendem System aufzubauen und die Fehler/Macken auszubessern und das System zu verbessern. Der +4 war ja nur ein Wunsch meinerseits. Man kann auch einen C64er nehmen, ihn in ein größeres, flacheres Gehäuse packen und erweitern/umrüsten. Wichtig wäre dabei die Handhabung, Programmierbarkeit und die Geschwindigkeit; zumindest für mich.

Darüber hatten wir schon vor vielen Seiten mal diskutiert. Ein Konzeptvorschlag sah grob zusammengefaßt so aus:

- Der Speicher wird verdoppelt. Es gibt zweimal 64 kb, die angeordnet sind als "untere" 64 kb (das alte Ram) und "obere" 64 kb (das neue Ram).

- Der VIC als auch der 6510 lesen bei jedem Taktzyklus von der gleichen Adresse sowohl 8 Bits aus dem unteren Ram als auch dem oberen Ram, insgesamt also immer 16 Bits.

- Der VIC benutzt die 16 Bits, um seine Auflösung zu erhöhen. Aus einer 320x200@2 Auflösung wird so 320x200@4. Anstelle von 160x200@4 erhält man 160x200@16.

- Der Prozessor kann wahlweise beim Lesen oder beim Schreiben (beides wird getrennt) auf die unteren oder oberen 8 Bits zugreifen.

- Beim Lesen des Befehls jedoch werden stets die vollen 16 Bits gelesen. Die 8 Bits aus den unteren 64 kb geben dabei den 6502-Befehl an. Die oberen 8 Bits bestimmen die Befehlserweiterung.

- Sind die oberen 8 Bits 0, handelt es sich um einen normalen 6502-Befehl (inklusive illegaler Opcodes). Beim Einschalten des Rechners werden die oberen Bits gelöscht. Da das Zeitverhalten von Prozessor und VIC völlig identisch ist mit dem eines C64, merkt ein normals C64-Programm so nicht, daß es in einer erweiterten Umgebung läuft. Damit ist die Kompatibilität gesichert.

- Eine höhere Geschwindigkeit wird durch Verwendung der erweiterten Befehle erzielt, also wenn die oberen 8 Bits ungleich 0 sind. Zu den erweiterten Befehlen gehören z. B. "ADD #40, X", "SUB #100, Y" oder "LSL #3, A" sowie neue relative Sprungbefehle wie "BRA" und "BSR".

- Desweiteren kann man bei den erweiterten Befehlen ähnlich wie beim 65816 (SCPU) die Registerbreite erhöhen von 8 auf 16 Bits. Dadurch sind auch sehr schnelle Adressierungsarten möglich, z. B. "LD A, (Y)" oder "LD X, (Y)+". Solche Adressierunsarten eignen sich zudem gut für die Implementierung von Hochsprachen.

- Man könnte auch daran denken, die Registerbreite auf 32 Bits zu erhöhen, um mehr Speicher als 128 kb direkt ansprechen zu können, Doch spätestens hier wird die Sache brenzlig. Je mehr man den Prozessor mit neuen Befehlen und Möglichkeiten ausstattet, umso mehr schwindet der Bezug zum eigentlichen C64. Am Ende verhält es sich dann so wie beim x86, der zwar im Real Mode bootet, aber später in den 32 Bit-Protected Mode wechselt (oder schlimmer noch in den x64-Modus). Da sollte man sich vorher gründlich überlegen, was man wirklich will.

Einen nicht zu unterschätzenden Nachteil hat das Konzept allerdings. Gerade die angestrebte vollständige Kompatibilität zum C64 erfordert einen extrem hohen Aufwand bei der Entwicklung einer Emulation oder eines FPGA-Cores. Die Anzahl der Leute, die einen passenden Emulator oder FPGA-Core schreiben können und wollen, ist 0. Und daran scheitert unausweichlich jedes Konzept.

Zitat von DivZero

Also auf dem Amiga konnte man damit nichts wirklich schönes anfangen, der war einfach zu langsam für Basic. Mal davon abgesehen dass Basic keine gute Einsteiger Programmiersprache ist, so wie es der Name vielleicht suggeriert.

Mein Eindruck war immer, daß das Basic schlecht programmiert war. Da hätte man sicherlich mehr rausholen können. Und Basic ist auch nicht gleich Basic. Ein Basic ohne Zeilennummern mit Prozeduren und richtigen Schleifenkonstrukten wäre durchaus machbar. Damit wäre man ungefähr auf dem Niveau von Pascal. Wenn es jedoch nach mir ginge, würde ich lieber von vornherein direkt auf Oberon (dem Pascal-Nachfolger) wechseln. Ist sehr leicht zu lernen und bietet dennoch das Potential, damit auch große Programme schreiben zu können.

Zitat von Unseen

Es gibt ein recht detailiertes Blockdiagramm

Vielen Dank!

Hmm... Dem Diagramm zufolge hängen sowohl A, X, Y als auch der Stapelzeiger S alle gemeinsam am gleichen interen Registerbus SB (rechts unten). Das würde bedeuten, daß ein gleichzeitiger Zugriff auf S zum Dekrementieren des Stapelzeigers und auf A/X/Y für eine Speicherung nicht möglich ist. Beide Vorgänge werden nur nacheinander abgewickelt, weshalb ein Befehl zum Pushen aller Register mindestens 3 * 2 Taktzyklen benötigen würde.

Zitat von Snear

Deswegen "interner Stack". In das RAM vom C64 wird gar nichts geschrieben.

Das Konzept des internen Stacks hatte ich auch mal auf dem FPGA umgesetzt. Doch leider gilt auch hier, daß die Werte nur nacheinander geschrieben werden können. Selbst wenn man den Stapelzeiger entkoppelt vom normalen Registersatz (A, X, Y ...), muß man wegen des Registerbus die zu speichernden Register einzeln nacheinander anwählen. Da man außerdem den Stack selbst als Blockram umsetzen wird, kann auch dieser nur einen Speicherzugriff pro Zyklus durchführen. Mit etwas Aufwand könnte man es vielleicht hinkriegen, daß ein Speicherzugriff pro Phase (und nicht pro Taktzyklus) durchgeführt wird, also doppelt so schnell, doch ergibt dies auch nicht die Anforderung, alle 3 Werte in einem Rutsch zu sichern.

Ein interner Stack macht eigentlich erst dann Sinn, wenn die Breite der Werte größer ist als der Speicherdatenbus. In meinem Fall waren das 32 Bit-Werte bei einer 16 Bit-Anbindung an das SRam. Der interne Bus zum CPU-Stapel kann anders als der Datenbus zum Ram eine beliebige Breite aufweisen, so daß man mit einem Takt die Rücksprungadresse oder andere Registerwerte sichern und wiederherstellen kann. Weiterer Vorteil: Dadurch, daß der Ram-Datenbus nicht durch das Speichern belegt wird, ist dieser frei für das Vorabladen von Befehlswörtern oder für den Videocontroller, der ebenfalls seinen Anteil haben möchte. Bei reinen 8 Bit-Prozessoren wie dem 6502 wäre es jedoch nicht so effizient.

Eine andere Möglichkeit wäre ein Verfahren, wie man es vom Z80 kennt: Der Prozessor rettet die Register nicht (z. B. bei einem Interrupt), sondern schaltet stattdessen auf eine andere Registerbank. Hierbei muß man natürlich aufpassen, daß eine laufende Interruptroutine nicht durch einen zweiten Interrupt unterbrochen wird. Sollte dies der Fall sein, müßte man wohl oder übel die Register auf einem Stapel sichern. Kann man die maximale Verschachtelungstiefe abschätzen (z. B. vier), ließen sich zur Not auch entsprechend vier Registerbänke definieren, deren Index pro Interrupt inkrementiert und anschließend dekrementiert wird, also quasi ein Registerstack. Das wäre dann auch die schnellste Methode, einen IRQ zu behandeln.

Zitat von Snear

Die CPU sehe ich gar nicht so kritisch, aber den neuen VICII 100% abwärtskompatibel zu machen, ist fast schon unmöglich.

Da bin ich mir nicht so sicher. Angenommen, man hat bereits einen VICII-Core, der 100% kompatibel ist. Dann ergeben sich für existierende Programme (sämtliche Demos eingeschlossen) keine Unterschiede. Die 8 Bits aus den höheren 64 kb würden zwar in jedem Zyklus gelesen, aber danach schlicht ignoriert werden. Sie kommen nur zum Tragen, wenn explizit ein neuer Modus aktiviert wurde. Problematisch sehe ich eher die Einbindung der neuen Modi in einen existierenden VICII. Da müßten solche Fragen beantwortet werden wie: Wie verhält es sich bei einem Modus 320x200@4 mit der Sprite-Hintergrund-Priorität? Oder gar bei 160x200@16?

Mir persönlich würde solch ein erweiterter C64 Spaß machen, gerade weil er von Natur aus erst einmal ein C64 ist. Die neuen Befehle hingegen bieten mächtig viel Power, so daß damit auch Dinge möglich werden, die auf einem normalen 1 Mhz 6502 nicht gehen. Leider ist man beim C65 einen anderen Weg gegangen: Der C65 ist inkompatibel zum C64, und der eingesetzte Prozessor nur mäßig schneller als der Vorgänger (kein Vergleich zum 65816).

Freddy schrieb, er wünsche sich einen 4 Mhz 6502. Nun kann ich meinen AppleII-Emulator per Tastendruck auf 4 Mhz beschleunigen, doch gewinne ich dabei nicht den Eindruck, daß dadurch eine neue Qualität an Software leichter möglich ist. Stattdessen würde ich lieber den Takt bei 1 Mhz belassen und die CPU erweitern. Der Geschwindigkeitszuwachs, der sich daraus ergibt, könnte mehr betragen, als ein 4 Mhz 6502 liefert.

Angenommen, man hätte bei den erweiterten Befehlen eine Registerbreite von 16 Bits. Der Befehl "LD A, (Y)" lädt dann 16 Bits von einer Adresse (untere und obere 64 kb). Da das Y-Register als Adreßregister fungiert, braucht kein Zeiger aus der Zeropage geladen zu werden. Der Befehl wäre daher vergleichbar schnell wie ein "LDA zp". Nimmt man das Postinkrement hinzu, entspräche ein simpler "LD A. (Y)+" mit 3 Taktzyklen ungefähr folgendem 6502-Code:

was günstigstenfalls 23 Taktzyklen braucht.

Nur hier liegt - wie gesagt - die Gefahr, daß man als Programmierer dann komplett auf den Originalbefehlssatz des 6502 verzichtet und nur noch die erweiterten Befehle verwendet. Wenn es allein darum geht, einen neuen Retrorechner zu haben, der auch C64-kompatibel ist, wäre dies kein Problem. Wenn man das Gerät aber verstehen will als Nachfolger des C64, könnte zu viel Flair vom Brotkasten verloren gehen, als daß es sich dann noch um einen würdigen Nachfolger handelt.

Zitat von daybyter

Meinst nicht, dass ein vic mehr Problem als Lösung ist, wenn es drum geht, einen Rechner zu bauen der einfach zu verstehen ist?

Eine Bitmap im Speicher ist wohl viel einfacher zu verstehen?

Das ist richtig. Meine Antwort bezog sich auf den geäußerten Wunsch, eine bestehende Plattform wie den +4 oder C64 zu erweitern. Da wäre das genannte Konzept mit dem verdoppelten Speicher eine mögliche Lösung. Eine reale Umsetzung jedoch gestaltet sich aufgrund des sehr hohen Aufwands sehr schwierig, sei es in Form eines FPGA-Cores oder als Emulator. Das wäre eine Sache für Experten und für mich mehr als eine Nummer zu hoch.

Zitat von daybyter

M.J. : magst nicht mal Teile Deiner Arbeit veröffentlichen? Dann könnte man einiges an einem konkreten Beispiel diskutieren?

Nun, die Rahmenwerte hatte ich ja bereits aufgelistet:

- 32 Bit-CPU Risc ähnlich und in der Geschwindigkeit vergleichbar mit einem 68000.

- 512 kb Ram für Programm und Videodaten (wie Amiga500 oder AtariST)

- Anschlüsse für PS/2-Tastatur, VGA, Klinkenstecker für Stereoton und SD-Karte. Als Bonus noch Flashrom, SPI, UART und Infrarotsensor dazu. NB: Die Hardware stammt nicht von mir, sondern wurde von maik entwickelt.

- Videoauflösung bis 320x200x16 oder 640x200x4. (Hier könnte man überlegen, ob man eventuell auch bis 640x200x16 geht.)

- Farbauflösung getrennt von X/Y-Auflösung. 160x200x2 möglich ebenso wie 80x100x16. (Wer's braucht...)

- Die Farbpalette ist zunächst vorgegeben und besteht aus 16 Farbwerten, die mir Retrofan freundlicherweise zur Verfügung gestellt hat. Die Farben entsprechen dabei ungefähr den Farbbeschreibungen der C64-Farbpalette: Schwarz, Weiß, drei Grautöne, Gelb, Dunkelblau, Hellblau usw.

- Eine DIsplay-List/Minicopper übernimmt weitestgehend die Funktion eines Rasterinterrupts, so daß sich ohne Taktzyklenzählen leicht Auflösung oder Farben zeilenweise verändern lassen.
- Kleiner mehrstimmiger Synthesizer ähnlich wie SID, aber ohne Filter (weil im Original analog) und nicht so exakte Hüllkurven.

- Kostenpunkt für die kleinste FPGA-Lösung mit genannten Anschlüssen: ca. 25-30 Euro.

Optional:

Aufgrund der geringen Hardwareanforderung besteht auch die Möglichkeit einer Umsetzung als Emulation auf dem PC, Tablet oder Raspberry Pi. Nimmt man z. B. einen Pi als Grundlage, lassen sich dadurch auch alle Anschlüsse, die dieser verwendet, benutzen.

Da es keine feste vorgegebene Hardware gibt, sondern nur eine Spezifikation wie beim RiscV, kann man das System in verschiedenster Form zum Laufen bringen und auf allen Ebenen zum Herumexperimentieren verwenden: auf FPGA-Ebene, auf OS-Ebene im Emulator (PC), als Spielkonsole im Wohnzimmer (Pi) etc.

Mehr kann ich dazu zum jetzigen Zeitpunkt nicht sagen. Herzeigbare Fotos vom laufenden System habe ich leider noch nicht. (Ein dreifarbiges Ufo, dessen Aussehen aus einem alten AppleII-Spiel geklaut ist, und was vor einem schwarzen Hintergrund auf und ab fliegt, ist nicht gerade der Brüller.) Daher werkel ich erst einmal an einem Emulator, mit dessen Hilfe man einfacher als mit dem FPGA Programme erstellen kann. Bis der fertig ist, wird es aber noch sehr lange dauern...

Zitat von Retrofan

Zitat von DivZero

Die Selbstbaucomputer scheinen ja wie Pilze aus dem Boden zu schießen.

Der Commander X16 war ja ein Grund, diesen Thread überhaupt zu starten. Einige Aspekte fand ich gut, andere hingegen gar nicht. Ich schätze aber, dass die Kiste recht erfolgreich wird – die Stückzahlen werden weit über denen des Mega65 liegen (Gründe mehrfach besprochen). Aber solange mir kein Gerät in seiner Gesamtheit signifikant besser gefällt als der C64, werde ich der alten Kiste wohl treu bleiben.

Von so einem neuen Retro-Computer erwarte ich eine Menge guter alter Traditionen aber auch einige spannende Neuheiten. Ich finde, dass einige der neuen Kisten die Balance nicht immer gut treffen (zumindest nicht für mich). Wenn ich mir z.B. die Doom-alike-Demo auf dem Mega65 so angucke (bestimmt mit 40 MHz, oder?) – was hat das noch mit 8-Bit-Feeling zu tun? Wenn ich sowas haben will, nehme ich einen Amiga oder DOS-Rechner.

Jeder erwartet bei so einem neuen Retrocomputer(geht so was überhaupt?) was anderes. Geht es wirklich nur um Limitierungen, braucht man keinen Retrocomputer, da gibt es genug Elektronik, die man aktuell kaufen kann. Durch diese vielen unterschiedlichen Anforderungen wäre es eigentlich besser einen FPGA Grund-Retrocomputer zu schaffen. Also ein Gerät mit Tastatur, HDMI-Anschluss, Joysticksport, USB und SD. Welcher FPGA-Core Neu oder Alt-Retrocomputer der Kunde rein lädt bleibt ihm überlassen. So etwas wie den Mist(er) nur wirklich fix und fertig und in schön mit Handbücher, Supportseite, Shop mit neuer Software etc. Denn die Hardware allein löst doch kaum einen Kaufreiz aus. Erst wenn da was dahintersteht, ist es wahrscheinlicher, dass sich eine langfristige Community bildet. Einfach nur "hier haste" wird meiner Meinung nach nur Sammler und ein paar Neugierige zum Kauf animieren und das Ding stirbt dann langsam den Softwaretod, weil keiner was für macht. Ein Computer definiert sich durch sein Softwareangebot, denn Software ist die Seele zu dem Körper aus Baugruppen.

Gibt es denn irgendwo mal eine Aufstellung von den Versuchen eine neue Retrohardware zu entwickeln und was wichtiger ist eine Bewertung wie aktiv dafür Software entwickelt wird, also ist das Ding langfristig erfolgreich? Dazu müsste man definieren was erfolgreich ist. Wie viel neue Software im Jahr kommt für raus? Wie sind die Verkäufe? Wie viel YouTube Kanäle reißen sich um das Ding usw. Also definieren wir doch erst mal, was ist ein erfolgreicher neuer Retrocomputer ist. Oder wollen wir da gar nicht hin? Ich meine viele neue Retrohardware wird doch auch nur entwickelt, weil man eben so etwas mal selbst entwickeln will, also zum Selbstzweck. So ein Projekt würde mich persönlich auch interessieren, habe aber zu wenig Kenntnisse in dem Bereich und auch zu wenig Zeit mich da rein zu fuchsen.

Also meine Grundfragen hier lauten: Würde nicht ein Allround FPGA Computer besser sein? Wie definieren wir den Erfolg dieses neuen Retrocomputers? Und ist es nicht auch wichtig mal weg von irgendwelchen Spezifikationen zu kommen und mal um das Drumherum eines Computers zu reden, also Software, Shops, Support, Community, YouTubeKanal (alles jetzt nur zufällige Beispiele) Nur ein Stück Hardware in einem Gehäuse haucht dem Computer kein Leben ein. Bitte nicht übel nehmen, das ist hier die Sicht eines Software-Menschen