Arduino (FPGA/ARM) als Basis für einen Retro-Computer [aus: Neuer Retro-Computer ...]

Maiks CPU ist halt das minimale 32Bit Integer Feature Subset RV32i. Ich fürchte halt 0xdeadbeef wird da noch mehr vermissen, als beim plain old M68000.

Aber das tolle an Eff-Pee-Geh-Aaahhs ist ja, das man sich nicht sofort festlegen muss. Man kann ja Varianten durchprobieren. Ich seh auch - zumindest für mich - eher den Weg als das Ziel. Ob dann jemals sowas wie ein fertiges System für viele Nutzer entstehen wird, steht in den Sternen.

Ich denke, wir werden hier nicht auf den genialen Masterplan kommen, was genau man wie umsetzt und dann erfolgreich produziert und vermarktet. Ich glaube im besten Fall können wir (vielleicht modulare) open source Prototypen solcher Systeme basteln (als Emulationen auf PC/Raspi oder evtl. FPGA Entwicklerboards). Vielleicht kristallisiert sich daraus etwas, woraus dann jemand ein Produkt manchen kann.

Den TheC64 hätte es nicht ohne VICE gegeben. Mist(er)/Sidi nicht ohne original Minimig, TG68 Core, etc.

Minimig und Mist waren erstmal Bastelprojekte mit FPGA Starter Boards, dann wurden "richtige" Boards dafür entworfen, dann fanden sich Hersteller (ACube, Lotharek, Manuferhi).

Mister hat den Ansatz "An FPGA Starter Board was dranbasteln" zum Prinzip erhoben und ist sehr erfolgreich ohne einen zentralen Hersteller.

Und vielleicht wird es ja auch mal eine Variante geben, die als "all-in-one" Tastaturcomputer kommt. Manuferhi hat das schon bei seinem Spectrum-Next Clone "N-GO" gemacht:

pasted-from-clipboard.png

Vielleicht wird SiDi64 ähnlich. Das Prototypen Board auf Twitter sieht vom Formfaktor schon aus, als wäre sowas angedacht.

Man kann noch sehr lange alle Ansätze und Specs durchkauen, ohne je auf einen gemeinsamen Nenner zu kommen. Daher denke ich, nur kleine, inkrementelle Schritte führen weiter. Ich schau mir nun erstmal den MKR Vidor 4000 an, inwiefern die HDMI Ausgabe bzgl. Auflösung was taugt, und wie man da eigene Cores in den FPGA bekommt. Der Arduino Ansatz ist ja eher, vom ARM aus vorgefertigte FPGA-IP Blöcke zu aktivieren und zu nutzen. Das Design mit den gemeinsamen GPIOs zwischen ARM und FPGA sieht fragil aus, und ist wohl E-technisch leicht zu schrotten (wenn beide einen Pin beschreiben wollen). Mal sehen, wie lange der bei meinem Trial-and-error Coding Stil überlebt

Retrofan :

Bzgl FullHD HDMI durch ARM: die ARM MCUs von MKR V4000, Mist und SiDi sind reine kleine CPUs, die haben 40-50 MHz und da ist keine GPU und auch kein grosses RAM, und nicht die Speed, um FullHD HDMI in Software rauszupusten (und nebenbei noch USB und SD zu verarzten).

Mister (bzw DE10-nano) hat zwar deutlich potentere Dual-Cortex-A9 mit FPU und NEON SIMD Einheiten etc bei 900MHZ , aber eine dedizierte GPU wie bei Mobile-SoCs (selbst bei den Raspi BMCxxxx) gibt es da auch nicht. Grafik wird mit dem FPGA-teil des Cyclone V gemacht. Im Mister Framework wird da ein Teil des 1GB DDRx RAM als HD Framebuffer genutzt. Der FPGA skaliert den Framebuffer des jeweiligen Retro-Systems dorthin hoch und filtert ihn, und evtl kommt noch Bezel usw.

Der Framebuffer der Retrosysteme sind je nach System und grösse im BlockRAM des FPGA oder im (optionalen) 32/128MB SDRAM Modul.

