Nova 16:9 Auflösungen ...

[Lukas Frank]

Hier auf dem ST mit VOFA und Nova Treiber mit GEMBENCH 6 ...



Nimm mal NVDI als Treiber das ist schneller ...

[1ST1]

Bei mir nicht inerlaced ...

Nein DVD und MPEG und so Sachen sind nicht am Atari und der Grafikkarte. Der Falcon kann sowas wegen dem DSP ...

Kannst du vergessen, selbst mit der ct60 bei 100 Mhz und aktivem DSP ruckeln schon MPEG Videos in SVCD-Qualität. Noch schlechter aufgelöste AVIs und andere ähnliche zeitgenössische Videoformate gehen einigermaßen. Hab ich natürlich schon in Aniplayer getestet, muss ja wissen was mit der Kiste möglich ist. Nur eins habe ich bei den Tests nicht bedacht, das muss ich nochmal nacholen: Ich habe die Videos von einer vom PC beschriebenen CF abgespielt. Die hat natürlich Byteswap, was zusätzliche Systemlast erzeugt. Wenn ich mal Lust habe probiere ich das nochma, nachdem ich die Dateien auf die bootfähige CF umgeschoben habe. Vielleicht dann...?

[Lukas Frank]

Hier eine BIB für die MACH zu testen für 16:9 ...

[Lukas Frank]

Hiermal ein Bench mit der ET4000 /VOFA im original Mega ST und NVDI 3 /ET4000 ...

[tuxie]

Werde ich dann gleich mal Testen und Benchmarks machen, wobei ich erst meine Platte einrichten muß, hab mir die cf zerlegt beim Testen der Storm Platinen.

[dbsys]

Nicht übel!

Mit was für einer VMG Software arbeitest Du bevorzugt?

Hier auf dem ST mit VOFA und Nova Treiber mit GEMBENCH 6 ...



Nimm mal NVDI als Treiber das ist schneller ...

[Lukas Frank]

Ich mag GEMBENCH 6 nicht weil die Ergebnisse immer viel zu gut sind ...

Als VMG das normale für die ATI Karte der Nova Software mit den Timings von der zuvor verlinkten Seite. Bei der ET4000 im ST mit dem VOFA Adapter auch mit dem VMG der Nova Software. Im Grunde benutze ich nie NVDI, immer den Nova Treiber weil der keine Probleme mit MiNT macht.

[1ST1]

Das Ergebnis sieht performancemäßig gut aus. Wenn man dann noch die DMA-Zugriffe des Shifters abschalten könnte, damit der 68000 mehr Buszyklen bekommt, wäre noch cool.

[tuxie]

Ich denke das der DMA das macht,

[1ST1]

Ich glaube eher, dass der Shifter weiter ein Bild raus haut, der lässt sich leider softwaremäßig nicht stoppen. Und solange er das tut, nimmt er der CPU Buszyklen weg.

[czietz]

Das ist in der MMU hart eingebaut, dass abwechselnd CPU-Zyklen und Shifter-Zyklen (bzw. in der Austastlücke Refresh-Zyklen) auf den RAM stattfinden.

[mfro]

Ich glaube eher, dass der Shifter weiter ein Bild raus haut, der lässt sich leider softwaremäßig nicht stoppen. Und solange er das tut, nimmt er der CPU Buszyklen weg.

und ich denke, das tut er nicht (zumindest nicht im Originalzustand).  Die m68k-CPU legt doch sowieso immer nach zwei Taktzyklen Buszugriff zwei interne "Denk-Takte" ein.

Das war doch grad' der Witz am verzahnten ST-Design, daß es die Shifter-Zugriffe in die Takte legt, wo die CPU sowieso nichts vom Bus haben will und so ein "arme-Leute-Dualport-RAM" bastelt.

[czietz]

In vielen Fällen stimmt das, es gibt aber Kombinationen von Instruktionen, da würde die CPU schon gerne schneller wieder auf den RAM zugreifen, wird aber von der MMU daran gehindert, weil der Shifter gerade dran ist. Das kann man daran erkennen, dass diese Instruktionen weniger Zyklen brauchen, wenn sie aus dem ROM ausgeführt werden. Das wird hier (in Abschnitt 4) kurz angerissen:
http://pasti.fxatari.com/68kdocs/AtariSTCycleCounting.html

Insgesamt bringt das aber nicht viel, weil eben -- dank des geschickten ST-Hardwaredesigns -- in der Tat während der Shifter/Refresh-Zyklen oft "Denkpause" bei der CPU ist.

[tuxie]

Wir haben da mal rumgespielt am Wochenende
1280x720x64k ist zwar nicht mehr so Performant wie bei 256 Farben aber sieht schon echt geil aus, vorallen wenn man Fotos mit zView öffnet.

VG

[atari-inside]

Sorry wenn ich es überlesen habe - aber sprecht ihr da von der "Nova Falcon" in 16:9? Oder geht´s um den TT? Als ich damals mein Nova Falcon Setup zum Laufen gebracht habe, bin ich an 16:9 gescheitert...

@ Lukas Frank:  STA_VDI.169.zip.pdf - Damit könnt ich´s am Falcon probieren?