Autor Thema: 256MB TT-RAM und MinT streikt  (Gelesen 546 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Lukas Frank

  • Benutzer
  • Beiträge: 7.744
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: 256MB TT-RAM und MinT streikt
« Antwort #40 am: Do 09.08.2018, 18:38:04 »
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.

Offline tuxie

  • Benutzer
  • Beiträge: 6.018
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: 256MB TT-RAM und MinT streikt
« Antwort #41 am: Do 09.08.2018, 19:40:18 »
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.
Tschau Ingo


PC Intel i7 4820, 16gb quad @2400,Mac OS X El Capitan
http://tuxie.de http://hwbot.org/user/tuxie/

Offline DonQuichote

  • Benutzer
  • Beiträge: 156
Re: 256MB TT-RAM und MinT streikt
« Antwort #42 am: Do 09.08.2018, 22:16:27 »
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!

Online mfro

  • Benutzer
  • Beiträge: 1.107
Re: 256MB TT-RAM und MinT streikt
« Antwort #43 am: Fr 10.08.2018, 06:56:52 »
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.
« Letzte Änderung: Fr 10.08.2018, 07:03:25 von mfro »

Offline DonQuichote

  • Benutzer
  • Beiträge: 156
Re: 256MB TT-RAM und MinT streikt
« Antwort #44 am: Fr 10.08.2018, 07:34:03 »
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?


Online mfro

  • Benutzer
  • Beiträge: 1.107
Re: 256MB TT-RAM und MinT streikt
« Antwort #45 am: Fr 10.08.2018, 07:46:49 »
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:

#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.
« Letzte Änderung: Fr 10.08.2018, 07:51:34 von mfro »

Offline czietz

  • Benutzer
  • Beiträge: 1.562
Re: 256MB TT-RAM und MinT streikt
« Antwort #46 am: Fr 10.08.2018, 08:29:43 »
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.)

Online mfro

  • Benutzer
  • Beiträge: 1.107
Re: 256MB TT-RAM und MinT streikt
« Antwort #47 am: Fr 10.08.2018, 10:17:31 »
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.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 112
Re: 256MB TT-RAM und MinT streikt
« Antwort #48 am: Fr 10.08.2018, 15:12:14 »
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.