Hello, Guest the thread was called1.9k times and contains 106 replays

last post from RexRetro at the

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

  • Welches System meinst Du jetzt? Vom MinimigAGA/RTG auf Mist/SiDi oder Mister, oder vom Vidor 4000?


    Minimig müsste man mal anschauen und am besten die Leute fragen, die AGA und RTG implementiert haben. Wobei RTG von jemand für Turbo Chameleon und dann MiST gemacht wurde (sehr ähnlich) und dann mit Hilfe von Leuten im Mister Forum an das komplexere Grafiksystem vom Mister portiert wurde.


    Bei Mister wird wohl der Framebuffer des Retro-Systems vom SDRAM gelesen und dabei ins DDR3 des Cyc5 kopiert (bzw. dabei skaliert und gefiltert) und dort kann auch der ARM zugreifen für Screenshot und Overlays. Und von dort wird wohl das eigentliche Ausgabe-HDMI gemacht. Wieder vom FPGA-Teil. Wie der DDR3 Memory-Controller die Zugriffe der 2 ARM Cores und des FPGA regelt, hab ich keine Ahnung. Aber ich glaube da ist auch auf FPGA Seite ein "Hardcore Memory Controller" und man muss nicht viel HDL erstellen, um DDR3 optimal anzusteuern.


    Bei Minimig, Mist, Sidi und Co wird wohl immer nur eine Zeile (oder evtl. 2) im BRAM gepuffert und horizontal gefiltert und skaliert ausgegeben und evtl. wiederholt mit leichter Tönung (als billiger Scanline Effekt). Wenn man noch einen Multisync oder 15kHz CRT hat, kann man auch ohne Scandoubler Effekt ausgeben.


    Was es noch gibt, sind diese Menu-Overlays. Ich glaube die macht der ARM. So eine Art Genlock Effekt.


    Beim Vidor 4000 ist mir immer noch unklar, wie der ARM in den Framebuffer im SDRAM am FPGA schreibt. Der hat keine Verbindung. Im Bitstream von Arduino sind 10 FPGA "Devices". Eines ist MB_DEV_SDRAM und eines MB_DEV_GFX. Nehme an das sind SDRAM Controller (mit Zugang ARM<->SDRAM) und FB/GFX Controller. Auch hier ist mir unklar, wie die Zugriffs-Kollisionen vermeiden.


    Was SDRAM Geschwindigkeit angeht: da sag ich nix ohne Anwalt. Da hab ich zu wenig Überblick. Der Takt sagt ja erstmal nur, wie schnell das Protokoll läuft. Wieviele Takte da Bänke, Seiten, Zeilen, Spalten selektiert werden, wie lange es dann dauert was zu lesen oder zu schreiben und wie das mit Bursts oder Bank-Wechseln läuft.... muss man sich erstmal einlesen. Der Mensch, der den Minimig um RTG erweitert hat, hat einen Block, wo er viel zu seinen Experimenten geschrieben hat, vor allem hier mit dem TG68 als CPU.


    Ich hab den Vidor 4000 jetzt etwas besser unter Kontrolle und er läuft jetzt schon seit ca. 40 min stabil am TV mit eigenem Netzteil. Die Aussetzer scheinen also USB-Stromversorgung vom Laptop aus zu sein (der auf Batterie im Energie-Spar-Profil läuft).


    Das Rumgezicke mit Upload und Start war einfach doppelte Dummheit von mir: wenn der Serial Monitor läuft, kann die IDE nicht uploaden. Der Demo Sketch hat aber im setup eine leicht zu übersehende while-Schleife, die auf den Serial Monitor wartet. Man muss den also immer zu machen, flashen, auf machen.


    Jetzt muss ich rausfinden wie ich FPGA Bitstream im Flash, ARM Bootloader im EEPROM und die WiFi/BLE-Chip Firmware jeweils update. Und dann mal eigenen Bitstream erzeugen und laufen lassen.

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

    Was tun die anderen "Zooms", vor allem Auto-Zoom. Und was ist Default?

    Was die tun? Mich nerven. Default kennt nur Phillips, das Gerät merkt sich die letzte Einstellung.

    Auto Zoom versucht verlust- und verzerrungsfrei hoch zu skalieren und erkennt horiz. Balken in alten 4:3 Videos oder Border vom C64. Aber wehe da passiert was im Border, dann flippt es nervig die Skalierung.

    Unskaliert ist klar, ein anderer verzerrt stur auf volle 16:9 und wieder ein anderer veezerrt nicht und schneidet lieber irgendwas ab, um irgendwo schwarze Balken zu vermeiden.

    Andere TVs und Monitore nachen es sicher wieder anders.

    Ich denke sicher wäre nur nach HDMI 1.0 zulässige 16:9 Formate zu erzeugen, denn die sollte jeder TV und 16:9 Monitor dann automatisch und richtig skalieren können.

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

    https://www.fpga4fun.com/HDMI.html


    Die Idee ist ganz schlicht eine HDMI Verbindung und paar Drähte. Kein Chip der irgendwas wandelt, oder so....

    Also wird eine Video-Auflösung gesucht die zu den Möglichkeiten des FPGA passt.

    Was schiebt denn eigentlich son DVD-Player über HDMI raus wenn er Widescreen ausgibt? Das sollte doch irgendwas auf PAL Basis sein. Da müsste die Datenrate doch moderat ausfallen und jeder aktuelle Fernseher sollte damit klarkommen.

  • Was schiebt denn eigentlich son DVD-Player über HDMI raus wenn er Widescreen ausgibt?

    Das Bild ist, soweit ich weiß, anamorph (also gegenüber dem Originalbild (hier horizontal) gestaucht) 720 x 480 (NTSC) oder 720 x 576 (PAL) und wird dann auf das entsprechende Seitenverhältnis skaliert. So ist es gespeichert und ich denke, so wird es auch übertragen.

  • Was schiebt denn eigentlich son DVD-Player über HDMI raus wenn er Widescreen ausgibt?

    Das Bild ist, soweit ich weiß, anamorph (also gegenüber dem Originalbild (hier horizontal) gestaucht) 720 x 480 (NTSC) oder 720 x 576 (PAL) und wird dann auf das entsprechende Seitenverhältnis skaliert. So ist es gespeichert und ich denke, so wird es auch übertragen.

    Naja aber gibt es da eine Signalisierung? Bei einigen DVDs sehe ich 4:3 bei anderen 16:9 ohne dass ich am Fernseher umschalten muss. Oder ist das 4:3 Format inklusive Seitenbalken auf der DVD?

  • Naja aber gibt es da eine Signalisierung?

    Das wird wohl im Header stehen. Hier in den Video Attributes (IFO Header).


    Oder ist das 4:3 Format inklusive Seitenbalken auf der DVD?

    Das wäre blöd, weil du die DVD ja auch auf einem 4:3-TV gucken könntest. Ziel von gut gemachten DVDs ist es, die Auflösung möglichst gut auszunutzen (also gegebenenfalls anamorph zu speichern) und bei der Ausgabe das Bild auf Original-Seitenverhältnis zu entzerren.

  • Naja aber gibt es da eine Signalisierung?

    Das wird wohl im Header stehen. Hier in den Video Attributes (IFO Header).

    Also auf dem Medium ist die Info schon mal vorhanden. Gut zu wissen. Aber wie schauts mit der Signalisierung auf dem Kabel aus?

    Für analoges Video ist wohl das hier relevant: https://en.wikipedia.org/wiki/Widescreen_signaling

    Nur für digitales Video finde ich irgendwie nüscht. Oder wird das einfach nur entsprechend digital übertragen?

  • Ich habe extra noch einen alten Phillips DVD-Player mit (analog) Scart, weil ich da am Player und am Fernseher das Format tweaken kann.

    Der Panasonic BlueRay/HDD-Recorder gibt alte 4:3 DVDs über HDMI stur als 16:9 verzerrt aus und ich habe weder beim Player (noch dann beim TV) die Möglichkeit das auf 4:3 zu stauchen.

    Aber die Welt bestand früher nicht nur aus Breitmaulfröschen!

    Tolle neue Technik.


    Also: in der Theorie sollten DVD und HDMI entsprechende Format-Flags haben. In der Praxis halt der übliche Murks.

  • Ich lese gerade dass bei HDMI die Pixelclock mindestens 25MHz betragen muss. Videoformate mit kleineren Raten übertragen mit einem Pixel-Wiederholungs-Schema. Bei PAL wären das wohl 27MHz. Bei angenommenen 10 Bit pro Pixel haben wir 270MHz serielle clock was dann wohl den technischen Rahmen des FPGAs mit 250MHz sprengen wird.


    Ich bedanke mich für ihre Aufmerksamkeit.

  • Zum MKR Vidor 4000 mal weitere Infos:

    die "Devices" im offiziellen FPGA Bitstream von Arduino nutzen eine Nios2/f Softcore CPU (f == fast) als Koordinator. Die scheint auch die eigentliche Grafik zu pixeln, der ARM sendet nur Befehle.

    Der Bitstream wird in den Arduino Sketch mit eincompiliert, der dann vom ARM den FPGA initialisiert. Scheint mir umständlich, aber ok. Erklärt auch, warum das Kompilieren der Sketches so ewig dauert.


    Und zwar ist laut Arduino.cc alles "Open Source" aber dummerweise bekommt man den schnellen Nios2/f mit Caches nur mit der kommerziellen Version von Quartus und nicht der Lite. Da muss man sich mit einem langsameren Nios2 begnügen, der wohl Timing-Probleme hat, weil er den Programm-Code direkt aus dem Flash ausführt (ohne I/D-Caches). Daher kann man wohl den Arduino.cc Bitstream nicht mal eben selbst bauen und umbauen - zumindest nicht ohne Probleme.


    Auch hat sich Arduino.cc nicht so richtig ins Zeug gelegt, die eigentliche FPGA-Nutzung (neben dem vorgefertigen Modulen im offiziellen Bitstream) irgendwie sinnvoll erweiterbar oder austauschbar zu machen.

    Also entweder man nimmt den FPGA nur als Co-Prozessor für vorgefertigte Libs von Arduino, oder man muss alles selbst machen und dazu noch umständlicher als bei "normalen" FPGA-Dev-Boards (wie Terasics DEx).


    Aber immerhin haben schon einige Leute da rumexperimentiert und es gibt eine Reihe Tutorials im Netz und einige Projekte auf Github etc. Hier mal eine Liste interesanter MKR Vidor Projekte auf github:


    offizielle Repos:

    https://github.com/vidor-libraries/VidorBitstream

    https://github.com/vidor-libraries/VidorFPGA

    https://github.com/vidor-libraries/VidorGraphics



    "richtiges HDMI" (auch mit V4000):

    https://github.com/hdl-util/hdmi

    https://github.com/hdl-util/hdmi-demo

    https://github.com/hdl-util/sdram-controller


    DVI Text-Modus mit 80x25 Zeichen a 8x8 (640x360)

    https://github.com/Giako68/TEXT_DEMO


    Tiled graphics (16x16 Tiles)

    https://github.com/Giako68/TiledScreen


    Vidor Game library

    https://github.com/MinatsuT/VidorGdev

    https://github.com/MinatsuT/VidorBitstream_GFX_HW



    Ncht für MKRV4000, aber DVI 960*540, SDRAM burst read for GFX

    https://github.com/Giako68/SD_RAM_VIDEO



    HW-line rasterizer addon for VidorGraphics with free Nios /e

    https://github.com/vstrakh/VidorRaster



    "This repository contains a basic file structure to upload a custom FPGA design to the Arduino VIDOR 4000 FPGA EEPROM."

    https://github.com/jloaiza/sketch-vidor-fpga-basic


    This repository contains the bare minimum to create a project for the MKR Vidor 4000 from scratch.:

    https://github.com/chelmich/vidor_template


    https://github.com/hannessolo/verilog-simple-cpu

    https://github.com/crispycookies/VidorTemplateFPGA

    https://github.com/mongoq/MKR_Vidor_4000 (getting started)

    https://github.com/FPGAArcade/replay_mkrvidor4000



    Infos und Tutorials:

    https://hackaday.com/2018/07/3…pga-board-mkr-vidor-4000/

    https://hackaday.com/2018/11/0…on-with-the-arduino-fpga/

    https://hackaday.com/2018/10/1…-instructions-hit-france/

    https://systemes-embarques.fr/…e-trame-dvi-avec-un-fpga/

    https://nerdhut.de/2020/08/17/…mcu-hello-world-tutorial/

    https://maker.pro/arduino/tuto…ga-with-intel-quartus-ide

  • Ich denke sicher wäre nur nach HDMI 1.0 zulässige 16:9 Formate zu erzeugen, denn die sollte jeder TV und 16:9 Monitor dann automatisch und richtig skalieren können.

    Entspricht leider auch meiner Erfahrung. Man kann es bereits daran erkennen, wenn man Videos am Fernseher abspielen will (z. B. über USB-Stick) und die Videos über eine "krumme" Auflösung verfügen. Da wird dann bei einigen Fernsehern munter ein Teil des Bildes abgeschnitten. Nicht gerade das, was man möchte. Zwar ist - wenn ich mich recht erinnere - seit HDMI 1.2 in der Definition festgehalten, daß das Ausgabegerät jedes Bildformat annehmen soll, doch wie die Wiedergabe konkret aussieht, ist völlig der Willkür des Herstellers überlassen.

    Um einigermaßen auf der sicheren Seite zu sein, empfiehlt es sich daher dringend, entweder eine alte etablierte VGA-Auflösung wie 640x480 zu nehmen, wobei dann wenigstens der Rahmen konstant schwarz bleibt, oder wie RexRetro sagt, ein modernes 16:9 Format heranzuziehen. Ansonsten läuft es darauf hinaus, daß man dem Computer eine Empfehlung für bestimmte Fernseher beifügen muß: "Das beste Bild für diesen Rechner erzielen Sie auf einem Samsonic Z80cpc, aber nur wenn draußen die Sonne scheint und gleichzeitig die Glocken läuten, weil gerade Ostern ist."

    Und dann muß man sich halt überlegen, welche Grundauflösung man als Fernseherauflösung haben möchte, um z. B. 480 Pixel horizontal anzuzeigen. Sicher ist: Bei allen Auflösungen außer Full HD 1920 erhält man auf jeden Fall einen schwarzen Rand links und rechts, denn erst 1920 entspricht einem Vielfachen von 480. Dadurch hat man aber auch ein sehr scharfes, d. h. pixelgenaues Bild, was nicht unbedingt gut aussehen muß. Der größte Nachteil bei Full HD wird allerdings sein, daß man die Übertragungsgeschwindigkeit mit einem FPGA nicht hinbekommt. Da wird teure Zusatzhardware nötig sein. Ob das lohnt?

  • Naja aber gibt es da eine Signalisierung?

    Ja, mehrere =(


    Der größte Nachteil bei Full HD wird allerdings sein, daß man die Übertragungsgeschwindigkeit mit einem FPGA nicht hinbekommt.

    Doch, es gibt FPGAs mit denen man das hinbekommt. Entweder durch Übertaktung und sorgfältiges Placement oder durch Verwendung von GBit-tauglichen Transceivern wenn der Chip welche besitzt. Erstere Variante fand sich zB mal mit einem Spartan 6 im alten Hamsterworks-Wiki. Letzteres findet man zB oft in Hardware von Blackmagic Design, zB im HDMI/SDI Bidirecitonal Micro Converter.

  • die "Devices" im offiziellen FPGA Bitstream von Arduino nutzen eine Nios2/f Softcore CPU (f == fast) als Koordinator. Die scheint auch die eigentliche Grafik zu pixeln, der ARM sendet nur Befehle.

    Ich verstehe nur Bahnhof. Da wird also in die 16000 LEs bereits ein Softcore eingebaut für die Bildanzeige? ?( Der Code dafür befindet sich in einem Flashrom, welches die Daten über eine serielle Verbindung an die CPU schickt? Ernsthaft? Irgendwie versuche ich verzweifelt. das Konzept dieses Systems zu verstehen, aber es scheint mir nicht zu gelingen.

    Meine bisherige Schulßfolgerung aus dem Gesagten ist, daß sich im FPGA zusätzlich zum SoftCore noch ein Videocontroller befinden muß, der die Daten aus dem SDRam holt und an den HDMI-Port schickt. Nichts von alledem macht für mich irgendwie einen Sinn, denn eigentlich sollte es darum gehen, eine eigene CPU und einen eigenen Videocontroller zu entwerfen. Den Links zufolge haben sich das wohl auch andere schon gedacht und folglich angefangen, Video- und SDRam-Controller selbst zu schreiben. Leider habe ich nicht die Zeit, mir all die Links anzugucken. Wäre daher nett, wenn Du uns weiter über Deine Erfahrungen berichten könntest.

  • Bei PAL wären das wohl 27MHz. Bei angenommenen 10 Bit pro Pixel haben wir 270MHz serielle clock was dann wohl den technischen Rahmen des FPGAs mit 250MHz sprengen wird.

    Im V4000 Forum wurde geschrieben, dieser Cyclone 10 mache mit LVDS transmitter 640 Gbits.

    Und 8 statt 10 Bit pro Farbkanal sollte auch gehen.

  • Naja aber gibt es da eine Signalisierung?

    Ja, mehrere =(


    Doch, es gibt FPGAs mit denen man das hinbekommt. Entweder durch Übertaktung und sorgfältiges Placement oder durch Verwendung von GBit-tauglichen Transceivern wenn der Chip welche besitzt. Erstere Variante fand sich zB mal mit einem Spartan 6 im alten Hamsterworks-Wiki. Letzteres findet man zB oft in Hardware von Blackmagic Design, zB im HDMI/SDI Bidirecitonal Micro Converter.

    Klingt spannend. Gibt es da irgendwelche bezahlbaren Dev Boards mit DVI/HDMI-Out für ETechnik-Noobs mit SMD Lötallergie (wie mich)?

  • Um einigermaßen auf der sicheren Seite zu sein, empfiehlt es sich daher dringend, entweder eine alte etablierte VGA-Auflösung wie 640x480 zu nehmen, wobei dann wenigstens der Rahmen konstant schwarz bleibt, oder wie RexRetro sagt, ein modernes 16:9 Format heranzuziehen.

    Ich habe mir nochmal die alten Postings bzgl. Auflösungen angesehen und würde folgenden Kompromiss-Vorschlag machen: Ich könnte mir die VGA-Auflösung als HDMI-Output vorstellen, allerdings dann verzerrt auf 1920 x 1080 (das müsste man am TV ja einstellen können, wenn es nicht per default passiert). Dann hätte man etwas in die Breite gezogene Pixel, ähnlich der C64-Multicolor-Auflösung (oder auch beim NES). Als native Grafikauflösung für Spiele hätte man dann 1/4 dieser Auflösung, also 320 x 240 Pixel (natürlich auch in die Breite gezogen). Diese Auflösung müsste dann der FPGA nur auf VGA (640 x 480) hochskalieren (das sollte ja nicht allzu aufwendig sein). Für den Code-Editor setzen wir dann auf die volle VGA-Auflösung aber da bieten wir nur einen Textmode an, keine Bitmap-Grafik. Das müsste doch eigentlich klappen.


    Das ganze macht aber nur Sinn, wenn die TVs nicht zusätzlich in den Overscan gehen und überall an den Rändern Grafik abschneiden.

  • das müsste man am TV ja einstellen können

    Also bei meinem Fernseher (Panasonic) kann ich da nichts einstellen.

    320 x 240 Pixel

    Verstehe ich das jetzt richtig: Du verzichtest notgedrungen auf die eigentlich anvisierten 480 Pixel? Wenn dies so sein sollte, hätte es auch Auswirkung auf die Frage nach VGA und HDMI, denn genau diese 480 Pixel Auflösung war ja der Hauptgrund dafür, HDMI bereits im Rechner zu verbauen und nicht (zumindest vorübergehend, solange es keine bessere Lösung gibt) ein VGA-Bild von 640 Pixeln per Adapter nach HDMI zu konvertieren.

    Für den Code-Editor setzen wir dann auf die volle VGA-Auflösung aber da bieten wir nur einen Textmode an, keine Bitmap-Grafik.

    Oder man macht es halt wie beim CPC und setzt eine Obergrenze von 2 Farben pro Zeile.


    Aber bitte beachten:

    Da die Farben wie beim C64 über Farbregister zugewiesen werden, kann man diese auch zeilenweise abändern. Sprich: Auch eine 640 Pixel reine Zeichenausgabe kann man durch zeilenweises Abändern sehr bunt aussehen lassen. Das gilt insbesondere dann, wenn das Ändern der Farbe wie bei meinem Videocontroller nicht von Hand durch den Prozessor geschieht, sondern automatisch durch die Anzeigeliste (= kein Rasterinterrupt nötig).

    Es wird schwierig sein, zwischen einer 320 Pixel-Anzeige und einer 640 Pixel-Anzeige künstliche Begrenzungen einzuführen, denn all diese erfordern aufwendigen Code im FPGA. Wie ist es z. B. mit dem X-Scrollregister? Wird das lahmgelegt? Kann man die Adresse des Zeichensatz umsetzen? Wenn beides möglich ist, wird sich sicherlich jemand finden, der für diesen Modus ein Ballerspiel schreibt. Der Zeichensatzmodus ist schließlich der stärkste Modus und verbraucht daher im Videocontroller am meisten Platz. Diesen in einer höheren Auflösung künstlich zu beschränken wird nicht leicht.

    Ich würde nal 16:9 Formate wie 640x360 und 768x432 testen wollen.

    Sofern man jetzt einen HDMI-Anschluß hat, könnte man das machen. Das ergäbe dann bei 320 Pixeln horizontal aber nur eine krumme vertikale Auflösung von 180 Pixeln. Krumm deshalb, weil man sie nicht durch 8 teilen kann, was der Standardhöhe eines Zeichens entspricht. Man erhält so 22,5 Zeilen auf dem Bildschirm. Als reiner Bitmapmodus könnte es aber natürlich funktionieren.