Neuer Retro-Computer im 8-Bit Style

Bei einem Homecomputer gibt es wohl einige Abwägungen zu treffen:

1. Preis:
Die Wahl des Mikroprozessors hat Konsequnzen in Hinblick auf die benötigte Komplexität und das Platinenlayout. Ein 65816 Prozessor beispielsweise ist kein SoC. Dementsprechend müssen weitere Peripheriekomponenten mit eingerechnet werden, was sowohl das Layout verkompliziert als auch die Kosten erhöht. Gleiches gilt wohl prinzipiell auch für günstige FPGA's. Einen Preis unter schätzungsweise 100 Euro ist hierdurch eventuell nicht realistisch, zumal ja die Kosten für ein Gehäuse etc. noch nicht berücksichtigt sind. Daher halte ich ein günstigen Mikrocontroller mit internem Speicher und seinen vielen, integrierten Funktionen für eine bessere Wahl. Gut geeignet wäre beispielsweise der Propeller II (falls er denn irgend wann einmal regulär lieferbar sein sollte). Wichtig ist hier die Anzahl aller benötigter Komponenten nach Möglichkeit zu minimieren, das Platinenlayout so klein wie möglich zu halten und dementsprechend auch die Dimensionen eines möglichen Gehäuses gering zu halten.

2. Kaufanreiz:
Viele Privatanwender als auch etliche Firmen (z.B. für Steuerungsaufgaben etc.) würden sicherlich einen unkonventionellen kleinen Computer zu schätzen wissen, der
I. einfach zu bedienen und zu programmieren,
II. sowie hardwareseitig nicht auf regulärem Wege kompromittierbar wäre.
Aus meiner eigenen Erfahrung weiß ich, das gerade der Sicherheitsaspekt sowie die Nachvollziehbarkeit des Systems wichtig sein können. Dieser Aspekt wird meistens übersehen. Computer wie ein Raspberri Pi eignen sich hierfür beispielsweise aufgrund des verbauten ARM Prozessors ebenso wenig wie ein Standard PC.

Zitat von Retrofan

Was genau macht den 6502 für Hochsprachen ungeeignet?

Das ist keine leichte Frage, denn da spielen mehrere Aspekte zusammen.

1.) Der 6502 ist ein 8 Bit-Rechner. Als Datentyp einer Hochsprache sind mindestens zwei vorgesehen, die auf 16 Bit oder mehr basieren: Zahlen und Zeiger. Mit diesen kann der 6502 nicht gut umgehen. Es ist zwar möglich (wie wir wissen), aber umständlich und erzeugt langen Code mit langsamer Ausführungszeit. Der 65816 ist zwar ein 16 Bit-Rechner und kann damit 16 Bit-Zahlen direkt verarbeiten, jedoch besteht der Adreßraum aus 24 Bit, was wiederum zu viel ist für einen 16 Bit-Zeiger.
2.) Der Datenbus beträgt nur 8 Bit. Möchte man Datentypen verwenden, die mehr Bits benötigen, erfordert dies mehrere Zugriffe auf den Speicher. Bei Standard-Fließkommazahlen z. B. vier Zugriffe. Wichtig sind aber auch die Befehle selbst, da jedes Befehlsbyte einzeln geladen werden muß. Diesen Nachteil weist auch der 65816 auf.
3.) Der 6502 verfügt nur über ein Akkumulatorregister. Das macht es schwierig, Ausdrücke der Form "(A verknüpft B) verknüpft (C verküpft D)" umzusetzen. Hierfür sind folgende Schritte notwendig:

Bei einem Prozessor mit mehr Registern sähe es hingegen so aus:

Man spart sich die Zugriffe auf eine temporäre Variable, da man hierfür Register verwenden kann, was den Code kürzer und schneller macht.
4.) Die Adressierungsarten des 6502 unterstützen indirekte Adressierung nur rudimentär. Viele Hochsprachen benötigen indirekte Adressierung aber für Zeiger, sei es explizit oder implizit z. B. bei der Übergabe von Parametern als call-by-reference. Für die indirekte Adressierung stehen auf dem 6502 jedoch nur zwei Möglichkeiten zur Verfügung: (zp, x) und (zp), y. In beiden Fällen ist ein Indexregister involviert, das dann für einen weiteren, parallen Gebrauch nicht verwendet werden kann. Das X-Register dürfte in den meisten Fällen fest auf 0 stehen, was diese Adressierung ungeeignet macht für 16 Bit-Variablen, da das zweite (höherwertige) Byte nicht durch Erhöhen des X-Registers erreicht werden kann. Was leider fehlt, ist eine Adressierung analog zu

