Hardware > Hardware (Classic 16-/32-Bit)

FPGA VGA als Ansatz ?

<< < (4/4)

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:

--- Zitat von: wfoerster am Do 13.11.2008, 07:34:55 ---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).

--- Ende Zitat ---

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.


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

--- Ende Zitat ---

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


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

--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[*] Vorherige Sete