Beim MKR Vidor macht auch der FPGA das (DVI over) HDMI Signal und das 8 MB SDRAM hängt am FPGA (nicht am ARM MCU) und kann so zB als Framebuffer dienen.

Was man aber wirklich aus FPGA und SDRAM an Bandbreite für die Bildausgabe holen kann, müssen Tests zeigen. Ich bezweifel stark, dass es für 1080p reicht.

Zitat von RexRetro

Ich bezweifel stark, dass es für 1080p reicht.

Nun ja – es gibt ja auch noch den Fernseher, der notfalls das hereinkommende Signal skaliert, oder nicht? Also angenommen, man produziert irgendwas, was 16:9 (aber nicht 1080p) entspricht und schickt das über HDMI rüber – was macht dann ein handelsüblicher Fernseher? Der bläst das doch (wie bei SD-PAL) auf, oder?

Die geringste HDMI-Auflösung müsste doch
https://de.wikipedia.org/wiki/720p

sein, oder?
Skalierungsmatsch wird's wohl so immer geben, mindestens 1x.

Evtl. von Retro-Auflösung auf 720p aber dann sicher von 720p auf Full-HD, 4K ect....

Zitat von M. J.

Zusammengefaßt lautet das Problem also: Noch weiß ich überhaupt nicht, wo und wie man mit dem Vidor 4000 eine Bitmap speichern kann, und ob die Videodaten schnell genug zum HDMI-Port gelangen und dort wiederum schnell genug als FullHD ausgegeben werden.

Aber irgend eine Möglichkeit werden die Vidor 4000 Entwickler doch wohl vorgesehen haben, HDMI zu nutzen, oder? Die verbauen doch nicht irgend so eine Schnittstelle und kümmern sich dann einen Scheiß darum, ob man sie mit dem Rest benutzen kann. Davon ab ist doch HDMI heutzutage in jedem "Taschenrechner und Kugelschreiber" und 20-Euro-Geräten, wie dem The64 mini verbaut. Die bekommen doch auch alle irgendwie ein Retro-Bild auf den Bildschirm gezaubert.

Und wie ist das mit den anderen Ports (USB, BT, WLAN)? Sind die auch nur als "Deko" auf die Platine geklebt worden oder kann man die wenigstens über den ARM verwenden, ohne sich ein Bein auszureißen?

Zitat von M. J.

Ja, er skaliert das hoch, aber welche Grundauflösung willst Du ihm schicken? Die niedrigste HDMI-Auflösung ist 640. Verwendest Du die, haben die 480 Punkte links und rechts einen dicken Rand.

Irgendwie stehe ich gerade auf dem Schlauch. Wieso entsteht ein Rand, wenn der TV hochskaliert? (Aus unseren alten Auflösungs-Diskussionen bin ich irgendwie raus und muss mir das erst wieder anlesen). Angenommen, ein TV bekommt (Norm oder nicht) ein Signal mit 640 x 360 Pixeln übertragen. Bleibt der Bildschirm schwarz oder stellt er das dar? Falls er es darstellt und skaliert – wo soll da ein Rand entstehen?

Hier wird ein Lowtec-Beamer per HDMI von einem Pi Zero mit 320 x 240 Pixeln versorgt (was hier der nativen Auflösung entspricht) und es scheint problemlos zu funktionieren. Also, 640 Pixel (in welcher Richtung auch immer) scheinen bei HDMI nicht vonnöten zu sein. Vielleicht ist ein PI ohnehin mal eine gute Testmaschine, um zu gucken, was TVs so anstellen, wenn man ihnen Retro-Auflösungen in seltsamen Seitenverhältnissen schickt. Abfackeln wird man die TVs damit ja wohl nicht.

Zitat von Tobias

Skalierungsmatsch wird's wohl so immer geben, mindestens 1x.

"Skalierungsmatsch" fände ich gar nicht so schlimm. Ich möchte gar nicht unbedingt knackscharfe Pixel mit 1 cm Kantenlänge. Ein bisschen "kostenloser" Weichzeichner wäre klasse.

