256MB TT-RAM und MinT streikt

[Lukas Frank]

5V Logikbausteine gibt es kaum noch in neu zu kaufen schon seit langer Zeit. Eine kleine Ausnahme sind die 4000er CMOS oder 74xx Baureihen. Auch die Storm, Thunder und Lightning arbeiten mit 3,3V.

[tuxie]

Was du einmal machen könntest wäre zu Prüfen das deine Storm genug Strom bekommt, einmal mit einem Multimeter besser wäre mit einem OSZI messen ob nicht eventuell die Speicherriegel zu viel Strom ziehen. Meist ist nicht die +5V das Problem sondern GND. (hatten wir am Anfang Probleme) ansonsten BURST Mode ausschalten und erstmal testen, dann mit FPM Burst testen.

[DonQuichote]

Was du einmal machen könntest wäre zu Prüfen das deine Storm genug Strom bekommt, einmal mit einem Multimeter besser wäre mit einem OSZI messen ob nicht eventuell die Speicherriegel zu viel Strom ziehen. Meist ist nicht die +5V das Problem sondern GND. (hatten wir am Anfang Probleme) ansonsten BURST Mode ausschalten und erstmal testen, dann mit FPM Burst testen.

Hallo tuxie,
nein, ich habe keine Probleme mit der Storm oder den 3.3V Riegeln. Läuft so weit alles stabil mit Burst.
Das war nur ein Gedankengang zu den verwendeten 3.3V Speichechips. Ist aber einleuchtend dass wenn keine 5V Chips mehr produziert werden eben 3.3V Chips verwendet werden die auch 5V ab können.
Die Storm selbst scheint damit keine Probleme zu haben. Gutes Stück!

[mfro]

Schnellschuss: kannst Du das mal bitte (ungezipt, natürlich) in deinen Autoordner stecken und *vor* MiNT starten?

Damit sollte dein TT-RAM um 16 MByte "gekürzt" werden und damit die MMU-Tables gerade noch ausreichen.

[DonQuichote]

Schnellschuss: kannst Du das mal bitte (ungezipt, natürlich) in deinen Autoordner stecken und *vor* MiNT starten?

Damit sollte dein TT-RAM um 16 MByte "gekürzt" werden und damit die MMU-Tables gerade noch ausreichen.

Bombt leider immer noch mit MP=on.
CUTMEM.PRG habe ich vor MINT030.PRG im AUTO.

Gegenprobe unter TOS:

CUTMEM inaktiv: 249MB TT-TAM frei
CUTMEM aktiv: 249MB TT-TAM frei - sollten hier 16MB weniger sein, oder?

[mfro]

Schnellschuss: kannst Du das mal bitte (ungezipt, natürlich) in deinen Autoordner stecken und *vor* MiNT starten?

Damit sollte dein TT-RAM um 16 MByte "gekürzt" werden und damit die MMU-Tables gerade noch ausreichen.

Bombt leider immer noch mit MP=on.
CUTMEM.PRG habe ich vor MINT030.PRG im AUTO.

Gegenprobe unter TOS:

CUTMEM inaktiv: 249MB TT-TAM frei
CUTMEM aktiv: 249MB TT-TAM frei - sollten hier 16MB weniger sein, oder?

Ja, sollten. Eigentlich kann man da nicht viel falsch machen, aber ich hab's anscheinend doch geschafft:

Code: [Auswählen]

#include <mintbind.h>
 
unsigned long *memtop = (unsigned long *) 0x5a4;

void cutmem(void)
{
    *memtop -= 16 * 1024UL * 1024UL;
}

int main(int argc, char *argv[])
{
    Supexec(cutmem);

    return 0;
}

Schnellschuss halt. Fällt jemand was dran auf? Ich hab' jetzt grade keine Zeit, aber werde mir das am WE nochmal anschauen.

Entweder ich habe einen Denkfehler oder das gepatchte TOS macht *nach* dem Autoordner noch was mit memtop.

[czietz]

Ich vermute, der Denkfehler ist wie folgt: MiNT besorgt sich sein Alt-RAM ja von TOS, via Mxalloc. Wenn Du also aus dem AUTO-Ordner -- und damit, nach der Initialisierung von GEMDOS -- etwas an ramtop änderst, wird MiNT trotzdem von GEMDOS noch den Speicherbereich oberhalb von 256 MB angeboten bekommen. Beim Zugriff darauf kommt's dann zum Absturz.