also Basisregister plus festem Offset zur Adreßangabe. Dies wird benötigt, um z. B. schnell auf Verbundstrukturen (structs bzw. Records) zuzugreifen. Bei einem 6502 muß für einen Zugriff auf das x. Element eines Records das Y-Register vorab auf den relativen Offset gesetzt werden. (65816: s. u.)
5.) Ein Multiplikationsbefehl ist nicht vorhanden. Eine Division kann man vielleicht verschmerzen und lediglich als Unterroutine im Rom anbieten. Eine Multiplikation ist jedoch nicht nur eine häufige mathematische Operation, sondern auch Grundlage für Arrays, die sich nicht aus Datentypen mit einer Länge in Höhe einer Zweierpotenz zusammensetzen. Beispiel: Es soll ein Array gebildet werden mit Fließkommazahlen im C64-Stil, d. h. 5 Bytes pro Zahl. Wie erreicht man nun das x. Element in diesem Array? Hierfür muß der Index mit der Anzahl der Bytes des Grundelements multipliziert werden. Entweder ruft man nun für jede Indizierung eine Unterroutine auf, die umständlich und zeitraubend die Multiplikation durchführt, oder man erzeugt einen Haufen Code, um diese Multiplikation mittels Herumschieben der Bits und Aufaddieren direkt im Code abzubilden. So oder so ist dies ein recht langsamer Vorgang.
6.) Moderne Hochsprachen verfügen üblicherweise über lokale Variablen auf einem Stapel, da diese ein Programm wesentlich überschau- und handhabbarer machen, durch Mehrfachbelegung des Speichers Platz sparen sowie Rekursion ermöglichen. Der Prozessorstapel des 6502 ist hierfür jedoch ungeeignet, da er viel zu klein ist und eigentlich nur für Rücksprungadressen vorgesehen wurde, nicht jedoch, um Werte darauf zu speichern. Daher gibt es bis auf PHA:PLA (PHP:PLP) und TSX:TXS (zusammen mit nachfolgenden abs, x-Befehlen) keine Möglichkeit, den Stack im Sinne einer Hochsprache zu verwenden. Zum Vergleich wieder:

Beim 65816 gibt es zumindest die Möglichkeit, den Stack in einem 16 Bit-Raum frei zu plazieren, zu Beginn einer Unterroutine den aktuellen Stackzeiger ins X-Register zu laden und dann die Elemente mittels der Adressierungsarten zp, x und abs, x anzusprechen. Dieses Verfahren läßt sich für Y ebenfalls anwenden, um die oben genannte Adressierung für Verbundstrukturen zu erzielen. Doch wie bereits erwähnt stehen damit die Indexregister anderweitigen Operationen nicht mehr zur Verfügung. Drei Register (Akkumulator, X-Stackzeiger und Y-Basisregister) sind einfach zu wenig.
7.) Die mangelnde Anzahl an Registern macht sich auch bemerkbar bei der Paramaterübergabe. Die Übergabe in Registern ist meist die kürzeste und schnellste Methode, und die aufgerufene Routine kann selbst entscheiden, ob sie die Werte auf dem Stack ablegt oder direkt in den Registern mit ihnen weiterarbeitet. Eine Parameterübergabe beim 6502 hingegen verläuft entweder so, daß man kleine Werte in den Registern übermittelt, oder das aufgerufene Programm "weiß", wo die zu benutzenden Werte stehen, und verwendet sie direkt (globales Herumpfuschen). Programme, bei denen Werte über den Stack übergeben werden, findet man nur sehr selten, da die Handhabung kompliziert ist: Um den eigentlichen Wert zu bekommen, muß man zuerst die Rücksprungadresse herunterholen, dann den Wert und am Ende die Rücksprungadresse wieder oben drauf legen. Oder man überläßt es dem Aufrufer, den Stack später zu korrigieren, indem man eine Menge von PLAs einfügt oder TSX:INX:INX:TXS und dergleichen. Beim 65816 ist die Übergabe per Stack einfacher, da sein Stapel größer ist und auch 16 Bit-Werte mit einem PHA auf den Stapel gebracht werden können, aber immer noch weit vom Komfort der Übergabe in Registern entfernt.

