Alles anzeigenDas 8MB SDRAM hängt momentan mit 100 MHz und 16 Bit am FPGA.
Wenn ich das jetzt richtig verstanden habe, funktioniert die Videowiedergabe so:
1.) Der Videocontroller im FPGA holt sich die Videodaten für zwei Anzeigen (= 2 Bitmaps) aus dem Ram.
2.) Daraus konstruiert er die Bilddaten und schreibt für jedes Pixel einen 16 Bit-Wert in das Ram.
3.) Der ARM-Prozessor holt sich die Pixeldaten aus dem Ram und leitet sie an den HDMI-Port weiter.
4.) Der Prozessor im FPGA greift auf das Ram zu, um sich von dort Befehle und Daten zu holen.
5.) Der ARM-Prozessor greift auf das Ram zu, um sich von dort Befehle und Daten zu holen (für zusätzliche USB-Behandlung etc).
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 Bitte melde dich an, um diesen Link zu sehen..
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.