image.jpg

Der MKR V4000 ist da und ich hoffe am WE mal zumindest die Arduino Demo Sketches zu testen.

Auch wenn ich noch keine first-hand experience habe, will ich aber mal meinen (un-)educated guess zum Thema HDMI Output loswerden:

Zitat von Retrofan

Zitat von M. J.

Zusammengefaßt lautet das Problem also: Noch weiß ich überhaupt nicht, wo und wie man mit dem Vidor 4000 eine Bitmap speichern kann, und ob die Videodaten schnell genug zum HDMI-Port gelangen und dort wiederum schnell genug als FullHD ausgegeben werden.

Aber irgend eine Möglichkeit werden die Vidor 4000 Entwickler doch wohl vorgesehen haben, HDMI zu nutzen, oder? Die verbauen doch nicht irgend so eine Schnittstelle und kümmern sich dann einen Scheiß darum, ob man sie mit dem Rest benutzen kann. Davon ab ist doch HDMI heutzutage in jedem "Taschenrechner und Kugelschreiber" und 20-Euro-Geräten, wie dem The64 mini verbaut. Die bekommen doch auch alle irgendwie ein Retro-Bild auf den Bildschirm gezaubert.

Und wie ist das mit den anderen Ports (USB, BT, WLAN)? Sind die auch nur als "Deko" auf die Platine geklebt worden oder kann man die wenigstens über den ARM verwenden, ohne sich ein Bein auszureißen?

Arduino.cc hat eine AdafruitGFX kompatible Grafik-Lib für den ARM geschrieben, die einen SDRAM Framebuffer nutzt und DVI/HDMI Ausgabe über eine IP Block für den FPGA macht.

Man schreibt also einen Arduino Sketch, macht die Lib auf und macht damit den FPGA an und kann dann Text, Linien etc. ausgeben.

Die Auflösung in den C Beispielen sieht nach 640 x 480 aus, aber der HDL Code auf gibthub sieht aus, als wären es 1280x720. Evtl. ist das eine die Framebuffergröße und das andere die Ausgabeauflösung und da wird zentriert oder skaliert ausgegeben. Farbtiefe hab ich noch nicht gecheckt.

Retrofan Ich bin nicht sicher, ob wir die technischen Diskussionen hier im Thread haben sollen, oder ob die nicht stören. Du bist doch Mod und könntest das auslagern?

Meine rein persönliche Einschätzung zum Thema Grafik:

Das 8MB SDRAM hängt momentan mit 100 MHz und 16 Bit am FPGA. Der Entwickler im entsprechenden arduino.cc Forum meint, mit entsprechenden Timing Constraints in eigenem FPGA HDL Code, könnte man es evtl. auch bis 130 MHz bekommen. Das sind also ähnlich den Specs, wie SDRAM auch bei MiST, SiDi und Mister benutzt wird (nur nutzen die 32/64/128MB große 16-Bit SDRAM Module).

Dort bekommt man es mit Cyclone 3/4/5 hin, einen AGA Amiga plus RTG Grafikkarte zu implementieren.

Wenn jetzt der Cyclone 10 und das SDRAM vom MKR V4000 nicht signifikant langsamer sind, sollte ähnliches auch da möglich sein.

Ja, mit SRAM wäre es einfacher, weil man nicht irgendwelche Burst-Modi nutzen muss. Aber prinzipiell geht es.

Und wir wollen ja nicht superhohe Auflösungen und Farbtiefen im Framebuffer im SDRAM, sondern nur den Framebuffer des Retro-Systems.

Der FPGA würde den für jede neue Zeile in ein BRAM puffern und dann horiz. skaliert (und Zeilen-dupliziert) ausgeben.

Da sollte dann auch noch genug Bandbreite für die CPU bleiben.

Zitat von RexRetro

Der MKR V4000 ist da

