DFB1 Atari Falcon 030 Beschleuniger mit Fastram ...

[Lukas Frank]

DHL war gerade da. Hat mich knapp 46,- Euro an Zollgebühren gekostet. Ich hatte David 200,- Euro gespendet für sein Projekt. Habe jetzt einen DFB1 Beschleuniger zum Test mit der Nova Falcon. Muss mir aber erst einen Quarz bestellen für die Karte ...

[Lukas Frank]

Damit ich die Pins für die Nova Falcon auflöten kann muss der Oszillator Sockel erstmal ausgelötet werden. Bevor ich das mache teste ich Karte mal ...

[djbase]

Cool, bin gespannt, wäre ja auch noch was für meinen Falcon.

[Lukas Frank]

Dachte man schaltet den Rechner ein und hat Fastram wie beim Atari TT oder der PAK68/3 aber dem war nicht so. Man muss die TFTOOLS nutzen zusammen mit NVDI weil NVDI den Blitter umgeht. Ohne NVDI bekommt man Pixelmüll und der Desktop ist nicht mehr nutzbar. Die Gembench Ergebnisse sind einmal mit Fastram.prg und einmal mit maprom.prg plus NVDI im Autoordner.

Bei mir ist das aber alles instabil und nicht Nutzbar. Mein Falcon ist original ohne Clockpatch, muss mal mit David schreiben woran es liegt ...

[Arthur]

Gefällt mir... wenns mit der Nova auch noch läuft, wow.

[tuxie]

Auch hier wieder das Problem, der Blitter kann nicht aufs Fastram zugreifen und wohl auch nicht aufs TOs. Was aber beides zwingend notwendig ist..

[mfro]

Auch hier wieder das Problem, der Blitter kann nicht aufs Fastram zugreifen und wohl auch nicht aufs TOs. Was aber beides zwingend notwendig ist..

Ich kenne keinen Atari-Rechner, wo der Blitter auf das FastRAM zugreifen könnte und auch keinen Clone.

Warum ist das "zwingend notwendig"?

[czietz]

Ich kenne keinen Atari-Rechner, wo der Blitter auf das FastRAM zugreifen könnte

Welchen Atari-Rechner kennst Du denn, der von Haus aus Blitter und Fast-RAM mitbrächte? Der TT hat keinen Blitter, alle anderen Rechner kein Fast-/Alt-RAM.

Fakt ist, dass sich Programme darauf verlassen, dass sie aus ihrem Speicherbereich z.B. auf den Bildschirm "blitten" können. Wenn das Programm im Fast-/Alt-RAM läuft und TOS dabei den HW-Blitter verwendet, dann muss der Speicher folglich dafür erreichbar sein. (Atari TOS 4 auf dem Falcon hat m.W. nicht einmal mehr die Routinen, per Software/CPU zu "blitten".)

Deswegen treiben die Entwickler von Alt-RAM-Erweiterungen für den ST/MegaST/STE normalerweise einen ordentlichen Aufwand, um das Alt-RAM für den Blitter erreichbar zu machen.

Mit dem DFB1 im Falcon aus diesem Thread muss man hingegen NVDI installieren (wie Frank schon schrieb), um die SW-Blit-Routinen nachzurüsten. EmuTOS mit deaktiviertem Blitter wäre vermutlich auch eine Option.

[tuxie]

Auch hier wieder das Problem, der Blitter kann nicht aufs Fastram zugreifen und wohl auch nicht aufs TOs. Was aber beides zwingend notwendig ist..

Ich kenne keinen Atari-Rechner, wo der Blitter auf das FastRAM zugreifen könnte und auch keinen Clone.

Warum ist das "zwingend notwendig"?

Wir sprechen aus Erfahrung

[mfro]

Ich kenne keinen Atari-Rechner, wo der Blitter auf das FastRAM zugreifen könnte

Welchen Atari-Rechner kennst Du denn, der von Haus aus Blitter und Fast-RAM mitbrächte? Der TT hat keinen Blitter, alle anderen Rechner kein Fast-/Alt-RAM.

Keinen. Genau.

Atari ist dem Problem offensichtlich aus dem Weg gegangen, entweder es gibt AltRAM - dann keinen Blitter oder eben andersrum.

Das jetzt noch nachrüsten zu wollen, ist m.E. zum Scheitern verurteilt.

Das wird bei Spielen oder Demos aufgrund des oft sowieso nicht genau genug abzubildenden Timings (AltRAM kann per Definition alles mögliche sein: schnell oder schnarchlangsam) nicht funktionieren und GEM-Anwendungen müssen eben das passende VDI haben, das die Blit-Routinen passend zur vorhandenen Hardware implementiert.
TOS4 hat keinen Software-Blitter mehr. Deswegen ist TOS4 ja auch das Falcon-TOS für den Rechner, der kein AltRAM hat.

