ct60(e)/CT63 und WinX (shellbuffer, TOS im RAM)

[1ST1]

Und noch ein Problem... Auf meinen 030 Ataris (TT, Falcon) verwende ich gerne das WinX Patchtool, um ein paar Limitierungen von TOS (überwiegend Fensterverhalten) aufzuheben. Am wichtigsten ist aber, dass der Shellbuffer vergrößert wird, so dass der Rechner nicht beim Starten von jedem Programm aus dem GEM Desktop meldet, dass er zu wenig Speicher hat und dann nach Programmende alle geöffneten Laufwerksfenster zu sind, bzw. einen Auflösungswechsel mit der selben Meldung verweigert. Das ist scheinbar bei mir unbedingt notwendig, weil meine Rechner viele sichtbare BGM-Partitionen (bis P:) haben, die alle bis zu 1 GB groß sind (nur auf den TTs ist C: 512MB, auf den Falcons auch das 1 GB). Dafür ginbs sicher noch einen anderen Patch (welchen?), und vielleicht kann ja auch jemand hier bestätigen, dass das ct6x TOS dieses Shellbuffer-Problem garnicht mehr hat? (Jedenfalls ist mir die Fehlermeldung gestern ohne WinX nicht begegnet.)

Aber zurück zur grundsätzlichen Verwendung von WinX... Damit das seine Arbeit verrichten kann, muss das TOS von zb. romram.prg (oder romspeed, tosram, gemram und wie die Tools alle heißen) vor WInX im Autoordner liegen, um TOS ins RAM zu kopieren.

CT6x(e) kopiert das TOS aus Performancegründen ja ohnehin schon ins RAM. Aber wenn ich ohne romram winx im Autoordner aufrufen lasse, meckert WinX dass TOS nicht im RAM liegt. Wenn ich aber eines der genannten Tools davor aktiviere (bisher nur romram getestet), meckert romram, dass schon ein anderer romram-Manager aktiv sei und verrichtet auch seinen Dienst nicht.

Wie kann man das lösen, so dass WinX läuft?

[mfro]

... CT6x(e) kopiert das TOS aus Performancegründen ja ohnehin schon ins RAM...

Bei der CT60 wird das TOS nicht (oder nicht nur) aus Performancegründen ins RAM kopiert, sondern hauptsächlich, um die eigenen 060-Patches anbringen zu können (prinzipiell gleich wie bei der von dir so geliebten FireBee). Da noch weitere Patch-Programme drauf loszulassen, kann funktionieren, muß aber nicht (letzteres ist wahrscheinlich). WinX versucht, nicht dokumentierte AES-Strukturen zu verändern und sucht dazu (wahrscheinlich) nach bestimmten Mustern an bestimmten Offsets. Die können bei der CT60 durchaus schon anderweitig gepatcht sein, dann geht das eben schief.

[1ST1]

Ok, das verstehe ich. Gibts eine einfache Möglichkeit, wenigstens herauszubekommen, wie groß der Shellbuffer vom ct60 TOS 4.04 ist? Das wäre das allerwichtigste, denn dieser Bug (vor allem in TOS 3.06 und 4.04) ist sehr nervig. und ist der ursprüngliche Grund, warum ich WinX überhaupt verwende, die restlichen Patches die WinX durchführt, sind nur das i-Tüpfelchen, darauf kann ich auch verzichten.

[mfro]

Ok, das verstehe ich. Gibts eine einfache Möglichkeit, wenigstens herauszubekommen, wie groß der Shellbuffer vom ct60 TOS 4.04 ist?

Code: [Auswählen]

#define SHBUF_SIZE 0x7FFE                        /* 32 KB */

(so zumindest in der letzten Version)

[1ST1]

Ich muss nachsehen, was WinX einstellt, um zu sehen, ob das ausreichend ist.