Ein süßer kleiner Racker, äh Riegel. Ich bin mal gespannt, ob das evtl. das richtige Ding als Basis für ein Projekt im Sinne dieses Threads ist.

Zitat von ZeHa

Was genau ist denn jetzt eigentlich im Sinne dieses Threads? Geht es hier jetzt nur noch um den Lern-Computer?

Ich glaube dass dies hier de facto nach wie vor der "Sammelthread aller Parteien" ist

Wir haben Diskussionen, was das System können und wie das System aussehen soll und wir haben Diskussionen, wie man das mit Emulation auf SBCs oder halt FPGAs umsetzen könnte.

Emulation auf Raspi wurde schon ausgelagert.

Ich möchte die FPGA Evaluation vorantreiben - gerne in einem eigenen Thread.

M.J.s Core ist schon jetzt ziemlich cool, aber setzt halt auf ein weniger verbreitetes, aber dafür günstiges (China) Experimentierboard + Erweiterungsplatine von Maik. HDMI ist damit eher nicht drin. USB braucht weitere Erweiterungen.

Terasic DE10-nano/Mister hätte HDMI und USB, ist aber teuer und wahrscheinlich vom FPGA völliger Overkill. Ähnliche Boards mit Xilinx FPGA, z.B. ZYBO Zynq-7000 von Digilent sind ähnlich teuer.

Einfachere und ältere FPGA-Experimentierboards setzen meist noch auf VGA Output.

Das Arduino MKR Vidor 4000 Board ist das einzige FPGA-Experimentierboard, das ich leicht finden konnte, mit HDMI, aktuellem FPGA, ARM Controller, USB und noch Extras wie WiFi/BLE und das unter 100€ ist (und nicht in China geordert werden muss; habe nämlich keinen Bock auf Zoll Scherereien).

Daher will ich das mal genauer antesten und Euch meine Erkenntnisse mitteilen. Und Experten wie M.J. und daybyter können entscheiden, ob das eine gangbare Alternative wäre, zu selbstentworfenen Boards.

Damit meine ich erstmal nur für die Entwicklung. Wenn denn mal ein richtiges Produkt entstehen sollte, könnte man ja immer noch ein eigenes PCB mit genau der nötigen HW in der richtigen Größe nehmen(z.B. Cyclone 10 mit weniger LEs, etc.). Arduino hat IMHO auch den Vorteil, dass das recht Open Source mäßig ist. So wie ich es sehe, setzen die auf Open Source HDL, C Code und Schematics und nicht auf viel Probrietäres (wie Raspi mit dem Broadcom Kram).

Zitat von Retrofan

Davon ab ist doch HDMI heutzutage in jedem "Taschenrechner und Kugelschreiber" und 20-Euro-Geräten, wie dem The64 mini verbaut. Die bekommen doch auch alle irgendwie ein Retro-Bild auf den Bildschirm gezaubert.

Ich möchte hier nochmal was klären: HDMI ist im Massenmarkt natürlich kein Problem. Wenn man Millionen Gadgets herstellt, kann man auch eigene Chips (ASICs) dafür hernehmen. Die Emulationssachen wie The64, (S)NES/PS/Sega-Mini usw. nehmen einen der zahlreichen SBCs mit irgendeinem ARM SoC, wo auch irgendeine (richtige) GPU mit drin steckt. Kann man sich mit dem richtigen Budget auch selbst bei ARM alles als IP kaufen (verschiedenste ARM Kerne, MALI GPUs) und bei einer Foundry seinen Traum-SoC backen lassen.

Aber die haben halt alle nicht das Ziel, nativ Retro-Grafik zu machen, sondern OpenGL ES 3.x und Vulkan 1.x.

Und man muss halt ein paar Millionen hinblättern.

Aber ARM-SoCs und SBCs gibt es billig wie Sand am Meer, auch für Bastler: Raspis, Banana Pis, Odroids, Beaglebones, etc.

Make Magazin vergleicht jährlich die 20-30 interessantesten.

Aber für FPGA mit HDMI und bezahlbar sieht das Angebot überschaubar aus.