Insgesamt ist der 65816 somit auf den ersten Blick besser geeignet als der 6502 und damit ein Fortschritt, doch dafür nervt er mit dem komplizierten und fehleranfälligen Mechanismus der Umstellung der Registerbreite per getrenntem Befehl, seinen wenigen Registern, seinem Mischmasch aus 16 Bit und 24 Bit-Adreßraum, der meistens zu einer Art 64 kb-Banking führt mit Near- und Far-Jumps, und einem Stackzeiger, der auf nur 16 Bit und einer Bank beschränkt bleibt. Im Grunde genommen ist der 65816 nicht Fisch noch Fleisch. Ein paar Verbesserungen hier und dort, aber immer noch 8 Bit-Bus, keinen Multiplikationsbefehl, keine indirekte Adressierung basierend allein auf Registern (ohne umständliches Kopieren eines Zeigers in die Zeropage) usw.

Nebenbei: Was UCSD-Pascal anbelangt, so basiert dieses auf einer virtuellen 16 Bit-Stackmaschine, deren Befehlssatz speziell angepaßt wurde an die Bedürfnisse einer Hochsprache, z. B. beim Laden und Speichern von lokalen Variablen. Als Ergebnis erhält man eine sehr hohe Codedichte jedoch mit dem Nachteil der langsameren Ausführung.

Zitat von Retrofan

Der IIGS wäre wahrscheinlich einfacher nachzubilden als das SNES

Das mag sein. Das SNES kenne ich nicht. Aber mit Sicherheit ist die Hardware des Apple //gs sehr schwer nachzubauen, nicht nur wegen der Audioausgabe, sondern auch aufgrund der eigenen Graphikmodi und der Kompatibilität zum AppleII. Um das OS nutzen zu können, bedarf es mehr als nur der Nachahmung der Graphik. Dazu gehört ebenfalls der ganze Speicheraufbau des AppleII mit seinen Softswitches und den Slotkarten. Bislang kenne ich auch keinen Emulator, der den Apple //gs fehlerfrei nachbildet. Dabei ist der Apple //gs an sich ein schöner Rechner trotz des 65816. (Falls Du Deinen nicht mehr brauchen solltest, überlass ihn ruhig mir. ) Es gibt nur noch einen gravierenden Nachteil: Die Firma Apple würde es kaum zulassen, daß jemand anders sich ihres Betriebssystems bedient.

Zitat von Mat4

Aus meiner eigenen Erfahrung weiß ich, das gerade der Sicherheitsaspekt sowie die Nachvollziehbarkeit des Systems wichtig sein können.

Interessanter Hinweis. Wäre auch mal eine gute Motivation, einen eigenständigen Rechner zu basteln.

Zitat von steril

Was mich hier interessieren würde sind weniger technische Specs sondern was ihr euch für ein 'Gefühl' davon verspricht dann an dieser Kiste zu sitzen.

Persönlich würde mich an einem solchen Rechner allein schon die Entwicklung des OS reizen. Da ich damals[tm] schon auf dem Amiga mein eigenes System verwendet habe, wäre es für mich durchaus auch ein nostalgisches Gefühl, einen echten eigenen Rechner, den man selber voll unter Kontrolle hat, zu benutzen anstelle eines Windows/Linux-PCs. Ist der Prozessor leistungsfähig genug (und der Rechner ausgestattet mit einer SD-Karte für den leichten Datenaustausch), könnte man das System sogar produktiv einsetzen zum Schreiben von Texten oder Entwickeln von Programmen. Den Mega65 z. B. halte ich hingegen für ungeignet, da der Adreßraum zu beschränkt und die CPU weiterhin eine 8 Bit-CPU ist. Da nutzen dann auch 50 Mhz wenig, wenn die meiste Leistung draufgeht fürs Addieren von größeren Zahlen oder das Handhaben von Zeigern, Vorgänge für die andere Prozessoren gerade einmal einen Befehl benötigen. Ich hatte das woanders schon mal geschrieben: Selbst bei einem vergleichbaren Taktverhalten bei nur 1 Mhz schneidet ein 16 BIt-Risc besser ab in puncto Geschwindigkeit und Codelänge als ein 6502. Eigentlich *hätte* man damals diesen Weg gehen sollen: Anstelle eines 65CE02 oder 65816 einen Risc zu konstruieren, der kompatibel ist zum 6502, aber erweitert um mehr Register und bessere Adressierungsarten. Darin *hätte* man Zeit und Geld investieren können. Tatsächlich hatte nur die Firma Acorn als einzige den Mut, mit ihrem Archimedes diesen Weg einzuschlagen. Dafür demonstriert die CPU bis heute ihre Leistungsfähigkeit.

Zitat von ogd

Wie viel Geld müsste/sollte man mindestens für den Chipsatz/FPGA, für die Platine + Bestückung und für ein schickes Gehäuse einplanen?

Um die Frage nach dem Preis zu beantworten, sollte man Deinem Gedankengang folgend zunächst festlegen, was fester Bestandteil des Rechners ist, und was eher einer austauschbaren Komponente entspricht. Persönlich würde ich keinen Wert legen auf ein festes, bestimmtes Gehäuse oder eine eingebaute Tastatur, Diskettenlaufwerk usw. Diese Sachen sollte jeder so gestalten, wie er mag. Das schließt nicht aus, daß jemand für sich ein spezielles Gehäuse designt und es dann anderen anbietet, aber letztendlich würde ich die Rechnerstruktur offen anlegen für Erweiterungen.
Für ein Grundmodell würde ich daher nur Schnittstellen vorsehen für Tastatur und Maus (PS/2), VGA, SD-Karte und vielleicht irgendeine Audiosausgabe sowie ein weiterer Anschluß für die Kommunikation mit anderen Rechnern. IEC, DVI/HDMI, Ethernet usw. sind für mich eher Anschlüsse, die man später nach Belieben hinzufügen kann, vorausgesetzt daß das Grundsystem erst einmal funktioniert.
Begnügt man sich für den Anfang mit den genannten einfachen Schnittstellen, hat das den Vorteil, daß der Preis runtergeht, das Design einfacher wird und man schneller zu Ergebnissen kommt. Für diesen Zweck reicht es völlig aus, ein FPGA zu nehmen, die genannten Anschlüsse dranzuklemmen und die rudimentären Dinge wie CPU und Videoausgabe in Verilog/VHDL zu programmieren, ohne gleich ein ganzes Board entwerfen zu müssen. In dem Thread zum Foenix256 hat Stefany selbst geschildert, daß die Entwicklung des Boards zusammen mit der Auswahl an Bauteilen, die größtenteils damals[tm] in ähnlicher Form bereits erhältlich waren, eine bewußte Entscheidung war als Herausforderung und Spaß an der Sache, weniger aus praktischen Gründen. Hierfür hätte ein großes FPGA genügt. Jemand wie ich, der im Boarddesign nicht die große persönliche Erfüllung sieht, würde daher konsequent auf FPGA(s) als Grundlage setzen und auch auf gesonderte Hardware-Prozessoren wie den 65816 verzichten.
Und jetzt zur Preisfrage: Wie teuer ist ein FPGA-Board, um erste Schritte in Sachen "Rechnerentwicklung" vorzunehmen? Die Antwort lautet: Irgendwas bis zu 20 Euro. Daybyter arbeitet zur Zeit an einem Projekt auf Basis des "ALTERA cyclone ll EP2C5T144 Minimum Development Boards". Hierzu hat er hier im Forum eine ausführliche Anleitung verfaßt, in der er auch auf ein fertig gestelltes Projekt verweist, in dem der Entwickler ein altes 6502-Computersystem auf dem Miniboard erzeugt. Natürlich reicht der eingebaute Blockramspeicher des Boards für größere Programme nicht aus. Da ist zusätzliches externes Ram gefragt. Aber preislich gesehen bereitet Ram heutzutage auch nicht mehr das Problem genauso wenig wie die Anschlüsse.
Hier ein Hinweis: Falls sich jemand für die aktive Entwicklung eines eigenen Rechners oder allgemein für die FPGA-Programmierung interessiert, kann er sich gerne an Daybyter wenden. Zur Zeit hat er eine VGA-Ausgabe an das Board gebastelt, und Tastatur und SD-Karte sollen bald folgen. Danach liegt es am FPGA-Programmierer, was genau er haben will, wie die CPU aussehen soll und welche Graphik-Modi vorhanden sein sollen. Nur ein Wort der Warnung: Wenn man sich selber mit dem Aufbau der Hardware beschäftigt, ist dies nicht nur eine allgemeine, nützliche Bereicherung, sondern man lernt auch, was alles eben nicht so einfach geht und warum das so ist.
Kurz gesagt: Für den Einstieg in die Entwicklung eines Rechners muß man gar nicht viel Geld ausgeben. Das kann eigentlich jeder leisten, und jeder kann daran mitarbeiten. Natürlich steht es frei, ein größeres FPGA zu nehmen oder gar den MiSTer mit vielen vorgefertigten Anschlüssen. Doch selbst bei den großen Boards liegt man preislich noch im genannten vertretbaren Rahmen. Von 30 Euro bis 150 Euro ist somit alles drin (, wenn auch ohne Gehäuse, Tastatur und andere Peripherie). Für den Einstieg reicht aber schon das Miniboard aus. Bis man in der Lage ist, dieses voll auszunutzen, dürfte einige Zeit vergehen.

