Hello, Guest the thread was called51k times and contains 1448 replays

last post from cbm_frank at the

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.

  • Wie muhahaha weiter oben schon geschrieben hat, habe ich mir heute auf der Make Munich auch mal das "Steckschwein" angeschaut. Ich finde diesen Weg persönlich recht gut. Natürlich muss man dafür mehr selbst basteln, klar. Hier wird einem sicher kein Computer alla Spectrum Next, MEGA65 usw. fertig mit Gehäuse und Tastatur auf den Tisch gestellt.


    Vom Steckbrett zu den nun schon fertigen Platinen. Ist doch auch schon ein guter Fortschritt.


    Hm, das Projekt beobachte ich weiter. Jucken tuts mich schon ein wenig.

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

    Code
    1. lda A ; lade zunächst den ersten Wert
    2. and B ; Beispiel für eine Verknüpfung mit B
    3. sta temp ; speichere Ergebnis in temporäre Variable
    4. lda C ; lade nun C
    5. and D ; führe zweite Verknüpfung aus mit D
    6. eor temp ; dritte Verknüpfung

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

    Code
    1. move a, d0
    2. and b, d0
    3. move c, d1
    4. and d, d1
    5. eor d1, d0

    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

    Code
    1. move disp16(Ax), d0
    2. bzw. mov eax, [esi + disp32]

    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:

    Code
    1. move disp16(sp), d0
    2. bzw. mov eax, [esp + disp32]

    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.

    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.

    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.

    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.

  • Preis: Für mich wäre ein Retro-Homecomputer vor allem auch ein Home-Computer. Der sollte kostengünstig sein. ... Ich denke, 99$ sind halt eine gewisse Grenze, 199$ auch. darüber wird die Luft dann schon dünner.


    Preis:
    ... 100 Euro halte ich daher für eine Schmerzgrenze, vielleicht noch bis 150 Euro, aber dann dürfte bei vielen Schluß sein, denn Kosten für eine eigentlich sinnfreie Anschaffung dürfen nicht weh tun


    Vom Preis bzw. den Kosten hängt ja im Grunde genommen alles andere ab. 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?

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

  • Will man unbedingt mehr, dann bitte mit dem Amiga oder andere echter Hardware.

    Du hast dahingehend recht, dass es nichts bringt, einen Retro-Rechner zu entwerfen, der den vorhandenen zu sehr ähnelt. Wenn der "verlorene C64-Nachfolger" kaum was anderes darstellt als ein Amiga 500, kann man sich die Arbeit auch sparen.


    J-Snake zeigte mir ein Spiel, das es auch bei Steam gibt, das lief auf einem C64er ähnlichen Maschine von der Grafik her, die es in Wirklichkeit nicht gibt. Aber Rechenzeit hat das Ding viel viel mehr als der C64er. Hat mich richtig geärgert.

    Ärgern muss man sich deswegen nicht. Aber es stellt sich halt die Frage nach der Angemessenheit, wenn ein C65-Nachbau optional mit 50 Mhz taktet und damit sämtliche Einschränkungen des Systems ad absurdum führt und die Kiste zu einem Super-Amiga mit 65xx-Label aufbohrt. Wer soll da noch sagen können, ob ein erstaunliches Spiel dem Entwickler zu verdanken ist oder einfach der hochgerüsteten Hardware.


    Warum würde das für euch besser sein als wie an einer der bereits existierenden 8-Bit-Kisten?
    Warum denkt ihr dass das andere Leute begeistern könnte?

    So eine Retro-Kiste macht nur Sinn, wenn sie "anders" ist, als das, was es schon gibt. Entweder muss sie eine Lücke füllen oder aber außergewöhnliche Eigenschaften haben. "Außergewöhnlich" meint aber nicht "besonders hoch, weit oder schnell", sondern eben "anders". Ungewöhnliche CPU, besondere Grafikmodi, besondere Farbpalette, selten genutzter Soundchip, besonders zugängliches Betriebssystem, leistungsfähige Programmierumgebung, besonders einfache Kopplung mit aktueller Technik/PCs, simple Steuerungsmöglichkeiten externer Hardware, natürlich alles OpenSource und lizenzkostenfrei (was bei ST, Amiga und manchen FPGA-Projekten immer noch nicht realisiert ist).


    ... 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.

    OK, insgesamt erklären mir deine Ausführungen gut, warum weder der 6502 noch der 65816 ein guter Kandidat für einen Retro-Rechner wären, der stark darauf setzt, dass man ihn gut in einer Hochsprache programmieren kann.


    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.

    OK, der IIGS ist also dann doch wohl zu komplex, um ihn einfach mal so als Gimmick "mitzuliefern". Es geht mir ja auch nur um den Grundgedanken, eine gewisse optionale Kompatibilität zu etwas existierendem herzustellen, um User der ersten Stunde nicht auf dem trockenen sitzen zu lassen, was Spiele etc. angeht. Ich sehe das aber auch nicht als zentral an und mir wäre auch die Wahl des Systems recht egal.


    Die Firma Apple würde es kaum zulassen, daß jemand anders sich ihres Betriebssystems bedient.

    Das würden wir ja nicht tun. Der Rechner wäre nur zu dem OS kompatibel, mitliefern würden wir es nicht (Apple bot es jahrelang offen zum Download an). Und es gibt jetzt sogar ein Update, das ein paar Fans umgesetzt haben, ohne dass das Apple (öffentlich) gestört hätte. Aber das Ganze macht natürlich keinen Sinn, wenn unser Retro-Rechner noch nicht einmal die gleiche CPU bekäme.


    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.

    Ja, der ARM war ein Erfolgsrezept, das bis in die heutige Zeit strahlt – mit dem Acorn Archimedes als erstem Homcomputer und dem Apple Newton als erstem Mobile-Device mit der CPU. Acorn und Apple haben mit der Gründung der ARM Ltd. der IT-Industrie einen großen Dienst erwiesen. Das war ein zukunftsweisendes Konzept aber ich befürchte, dass man "uns" einen Retro-Rechner mit einer RISC-CPU (womöglich sogar einem ARM, den man heute in jedem Smarty findet) nicht wirklich abnähme. Potentielle Interessenten würden sich fragen, was denn an einer leistungsfähigen RISC-CPU "retro" wäre. Damit würde das Projekt wahrscheinlich in eine ganz andere Richtung "driften" – von einem Retro- zu einem Experimental-Rechner. Das kann auch toll sein, wäre dann aber schon etwas anders gelagert.


    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.

    Auch das wäre dann das Projekt: Experimenteller Hobby-Computer. Ich persönlich fände ein Gehäuse wichtig – einfach weil es emotional ist, Kundenbindung hervorruft und den Wiedererkennungseffekt verstärkt. Für den Erfolg des Apple II (6,5 Mio. Einheiten) gegenüber dem Apple I (200 Einheiten) war unter anderem auch das Gehäuse verantwortlich. Für den Mega65 würde sich wahrscheinlich kaum jemand interessieren, wenn er nicht das Gehäuse des C65 nachbilden würde. Das Konzept verkauft sich quasi NUR über das Gehäuse – zumindest an die Zielgruppe, die sich jetzt dafür begeistert.


    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 – notfalls bis zum reinen Schaltplan plus Bauteile-Liste (für die ganz harten).

  • So eine Retro-Kiste macht nur Sinn, wenn sie "anders" ist, als das, was es schon gibt. Entweder muss sie eine Lücke füllen oder aber außergewöhnliche Eigenschaften haben. "Außergewöhnlich" meint aber nicht "besonders hoch, weit oder schnell", sondern eben "anders". Ungewöhnliche CPU, besondere Grafikmodi, besondere Farbpalette, selten genutzter Soundchip


    Diese außergewöhnlichen Eigenschaften sollten mMn aber kein reiner Selbstzweck sein und immer die Entwicklersicht berücksichigen.


    Um mal ein Beispiel zu nennen: Weiter oben wurde als Kontrast zum SID-Chip der Yamaha-Chip mit FM-Synthese vorgeschlagen, der vom PC bekannte Adlib-/SB-Sound. Damit sind zwar ungewöhnliche Klänge möglich, das ist richtig. Aber das Sounddesign ist sehr komplex, weil schwer vorhersagbar, im Vergleich zu der eher intuitiven subtraktiven SID-Klangerzeugung. Ein Kompromiss wäre vieleicht die Möglichkeit, die Grundwellenformen auch aus kurzen Samples zusammenstellen zu können.

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

    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.

    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.)

  • Diese außergewöhnlichen Eigenschaften sollten mMn aber kein reiner Selbstzweck sein und immer die Entwicklersicht berücksichigen.

    Klar. Zu Soundchips kann ich nicht viel sagen, da kenne ich mich nicht mit aus. Aber wenn man sich z.B. die Grafik anguckt, fand ich M. J.s Vorschlag gut, der die Grafik-Eigenschaften des C64 geschickt aufbohrt – aber (trotz ähnlicher Auflösung) nicht identisch zu Amiga- oder ST-Grafik macht. Man müsste somit als Grafiker immer noch über mögliche Colorclashes nachdenken und kann nicht einfach 16 oder 32 Farben aus einer sehr großen Palette über die ganze Fläche "schütten". Auch wenn die horizontale Auflösung des C64 quasi verdoppelt würde, wäre es in Grundzügen immer noch C64-ähnlich und nicht etwas, was man von 16-Bittern erwarten würde. Die Arbeitsweise wäre beim Pixeln genauso, wie man es vom C64 kennt, nur eben mit 320 statt 160 Pixeln horizontal. Das würde den erfahrenen 8-Bit-Pixlern sehr entgegen kommen – und trotzdem wäre es auch neu.

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

    Ich sehe das Problem nicht bei der Realisierung der CPU (klar, wenn man davon keine Ahnung hat) ;) sondern bei der "Vermarktung". Wenn der Kunde was von RISC oder ARM liest, denkt er womöglich an eine leistungsstarke CPU (anders als beim Begriff 8-Bit) und erwartet dann evtl. zuviel bzw. ist enttäuscht von dem, was er letztendlich auf dem Screen zu sehen bekommt – was sich wiederum negativ auf die Reputation der Software-Entwickler auswirkt. Dass wir RISC nur genommen haben, weil es für den Programmierer angenehm ist und ihm unnötigen Ärger erspart (oder wahlweise mehr Spaß bereitet), wird der einfache User/Spieler nicht sehen. Man muss also tiefstapeln, von 65ARM02 oder 6502R oder ähnlichem als CPU sprechen und vermeiden, Assoziation mit modernen 2-GHz-8-Kern-Smartphones zu befördern. Es muss klar sein, dass man sich bzgl. der Leistungsfähigkeit zwischen 8-Bit und 16-Bit bewegt, nur halt einfacher programmierbar.


    1.) Ein Gehäuse ist teurer als das Innenleben. Wirkt beim Kauf vielleicht etwas merkwürdig.

    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.



    Sowas kostet bei AliExpress rund 10$.


    2.) Das Innenleben ist nicht sonderlich groß.

    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.


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


    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?


    Ich hab den Thread jetzt nicht noch mal komplett gelesen, aber hat überhaupt schon jemand die Frage nach der Zielgruppe gestellt? Neben Sammlern sind das doch in erster Linie Hacker, Coder, Bastler etc. mit Retro-Bedürfnis. Wenn der Rechner nicht dem möglichst nahe kommt, was einen typischen Heimcomputer der Achtziger ausgemacht hat, wieso sollten sie ihn sich dann zulegen?


    • Programmierung in Assembler, es sei denn es geht um kleinere Tools oder weniger Speed-kritische Produktivanwendungen
    • die Register des Grafikchips bzw. deren korrekte Nutzung zu kennen ist wichtiger als jegliche Programmiererfahrung, die ein potentieller Entwickler eventuell mitbringt
    • BASIC möglichst beim Kaltstart, samt halbwegs brauchbarem Handbuch ("up, up and away!")
    • komische Grafikmodi mit diversen Einschränkungen. Außerdem Sprites, Hardwarescrolling, Raster Interrupts


    Aber hey, gut dass wir schon wieder mausbasierte graphische Benutzeroberflächen diskutieren. Das hatten wir schon länger nicht mehr :P


    Quote

    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.)


    Das kann man ja ja auch optional machen. Niemand sagt dass der Rechner nur mit Gehäuse verkauft werden darf. Ein gutes, neues Tastaturgehäuse habe ich bisher aber noch nicht gesehen - zumindest keines, was über den Status eines gerenderten Bilds hinausgekommen wäre.

  • 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. ^^ )

    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?

    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. ^^

    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. ^^

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

    Tun wir das?


    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?

    Auch ohne Druck-Experte zu sein, kann ich das mit "ja" beantworten. Das Apple TV ist unter 10 x 10 cm groß und damit selbst mit den billigsten Selbstbau-3D-Druckern herzustellen. Ein bisschen größer würde ich zwar schon werden wollen – aber selbst 20 x 20 cm wären noch mit einigen Billig-Druckern (unter 500 Euro) zu machen (zumindest wäre der Bauraum dafür ausreichend).


    Ich sehe ja gar nicht so viele Anschlüsse: Micro-USB für die Stromversorgung (das macht das Netzteil optional), ein paar USB-Buchsen, irgendein Monitor/TV-Anschluss, Audio-Cinch, SD-Karten-Slot auf der Vorderseite. Joysticks etc. würde ich ohnehin per Bluetooth anbinden, gerne im Retro-Look. Vielleicht fehlt noch ein Anschluss, mit dem man etwas auf einfache Art und Weise steuern kann.


    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.

    Er hat Jehova gesagt! ich würde eher etwas nehmen, was besser zum 6502 passt, wenn man dessen Architektur als Basis für die Verbesserungen nimmt.

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

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

    Dagegen hat niemand was gesagt.

    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.

    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.

    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.

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

    ??? :nixwiss: 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.

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

    Klingt gut. Danke für die Auskunft.

    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.

    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.

  • Hardwarescrolling ja, aber nur wie beim C64, d. h. kein direktes Scrollen der ganzen Landschaft nur durch Umsetzen eines Registers (Startadresse der Bitmap).


    Wie ich ja schon mal per PN angeregt habe, halte ich eine hardwaremässige Scrollunterstützung, die über 8 Pixel hinausgeht, für überlegenswert, damit nicht 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?


    Eine andere, C 64 konformere Lösung wäre, den Beginn des Screen- bzw. Bitmap-Speichers innerhalb der 1024- bzw. 8192-Byte-Grenzen frei positionierbar zu machen. Wenn die erste Zeile zum Beispiel an Adresse 1024+40 beginnt, werden die Daten der letzen Zeile von Adresse 1024 geholt. Die CPU braucht sich dadurch weniger um monotone Kopieraktionen kümmern.

  • Was verstehst Du bei modernem Prozessor unter "moderne Features"?

    Ziemlich das, was du aufzählst ;) Hier war ja bereits von ARM die Rede. Ich habe mit m68k keine Erfahrungen - aber ich würde die Grenze irgendwo dort ziehen, wo ein Compiler u.U. ähnlich effektiven Code erzeugt wie ein Mensch. Ich will, dass das System mich zwingt ASM zu benutzen, wenn ich (bspw.) Hardware-Scrolling haben will. Ansonsten ist es mit "Retro" IMHO nicht weit her.


    Mir ging es aber auch darum, dass der Retro-Rechner ja ASM.-Coder als Zielgruppe anvisiert. Das schränkt die Auswahl eben auf 6502 (bzw. 65816), m68k und (mit Einschränkungen) Z80 ein - schlicht weil das die Prozessoren sind, die die Leute "können". Wie viele aus der potentiellen Zielgruppe können ARM-Assembler oder sind bereit, einen komplett neuen Befehlssatz zu lernen?


    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.

    Sicher, aber Programmlogik hat ja wenig mit Retro zu tun. Wenn sich die Programmierung des Systems nicht "retro" anfühlt, wo liegt dann der Reiz für einen Retro-Programmierer? Ich halte Grafik- und Soundprogrammierung per Chip-Register für eines der wesentlichsten Elemente beim Retro-Coding: "Banging the metal". Abstrahiere ich das, verliere ich außerdem Leistung - die das System durch erhöhte CPU-Ressourcen kompensieren müsste - nicht meine Vorstellung von Retro.


    Klar, dem Rechner eine kommentierte ASM-Routine für Hardware-Scrolling mit Double-Buffering beilegen - dafür bin ich sofort zu haben. Eine Bibliothek mit einer Schnittstelle? Nein danke.


    Verzeih, aber das stimmt schon für den C64 nicht. Allein mit Kenntnissen zur Nutzung der Register kommt man nicht weit

    "Programmiererfahrung" im Sinne von "weiß was eine Rekursion ist und hat mal ungarische Notation gelernt". Mir ging es darum, dass Spiele-Entwicklung auf einem Retro-System etwas völlig anderes ist als in einer Hochsprache auf Basis von SDL zu entwickeln.


    Nur daß sich zeilenorientiertes Basic auf einem neuen Rechner niemand mehr freiwillig antun möchte.

    Wie das nun im Detail aussehen würde, muss man sich halt noch überlegen - dass muss ja nicht zwangsweise zeilenorientiert sein. Aber einschalten, paar Zeilen aus dem Handbuch abtippen, ein Heißluftballon segelt über den Schirm: so sehen minimale Einstiegshürden aus - "ich hab was programmiert!". Keine Editoren, Bibliotheken und Compiler installieren/nachladen, keine Bibliotheks-Header einbinden, keine Compiler-Durchläufe...


    Nicht zu vergessen der Punkt, den bereits jemand erwähnt hatte - eine minimal strukturierte Sprache ist (a) leichter zu erlernen und (b) näher an der Maschinenlogik - hilft also beim "Umstieg" auf Assembler. Ich hab in der Hinsicht noch nichts gesehen, was BASIC das Wasser reichen könnte.


    ??? :nixwiss: Wann und wo wurde darüber diskutiert?

    Oh, scheint als wäre die "GEOS oder doch lieber was anderes"-Bemerkung, die ich im Kopf hatte wohl in einem der anderen Retrocomputer-Threads gefallen. Aber auch hier war von "Der Rechner wäre nur zu dem [IIgs] OS kompatibel" die Rede...

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