FPGA VGA als Ansatz ?

[guest522]

Hi,

das mit der besseren Grafik für unsere kleinen Kisten lässt mir keine Ruhe. Wie sieht es mit einem Ansatz wie diesem aus?

Bsp. 1
Bsp. 2

[matashen]

Ist ein guter Ansatz, vor allem Beispiel 2 zeigt sehr schön die Grundlagen.

Die Frage ist nur wie willst du das am Atari anbinden - brauchst dann ja Treiber oder so was...
... und jemanden der was mit FPGAs drauf hat.

Gruß Matthias

[guest522]

Was genau mus man tun um die Ausgaben zu verbiegen?
Sicher doch die VDI calls durch eigene ersetzen und auf dem FPGA ablaufen lassen, oder? Damit wäre man natürlich nur kompatibel zu sauberen calls. Also nicht wie bei SuperVidel, der ja die Originalhardware ersetzt.

Dabei kann man sicher stufenweise VDI Funktionen durch FPGA ersetzen. Aber so wirkliche Ahnung hab ich davon nicht. 

[frank.lukas]

War nicht der Grafikcontroller auf der Galaxy VME Bus Karte von Mario Becroft ein FPGA ?

Wenn jemand es hinbekommen würde die paar ET4000 Befehle welche im NVDI genutzt werden um die ET4000 Grafikkarte anzusprechen in einem FPGA so umzusetzen/einzubauen das die Treiber einen Virtuellen ET4000 aber mit mehr Videoram und höher Bandbreite (Pixelclock) ansprechen ...


Frank

[frank.lukas]

Unter diesem Link  bekommt man viele ET4000 Datenblätter über diesen Grafikprozessor.

Dort gibt es auch etwas über einen Intel 82786 Grafikprozessor der in allen Matrix Garfikkarten egal ob Mega ST Bus oder VME drauf ist außer der TC Karte und einer reinen ECL Karte. Das Ding war auch auf einer Maxon Karte für den Mega ST Bus drauf.

Frank

[wfoerster]

Hi,
ich denke, dass ich es hinbekommen könnte. Grafik steht bei mir nämlich auch auf meiner Prio-Liste ganz oben. Ich würde anregen vielleicht das Ganze bereits für TFTs oder mit DVI Schnittstelle zu planen. Damit ist man dann gleich um ca. 20 Jahre moderner als mit VGA. Vielleicht kann man an dieser Stelle evaluieren, was eigentlich wer will und wie das mit den Grafiktreibern aussieht etc. Wer mir Infos schicken möchte (Datenblätter, Programmierhandbücher usw.) gerne auf wf@inventronik.de. Für eine Internetrecherche fehlt mir leider momentan die Zeit. Ich würde mich dann zu gegebener Zeit wieder hier einklinken.

Grüße

Wolfgang

[tuxie]

Hi,

habe hier schonmal geschaut
http://www.opencores.org/browse.cgi/by_category

Aber so richtig was brauchbares gibts wohl nicht. Könnte es sein das der Wishbone Bus dem des 68k recht ähnlich ist?

[guest522]

Ich werd mal meine Energien in Richtung (Nova)VDI lenken. Mal sehen was ich lernen kann.

Was ich will?

- DVI ist ne gute Idee, da spart man die D->A->D Wandlung
- mind. 4MB Speicher
- .....

   

[frank.lukas]

Hallo,

ich denke mal stark das so ein Projekt ohne die richtige Treibersoftware recht sinnlos ist. Selbst wenn sich jemand findet der einen solchen Treiber schreiben könnte wird er wohl nie den Level der Nova oder NVDI Treiber erreichen. Alles andere egal ob fVDI oder Treiber der diversen anderen Karten (Galaxy etc.) sind noch weit von den Nova oder dem NVDI entfernt und sind schon verstorben oder im Falle des fVDI wird nur daran gearbeitet um die Anbindung an Aranym zu verbessern.