Zitat von Retrofan

Der Rechner wäre nur zu dem OS kompatibel

Selbst das zu gewährleisten, wäre schon ein immenser Aufwand. Das Apple//gs-System ist vergleichbar mit dem TOS vom AtariST oder weiten Teilen des AmigaOS. Da wäre es wohl besser, von Anfang an auf die Entwicklung eines eigenen Systems mit eigenen Spielen zu setzen. Aber vielleicht könnte man beim Design ja darauf achten, daß die Spieleentwicklung nicht zu kompliziert wird, und ein paar Bibliotheken z. B. für die Graphik mitliefern. Auch die Verwendung einer Hochsprache würde in vielen Fällen die Entwicklung vereinfachen. Daher halte ich das Angebot an Tools wie Assembler, Compiler und Emulator auch für essentiell, um die Akzeptanz zu erhöhen. Nur darauf zu warten, daß andere die Spiele schreiben, die man gerne hätte, dürfte in der heutigen Zeit ohne kommerziellen Hintergrund nicht möglich sein.

Zitat von Retrofan

was denn an einer leistungsfähigen RISC-CPU "retro" wäre

Das käme auf das Design der CPU an. Ein ARM ist schon sehr mächtig, wie der Archimedes zeigt, nichtsdestoweniger ist aber auch der Archimedes schon "retro". Vom 68000 existiert eine Risc-Version namens ColdFire, die um ein paar Befehle reduziert wurde. Der 68000 an sich ist ja schon "retro", warum sollte es dann eine CPU mit vergleichbaren Befehlssatz nicht sein? Natürlich würde es nichts bringen, wenn man einen modernen ARM nehmen würde mit extrem hoher Taktfrequenz. Wenn, dann nur mit dem damals üblichen Leistungswert, d. h. auf der Basis des 6502 gerechnet vielleicht maximal etwas wie die SCPU. Mehr würde wahrscheinlich mit einem FPGA auch nicht gehen. Das Miniboard z. B. hat eine interne Taktfrequenz von 50 Mhz. Ein Befehl benötigt aber mehrere Taktzyklen zur Ausführung, so daß man effektiv auf einen wesentlich niedrigeren Befehlsdurchsatz kommt. Hinzukommt, daß der externe Speicher sehr stark ausbremst. Bei günstigem Ram kann die CPU-Einheit zusammen mit der Videoeinheit gar nicht so schnell auf den Speicher zugreifen, als daß man damit Taktraten von über 50 Mhz erzielen könnte.
Risc würde also nicht bedeuten "superschneller Prozessor", sondern einfach nur "reduzierter Befehlssatz zur einfachen Implementation", von der Programmierung her gesehen ein Mittelding zwischen 6502 und 68000, aber ohne die ganzen CISC-Adressierungsarten und -Befehle wie beim letzteren. Anders gesagt: So eine CPU wäre nicht Original-"retro", weil es sie damals nicht wirklich gab, aber ansonsten entspräche sie in Umfang und Leistung durchaus der damaligen Zeit.

Zitat von Retrofan

Ich würde, um alle potentiellen Kunden glücklich zu machen, anders als die meisten verfahren: Den Rechner als Komplett-Gerät mit interessantem Gehäuse und Verpackung anbieten/bewerben und ihn dann im Online-Shop frei konfigurierbar machen, inkl. des Verzichts auf Gehäuse und andere Annehmlichkeiten.

