Hallo Besucher, der Thread wurde 180k mal aufgerufen und enthält 1853 Antworten

letzter Beitrag von Retrofan am

Neuer Retro-Computer im 8-Bit Style

    Zitat von Unseen

    Meines Wissens ist auch Bluetooth reichlich komplex, wenn man den Stack selbst implementieren will.

    [I/O] Die Frage ist, ob man das muss. Müssen tut das ja meistens nur der Erste, der so etwas machen will. Wären wir "der Erste?"


    ---


    Noch etwas zum HDMI/DVI-Output: Wahrscheinlich gibt es doch 2 Möglichkeiten: Entweder das nackte, nicht hochskalierte, Bild über den Port jagen und hoffen, dass der TV-/Monitor-Upscaler das auf die Bildschirm-Fläche hochzieht (2K, 4K, 8K). Allerdings hätte man bei dieser Lösung keinen Einfluss auf die Art und Weise und Qualität. Und man hätte natürlich auch keine Scanlines etc. Oder aber man müsste vor der HDMI-Ausgabe halt einen Upscaler integrieren, der das Bild skaliert/optimiert. (Gibt es sowas schon? – Die beiden C64-Beschleuniger haben sowas doch z.B. auf ihrem FPGA)

    Also nach meiner Überlegung müsste man eh sowas wie 640x540 ausgeben und die Pixel horizontal 3x ausgeben und vertikal 2x. Weil: die verbauten Rams haben einfach nicht die Bandbreite, um einen Bildschirmspeicher für 1920x1080 auszulesen. Das würde den Bus mindestens komplett dicht machen, d. h. die CPU könnte kein Programm mehr ausführen.

    D. h. es spart hauptsächlich das Geld für den Konverter und paar Pins am fpga.

    Zitat von daybyter

    Also nach meiner Überlegung müsste man eh sowas wie 640x540 ausgeben und die Pixel horizontal 3x ausgeben und vertikal 2x.

    [Grafik, I/O] Mögliche native Auflösungen hatte ich ja schon zur Genüge genannt (war dafür wohl zu früh), vertikal wäre man aber immer eher so im 200er-Bereich (z.B. 1080/5). Die Frage ist eher, ob man auf dem großen Fernseher kantenscharfe Retro-Pixel sehen will (wurde ja schon kritisiert) oder ob man das Bild erst aufbereiten will/muss (das hatte ich ja schon simuliert und gepostet). Und falls letzteres, muss man gucken, ob man das noch auf dem FPGA schafft (wohl eher nicht, wenn ich das hier so lese) oder ob man dafür einen zweiten günstigen FPGA nimmt oder aber einen dedizierten "Baustein" (falls es sowas gibt – aber es soll ja schon vereinzelt Geräte geben, die HDMI bzw. DVI ausgeben können).

    Da finde ich z.B. Gideons Loesung cool, er liefert ein normales PAL-Signal auf HDMI, optional mit Scanlines (jede 2. Zeile in der halben Helligkeit). Das sieht eigentlich ziemlich gut aus auf einem modernen Geraet, finde ich. Wenn man es direkt davor auf FullHD hochskaliert und dann noch Scanlines oder sowas will, kostet es auf jeden Fall mehr Rechenzeit, die soweit ich weiss auf dem U64 nicht zur Verfuegung steht. Und es kostet evtl auch Frame-Zeit, sprich es erzeugt Latenz.

    Zitat von ZeHa

    Und es kostet evtl auch Frame-Zeit, sprich es erzeugt Latenz.

    [I/O] Wieso, wenn es z.B. auf einem zweiten, unabhängigen, FPGA (oder etwas ganz anderem) liefe. Noch hat niemand meinen Vorschlag kommentiert, die modernen Schnittstellen komplett vom Haupt-FPGA zu trennen. Mich würde mal interessieren, ob das eine denkbare Lösung wäre oder wo dabei das Kern-Problem stecken würde.


    Zitat von ZeHa

    optional mit Scanlines (jede 2. Zeile in der halben Helligkeit)

    Das wäre ja auch so die "billigste" Art, Scanlines darzustellen. In meinen Beispiel-Mockups habe ich z.B. "weiche" Scanlines verwendet, die zudem weniger hoch sind als die Pixel-Zeilen. Das wäre ein "einfacher" Overlay, dazu käme bei einer simplen CRT-Simulation noch Unschärfe (Blur). Ich habe aber auch schon mit Pixel-Simulationen gespielt, die helle Pixel die Scanlines stärker überstrahlen lassen als dunkle (was CRTs auch tun). Das ginge aber wohl schon zu weit. Aber einfach jede 2. Zeile etwas dunkler ist schon recht "vereinfacht". ;) (aber natürlich besser als nix)

    Da kenne ich mich zu wenig aus - wenn das on-the-fly prozessiert werden koennte, dann wuerde es gehen. Wenn aber erstmal das Bild fertig sein muss und DANN nochmal "crt-isiert" werden soll, dann eher nicht. Ist halt die Frage ob ein externer FPGA on-the-fly das gleiche tun koennte wie eine Phosphor-Schicht auf nem CRT... wenn ja, dann gerne so :)

    Zitat von Retrofan

    [I/O] Bisher ist niemand von den technisch Versierten auf meinen Vorschlag eingegangen, das "Retro-Board" komplett vom "Modern-Board" mit den modernen Schnittstellen zu trennen, intern also "oldschool" (VGA, PS/2) zu reden und nur nach außen modern.

    [I/O] Ich muß gestehen, daß ich das nicht verstanden habe. Was willst Du wovon trennen? Was bedeutet hier innen und außen? Wenn Du meinst, daß der FPGA ein VGA-Signal erzeugt, welches später durch andere Hardware auf HDMI umgesetzt wird: Ja, das geht. Vielleicht gibt es auch einen Konverter für PS/2-Tastatur und USB-Tastatur. Bin kein Techniker und kenne sowas nur von meiner alten Maus. So oder so: Wenn der FPGA den VGA-Standard 640x480 erzeugt, wird daraus auch nach der Umwandlung nur 640x480. Andere Auflösungen, die sich an HD orientieren, sind für VGA bzw. den Konvertern "krumm", d. h. es kann passieren, daß diese als nichtkonforme Auflösung verweigert werden und die Anzeige dunkel bleibt. Und zuletzt bringt anderes VGA-Timing bei anderen Auflösungen das interne Timing des FPGAs kompletet durcheinander. Zur Zeit arbeiten die Schaltungen im FPGA (Video, Prozessor, Tastatur, SD-Karte, Audio) auf Grundlage eines 50 Mhz-Taktes. Eine von 640 abweichende VGA-Auflösung würde einen anderen Takt verlangen mit Auswirkungen auf alle anderen Module.

    Zitat von Retrofan

    [I/O] Was tut eigentlich der von mir hier verlinkte, aktive Adapter von USB-Gerät auf PS/2-Buchse?

    [I/O] Hast Du den Link noch irgendwo? Ich kann ihn nicht mehr finden.

    Zitat von Retrofan

    Kann man also sagen, ohne das überprüft zu haben, Bluetooth wäre noch schlimmer?

    Ob "schlimmer" oder "ein bißchen weniger schlimm" spielt keine Rolle. Der Aufwand ist in beiden Fällen sehr groß-

    BlueTooth und USB sind anders als z. B. ein Joystickanschluß. Es reicht nicht aus, einzelne Bits auszuwerten, um zu sagen: Jetzt wird der Joystick nach oben bewegt" oder "jetzt wird der Button gedrückt". Beide verhalten sich so wie HTML zu Ethernet. Um im Internet surfen zu können, reicht es auch nicht aus, einfach nur das Kabel in den Rechner zu stecken. Dazu gehört, daß es im Rechner ein Programm gibt, welches in der Lage ist, Internetpakete zu senden und (geordnet) zu empfangen. Und darauf aufbauend bedarf es noch eines Browsers, der die Inhalte der Datenpakete passend interpretiert als z. B. ftp oder http. Für letzteres z. B. ist notwendig, daß der Browser die Sprache html mit ihrer Syntax und den Schlüsselwörtern versteht, um daraus dann die eigentliche Seite aufzubauen. Mit USB oder BlueTooth ist es ähnlich, wenn auch nicht ganz so schlimm. Auf unterster Ebene muß zunächst mal dafür gesorgt werden, daß überhaupt eine Kommunikation stattfindet. Hier können bei BlueTooth z. B. gesonderte Chips helfen. Aber früher oder später kommt die Ebene, in der man die empfangenen Daten interpretieren muß (also ftp oder html beim Internet). Dazu muß man aber erst einmal wissen, wie die Syntax aufgebaut ist, welche Befehle es gibt, und was die genau bewirken. Und dann muß man daraus irgendwie eigenen Code entwickeln, der das alles leistet.


    Und jetzt stell Dir mal vor, dies sollte ein neuer 8 Bit-Rechner schaffen... Unmöglich. Allein der Code, der dafür notwendig ist, sprengt die 64 kb des Homecomputers, abgesehen davon, daß er zu langsam ist für die Kommunikation.


    Und jetzt stell Dir mal vor, dies sollte ein neuer 32 Bit-Rechner schaffen. Nicht ganz unmöglich, aber zu welchem Preis? Man braucht auch hier zusätzliche Mengen an Speicher und Code, nur um das USB-Protokoll zu bedienen. Das wiederum bedeutet, daß es ein Betriebssystem geben muß, welches die Daten rechtzeitig (per Interrupt) übernimmt und auswertet. Und das ist der Todesstoß für jede bare metal-Programmierung, wenn stets im Hintergrund ein OS mitlaufen muß, welches Dein Programm unterbricht wann und wie es will, nur um eine Taste in Empfang zu nehmen oder zu wissen, ob ein Button an einem Controller gedrückt wurde.


    Abgesehen davon ist ebenso eine Voraussetzung dafür,

    a) daß die Art und Weise, wie die Geräte kommunizieren, offen einsehbar ist, d. h. die Herstellerfirmen stellen freiwillig im Internet die Informationen zur Verfügung, wie ihre Geräte funktionieren, und verdongeln diese stattdessen nicht mit ihrem Treiber,

    b) daß es eine oder mehrere Personen gibt, der/die ohne Bezahlung den Fulltime-Job übernehmen und in monatelanger Arbeit eigene Treiber schreiben.


    Kurz: Selbst wenn es für einige Sache vorgefertigte (Chip)Lösungen gibt, bleibt es ein enormer Kosten- und Zeitaufwand.


    Eine gängige Lösung ist daher, daß der Rechner aus zwei Rechnern besteht: a) die Zielplattform (der Retrorechner) und b) ein ARM mit einem Linux(artigem) System, welches die USB-Kommunikation übernimmt und nur noch das fertige Ergebnis an den Retrorechner sendet. Das Verhältnis zwischen Retrorechner und ARM ist jedoch ungefähr so, als hätte man Steve Wozniak damals[tm] gesagt: "Okay, dein Apple-Rechner ist ja ganz in Ordnung, aber das mit der Tastatur, das geht so nicht. Dafür mußt du deinen Apple an eine Cray anbinden."

    Zitat von Retrofan

    [I/O] Die Frage ist, ob man das muss. Müssen tut das ja meistens nur der Erste, der so etwas machen will. Wären wir "der Erste?"

    [I/O] Die Allerersten. Selbst wenn man - wie gesagt - teilweise auf vorgefertigte Chips zurückgreifen kann, die einen Teil der Arbeit übernehmen (z. B. Codierung für die BlueTooth-Übertragung), bleibt es am Ende ein Riesenaufwand. Frage: Warum verwendet auch der Commander X16 nur PS/2-Tastaturen und VGA? Antwort: Genau deswegen.

    Zitat von Retrofan

    Die Frage ist eher, ob man auf dem großen Fernseher kantenscharfe Retro-Pixel sehen will

    [Video] Wäre dafür. Warum soll man sich verwaschene Bilder angucken? Nur weil die Qualität der Bildschirme damals[tm] schlecht war? Gerade, wenn man auch mal irgendwie Text schreiben will, braucht man eine saubere Darstellung.

    Zitat von Retrofan

    Mögliche native Auflösungen hatte ich ja schon zur Genüge genannt

    [Video] Da das FPGA zunächst nur die Standard-VGA-Auslösung 640x480 erzeugt, müßte man alle anderen Auflösungen da reinpressen. Wenn danach noch die VGA-Auflösung an einen HD-Bildschirm ausgegeben wird, hat man lustige, dicke schwarze Balken überall. Und ja, im Prinzip hätte ich auch gerne einen 16:9-Bildschirm bei entsprechend aufgelöster Grafik. Geht aber zum jetzigen Zeitpunkt leider nicht.

    Zitat von Retrofan

    einen zweiten günstigen FPGA

    [FPGA, Video] Daybyter hatte ja schon gepostet, was so ein billiges Board mit HDMI kostet. Das wäre einfacher und wohl auch günstiger als zwei FPGAs zu nehmen, die auf einem speziell dafür gemachten Motherboard sitzen. Man muß sich dann aber von dem Gedanken verabschieden, daß sowas mit 50 € zu machen ist.

    Frag doch mal die Mister Leute, wie viel FPGA-Ressourcen dort der HD-Scaler mit seinen ganzen Scanline/Filter-Optionen belegt!


    Meine Schätzung ist, dass man dann M.J.s Einsteiger-Cyclone2 völlig vergessen kann, und auch der Cyclone 3/4 von MiST und SiDi nicht reichen.

    Dann nimmt man gleich den DE10-nano vom Mister, weil alles Vergleichbare ähnlich teuer ist, und es für den Mister nunmal schon alle nötige Infrastruktur gibt.

    Zitat von M. J.

    Das Verhältnis zwischen Retrorechner und ARM ist jedoch ungefähr so, als hätte man Steve Wozniak damals[tm] gesagt: "Okay, dein Apple-Rechner ist ja ganz in Ordnung, aber das mit der Tastatur, das geht so nicht. Dafür mußt du deinen Apple an eine Cray anbinden."

    Der Apple II- mit Cray für Tastatur Vergleich bringt es auf den Punkt. Andererseits hängen Leute einen RasPi3 an den C64 um einen 6502 in den Commodore Floppies zu simulieren.

    Und ich schätze der RasPi3 hat 100 mal mehr Wumms als eine Cray1 und ne Million mal mehr als der simulierte 6502.


    MiST hat auch einen 48MHz ARM-M-irgendwas für USB nach legacy und Mister nutzt defür 2 ARM-Cortex-7 mit 800MHz und Linux drauf.


    Für Bluetooth/Wifi könnte man einen 5€ ESP32 benutzen.


    Ist halt dann ein Retro-Modern-Mix.

    Man darf dann halt nicht annehmen, dass es so einen Computer vor 30-40 Jahren hätte geben können.


    Das finde ich auch lustig an Gigatron: da werden Chips verwendet, die es so prinzipiell auch 1977 gegeben hätte.

    (Allerdings wären die 32KB SRAM und das 128KB ROM damals auch kaum bezahlbar gewesen)

    Bzgl. Scan-Converter gibt es ja auch den Open Source Scan Converter (OSSC), der alles mögliche nach HDMI wandelt und wohl vielfältige Settings hat.

    https://github.com/marqs85/ossc


    FPGA scheint ein Cyclone 4 EP4CE15E22 zu sein.


    Ich seh halt nicht, warum M.J. seinen Core in einen winz-Cyclone2 quetscht, damit daneben dann nochmal ein fetter FPGA steckt, damit man VGA nach FullHD-HDMI aufbläst.


    Dann wird es billiger und einfacher gleich einen fetten FPGA zu nehmen. Und die Löterei spart man sich halt auch weitgehend, wenn man mit dem DE10-nano auskommt.

    Wobei Mister ja noch für SDRAM und Legacy-IO (DB9, VGA, yeah) diverse Addon-Boards hernimmt.

    Zitat von ZeHa

    Gerade der MiSTer waere ja ein Beispiel wo der FPGA mit einem ARM kombiniert wird. Koennte das ganze Scaling usw nicht auch der ARM machen?

    Vielleicht, aber der FPGA wird es sicher mit weniger Latenz machen. Die ARM Cores vom Mister haben ja keine GPU/VideoCore Teile für irgendwelche Pixelshader, wie sie Emulatoren auf ARM-SoCs wie RasPi und Co verwenden.

    Zitat von ZeHa

    Koennte das ganze Scaling usw nicht auch der ARM machen?

    Gerade solche langweiligen Video-Verarbeitungs-Pipeline-Sachen sind eigentlich ziemlich gut für einen FPGA geeignet. Erst wenn du wilde Zugriffe kreuz und quer in der Grafik machen willst oder abhängig vom Bildinhalt unterschiedlich lange Berechnungen durchführen willst wird es evtl. einfacher, den Job einer CPU zu übergeben.


    Und Nearest-Neighbour-/Bilinear-Scaling eines Bildsignals ist echt langweilig. Die lästigsten Elemente daran sind noch die Zeilenpuffer (zwei reichen für NN, Bilinear bräuchte vermutlich drei) und der Datentransfer in eine andere Taktdomäne.

    Zitat von M. J.

    Ich muß gestehen, daß ich das nicht verstanden habe. Was willst Du wovon trennen? Was bedeutet hier innen und außen? Wenn Du meinst, daß der FPGA ein VGA-Signal erzeugt, welches später durch andere Hardware auf HDMI umgesetzt wird: Ja, das geht.

    [Video] Warum wird sowas nicht früher nachgefragt? Ich hatte hier bestimmt schon 3 bis 5 mal versucht, das zu erklären. Im Prinzip liegst du aber richtig.


    Zitat von M. J.

    Vielleicht gibt es auch einen Konverter für PS/2-Tastatur und USB-Tastatur.

    [I/O] Ja, gibt es. Hatte ich schon gefunden und verlinkt. Und zwar in die richtige Richtung, also von USB-Gerät auf PS/2-Anschluss, natürlich "aktiv".


    Zitat von M. J.

    Wenn der FPGA den VGA-Standard 640x480 erzeugt, wird daraus auch nach der Umwandlung nur 640x480. Andere Auflösungen, die sich an HD orientieren, sind für VGA bzw. den Konvertern "krumm", d. h. es kann passieren, daß diese als nichtkonforme Auflösung verweigert werden und die Anzeige dunkel bleibt.

    [Video] Naja, wenn wir den "Umwandler" selber machen, können wir ja darauf achten, dass er z.B. auch mit 640 x 216 Pixeln klarkäme, bzw. diese Untermenge für die Skalierung extrahiert.


    Zitat von M. J.

    Hast Du den Link noch irgendwo? Ich kann ihn nicht mehr finden. (zu: aktive Adapter von USB-Gerät auf PS/2-Buchse)

    [I/O, Thread] Muss ich selbst im Thread suchen. Nachdem ich hier etwas verlinke, schließe ich normalerweise den Quellen-Tab.


    Zitat von M. J.

    Und jetzt stell Dir mal vor, dies sollte ein neuer 8 Bit-Rechner schaffen... Unmöglich.

    Zitat von M. J.

    Und jetzt stell Dir mal vor, dies sollte ein neuer 32 Bit-Rechner schaffen. Nicht ganz unmöglich, aber zu welchem Preis?

    [Video] Du hast meine Idee der getrennten Boards noch immer nicht "verinnerlicht". Dein Core braucht das nicht zu können. Der schickt irgendwelche Uralt-Signale raus, die ein anders Board (oder Chip) dann für die heutige Welt übersetzt.


    Zitat von M. J.

    "Okay, dein Apple-Rechner ist ja ganz in Ordnung, aber das mit der Tastatur, das geht so nicht. Dafür mußt du deinen Apple an eine Cray anbinden."

    [I/O] Das wäre auch damals völlig OK gewesen, wenn die Cray in eine Streichholzschachtel gepasst und 5 Dollar gekostet hätte. Ich sehe das nicht als so großes Problem an. Guck dir z.B. das SD2IEC oder die 1541U oder die WiFi-Modems am C64 an. Jedes dieser Geräte übertrifft den C64, an dem sie hängen, wahrscheinlich um das Tausendfache, wenn es um Rechenleistung geht. Das ist egal, wenn die Dinger nur klein genug sind und "nichts" kosten. Die WiFi-Modems mit ESP8266 haben auch gleich den ganzen TCP/IP-Stack drauf – da muss sich der C64 nicht drum kümmern – das würde ihn auch ganz schön belasten. Aus Sicht des C64 ist dieser WLAN-Internet-Zugang im Prinzip ein altes Modem – der weiß nichts vom großen Internet und kann trotzdem darauf zugreifen.


    Zitat von M. J.

    Riesenaufwand. Frage: Warum verwendet auch der Commander X16 nur PS/2-Tastaturen und VGA? Antwort: Genau deswegen.

    [I/O] Und deswegen kommen auch Nintendo-Controller-Ports zum Einsatz. Gruselig. Mir ist schon klar, warum das gemacht wird – weil es einfach ist.


    [Team] Bei allen Entwicklungs-Sachen gibt es quasi eine Art Schiebe-Regler, mit dem man einstellt, wem man die Komplexität und Probleme "zuschieben" will – den wenigen Entwicklern oder den vielen Usern, die später das Produkt nutzen sollen. Der Designer innerhalb eines Developerteams ist meistens der Anwalt der User und sagt: Die Schwierigkeiten halsen wir dem Programmierer auf. ;) Der Programmierer will den Schieberegler meistens in die andere Richtung bewegen. Das ist jedesmal ein Quell für "lustige" interne Diskussionen.


    [I/O] Ich finde es, ehrlich gesagt, schon recht gewagt, den Käufern des X16 zuzumuten, dass sie sich einen alten VGA-Schirm suchen sollen (was wahrscheinlich von der Beschaffung her noch die einfachste Übung ist) und darüber hinaus eine PS/2-Tastatur (die ich nur im Haus habe, weil ich auch SGIs sammle) und Nintendo-Controller (bei denen ich passen müsste). Und dieser Geräte-Zoo hat sicherlich einen WAF (und damit Wohnzimmer-Tauglichkeit) von exakt Null.


    Zitat von M. J.

    [Video] Wäre dafür. Warum soll man sich verwaschene Bilder angucken? Nur weil die Qualität der Bildschirme damals[tm] schlecht war? Gerade, wenn man auch mal irgendwie Text schreiben will, braucht man eine saubere Darstellung.

    [Video] Es gibt diverse Gründe, sich "verwaschene" Bilder angucken zu wollen. Zum einen sorgen diese Bilder dafür, dass sich bestimmte Pixel optisch miteinander verbinden, von denen man das wünscht. Das kann sogar bei Schrift zu positiven Effekten führen (leichteres Erkennen von Buchstaben-Mustern durch das Auge), ist dort aber sicherlich Geschmackssache. Vor allem ist das Weichzeichnen durch den CRT-Screen aber ein Effekt, den sich gerade die C64-Künstler zu Nutze machen. So erst kommen die Mischtöne im Auge zustande, die Verläufe etc. ermöglichen. Die C64-Palette (auf deren Prinzipien ich ja die Palette aufgebaut habe, die du verwendest) ist prädestiniert für diese Verwendung (und meine noch viel mehr). Ohne den CRT-Effekt funktionieren viele Pixeleien nicht so, wie sich die Pixel-Künstler das wünschen. Dann kann man eigentlich auch gleich Primär-Knall-Farben, wie auf CPC und Specci verwenden.


    Aber man soll den Effekt natürlich auch abstellen können, wenn man die 100% scharfe Darstellung bevorzugt.


    Zitat von M. J.

    Und ja, im Prinzip hätte ich auch gerne einen 16:9-Bildschirm bei entsprechend aufgelöster Grafik. Geht aber zum jetzigen Zeitpunkt leider nicht.

    [Video] Schön, zu hören, dass du grundsätzlich FÜR diese Darstellung und das Seitenverhältnis bist. Vielleicht finden wir ja doch noch eine Lösung für das Problem.

    Zitat von Retrofan

    [I/O] Ich finde es, ehrlich gesagt, schon recht gewagt, den Käufern des X16 zuzumuten, dass sie sich einen alten VGA-Schirm suchen sollen (was wahrscheinlich von der Beschaffung her noch die einfachste Übung ist) und darüber hinaus eine PS/2-Tastatur (die ich nur im Haus habe, weil ich auch SGIs sammle) und Nintendo-Controller (bei denen ich passen müsste). Und dieser Geräte-Zoo hat sicherlich einen WAF (und damit Wohnzimmer-Tauglichkeit) von exakt Null.

    Ich frage mich immer, was ihr alle für Monitore habt?! Ich habe gerade mal auf Geizhals nachgeschaut. Dort sind 2045 Monitore gelistet. 1698 davon haben HDMI und 1226 haben VGA. Selbst wenn ich die Monitore seit 2018 nehme: 1084 Monitore, davon 1051 mit HDMI und 510 mit VGA. Man kann also sagen, dass selbst bei neuen Monitoren noch jeder zweite einen VGA-Anschluss hat! Selbst bei den 2557 gelisteten Fernsehern haben 583 einen VGA-Anschluss. Bei Tastaturen kann ich den Einwand eher verstehen. Von 2130 kabelgebundenen Tastaturen kommen nur noch 136 mit PS/2. Aber wer sich eine Retro-Konsole für mehrere Hundert Dollar holt, der wird sicher auch noch einen Zehner für eine Tastatur übrig haben. :) Was die Nintendo-Controller betrifft: da gibt's doch immer noch billige Nachbauten in der Bucht.

    Ich finde, das Bildschirmformat ist ein größeres Problem geworden als der Anschluss. Wir haben heutzutage nun mal fast nur noch 16:9, 16:10 oder auch 138:9 oder so was. 4:3 bekommt man neu quasi nur noch direkt aus China.


    Viele Monitore haben keine 4:3-Option, mein Iiyama auch nicht; das macht der Framemeister. Und hat man es geschafft, ein 4:3-Bild auf seinem Breit-Panel zu zaubern, stören sich viele an dem nutzlosen schwarzen Rand, zumindest dann, wenn der Monitor ausschließlich für den Retro-Computer benutzt werden soll.


    Es ist nun mal ein Dilemma. Vielleicht könnte man aber das Retro-System so machen, dass es auch einen 16:9-Modus gibt, z.B. zum Programmieren und Debuggen, oder auch für Tracker und andere Tools. Z.B. das Bild nach rechts schieben und links der Code. So ähnlich hatten wir das früher auch beim AutoCAD, allerdings mit zwei Monitoren, links ein kleiner für Werkzeug und rechts der große für die Zeichnung. Der Retro-Computer sollte dann den schwarzen Rand im Spielmodus selbst erzeugen können, sodass man immer effektiv ein 16:9-Bild hat, und die Frage nach dem Monitor hätte ein Ende.

    Zitat von Snear

    Ich frage mich immer, was ihr alle für Monitore habt?!

    [I/O] Es geht nicht in erster Linie um Monitore, sondern um TV-Geräte. Nach deinen Zahlen hat fast nur noch jeder 5. angebotene Fernseher einen VGA-Anschluss. Homecomputer standen und stehen aber oft im Wohn- oder Jugendzimmer, werden zum Spielen in der Gemeinschaft genutzt (zumindest würde ich genau DAS fördern wollen). Und dann geht es auch nicht ausschließlich um den Anschluss, sondern auch um das Seitenverhältnis des Bildschirms. 4:3, wie es z.B. beim Commander X16 favorisiert wird, kommt immer seltener zum Einsatz (selbst bei Geräten mit VGA-Anschluss). Und man muss bei VGA, PS/2 und Nintendo-Ports ja auch den Zeitfaktor sehen, der gegen die alten Anschlüsse arbeitet. Wenn wir heute ernsthaft anfangen würden, einen neuen Computer zu konzipieren, dann wäre der, realistisch gesehen, in frühesten 5 Jahren fertig. Wir sind ja nicht annähernd so organisiert, wie der 8-Bit-Guy oder der Mega65-Verein. Die alten Anschlüsse werden ja nicht mehr, sondern weniger werden.


    Man hat das mit dem Zeitfaktor doch bei der (Open-)Pandora gesehen. Als die angekündigt wurde, waren die Specs nahezu High-End (und der Preis dafür überraschend gut). Als sie dann (mit 2 Jahren Verspätung?) herauskam, war sie von der Performance und dem Display her her schon von jedem 150-Euro-Handy überholt worden. Lediglich die Eingabe (Controller/Keyboard) war normalen Handys gegenüber noch im Vorteil – dafür war der Preis für Nicht-Backer auf eine unattraktive Höhe gestiegen.


    Was Legacy-Schnittstellen angeht, arbeitet die Zeit gegen uns.


    Und wie gesagt, wenn man sich eine neue Konsole (bzw. wohnzimmertauglichen Homecomputer) kauft (und sei sie/er auch "retro" in manchen Aspekten), so wird man sich nicht unbedingt Geräte von der Reste-Rampe oder dem Elektro-Schrott dazu stellen wollen.

    Ich habe den Eindruck, dass Fernseher von jungen Leute recht wenig benutzt werden, so ist das jedenfalls bei meinen Kindern und deren Freunden(Alter 12 bis 21). Das meiste an Medieninhalten wird über Smartphone, Tablet oder Laptop konsumiert, wobei Smartphones ganz weit vorne dabei sind.


    Bei den Leuten, die noch regelmäßig wirklich klassisches Fernsehen gucken(weiß gar nicht mehr wann ich meinen TV das letzte mal an hatte) steht sicher ein großer 16:X Flachmann auf einem niedrigen Fernsehschrank, oder das Teil hängt an der Wand. Mich vor so einem Riesenfernseher zu setzen mit einem Heimcomputer und da was zu tippen, stelle ich mir extrem anstrengend und unbequem vor. Dann doch lieber ein separates und bequemes Eckchen. Was dann aber wieder den Sinn eines Heimcomputers für das schon vorhandene Fernsehgerät in Frage stellt.


    Ich persönlich lümmle extrem entspannt lieber mit einem Laptop auf der Couch, denn starr am Tisch sitzen, das habe ich auf Arbeit genug.

    Wenn TV tot ist, und alle Riesen-Smartphone und Tablet als Display nutzen, dann könnte die Ausgabe über einen ESP32 Webserver als Stream angeboten werden. Und Input kommt dann auch von dort.


    Aber ehrlich gesagt: dann kann auch alles als Emulation im Browser laufen. Mit asm.js und Web Assembly ist das auch auf schwächeren Mobil-Geräten ausreichend schnell, um einen Retro-Homecomputer zu emulieren.

    Gibt z.B. seit vielen Jahren schon den SAE (Skripted Amiga Emulator) und das ist noch plain old Javascript.


    Zurück zu echter Hardware: wenn wir davon ausgehen, dass FPGAs im low-cost Bereich bestenfalls 640x480x60Hz erzeugen können, und es günstige Konverter gibt, die es auf 16:9 HDMI mit HD oder FullHD skalieren, und dabei den schwarzen Border oben und unten im VGA Signal erkennen, dann wären doch eigentlich nur folgende Auflösungen möglich (16:9, randlos, quadratische Pixel):


    HD (1280x720):

    640x360

    320x180


    FullHD:

    (960x540)

    640x360

    480x270

    320x180


    Wie gesagt, die 4:3 VGA Ausgabe hätte einen schwarzen Border (nicht nutzbar und änderbar, damit keiner mit 4:3 Gerät auf die Idee kommt, da was zu machen, was dann beim 16:9 TV wegfällt).

    16:9 wäre immer randlos.


    Ich schlage vor:

    320x180 für Spiele mit 16 Farben (fixe Palette oder 256 rrrgggbb ?), ca. 28KB oder 56,25KB mit double buffering

    640x360 für Editor/Tools (80x40 Text bei 8x9 Font), 2 oder 4 Farben bei 56,25KB


    Textmode oder Tiles würde ich sein lassen und auch Sprites eher als Software (wenn CPU schnell genug).


    Aber bei 56KB nur für den Screen, fällt ein unified/linear address space für CPU/Grafik bei 16Bit CPU Adressbus schonmal weg.

    Ich könnte mir aber auch eine 8Bit CPU mit 16Bit Speicher-Adressbus und 16Bit I/O-Bus vorstellen. VRAM und alle I/O-Register würden dann dort liegen.