Ich persönlich stelle für mich NVDI an die erste Stelle und erst an die zweite Stelle die Novatreiber. Letztendlich muss ich NVDI doch installieren wegen der Druckertreiber und vor allem der Vectorfont Unterstützung und dem damit verbundenen GDOS. Egal ob singleTOS, MiNT, MagiC oder sonst irgend etwas ...

Wenn man einen Grafikprozessor im FPGA emuliert ist es mit Sicherheit egal was für einen Grafikprozessor man da nachbildet. Die erreichbare Geschwindigkeit hängt ja in ersten Linie an der Taktung (und der Codequalität) des FGPA. Ich denke das sowas nicht allzu schwierig ist für jemanden der da genügend Erfahrung hat. Die Treiber NVDI und Nova nutzen ja nicht alle Möglichkeiten eines ET4000 oder ATI 68800 oder 88800 Prozessors.

Ich würde mir einen Grafikchip wünschen der eine ET4000 mit 4-8MB Garfikspeicher und einen Pixelclock der auch auf einem CRT Bildschirm 1280x1024-80Hz mit 16,7M Farben dastellen kann. Auf einem TFT Display auch gerne größere Auflösungen bei 60Hz und da braucht es schon 8MB an Grafikspeicher ...


grüße

  Frank

[matashen]

4-8MB und 1280x1024-80Hz mit 16,7MFarben hmm mal nachrechnen

1280x1024=(Taschenrechner rauszieh)13107200 Pixel
x 24Bit Farbtiefe

= 39321600 Byte(!) Würden also wenn man noch ein paar ablagemöglichkeiten für anderen krimskrams dazunimmt 8MB ausreichen.

hmm Ob die Datenmenge dann noch dein Rechner abkraftet wag ich zu bezweifeln. Der Alte Bus schafft doch höchstens 2MB/sec(bitte korrigieren, das weis ich nciht) ojeoje da sieht man dann den Bildaufbau wenn was an die GraKa übertragen wird.

Gruß Matthias

[frank.lukas]

Hallo matashen,

habe mal verschiedene Farbtiefen getestet und muss sagen das selbst bei 32bit noch ein Arbeiten mit dem Rechner möglich ist. Ab der 16bit Auflösung aufwärts wird es natürlich recht langsam aber es geht noch. Und wer weiss schon ob nicht doch mal einen 040er Beschleuniger für den alten Atari TT geben wird. Ich persönlich würde gerne mit einer 16bit Auflösung und 1600x1200 Pixel den Atari TT betreiben wollen und dafür braucht es mehr Videospeicher ...

CPUNAME=68030-32Mhz;
FPUNAME=68882-32Mhz;
SYSTEMBUS=16Mhz;
BOGOMIPS=7.00;
MACHINE_NAME=TT030;
VIDEO=VME Nova Mach32 2MB_VRAM;
SOUND=PSG+DMA;
NAMEOS=MiNT 1.16.3/XAAES;
ROM=3.6;
AES=4.10;
GDOS=Yes;
VDI=NOVA 2.67/NVDI 5.3;
SPEEDO=Yes;


--- SCREEN=640*480 8bits ---

VDI_CIRCLE=497.925; (op/sec)
VDI_ARC=1493.776; (op/sec)
VDI_BAR=4119.231; (op/sec)
VDI_ELLARC=1487.603; (op/sec)
VDI_ELLIPSE=441.176; (op/sec)
VDI_ELLPIE=38.278; (op/sec)
VDI_PIESLICE=45.977; (op/sec)
VDI_RBOX=537.089; (op/sec)
VDI_PLINE=13643.836; (op/sec)
VDI_FILLAREA=66.812; (op/sec)
VDI_GTEXT=831.683; (op/sec)
VDI_JUSTIFIED=502.242; (op/sec)
VDI_BLITTING=4862.500; (op/sec)

VDI perf : 112.983


--- SCREEN=640*480 15bits ---