D'accord. Kann man gerne so halten. Man sollte aber zweierlei bedenken:
1.) Ein Gehäuse ist teurer als das Innenleben. Wirkt beim Kauf vielleicht etwas merkwürdig.
2.) Das Innenleben ist nicht sonderlich groß. Das Miniboard ist extrem klein, aber auch der MiSTer benötigt nicht gerade viel Platz in einem Gehäuse von der Größe einer Tastatur. Es sind eigentlich die Anschlüsse, die den Platz verbrauchen. Ansonsten ist da viel Luft.
Nichtsdestoweniger fände ich auch persönlich einen Rechner im Stil meines alten Amiga1200 sehr schick, und ein frei programmierbarer FPGA-Computer mit ein paar Anschlüssen und Tastatur wäre definitiv etwas, was auch mich zum Kauf motivieren würde. (Leider kann ich mich bis heute mit dem Design des C65 nicht sonderlich anfreunden.)

Zitat von Retrofan

Das käme auf das Gehäuse an. Ich glaube nicht, dass man es sich antun sollte, einen Tastatur-Computer zu konzipieren – zumindest nicht, wenn dafür auch noch das Keyboard gefertigt werden muss. Ich setze da eher auf ein externes Gehäuse (Kästchen), das zwar schick aussieht aber ansonsten nicht viel Spezial-Teile benötigt. Aber wenn man doch einen Homecomputer inkl. Keyboard haben möchte, wäre es vielleicht gut, vom Aufbau her an ein Notebook (ohne Display) zu denken. Man stelle sich ein keilförmiges Gehäuse vor, in dem ein Notebook-Keyboard steckt.

Ob Tastaturcomputer oder kleines Kästchen wäre mir letztendlich egal. Hauptsache, die Kiste funktioniert. Und ja, weder CPU noch Video noch Audio sind einfach zu implementieren. Was die reale Entwicklung anbelangt, so müßte man die Aufgaben halt angemessen aufteilen. Um das Design kümmern sich am besten die Leute, die auch was vom Design verstehen. (Bezieht sich auf das Gehäuse als auch die CPU. )

Zitat von Retrofan

Deswegen würde ich das Gehäuse auch nicht groß machen – sowas wie ein Apple-TV müsste eigentlich reichen – nur vielleicht etwas auffälliger.

Das Gehäuse sieht mir ein bißchen klein aus für die möglichen Anschlüsse, aber prinzipiell macht es Sinn. Mal eine Frage an die Druckexperten: Läßt sich ein Gehäuse in dieser Größenordnung von einem 3d-Drucker drucken?

Zitat von Retrofan

Ich sehe das Problem nicht bei der Realisierung der CPU [..] sondern bei der "Vermarktung".

Okay, da magst Du recht haben. Bin ja nur ein Möchtegern-Wozniak und kein Jobs.

Zitat von Retrofan

6502R

Zufällig ist "65R02" die Bezeichnung eines hypothetischen 6502-Nachfolgers, den ich mir vor Jahren mal ausgedacht hatte, wobei das "R" allerdings nicht für "Risc" steht, sondern für "Register", d. h. ein 6502 mit erweitertem Registersatz.

Nebenbei: Was vielleicht möglich wäre, um einem Benutzer ein bekanntes OS anzubieten, auf dem schon einige Programme - wenn auch nicht unbedingt Arcade-Spiele - laufen: Man könnte anstelle eines 6502 auch (Achtung: Häresie) einen Z80-kompatiblen Prozessor nehmen mit CP/M als EInstieg.

Zitat von Korodny

Wozu brauche ich denn einen Retro-Rechner, wenn...
- er einen modernen Prozessor bzw. einen Prozessor mit modernen Features hat
- in Hochsprachen programmiert wird
- ich nicht mit Registern hantiere, sondern eine Grafikbibliothek benutze?

- Was verstehst Du bei modernem Prozessor unter "moderne Features"? MMU? Out-of-Order sowie spekulative Ausführung? Fließkomma und SIMD-Befehle? Nichts von alledem hätte ein einfacher FPGA-Prozessor. Der Unterschied zum 6502 bestände in der Anzahl der Register (16 (15+sp) statt 4 (A,X,Y + sp)) und in den Adressierungsmodi. Letztere sind aber mitnichten mächtiger als das, was der 68000 bereits damals schon angeboten hat, eher weniger, weil reduziert auf die vier häufigsten und am einfachsten zu implementierenden Adressierungen. Auch der Z80 hat schon mehr Register als der 6502 und andere Adressierungsmodi, ist deswegen aber nicht modern.
Einen echten modernen Prozessor (x86 oder ARM) würde ich auch ablehnen. Da könnte man gleich auf dem PC oder dem Pi programmieren.
- Hochsprachen gab es schon damals und wurden auch - wie schon oft erwähnt - in der Spieleentwicklung eingesetzt. Hochsprache heißt ja nicht, daß man damit das ganze Programm schreibt, sondern nur die Teile, die z. B. nicht zeitkritisch sind wie Menüs. Auch bei einem 8 Mhz-Computer wird es weiterhin notwendig sein, bei Arcade-Spielen einen großen Teil in Assembler zu schreiben. Dieser Spaß bleibt also erhalten.
- Warum soll man als Programmierer nicht auf eine Bibliothek zurückgreifen dürfen? Für den AppleII gibt es einen ganzen Haufen Spiele, die z. B. die Linienroutine aus dem Rom gebrauchen, anstelle eine eigene zu verwenden. Wieso auch nicht? Programme sind mehr als nur ein paar Graphikroutinen. Der größte Teil eines Spiels besteht nicht aus Scrollroutinen oder Shapemalen, sondern aus der Programmlogik.

