Hardware > Hardware (Classic 16-/32-Bit)
VGA Interface FPGA
Mathias:
Ganz generell, ihr wissts aber schon, daß das mit dem Suska III-C schon vieles umgesetzt wurde, oder? Ich frage mich wieso immer wieder auf die geniale Arbeit von Wolfgang vergessen wird, und stattdessen OpenCores und Amigas herangezogen werden. Auch die Galaxy von Mario Becroft war ja Hardwareseitig fertig, und es fehlte "nur" noch der Treiber. Die erste fVDI-Version die er erstellt hat war halt so extrem buggy, daß er Endusern wie mir noch keine Karte "zumuten" wollte damals. Aber darauf könnte man sicher auch aufbauen.
Ich halte dieses ewige "Rad neuerfinden" für eines unserer Hauptprobleme. Wenn die ganzen letzten Mohikaner anfangen würden zusammenzuarbeiten, dann hätten wir vielleicht keine 12 Webbrowser, aber einen Funktionierenden, …
--- Zitat von: mfro am So 24.07.2016, 17:55:34 ---
--- Zitat von: Nervengift am So 24.07.2016, 14:56:24 ---Wobei es für diesen Core wohl noch Optimierungsbedarf gibt, was die Geschwindigkeit ...
--- Ende Zitat ---
Nö.
Die FireBee-Grafik ist als Framebuffer so schnell, wie der FlexBus der ColdFire-MPU das hergibt (die CPU kann einfach nicht schneller in das Grafik-RAM schreiben, weil alles über den gemultiplexten 32 MHz Bus muß).
Weitere Beschleunigung könnte man nur noch mit in Hardware gegossener Highlevel-Grafikbeschleunigung (Linien, Kreise, Rasterkopien, ...) erreichen.
Ansonsten ist die FireBee Grafik nahezu auf dem Niveau des SuperVidel (der "SuperBlitter" fehlt, würde allerdings auch nicht so sehr viel bringen, weil s.o.).
--- Ende Zitat ---
Danke für die technische Klarstellung!
Was mich jedoch schon wundert ist warum das Scrolling in hohen Auflösungen so extrem langsam ist? Da sollte doch noch mehr gehen?
Und der Hauptvorteil de Radeon wäre dann daß der PCI-Bus mit vollen 132 MHz an der CPU hängt?
--- Zitat von: mfro am So 24.07.2016, 17:55:34 ---
--- Zitat von: Nervengift am So 24.07.2016, 14:56:24 ---... etc. angeht
--- Ende Zitat ---
Fehler gibt es noch in den ST- und Falcon-Doppelzeilenmodi, sonst funktioniert weitgehend alles.
--- Ende Zitat ---
Plus dem Polaritätsproblem in sehr hohen Auflösungen für manche Monitore, oder?
mfro:
--- Zitat von: Mathias am Di 26.07.2016, 01:43:33 ---
--- Zitat von: mfro am So 24.07.2016, 17:55:34 ---
--- Zitat von: Nervengift am So 24.07.2016, 14:56:24 ---Wobei es für diesen Core wohl noch Optimierungsbedarf gibt, was die Geschwindigkeit ...
--- Ende Zitat ---
Nö.
Die FireBee-Grafik ist als Framebuffer so schnell, wie der FlexBus der ColdFire-MPU das hergibt (die CPU kann einfach nicht schneller in das Grafik-RAM schreiben, weil alles über den gemultiplexten 32 MHz Bus muß).
Weitere Beschleunigung könnte man nur noch mit in Hardware gegossener Highlevel-Grafikbeschleunigung (Linien, Kreise, Rasterkopien, ...) erreichen.
Ansonsten ist die FireBee Grafik nahezu auf dem Niveau des SuperVidel (der "SuperBlitter" fehlt, würde allerdings auch nicht so sehr viel bringen, weil s.o.).
--- Ende Zitat ---
Danke für die technische Klarstellung!
Was mich jedoch schon wundert ist warum das Scrolling in hohen Auflösungen so extrem langsam ist? Da sollte doch noch mehr gehen?
--- Ende Zitat ---
Wenn Du scrollen willst, mußt Du den Inhalt des Bildspeichers - z.B. für eine neue Bildschirmzeile - um 16 Pixel "nach oben" kopieren. Bei 1920 x 1080 x 32 Bit sind das etwa 8 MByte, die bewegt werden müssen.
Jedes einzelne Byte muß die CPU (die eigentlich wesentlich schneller wäre) über den (langsamen) FlexBus aus dem Bildspeicher holen und wieder zurückschreiben. Der FlexBus läuft mit 33 MHz und braucht für einen Buszyklus (mindestens) 4 Takte (für Lesen und Zurückschreiben entsprechend 8 ).
Im besten Fall braucht die CPU also für jeden Kopiervorgang (der ja - beim Textscrollen, z.B. - vielfach vorkommt) dieses Riesenbildschirms (das Problem ist weniger die Auflösung als die hohe Farbtiefe) etwa 0,5 s.
Tatsächlich braucht sie sogar noch etwas länger, weil sie während des Kopiervorgangs mehrfach dem TFP410 (dem "Firebee-Shifter") begegnet, der den Bildschirmspeicher in Richtung Bildschirm "pumpt" und auf den warten muß.
--- Zitat von: Mathias am Di 26.07.2016, 01:43:33 ---Und der Hauptvorteil de Radeon wäre dann daß der PCI-Bus mit vollen 132 MHz an der CPU hängt?
--- Ende Zitat ---
Nicht ganz. Der PCI-Bus ist mit 66 MHz angebunden (und das auch nur dann, wenn alle Karten, die drinstecken, auch 66 MHz unterstützen). Ist also maximal etwa doppelt so schnell als der FlexBus. Tatsächlich dürfte der Unterschied deutlich geringer ausfallen, weil jeder PCI-Bus Zugriff erstmal mindestens einen extra Buszyklus braucht, um den Bus zu übernehmen (wenn man das also "unglücklich" programmiert, ist er sogar langsamer als der FlexBus). In meinem m5484-Evaluationboard steckt eine Radeon-Karte drin. Die scrollt beim Booten wesentlich langsamer als die FireBee-Grafik.
Dieselbe Problematik (die alle Grafiksysteme haben, die hohe Auflösungen bei hoher Farbtiefe unterstützen) hat bei PCs erst zu den "LocalBus"-Grafikkarten und dann zu den Grafikbeschleunigern geführt. Statt die 8 MByte erst lahm zu lesen und sie dann wieder lahm zurückzuschreiben, sagt man der Grafikkarte einfach "um 16 Pixel nach oben verschieben" und der Vorgang läuft innerhalb des Grafikspeichers wesentlich schneller ab. Die (sehr) theoretische Speicherbandbreite des FPGA RAMs liegt bei etwa 2 GB/s (also etwa 60 mal schneller als unser FlexBus). In der Realität dürfte maximal etwa 1/3 davon erreichbar sein, was immer noch eine deutliche Steigerung wäre.
Um das hinzubekommen, bräuchten wir aber wieder "FPGA-Intelligenz" - also etwas wie den "SuperBlitter" der SuperVidel-Karte - und (völlig) andere, neue Grafiktreiber.
Damit wäre zunächst nur das Kopieren innerhalb des Grafikspeichers beschleunigt. Das Problem stellt sich aber beim Zeichnen von z.B. Rasterflächen und Linien genauso (also noch mehr Hardwarebeschleunigung und Treiberarbeit notwendig). Meines Wissens nach kann das die SuperVidel-Karte aber auch (noch) nicht.
--- Zitat von: Mathias am Di 26.07.2016, 01:43:33 ---
Plus dem Polaritätsproblem in sehr hohen Auflösungen für manche Monitore, oder?
--- Ende Zitat ---
Ich bin nicht sicher, aber das ist m.E. ein Hardwareproblem, das sich im FPGA nicht beheben läßt.
Börr:
Spiele laufen dann aber wieder nicht mehr oder? Ist es nicht besser sowas wie das http://www.vesalia.de/d_indivisionecs.htm hier zu bauen?
Gast120501:
Hmmm, 2 Shifter in einem ST, ob das geht? Glaube eher nicht. Obwohl... Wenn man den zweiten Shifter am Alt-RAM andocken würde.... Flickerfixer braucht man am ST nicht.
tuxie:
Doch das geht, gab es auch mal in der ct ein Projekt um mehr Farben darzustellen
http://atari4ever.free.fr/hardware/zip/32kcolor.zip
@matthias
Die Arbeit von Wolfgang Förster honoriere ich sehr, und ich habe auch hier auf meinem Rechner die Quellen des Suska Projektes liegen. Ich beschäftige mich erst seit kurzer Zeit mit VHDL und ich möchte auch einiges aus seinem Projekt einmal für normale ST´s umsetzen. Sind einiges was man da machen könnte.
In wie weit man jetzt den Videl Core z.b. verwenden kann um eine Grafikeinheit für den ST zu bauen kann ich jetzt so nicht sagen. Dazu habe ich es mir noch nicht angesehen
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln