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