VDI_CIRCLE=493.827; (op/sec)
VDI_ARC=1487.603; (op/sec)
VDI_BAR=3582.439; (op/sec)
VDI_ELLARC=1487.603; (op/sec)
VDI_ELLIPSE=433.213; (op/sec)
VDI_ELLPIE=38.318; (op/sec)
VDI_PIESLICE=46.036; (op/sec)
VDI_RBOX=537.089; (op/sec)
VDI_PLINE=12469.484; (op/sec)
VDI_FILLAREA=66.885; (op/sec)
VDI_GTEXT=827.586; (op/sec)
VDI_JUSTIFIED=500.000; (op/sec)
VDI_BLITTING=4466.986; (op/sec)

VDI perf : 107.749


--- SCREEN=640*480 16bits ---

VDI_TIMER_ERROR=0;
VDI_CIRCLE=493.827; (op/sec)
VDI_ARC=1487.603; (op/sec)
VDI_BAR=3582.439; (op/sec)
VDI_ELLARC=1487.603; (op/sec)
VDI_ELLIPSE=433.213; (op/sec)
VDI_ELLPIE=38.318; (op/sec)
VDI_PIESLICE=46.036; (op/sec)
VDI_RBOX=537.089; (op/sec)
VDI_PLINE=12469.484; (op/sec)
VDI_FILLAREA=66.885; (op/sec)
VDI_GTEXT=827.586; (op/sec)
VDI_JUSTIFIED=500.279; (op/sec)
VDI_BLITTING=4466.986; (op/sec)

VDI perf : 107.749


--- SCREEN=640*480 24bits ---

VDI_TIMER_ERROR=0;
VDI_CIRCLE=216.606; (op/sec)
VDI_ARC=983.607; (op/sec)
VDI_BAR=389.809; (op/sec)
VDI_ELLARC=956.175; (op/sec)
VDI_ELLIPSE=211.268; (op/sec)
VDI_ELLPIE=13.642; (op/sec)
VDI_PIESLICE=17.304; (op/sec)
VDI_RBOX=335.484; (op/sec)
VDI_PLINE=2107.937; (op/sec)
VDI_FILLAREA=27.617; (op/sec)
VDI_GTEXT=79.602; (op/sec)
VDI_JUSTIFIED=95.339; (op/sec)
VDI_BLITTING=1155.446; (op/sec)

VDI perf : 11.087


--- SCREEN=640*480 32bits ---

VDI_TIMER_ERROR=0;
VDI_CIRCLE=212.766; (op/sec)
VDI_ARC=1016.949; (op/sec)
VDI_BAR=376.615; (op/sec)
VDI_ELLARC=991.736; (op/sec)
VDI_ELLIPSE=215.827; (op/sec)
VDI_ELLPIE=11.749; (op/sec)
VDI_PIESLICE=15.126; (op/sec)
VDI_RBOX=349.847; (op/sec)
VDI_PLINE=2441.176; (op/sec)
VDI_FILLAREA=25.051; (op/sec)
VDI_GTEXT=137.255; (op/sec)
VDI_JUSTIFIED=152.511; (op/sec)
VDI_BLITTING=3764.516; (op/sec)

VDI perf : 15.745

--- Memory Video Busspeed ---

READ=2.281; (Mo/sec)
WRITE=3.518; (Mo/sec)
MOVE=34.064; (Mo/sec)

--- für alle Farbtiefen und Auflösungen gleich ---



grüße

  Frank

[guest522]

Klar wäre es schön wenn man solche Auflösungen hätte....aber mein Ziel ist es eher eine umsetzbare Lösung zu finden.

Wenn man auf bestehende Treiber aufsetzt ist der schwierigste Teil (die Software) erledigt. Da muss man ggfs. nur Adressen ändern. NVDI liegt mir leider nicht im Sourcecode vor und die Zeit für Reverse-Engineering habe ich nicht. Im Übrigen wird da ja auch nur ET4000 unterstützt, oder?

Das Nova VDI ünterstützt bereits ET4000, ET6000, Mach32 und Mach64, sowie das Einbinden von NVDI.