Wenn man den "Emulation auf SoC"-Weg gehen will, ist man mit 5-10€ für Pi Zero und Konsorten dabei. FPGA wird halt immer etwas teurer sein, dafür kann man CPU und Grafik und Sound in (fast echter) Hardware implementieren und hat nicht einen Emulationslayer und evtl. noch ein fettes Server OS unterm Hintern.

erster HDMI Output auf einem Dell Screen (neu von Anfang Lockdown 1):

image.jpg

Ist aber in der Tat nur 640x480@60Hz

Das war jetzt auch ansonsten alles ziemlich hakelig:

1. der Monitor hatte Probleme ein Signal zu erkennen
2. die Arduino IDE hat immer wieder Probleme mit dem COM Port beim Flashen
3. es klappt nur nach erneuter Compilation und die dauert ewig (für die paar Zeilen)
4. nach Reset und Power-on/off is der Sketch weg (scheint nicht im Flash/EEPROM)

Weil es so schwierig ist, überhaupt ein Bild zu bekommen, mach ich Statusausgaben über das Terminal.

zu 1) ich habe ausser dem 10 Jahre alten TV im Wohnzimmer keine Geräte mit HDMI-In. Alles DVI oder VGA. Bin wohl zu retro. Der Monitor ist von meiner Frau, die ihren Tablet-PC über USB-C->HDMI->DVI an einem recht aktuellen DELL Monitor hat (mit VGA, DisplayPort und DVI - kein HDMI). Der MKR V4000 hing jetzt über MiniHDMI->HDMI->DVI daran. Vielleicht zu viele Adapter und zuwenig Saft (Stromversorgung über Laptop->USB-Hub->MicroUSB).

Kann es noch später am TV probieren, mit Mini-HDMI->HDMI Kabel.

zu 2) wahrscheinlich typisches Win10 USB-COM Geraffel. Aber mit diversen ESP32 und Arduino UNOs hatte ich das nicht so schlimm.

zu 3) auch für den ESP32 braucht es auf dem Laptop (Thinkpad T450, Core i5-5300U, 2.3GHz, 8GB RAM, 250 GB SSD) extrem lang. Ist auch schon retro.

zu 4) Muss mal im Arduino-Forum dazu suchen. Evtl. ein Bootloader-Update für die ARM MCU nötig?

Wenn es schon ewig dauert, ein paar Zeilen simpelsten C Code für ARMv6 zu compilieren, dann brauch ich mit Quartus 18.x auf dem Laptop gar nicht anzufangen. Muss meine gute alte Fujitsu Workstation ran, die aber im Homeoffice-Setup doof steht und wo ich immer unterm Schreibtisch rumkriechen muss, um umzustöpseln.

Und ich brauche einen eigenen Test-Monitor mit HDMI (billig und nicht zu groß, aber FullHD 16:9).

Hat jemand Tipps ?

Zitat von daybyter

Wenn jemand mitbasteln will, hätte ich hier vielleicht ein Konzept, wie der Cyclone 2 quasi VGA als HDMI Signal ausgeben kann. Dann sind wir bei 250 MHZ Ausgabetakt pro Farb-Bit, was wohl das Höchste der Gefühle sein dürfte. Wenn es mehr sein muss, müsste da wohl eine zusätzliche Hardware her, die den Takt verdoppelt, verdreifacht, vervierfacht usw. Kost Geld und ich seh ehrlich gesagt nicht so recht den Vorteil.

Keine Ahnung wie eure Hardware aussieht aber ich bring nochmal den TFP410 von TI ins Spiel. Vorne RGB und Syncs rein und hinten DVI bzw. HDMI raus. Da müsste man nur noch mit 148,5MHz ballern. Haben wir hier in nem Kunden-Projekt mit 1024x768. Einen Testbild mit 1080p hat er aber auch geschafft.

Am TV (Phillips) geht es etwas besser und man kann einstellen, wie skaliert wird.

image.jpgimage.jpg

Aber auch der verliert ab und zu das Signal. :-/