PS: Außerdem sollte Dein Programm volatile auf die Variable zugreifen, sonst könnte der C-Compiler den Zugriff glatt wegoptimieren. (Geschriebener Wert wird nie gelesen.)

[mfro]

Ich vermute, der Denkfehler ist wie folgt: MiNT besorgt sich sein Alt-RAM ja von TOS, via Mxalloc. Wenn Du also aus dem AUTO-Ordner -- und damit, nach der Initialisierung von GEMDOS -- etwas an ramtop änderst, wird MiNT trotzdem von GEMDOS noch den Speicherbereich oberhalb von 256 MB angeboten bekommen. Beim Zugriff darauf kommt's dann zum Absturz.

Das ist der Grund. MiNT interessiert sich nur bei der Initialisierung der memory protection-Tabellen für ramtop, übernimmt aber ansonsten den GEMDOS-Speicher. So einfach ist's dann wohl doch nicht.

PS: Außerdem sollte Dein Programm volatile auf die Variable zugreifen, sonst könnte der C-Compiler den Zugriff glatt wegoptimieren. (Geschriebener Wert wird nie gelesen.)

Ist mir (nachträglich) auch aufgegangen, ist aber nicht das Problem (habe ich geprüft). Das Programm ist ohne Optimierung übersetzt und macht das Richtige.

[Thorsten Otto]

wird MiNT trotzdem von GEMDOS noch den Speicherbereich oberhalb von 256 MB angeboten bekommen. Beim Zugriff darauf kommt's dann zum Absturz.

Das wird wohl das Problem sein. Die letzten 16MB werden vermutlich dann noch nicht wirklich benutzt, allerdings wird für einen Programmstart immer die größtmögliche TPA angelegt, und der Stackpointer wird auf das Ende derselben gesetzt. Das führt vertmutlich dazu daß dieser Stachon schon irgendwo benutzt wird bevor das Programm eine Chance hat die TPA zu verkleinern.

Als "Schnellschuss" seh ich im moment 3 Möglichkeiten:

• Das Auto-Ordner-Programm müsste sich durch die Memory-Listen hangeln, und die relevanten Bereiche ausketten, bzw. einfach den letzten Bereich verkleinern. Der Aufbau dieser Listen ist eigentlich dokumentiert, trotzdem vlt. nicht ganz trivial zu implementieren
• Das Auto-Ordner-Programm alloziert allen Speicher in Häppchen von 1MB, gibt dann alles wieder frei was nicht im kritischen Bereich ist, und beendet sich dann über Ptermres(). Der nicht freigegebene Bereich ist damit "weg"
• Man setzt bei allen Programm das "SMALL-TPA" Flag (gibt ein Tool names phbit3.prg dafür, oder man nimmt das "flags" tool aus dem mintbin Paket). Das sollte dafür sorgen daß nur noch der im Programm-Header angegebene Speicher als TPA benutzt wird. Nachteil: man müsste das wieder rückgängig machen, wenn der "richtige" Fix erfolgt ist. Ausserdem könnte es zu Problemen kommen bei Programmen die mit GCC übersetzt wurden, da der Stack bei diesen nicht Teil des BSS ist, und die TPA damit eigentlich zu klein ist. Das wird zwar vom Startup-Code wieder korrigiert, aber bis dahin könnte der für den Stack benötigte Speicher schon anderweitig belegt sein. Als Test könnte man das aber mal bei den Programmen versuchen, die bis einschliesslich des Desktop gestartet werden. Das cutmem Tool würde dann natürlich auch noch benötigt.

[Thorsten Otto]

Um mich mal selber zu zitieren:

Als "Schnellschuss" seh ich im moment 3 Möglichkeiten:

Es gab noch eine viel einfachere Möglichkeit, nämlich direkt in Mint. Ist momentan auch nur ein Workaround (die letzten 16MB sind dann nicht vefügbar)

Don, könntest du das bitte mal testen?

Snapshot-build ist mittlerweile durch, und kann unter https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Ffreemint-1-19-606-020.zip downgeloadet werden.

[DonQuichote]

Don, könntest du das bitte mal testen?

Snapshot-build ist mittlerweile durch, und kann unter https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Ffreemint-1-19-606-020.zip downgeloadet werden.

Test erfolgreich. MiNT startet mit Memory Protection = Yes und 256MB TT-RAM durch!

Danke!

[Thorsten Otto]

Test erfolgreich. MiNT startet mit Memory Protection = Yes und 256MB TT-RAM durch!

Super. Dann mal an der "richtigen" Lösung weiterbasteln...

[Gaga]

Oh, das muss ich heute Abend doch auch gleich mal probieren. Ich habe (bisher) dieselben Probleme mit 256MB FastRAM unter Mint mit Memoryprotection on wie @DonQuichote

[Thorsten Otto]

Oh, das muss ich heute Abend doch auch gleich mal probieren. Ich habe (bisher) dieselben Probleme mit 256MB FastRAM unter Mint mit Memoryprotection on wie @DonQuichote

Ja, kann sicher nciht schaden

Nur so als Hinweis falls du nicht den ganzen Thread gelesen hast: das ist momentan nur ein Workaround, der die letzten 16MB vom Fastram "abschneidet". Du müsstest dann also 16MB ST + 240MB Fastram haben. Mehr als 256MB gehen damit also immer noch nicht (bzw. würden die dann auch auf 240MB gekürzt). Das ganze aber nur mit MP=ON, ohne sollte alles ganz normal wie vorher sein.

[Thorsten Otto]

was mich auch interessieren würde: gibt es merkliche Verzögerungen beim Programmstart, wenn 256MB und MP aktiv sind? Grund ist, daß dann nämlich für jeden Prozess der gestartet wird erstmal ~243K an MMU-Tabellen angelegt werden müssen. Bei 16MB TT-RAM wären das nur ca. 18K.

[Thorsten Otto]

So, es ist getan. MMU-Initialisierung überarbeitet, Resultat: siehe Anhang.

Aktueller snapshot-build dafür: https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Ffreemint-1-19-d0f-020.zip

Wie man sieht, sollte das jetzt bis 2GB funktionieren. Mehr geht momentan nicht, weil sonst Addressen negativ werden, aber darüber kann man sich dann unterhalten wehn es grössere Speichererweiterungen gibt

[1ST1]

aber darüber kann man sich dann unterhalten wehn es grössere Speichererweiterungen gibt

Gaga und Tuxie schaffen das schon. Die Storms lassen sich ja aufeinander stapeln. Bei 2 Meter Bauhöhe dürfte das Ziel erreicht sein...

[gh-baden]

So, es ist getan. MMU-Initialisierung überarbeitet, Resultat: siehe Anhang.

Aktueller snapshot-build dafür: https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Ffreemint-1-19-d0f-020.zip

Cool! Wenn man mir das so 1992 mal gesagt hätte …

Wie man sieht, sollte das jetzt bis 2GB funktionieren. Mehr geht momentan nicht, weil sonst Addressen negativ werden, aber darüber kann man sich dann unterhalten wehn es grössere Speichererweiterungen gibt

„Jaja, später machen wir es schön …“, schon klar 

[Thorsten Otto]

„Jaja, später machen wir es schön …“, schon klar 

Ja klar, kennst das doch

[DonQuichote]

So, es ist getan. MMU-Initialisierung überarbeitet, Resultat: siehe Anhang.

Aktueller snapshot-build dafür: https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Ffreemint-1-19-d0f-020.zip

Wie man sieht, sollte das jetzt bis 2GB funktionieren. Mehr geht momentan nicht, weil sonst Addressen negativ werden, aber darüber kann man sich dann unterhalten wehn es grössere Speichererweiterungen gibt

Hab es installiert. Macht aber bei mir Probleme mit der NOVA. Friert komplett ein, wenn ich die NOVA-Treiber mit starte. Ohne NOVA Treiber kommt der TT weiter, bis zum XaAES. In der XAAES.CNF wird bei mir TERADESK gestartet, was mit einem Dialogfeld endet:

PROCESS "desktop" KILLED:
MEMORY VIOLATION. (PID 010)
Type: private    PC: 014AB4E0
Addr: 0133EEB1

Wäre schön, wenn das außer mir auch noch mal jemand anders testen könnte (der mehr Ahnung von der Materie hat als ich). Möglicherweise mach ich was falsch.