Falls sich jemand die Mühe macht individuelle vdi-Routinen aus NVDI zu isolieren, kann man die ja evtl. auch in das Nova-vdi integrieren. Wobei ich bezweifle, dass da viel zu holen ist, da das NVDI ja einen komplett anderen Ansatz (bessere Nutzung der ATARI-Hardware) verfolgt.

[guest522]

VME2PCI Adapter

Kann sich das mal jemand ansehen?

[wfoerster]

Ich habe mir mal die Datenblätter zur ET4000 von Tseng-Labs angesehen. Prinzipiell steht der Umsetzung nichts im Weg. Was mich aber stört sind die in etwa fuffzig verschiedenen Grafikauflösungen, die sicher heutzutage keiner mehr braucht und Funktionen wie 'ich zeichne eine Linie' .... Wenn sich jemand die Mühe machen könnte und, sozusagen in einer Spezifikation, zusammenschreiben könnte, was wirklich wichtig ist, dann ließe sich eine bessere Grafikauflösung sicherlich schnell einrichten. Ich denke natürlich in Richtung Suska und würde einen erweiterten Shifter vorschlagen, der sich für Anwender älterer Hardware als Austauschmodul realisieren ließe. Interessant wäre natürlich auch die Kompatibilität zu Mint oder anderen Betriebssystemen. Bei Tos denke ich, ist da sowieso Ende der Fahnenstange.

Viele Grüße

Wolfgang

[frank.lukas]

Was mich aber stört sind die in etwa fuffzig verschiedenen Grafikauflösungen

... sowas findet man sicher bei jedem Chipsatz.

Was TOS, MiNT etc brauchen ist eine einfache mono Auflösung zu booten und ich persönlich würde vorschlagen sich an den Standard TFT-Display Auflösungen zu halten, also 1024x768, 1280x1024, 1600x1024 usw. und vielleicht alles mit jeweils ein Bit (mono), 8 Bit, 16Bit sowie 24/32 Bit. Jeweils fest einmal mit 60Hz (TFT) und gerne fest mit 75Hz für die alten CRT Multiscan Bildschirme. Eine Ausnahme würde vielleicht für Spiele und alte Programme ST-Gering mit 4 Bit sowie ST-Hoch bilden und wenn schon dann fehlen da noch die Auflösungen des Falcon die man für Spiele dringend braucht.

Wobei da natürlich einiges zusammen kommt.   

Idek sollte mal die Nova Quellen weiter geben ...

Interessant wäre natürlich auch die Kompatibilität zu Mint oder anderen Betriebssystemen.

Wenn man zum TOS zu einhundert Prozent kompatibel ist und bleibt bedeutet das ja auch das man mit MiNT, NetBSD, Linux, MagiC usw. keine Probleme bekommt ...

Allerdings unterstützen die BSD und Linux Geschichten nur original Atari Video Hardware einschliesslich der Atari TT-Hoch und der Viking ECL Karten Auflösung von 1280x960 Pixeln ...

[wfoerster]

Hi,
das klingt ok. Ein paar Auflösungen kann man sicher in Hardware vernünftig realisieren. Ich habe zwar auch zwei TTs rumliegen aber über Die Video-Möglichkeiten weiss ich nicht viel, bis auf die Tatsache, dass wohl ein externer 'Nicht-Atari'-Chip für die hohe Auflösung eingesetzt wurde, Viking-ECL kenne ich nicht, wäre aber über Infos dankbar. Kann jemand etwas über die Grafikfähigkeiten von Mint sagen? - Sorry, ich bin momentan nicht in der Software unterwegs, da Suska recht zeitintensiv ist.

Viele Grüße

Wolfgang

[frank.lukas]

Hallo Wolfgang,

Atari TT Video alle bei 60Hz VGA
- ST Gering
- St Mittel
- St Hoch
- TT Gering (ST Gering bei 256 Farben)
- TT Mittel 640x480 4bit (16Farben) VGA