[czietz]

Atari ist dem Problem offensichtlich aus dem Weg gegangen, entweder es gibt AltRAM - dann keinen Blitter oder eben andersrum.

Das jetzt noch nachrüsten zu wollen, ist m.E. zum Scheitern verurteilt.

Ganz so kategorisch würde ich diese Aussage nicht stehen lassen. Z.B. hat der Entwickler der Firmware der Storm ST sich darum gekümmert, die Blitter-Unterstützung (im MegaST oder nachgerüstet im ST) für das Alt-RAM nachzurüsten. Dort ist es also nicht zum Scheitern verurteilt und somit muss der Nutzer keine Klimmzüge (Blitter deaktivieren, "das passende VDI haben") machen; es funktioniert einfach wie gewohnt.

Nun ist es aber beim DFB1 aus diesem Thread bereits konzeptionell unmöglich (imho), das Alt-RAM für den Falcon-Blitter nutzbar zu machen. Deshalb eben der von Frank "bemängelte" Zwang, NVDI o.ä. nutzen zu müssen.

[mfro]

Nun ist es aber beim DFB1 aus diesem Thread bereits konzeptionell unmöglich (imho), das Alt-RAM für den Falcon-Blitter nutzbar zu machen. Deshalb eben der von Frank "bemängelte" Zwang, NVDI o.ä. nutzen zu müssen.

Die "richtige" Lösung wäre m.E. hier eben doch, das "passende VDI" zu haben, das selbstständig entscheidet, Screen-to-Screen (bzw. ST-RAM-to-ST-RAM) -Blits per Blitter und AltRam-nach-ST-RAM Blits per Software (oder eben einer anderen Lösung, wie z.B. Bus-Mastering bei Grafikkarten, die das können) auszuführen. NVDI (das "freiwillig" auf den Blitter verzichtet, selbst wenn es ihn benutzen könnte) sehe ich da nur als Notbehelf.

Leider hängen wir da am alten Problem, daß TOS auf so etwas nie vernünftig vorbereitet war.

[tuxie]

Ich denke die Logic der Firmware so aufzubauen das auch Blitter das Altram ansprechen kann ist nicht der große Aufwand. Man muss nur wissen wie man es am besten macht. Und vor allen berücksichtigen das der Blitter halt mit 16Mhz läuft und nicht mit 50!! Das heißt das auch dies hier berücksichtigt werden muss. Die Storm ST kann das ja eh schon weil für die Storm ST ist es ja kein Unterschied ob CPU oder Blitter zugreifen. Und gerade das bringt einen Enormen Geschwindigkeitsvorteil. Man sollte meinen das dies egal ist aber das ist es nicht.

[czietz]

Ich denke die Logic der Firmware so aufzubauen das auch Blitter das Altram ansprechen kann ist nicht der große Aufwand.

Ich schrieb bereits oben: Es geht beim DFB1 konzeptionell nicht! Egal mit wie viel Aufwand.

[mfro]

Ich denke die Logic der Firmware so aufzubauen das auch Blitter das Altram ansprechen kann ist nicht der große Aufwand.

Ich schrieb bereits oben: Es geht beim DFB1 konzeptionell nicht! Egal mit wie viel Aufwand.

Sehe ich auch so. Auch die ausgefeilteste Firmware kann keine fehlenden Adressbits herzaubern.

[tuxie]

Ach halt stimmt ja! Da liegt der Speicher ja oberhalb von 16Mb, daher von Falcon Seite nicht sichtbar!. Hatte das mit dem ST Beschleuniger Verwechselt den er gebaut hat. Da hat er das Problem nämlich auch!.

[Lukas Frank]

Habe jetzt mal mit David geschrieben und fange ganz unten an ...

32, 40 und 50Mhz Quarz ohne Fastram läuft stabil getestet mit Gembench  und Doom. Habe eine Goldcap 33Mhz 030 CPU drauf die mit den 50Mhz kein Problem hat.

Überlege gerade ob ich ein Clock Patch Modul kaufen soll ...
https://centuriontech.eu/product/falcon030-clockpatch/

[Arthur]

Mit dem TOSPATCH von Markus Heiden https://www.markusheiden.de/download/atari/tp404b20.lzh kann man das entsprechend Patchen wenn ich das richtig verstanden habe.

[Lukas Frank]

Mit dem TOSPATCH von Markus Heiden https://www.markusheiden.de/download/atari/tp404b20.lzh kann man das entsprechend Patchen wenn ich das richtig verstanden habe.

Warum? Wieso?

[Arthur]

Warum? Wieso?

Darum

Ohne NVDI bekommt man Pixelmüll und der Desktop ist nicht mehr nutzbar.