Grafikkarte (Nova) und Atari Falcon mit 10MB Ram Grenze ...

[Lukas Frank]

Grafikkarte (Nova) und Atari Falcon ...

Bei einer installierten 16MB Ramkarte werden im Combel hardkodiert 14MB vom TOS genutzt sagte mir @czietz  mal. Wäre es nicht möglich das TOS 4 so zu patchen das anstatt 14MB nur 10MB nutzbar sind. Die Grafikkarte belegt durch den Grafikkartentreiber den Bereich von 10MB bis 14MB. Darauf wird ja dann im Grunde doppelt geschrieben einmal in den Grafikkartenspeicher und zum zweiten in den Rechner Ram vom Bereich von 10MB bis 14MB. Also das Betriebssystem darf dann  keinen Zugriff mehr auf den Bereich von 10MB bis 14MB haben ...

Wie macht das denn z.B. die Rhothron VME Bus Erweiterung für den Atari Falcon. Der VME Bus sollte doch auch bei 10MB starten?

[Arthur]

Interesantes Thema. Es lassen sich ja einige Dinge mit der im 68030 enthaltenen MMU anstellen (hab ich mal gehört) . Aber ob  es ausreicht ein entrsprechendes Programm in den Autoordner zu packen oder ob der Falcon sich da wegen der sich überschneidenden Speicherbereiche schon vorher weg gebombt, da bin ich überfragt. Denn dann müsste doch das TOS gepatcht werden. Wenn du bloß so gut Assembler könntest wie du löten kannst, dann wäre das auch schon erledigt.

[czietz]

Wiederholtes fragen ändert leider nichts der Antwort: Das ist ein Hardwarethema und kann nicht einfach in TOS weggepatcht werden. (Nein, die MMU hilft da ebenfalls rein gar nichts.)
https://forum.atari-home.de/index.php/topic,14594.msg233145.html#msg233145

[Lukas Frank]

Wenn der Rechner bzw. das Betriebssystem bombt kann man das doch abfangen oder nicht?

[czietz]

Das hat mit Deiner ursprünglichen Frage aber nichts zu tun.

[Lukas Frank]

Es geht ja darum von den 14MB 4MB wegzunehmen/frei zu machen.

[czietz]

Irgendwie habe ich das Gefühl mich ständig zu wiederholen: Das ist ein Hardwarethema und kann nicht einfach in TOS weggepatcht werden.

Selbst wenn Du TOS 4 MB RAM wegnähmst (was selbstverständlich trivial wäre), hilft das nichts. Wenn der NOVA-Treiber auf die Grafikkarte zugreifen will, antwortet gleichzeitig auch das RAM. Das kannst Du nicht durch Software/Patches verhindern, weil die Adressdekodierung nicht in Software sondern im COMBEL gemacht wird.

[mfro]

Das TOS ließe sich schon dazu bringen, den Speicherausbau oberhalb 10 MB zu ignorieren (das obere Ende des ST-RAMS steht in der Systemvariable _memtop, was darüber liegt, wird von TOS nicht angefaßt.

Bloß ist das nur die eine (einfachere) Hälfte der Miete.

Du kannst nicht einfach auf zwei Speicher gleichzeitig schreiben und erwarten, dass das einfach so funktioniert. Selbst wenn die Bustreiber in der Lage wären, beide Speicher gleichzeitig zu "versorgen" (was ich bewzeifle), würden auch beide ein DTACK schicken. Und das garantiert nicht zum exakt selben (richtigen) Zeitpunkt.

Das kann nicht gut gehen.

Interesantes Thema. Es lassen sich ja einige Dinge mit der im 68030 enthaltenen MMU anstellen (hab ich mal gehört)

Die 68030-MMU kann eine ganze Menge. Aber Wunder wirken kann sie nicht.

[Lukas Frank]

Ich traue mich ja kaum hier mitzulesen ... ;-)

Also bestünde doch eventuell Hoffnung !?!

[mfro]

Ich traue mich ja kaum hier mitzulesen ... ;-)

Also bestünde doch eventuell Hoffnung !?!

Mir dünkt, Du hast nicht zuende gelesen?

[Lukas Frank]

DTACK wird durch die Hardware ausgelöst? Und das kann ein Programm nicht verhindern, oder?

[czietz]

mfro hat -- nur etwas ausführlicher und eloquenter -- das gleiche geschrieben wie ich: Das ist ein Hardwarethema und kann nicht einfach in TOS weggepatcht werden.

[Lukas Frank]