Zitat von Korodny

Programmierung in Assembler, es sei denn es geht um kleinere Tools oder weniger Speed-kritische Produktivanwendungen

Dagegen hat niemand was gesagt.

Zitat von Korodny

die Register des Grafikchips bzw. deren korrekte Nutzung zu kennen ist wichtiger als jegliche Programmiererfahrung, die ein potentieller Entwickler eventuell mitbringt

Verzeih, aber das stimmt schon für den C64 nicht. Allein mit Kenntnissen zur Nutzung der Register kommt man nicht weit, abgesehen davon, daß dies alle Programmierer auf dem AppleII oder anderen damaligen Homecomputern diskreditiert, da deren Rechner mit weitaus weniger Registern auskamen. Programmierung heißt "Algorithmen und Datenstrukturen", nicht Register.

Zitat von Korodny

BASIC möglichst beim Kaltstart

Nur daß sich zeilenorientiertes Basic auf einem neuen Rechner niemand mehr freiwillig antun möchte. Beim C64 ist es halt Nostalgie, weil man das so von früher noch kennt, doch diese Motivation fehlt heute. Da wäre das Booten in einen Texteditor zum schnellen Schreiben von Pascalprogrammen sinnvoller.

Zitat von Korodny

komische Grafikmodi mit diversen Einschränkungen

Hatte ich bereits vorgeschlagen.
Hardwarescrolling ja, aber nur wie beim C64, d. h. kein direktes Scrollen der ganzen Landschaft nur durch Umsetzen eines Registers (Startadresse der Bitmap).
Rasterinterrupt? Ja, klar. Das wäre auch nicht das Problem.

Zitat von Korodny

Aber hey, gut dass wir schon wieder mausbasierte graphische Benutzeroberflächen diskutieren.

??? Wann und wo wurde darüber diskutiert? GUI heißt nicht sofort mausbasierte graphische Benutzeroberfläche, sondern nur Graphische Benutzerschnittstelle. Das hatte bereits der CPC, denn der kannte gar keinen Textmodus.

Zitat von Retrofan

Auch ohne Druck-Experte zu sein, kann ich das mit "ja" beantworten.

Klingt gut. Danke für die Auskunft.

Zitat von Retrofan

ein paar USB-Buchsen [..] Bluetooth anbinden

Ich weiß, daß es sich hier nur um einen "Traumcomputer" handelt, aber trotzdem sei der Hinweis gestattet, daß USB- und Bluetooth jetzt nicht gerade die Anschlüsse sind, die man so einfach mal eben implementiert. Realistisch wäre da eher zunächst PS/2 und klassischer Joystickanschluß. Kann man sich damit begnügen, wäre solch ein leicht reduzierter "Traumcomputer" tatsächlich machbar.

Zitat von Retrofan

ich würde eher etwas nehmen, was besser zum 6502 passt,

Schon klar. Als alter 6502-Programmierer war der 6502 auch stets der Ausgangspunkt meiner Überlegungen. Nur gibt es leider für den 6502 kein so weit verbreitetes Betriebssystem mit einem Haufen lauffähiger Software. Für klassische 6502-Systeme benötigt man ein großes Mehr an Hardwareemulation, was nicht praktikabel ist.
Außerdem hatte ich es schon früher mal erwähnt: Eine brauchbare Erweiterung des 6502 führt automatisch dazu, daß der 6502 seine typischen Eigenschaftem verliert. Einen Prozessor mit mehr Registern programmiert man anders, z. B. bei der Übergabe von Parametern an eine Unterroutine. Im Grunde genommen ersetzen die Register die Zeropage als "schneller" Speicher für Werte sowie als Grundlage der indirekten Adressierung. 6502-kompatibel heißt daher nicht, daß Programme noch 6502-Charakter aufweisen.