- TT Hoch 1280x960 mono Pixelclock 128Mhz, Hsync 72Khz, Vsync 72Hz
---
Atari SM194
1280x960 mono Pixelclock 110Mhz, Hsync 66Khz, Vsync 66Hz
---

Außer der TT-Hoch ECL Auflösung sind alle anderen speziellen TT Auflösungen uninteressant denke ich da es sehr wenig bis gar keine Programme gibt die diese nutzen. Für die Software kompatibilität sind nur eine ST-Gering und die ST Hoch Auflösung wichtig. Die 1280x960 mono Auflösung kann in einer 1280x1024 Auflösung aufgehen. Man sollte natürlich noch die kleine Falcon Farbauflösung mit einbeziehen damit Demos und Spiele speziell für den Falcon Lauffähig sind.

grüße

  Frank

[wfoerster]

Hallo,
das klingt nicht sonderlich schwierig. Das Einzige, was man eventuell beachten müsste ist das 'shared memory' Konzept; soweit ich informiert bin, macht der TT das auch so. Die Videodaten werden dabei zwischen den CPU- und Blitter- und DMA Buszugriffen geholt. Das bedeutet aber, dass der Bus schnell takten muss, um den Datendurchsatz für die hohen Auflösungen zu schaffen. Beim TT wird die CPU glaube ich mit 32MHz getaktet, was dann einen Bustakt von maximal 10MHz ergibt (beim 68020/30 3 Takte pro Buszugriff). Nun lässt sich so ein Konzept natürlich nur schwer in normalen STs einsetzen und auch der Falcon ist dafür etwas zu langsam. Das wiederum würde bedeuten, dass man mit einem eigenen Video-RAM besser zurecht käme. Dabei leidet aber dann möglicherweise die Software-Kompatibilität.
Ich hoffe, dass ich mit diesen Ausführungen richtig liege und keinen Denkfehler gemacht habe.

Viele Grüße

Wolfgang

[pakman]

Die Videodaten werden dabei zwischen den CPU- und Blitter- und DMA Buszugriffen geholt. Das bedeutet aber, dass der Bus schnell takten muss, um den Datendurchsatz für die hohen Auflösungen zu schaffen. Beim TT wird die CPU glaube ich mit 32MHz getaktet, was dann einen Bustakt von maximal 10MHz ergibt (beim 68020/30 3 Takte pro Buszugriff).

Richtig. Aber der TT-Bus wird mit 16 MHz getaktet, nur die CPU läuft mit 32 MHz.
Die Video-Zugriffe besorgen so nebenbei auch den Refresh für die DRAMs.

dass man mit einem eigenen Video-RAM besser zurecht käme

Definitiv. Ich würde keine Kompromisse bei der Geschwindigkeit eingehen.

Dabei leidet aber dann möglicherweise die Software-Kompatibilität

Falls das wirklich gebraucht wird, folgender Vorschlag:
Ein eigenes Video-RAM! Dann per Glue-Logic dafür sorgen, dass Zugriffe auf den "Bildspeicher" parallel ins normale RAM und in den Videospeicher geschrieben werden. Die Zusatzlogik muss die Register 8200 und 8202 (Video Base High/Mid) überwachen. Falls diese Register beschrieben werden, muss der Bildschirmspeicher einmalig neu umkopiert werden, dann geht es wieder weiter mit parallelen Schreibzugriffen.

Vorteile:
Maximale Speed für DRAM-Zugriffe ausserhalb des Bildschirmspeichers!
Maximale Speed für DRAM-Lese-Zugriffe in den Bildschirmspeicher (Wenn die CPU Daten aus dem "Bildschirmspeicher" braucht, kann sie die aus dem DRAM holen)!
Einzig beim Schreiben in den Bildschirmspeicher könnte es sein, dass die CPU warten muss, da das Auslesen des Videosignal Vorrang hat, sonst blitzt es. Mit einem Buffer-Memory (nochmal so groß wie der Videospeicher) und "posted write" muss die CPU hier aber auch nicht mehr warten.

Gruß, Holger