Die 4MB der Grafikkarte liegen doch auf dem Bereich zwischen 10MB und 14MB. Ist doch gemappt, oder?

Kann das nicht völlig egal sein was da in den Speicher geschrieben und gelesen wird, wenn das Betriebssystem dafür gesperrt ist?

[guest522]

Wie würde das in Hardware aussehen?
Ist es der Combel der das /DTACK erzeugt abhängig von der Adresse und den vergangenen Zyklen?
Wenn dem so ist, könnte man dann das Signal unterbrechen und mittels eines Adressdecoder im Bereich oberhalb 10MB verhindern? Dann bliebe aber noch das Problem das erst zu aktivieren wenn das 14MB Modul bereits erkannt ist, richtig?

[1ST1]

Trotzdem würde man in zwei Speicher an der selben physischen Adresse schreiben. Das ginge zwar gut, solange ein DTACK unterbunden wird. Aber was ist, wenn der Grafiktreiber Status-Register oder so aus der Grafikkarte auslesen müsste? Dann würde gleichzeitig das RAM mit garantiert anderem Inhalt antworten.

Man könnte höchstens über eine Art Bankswitching nachdenken. Das würde aber umfangreiche Änderungen an der Platine erfordern, man müsste die Adressleitungen zwischen CPU und Combel auftrennen und da entsprechende Logik verbauen und irgend einen Weg finden, wie man die Bank schnell umschalten kann. Programme die dann auf der RAM Karte in Bankswitch-Bereich liegen, können dann etweder garkeine Grafik ausgeben, oder nur quälend langsam.

Das einfachste wird wohl sein, zu versuchen, sich noch eine ct60e zu sichern, wenn nochmal welche aufgelegt werden, und drauf hoffen, dass es nochmal SuperVidels gibt. Ist halt nicht wirklich billig.... Oder darauf hoffen, dass es mal eine Vampire für den Falcon gibt, an der für den A1200 wird ja schon gearbeitet - die A1200 Trapdoor-Schnittstelle dürfte technisch recht nah am Falcon-Erweiterungsbus sein.

[Arthur]

Wenn man das mit 8MB machen würde könnte  man an der ST-RAM Karte die 24te Adressleitung trennen. Dann müsste evtl. das Falcon-TOS noch angepasst werden, falls es sich nicht selbst über den Speichertest darauf einstellen kann. Der Zugriff über der 8MB Grenze wäre dann nicht auf zwei Speicherbereiche gleichzeitig und könnte sich auf den Grafikadapter konzentrieren.. Der Aufwand sollte dann von der Hardwareseite erheblich geringer sein, oder? Ich hoffe jemand versteht wie ich es meine.

[Ektus]

Das geht ja schon lange so ähnlich mit der Magnum Falcon (8MB gedrosselt auf 6) und einer 4MB ST-RAM Karte. Macht nur keinen Spaß, weil der Speicher da immer noch knapp und arg fragmentiert ist.

Wenn man dann mehr haben will, landet man ganz schnell bei Erweiterungen wie CT2, CT63 und ähnlichen Konzepten.


MfG
Ektus.

[Arthur]

Das geht ja schon lange so ähnlich mit der Magnum Falcon (8MB gedrosselt auf 6) und einer 4MB ST-RAM Karte. Macht nur keinen Spaß, weil der Speicher da immer noch knapp und arg fragmentiert ist.

@Ektus, und es ist einfacher eine Leitung auf zu trennen als eine Platine neu aufzulegen. So lange kein MiNT benötigt wird, mit mehreren Anwendungen im RAM ist das gar nicht so schlecht. Neu Speicherkarten für den Falcon könnten auch gleich einen passenden Jumper auf 8MB mitbringen. Und Geneva z.B. läuft auch mit wenig Speicher auf einen ST noch.

[1ST1]

Einfach eine Adressleitung auftrennen, ich weiß nicht, ob das bei DRAM geht, ob das reicht, um es still zu legen. Und es stellt sich die Frage, wie TOS auf 8 MB RAM reagiert, statt erwartete 1, 2, 4 oder 14 MB.

[Arthur]

Einfach eine Adressleitung auftrennen, ich weiß nicht, ob das bei DRAM geht, ob das reicht, um es still zu legen.

A24 zu den Chips kann ja auf einen definierten Pegel gelegt werden. A24 vom Board wird ja dann an der Grafikkarte anliegen...

Und es stellt sich die Frage, wie TOS auf 8 MB RAM reagiert, statt erwartete 1, 2, 4 oder 14 MB.

der Rest stand schon oben in #15 wegen des TOS.