Zitat von ogd

Wie ich ja schon mal per PN angeregt habe, halte ich eine hardwaremässige Scrollunterstützung, die über 8 Pixel hinausgeht, für überlegenswert, weil unnötig Rechenzeit verbraten wird. Soweit ich das weiss, wird das bei den 8 Bit-Ataris auch so gehandhabt. Klar die Möglichkeit, das ganze 'Playfield' vorzuhalten, ist schon sehr speicherintensiv. Aber warum ausschliessen, wenn es vieleicht einfach in den Grafikchip zu implementieren wäre?

Das ist die Frage: Ist es wirklich einfach zu implementieren?
Das Problem besteht im Umsetzen der Bildschirmadresse während des Bildaufbaus. WIe soll man bei einem vertikalen Scrollen bei einem Splitscreen (oben scrollen, unten HiScore) angeben, daß ab Zeile 200 ein anderer Bereich des Speichers als Bitmap interpretiert werden soll? Hierzu muß der Prozessor die Möglichkeit haben, die laufende Bitmapadresse im Videochip auf einen neuen Wert zu setzen. Beim horizontalen Scrollen kommt hinzu, daß hierzu (wie beim Amiga) ein Offset (oder Mod-Wert) angegeben werden muß, d. h. ein Wert, der zur aktuellen Bildschirmadresse hinzuaddiert wird, um den Anfang der nächsten Zeile im Speicher für jede Zeile neu zu berechnen. Hier hätte man bei einem Splitscreen sogar zwei Werte, auf die ein Prozessor (z. B. im Rasterinterrupt) einwirken müßte. Voraussetzung für die Änderung durch den Prozessor ist jedoch, daß die Änderung zu reproduzierbar gleichen Ergebnissen führt, also das Verhalten nachvollziehbar und vorhersehbar ist. Dies steht jedoch in Konflikt mit der Art und Weise, wie der Videochip intern funktioniert.
Die vornehmliche Aufgabe des Videochips ist es, die Videodaten vorab aus dem RAM-Speicher zu laden, damit sie passend an den Bildschirm geschickt werden können, schließlich kämpfen sowohl Prozessor und Videochip (oder andere DMA-Module) um diese wertvolle Ressource. Dies erfordert eine genaue Festlegung a) wann die Bildschirmadresse gültig ist, b) wann der Offsetwert auf die Bildschirmadresse addiert wird, und ob der Wert auf die Endadresse angerechnet wird (am Ende der Zeile) oder es zwei Adreßzähler gibt (einen für den Zeilenanfang und einen für die Zeile selbst).
Verwendet man dynamisches Ram für den Arbeitsspeicher hat man zusätzlich das Problem, die Daten schnell genug in den Speicher zu kriegen. Um Speicherzugriffe zu beschleunigen, kann man beim SDRam den Burstmodus verwenden, bei dem mehrere Speicherwörter direkt nacheinander übertragen werden. Dies setzt voraus, daß die Videoausgabe viele Taktzyklen vorher weiß, von welcher Adresse sie die Daten laden muß, da diese vorab in einem Puffer gespeichert werden müssen. Es kann sogar sein, daß es für die Videoausgabe erforderlich ist, alle Speicherwörter der kommenden Zeile intern zu cachen (s. VIC II), was voraussetzen würde, daß die Adreßberechnung bereits mindestens eine Zeile vorher stattfindet. Ein Programmierer müßte all diese nicht unveränderlichen Interna berücksichtigen, um zu verhindern, das z. B. eine falsche Zeile oder vorübergehend falsche Werte angezeigt werden. Eines sollte man aber aus der Vergangenheit lernen: Ein Programm sollte nicht darauf vertrauen, daß ein bestimmtes Timing auf ewig Gültigkeit hat, sei es bezüglich der CPU oder der Videoausgabe.
Aufgrund dieser (zumindest Anfangs-)Probleme beim Design einer Videoausgabe würde ich auf ein Hardwarescrolling, welches über die Bitebene hinaus auf die Adreßebene geht, zunächst verzichten. Aber das schreibe ich jetzt auch nur als Anfänger in der FPGA-Programmierung und auf Grundlage dessen, worüber ich mir an meinem grünen Tisch bislang Gedanken gemacht habe.