atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: DonQuichote am Sa 04.08.2018, 16:10:22
-
Hallo zusammen,
heute Morgen sind meine 256MB EDO für die Storm angekommen und natürlich habe ich sie gleich eingesteckt.
YAART gibt im 1. Pass keine Fehler aus und TOS/MagiC starten ohne Probleme.
Wenn ich allerdings MinT starte, gibts zwei Bomben beim Booten und der TOS Desktop erscheint.
Gibt es unter MinT sowas wie einen Bootlog, damit ich nachlesen kann was da abschmiert?
Die Gegenprobe mit 2x32MB in der Storm ist erfolgreich, damit startet MinT durch. Mein MinT ist allerdings auch noch nicht richtig konfiguriert. Habe es als Anfänger auch nur mit Ach und Krach auf den aktuellen Trunk aktualisieren können und dabei habe ich sicherlich nicht alles richtig gemacht.
-
Ups, falsche Gruppe. Wollte es in Alternative Betriebssysteme posten. Sorry.
-
Halte beim Aufstarten vom mint.prg die linke Shifttaste gedrückt und schalte mal die Memory Protection aus falls sie an ist zum Probieren. Dort kannst du auch das Log einschalten ...
-
Hab jetzt mal den original EasyMint Installationsordner zurückbenannt in MINT und die mint.030.prg von diesem in den AUTO-Ordner gelegt - hiermit gehts, Mint startet durch mit den 256MB.
Ich probiere das jetzt mal mit deinem Tip
-
Memory Protection ist es. Ohne startet Mint durch.
Funktioniert nicht:
<2> Load external XFS : no
<3> Load external XDD: no
<4> Execute AUTO PRGs: no
<5> Memory protection: yes
Funktioniert :
<2> Load external XFS : yes
<3> Load external XDD: yes
<4> Execute AUTO PRGs: yes
<5> Memory protection: no
Die letzte Zeile die ich im Bruchteil einer Sekunde sehe bevor gebombt wird und der TOS Desktop erscheint ist "FAT/VFAT ..... Frank Naumann" irgendwas.
-
Memory Protection ist es. Ohne startet Mint durch.
Das ist dann aber ein Bug! Der MiNT-Kernel muss schon mit Speicherschutz (memory protection) funktionieren.
-
Was nicht geht und wo mint stoppt ist wenn auch ein Medium mit HDDriver TOS/Windows mit ByteSwap eingerichtet hat. Das geht nur mit dem Helmut Kernel aber dafür hat der Helmut Kernel kein Ramfs.
-
Meine Seagate ist mit HDDRIVER partitioniert, nur TOS Kompatibilität, kein ByteSwap.
Ich versuche es jetzt noch mal mit meiner zweiten, identischen Seagate von der Picke auf. Ich mache sie patt und richte die Partitionen erneut ein. Lade mir für die Neuinstallation auch erneut den aktuellen Trunk herunter.
Bei euch funktioniert das ja auch, also muss es auch bei mir klappen.
@czietz
Wenns ein Systembug wäre, hättet ihr das bestimmt schon vor mir bemerkt. Ich denke mal der Bug bin ich ... :)
Werd aber schon rauskriegen an was es hängt.
-
Was für Erweiterungen hast du?
Thunder, Storm, Lightning... evtl Grafikkarte?
Funktioniert nicht:
<2> Load external XFS : no
<3> Load external XDD: no
<4> Execute AUTO PRGs: no
<5> Memory protection: yes
Das ist ja mal eine sehr konservative Einstellung... keine weiteren Filsysteme und keine Treiber und Autoordner-Programme aber Speicherschutz an.
Funktioniert :
<2> Load external XFS : yes
<3> Load external XDD: yes
<4> Execute AUTO PRGs: yes
<5> Memory protection: no
Das ist eigentlich der Normalfall, doch wie @czietz schrieb sollte es auch mit Speicherschutz laufen. Wenn dann die ein oder anderen Anwendung mit Speicherschutz nicht funktioniert kann man den ja ausschalten.
-
Bin durch einen Tipp von @Gaga auf VanillaMiNT gekommen. Lauft sehr stabil.
https://atari.joska.no/VanillaMiNT/ für den TT die 030er Downloaden.
-
Bin durch einen Tipp von @Gaga auf VanillaMiNT gekommen. Lauft sehr stabil.
https://atari.joska.no/VanillaMiNT/ für den TT die 030er Downloaden.
Hallo Arthur,
habe meine Platte komplett neu partitioniert. Habe dann VanillaMiNT heruntergeladen und den Inhalt auf die C: kopiert. Auch MINT030.PRG im AUTO-Ordner ist das von VanillaMiNT. Außer HDDRIVER.SYS und XBOOT wird nur der Treiber für die ET4000 vor dem MINT030.PRG gestartet, sonst nichts.
Erster Start: 2 Bomben und anschließend grüner TOS Desktop.
Zweiter Start ohne Memory Protection: Bootet komplett durch zum TERADESK Desktop.
Was zum Geier kann das sein? Könnten das Probleme mit der Partitionierung von HDDRIVER 10.12 sein?
-
Schalte doch mal zum probieren in der xaaes.cnf ganz am Ende Teradesk aus. Oder die desktop.cnf. Einfach an den entsprechenden Zeilen ein # voranstellen. Kann sein das Teradesk mit der Memory Protection nicht läuft? Das System sollte dann mit Memory Protection ein bis ins XaAES mit allen ACC booten ...
-
Schalte doch mal zum probieren in der xaaes.cnf ganz am Ende Teradesk aus. Oder die desktop.cnf. Einfach an den entsprechenden Zeilen ein # voranstellen. Kann sein das Teradesk mit der Memory Protection nicht läuft? Das System sollte dann mit Memory Protection ein bis ins XaAES mit allen ACC booten ...
Habe ich eben gemacht. Keine Änderung. Wie auch unter EasyMiNT (+Trunk) sehe ich nur einen sehr kurzen Bootvorgang, letzte Zeile an der Unterkante des Bildschirms ist für den Bruchteil einer Sekunde "FAT/VFAT/FAT32 ....". Mit MP=on gibt es nach wie vor 2 Bomben und anschließend den TOS Desktop. Der TT kommt auch gar nicht erst zum Laden des Desktops. Die Bomben gibt´s schon weit vorher.
Ich habe auf Verdacht auch mal XBOOT und die ET4000 Treiber deaktiviert. Es werden also nur noch HDDRIVER.SYS und MINT030.PRG beim Einschalten des TT geladen. Keine Änderung.
Kann es was mit dem Filesystem zu tun haben, da das ja die letzte Bootzeile ist die ich zu Gesicht bekomme?
-
Hallo @DonQuichote, mal eine LOG Datei in MiNT erstellen lassen oder für MiNT die Einzelbestätigung beim Systemstart aktivieren um zu sehen wann der Fehler genau auftaucht. Auch mal einen Test ohne den Grafikkartentreiber über den Falcon Monitorausgang.
Welchen ET4000/Karte bzw. Treiber benutzt du?
-
Kann es was mit dem Filesystem zu tun haben, da das ja die letzte Bootzeile ist die ich zu Gesicht bekomme?
Ich kann eigentlich nicht Helfen da ich immer mit Memory Protection off arbeite. Aber nach deiner letzten Zeile lässt EasyMiNT e2fsck also eine Filesystem Reparatur über deine ext2 Partition laufen wenn beim letzten Mal das System nicht sauber runtergefahren wurde. Da steht auch so in der mint.cnf ...
-
Habe mal aus lauter Verzweiflung die Storm herausgeholt. Mint startet jetzt durch, nur mit ST-RAM und mit MemoryProtection=on.
Probiere weiter ...
-
Wie sind deine Jumpersettings auf der Storm? Evtl. mal den Burst-Mode deaktivieren.
-
Storm wieder drin mit 2x32MB EDO im Burst mode -> MiNT startet durch mit MemoryProtect=on
2x128 MB EDO wieder in die Storm gesetzt, diesmal ohne Burst Mode, MiNT bombt.
Jetzt habe ich noch mal YAART gestartet, 2x128MB EDO im Burst Mode (J3=on). Lasse diesmal mehrere Passes durchlaufen.
-
Du könntest ja auch mal nur ein Modul einsetzen... 128MB. Wenn's klappt dann das andere auch einzeln testen.
-
Gute Idee. Mach ich gleich mal.
-
Vielleicht hat es damit etwas zu tun ...
Das sind alles 3,3V Module, meine EDO und FPM aus den USA auf jeden Fall. Da sitzt ein kleiner SMD Spannungsregler drauf der aus den 5V -> 3,3V für die Chips macht. Die Ein und Ausgänge der Speicherchips hängen aber direkt an der 5V Logik des Atari TT Buses.
-
Mit einem 128MB Riegel in der Storm (SLOT A, J1/2/3=on, J4/5/6=off) startet MiNT mit MP=on durch. Mit dem anderen 128MB Riegel läuft´s auch.
-
Auch in beiden PS/2-Slots gestestet?
-
Vielleicht hat es damit etwas zu tun ...
Das sind alles 3,3V Module, meine EDO und FPM aus den USA auf jeden Fall. Da sitzt ein kleiner SMD Spannungsregler drauf der aus den 5V -> 3,3V für die Chips macht. Die Ein und Ausgänge der Speicherchips hängen aber direkt an der 5V Logik des Atari TT Buses.
Da steht zwar 5V auf dem Riegel, aber wie du sagst, ein SMD Spannungswandler ist drauf.
Es scheint jedoch keine Probleme mit den 3,3 Volt für den TT-Bus zu geben, da wie gesagt zum Einen YAART bei zwei Modulen nicht meckert, zum Anderen TOS und MagiC problemlos laufen und wenn nur ein Riegel drin steckt, geht´s auch mit MiNT. Wären die 3,3 Volt zu wenig könnte ich mir vorstellen dass der TT bei allem Möglichen bomben würde wenn auch nur ein Bit kippt, selbst bei nur einem Riegel.
-
Versuche es mal mit 128 + 32 MB. Wenn auch das geht, liegt es wohl am Gesamt-Speicherausbau im Zusammenhang mit Memory-Protection.
Ich habe Memory Protection auch immer aus, weil damit laufen noch weniger Programme, als mit.
-
Auch in beiden PS/2-Slots gestestet oder nur in Slot A?
-
Vielleicht hat es damit etwas zu tun ...
Das sind alles 3,3V Module, meine EDO und FPM aus den USA auf jeden Fall. Da sitzt ein kleiner SMD Spannungsregler drauf der aus den 5V -> 3,3V für die Chips macht. Die Ein und Ausgänge der Speicherchips hängen aber direkt an der 5V Logik des Atari TT Buses.
Da steht zwar 5V auf dem Riegel, aber wie du sagst, ein SMD Spannungswandler ist drauf.
Wenn auf dem Speicherriegel extra ein Spannungsregler drauf ist, dann ist davon auszugehen, dass die ganzen Signalleitungen der Speicherbausteine 5V Tolerant sind. Da auch der Speichertest fehlerfrei durchläuft, und der TT ohne Memory Protextion stabil läuft, gehe ich auch davon aus, dass der Speichercontroller auf der Storm mit 3,3V Signalen seitens der Speicherbausteine zurecht kommt.
Ich gehe jetzt erstmal von einem Softwareproblem von Mint mit Memory Protection und 256 MB RAM aus. Vielleicht gibts ja einen MiNT-Kernel, der das behebt, der von den einschlägigen Forengöttern hier in der Konfiguration verwendet wird. Oder Memory Protection ist bei allen Leuten hier ausgeschaltet.
-
Auch in beiden PS/2-Slots gestestet oder nur in Slot A?
Slot A der Storm muss auf jeden Fall bestückt werden, damit man B benutzen kann. Das Modul in A muss das größere sein. Man kann höchstens nochmal die beiden 128er miteinander tauschen, ich glaube aber nach derzeitigem Kenntnisstand nicht, dass das was bringt.
-
Versuche es mal mit 128 + 32 MB. Wenn auch das geht, liegt es wohl am Gesamt-Speicherausbau im Zusammenhang mit Memory-Protection.
Ich habe Memory Protection auch immer aus, weil damit laufen noch weniger Programme, als mit.
Jepp, 128MB in SLOT A und 32MB in Slot B gehen. MiNT startet durch.
-
Hab es gerade mit memory protection getestet... läuft. Test allerdings mit 2x32MB in der Storm.
-
Bin gespannt, welches Verhalten die beiden 128MB Module bei mir zeigen werden.
-
Bin gespannt, welches Verhalten die beiden 128MB Module bei mir zeigen werden.
Die Module laufen bisher ja ganz gut in der Storm, auch mit Burst. Nur MemoryProtection=on in MiNT macht ja Probleme.
Hat denn noch jemand eine Storm mit 256MB unter MiNT laufen und könnte das mal mit dem MemoryProtect gegenprüfen? Möglicherweise hat @czietz direkt ins Schwarze getroffen und es ist wirklich ein Bug in MiNT.
-
Bitte einmal die Diskussion in den Github-Issue-Tracker von FreeMiNT tragen: https://github.com/freemint/freemint/issues. Ich verstehe den Code auf Anhieb nicht vollständig, aber ich glaube, beim Anschalten der Memory-Protection auf einem 68030 berücksichtigt der MiNT-Kernel nicht, dass die obersten vier Bits der Adresse nicht 0000 (oder 1111 bei Zugriffen auf IO) sein können. Genau das passiert aber bei 256 MB TT-RAM.
-
Trägt wohl niemand auf github ein ...
-
Würde mir ja eine Account einrichten um das dort einzutragen, aber als MiNT Newbie unter den Großen kann ich da nicht mithalten, ist ein Level zu hoch für mich. Beiss mir ja schon bei einer MiNT-Installation die Zähne aus.
-
So wird das aber nicht besser und bringt das ganze nicht voran ...
Account einrichten und einfach nur den Fehler melden so wie czietz das erklärt hat, es Rest machen die anderen schon.
-
Eben, nur so funktioniert Open-Source.
@DonQuichote: Keine Angst, Du hast doch schon sehr gute und systematische Fehlersuche betrieben. Melde Dich an, schildere das Problem und was Du schon unternommen hast, um es einzugrenzen (also: weniger RAM => OK, Memory Protection aus => OK), beantworte evtl. Rückfragen und Du wirst sehen, wenn es -- wie vermutet -- wirklich ein Bug in MiNT ist, wird es einen Fix geben.
Hier im Forum kann höchstens @Thorsten Otto noch etwas dazu sagen, ob die Implementierung der Memory-Protection im FreeMiNT 68030-Kernel für mehr als 256 MB RAM (ST-RAM und TT-RAM zusammen) ausgelegt ist.
-
Hab mir jetzt einen Account eingerichtet und das Problem dort geschildert. Hoffe nur mich mit meinem Schulenglisch verständlich genug ausgedrückt zu haben ...
-
Das klappt schon. Die schreiben schon wenn was unklar ist. ;)
-
Vielleicht hat es damit etwas zu tun ...
Das sind alles 3,3V Module, meine EDO und FPM aus den USA auf jeden Fall. Da sitzt ein kleiner SMD Spannungsregler drauf der aus den 5V -> 3,3V für die Chips macht. Die Ein und Ausgänge der Speicherchips hängen aber direkt an der 5V Logik des Atari TT Buses.
Hab noch mal darüber nachgegrübelt warum die US-Riegel als 5V belabelt sind, diese aber offensichtlich intern mit 3.3V arbeiten.
Kann es sein, dass nur die Speicherlogik der Cips mit 3.3V arbeitet (weniger Verlustleistung, schnellere Schaltzeiten), die Ein-/Ausgänge aber über integrierte Pegelanpassung verfügen und somit über 5V mit der Außenwelt angebunden sind? Welchen Sinn sollte es sonst haben, 3.3V Systeme mit 5V zu powern, um diese anschließend wieder auf 3.3V runterzuregeln? Kritzekratze?!? Hab leider kein Oszi um mal spaßeshalber nachzumessen.
-
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.
-
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.
-
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!
-
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.
-
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?
-
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.
-
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.)
-
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.
-
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.
-
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.
-
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!
-
Test erfolgreich. MiNT startet mit Memory Protection = Yes und 256MB TT-RAM durch!
Super. Dann mal an der "richtigen" Lösung weiterbasteln...
-
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
-
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.
-
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.
-
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 ;)
-
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...
-
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 ;)
-
„Jaja, später machen wir es schön …“, schon klar ;)
Ja klar, kennst das doch ;)
-
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.
-
Hab es installiert. Macht aber bei mir Probleme mit der NOVA.
Weisst du zufällig an welcher Addresse die NOVA ihren Speicher einblendet? Könnte sein daß es da Konflikte gibt.
Möglicherweise mach ich was falsch.
Denke nicht, sollte so funktionieren wie vorher, nur halt mit den vollen 256MB.
-
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
Evtl. ist das dieses Problem hier: https://github.com/freemint/freemint/issues/22#issuecomment-326999228
Lösungen: NVDI verwenden oder EmuTOS.
-
Evtl. ist das dieses Problem hier: https://github.com/freemint/freemint/issues/22#issuecomment-326999228
Möglich. Aber eigentlich müsste es dann schon bei dem Workaround geknallt haben, MP war ja da auch aktiv.
-
Ich nutze den neusten trunk und da stürzt bei der PAK68/3 beim aufstarten von XaAES Teradesk, xaaesnap und TOS2WIN ab.
-
Ich nutze den neusten trunk und da stürzt bei der PAK68/3 beim aufstarten von XaAES Teradesk, xaaesnap und TOS2WIN ab.
Mit weniger als 256MB, nehm ich an? Ungut, da scheint noch irgendwas im argen zu sein...
-
Ich bekomme bei 32MB FastRAM gleich zu Beginn jedes Mal einen Stillstand des TT mit 13 Bomben und einem Problem "Pexec ()".
-
Ich bekomme bei 32MB FastRAM gleich zu Beginn jedes Mal einen Stillstand des TT mit 13 Bomben und einem Problem "Pexec ()".
Oo. 13 Bomben? Das wäre "Coprocessor Protocol Violation"
Sieht so aus als müsste ich die letzten Änderungen erstmal wieder zurück nehmen, bis das Problem gefunden ist. Damit wäre es dann wieder auf dem Stand von dem Workaround, dh. von den 256MB wären dann immerhin 240MB nutzbar, mehr ginge aber nicht. Leider ist das ganze echt schwer zu debuggen, auch Hatari verhält sich da unterschiedlich je nachdem ob ich versuche mit TOS oder mit EmuTOS zu booten.
Für sonstige Vorschläge immer offen...
-
Für sonstige Vorschläge immer offen...
Hast Du einen TT? Evtl. kann @Gaga leihweise eine Storm und zwei 128 MB Riegel bereitstellen, damit Du auf echter Hardware testen kannst.
-
Hast Du einen TT?
Nein, leider nicht. Es scheint ja auch nicht nur an den 256MB zu liegen. Hab hier schon alles mögliche versucht, aber mit Hatari+EmuTOS funktioniert alles. Falcon-Emulation+TOS4 krieg ich irgendwie nicht ans laufen.
Dürfte auch schwierig werden an die Debug-Ausgaben zu kommen, die passieren bevor sie ins boot.log geschrieben werden könnten.
-
Ich erinnere mal an das mit dem Helmut-Build gelöste Problem (https://forum.atari-home.de/index.php/topic,13217.msg212557.html#msg212557). Ist das jetzt im neuesten trunk auch berücksichtigt?
-
Ich erinnere mal an das mit dem Helmut-Build gelöste Problem (https://forum.atari-home.de/index.php/topic,13217.msg212557.html#msg212557). Ist das jetzt im neuesten trunk auch berücksichtigt?
Ich hab leider überhaupt keine Ahnung wovon da die Rede ist, kan nur erschliessen daß es irgendwas mit BlowUp zu tun hat, das hat aber hiermit nix zu tun. Und von Helmuts Branch (der immer noch existert) ist da auch nix eingeflossen, also nein.
-
Es ging darum, daß MiNT den Bildspeicher verschiebt, um so die Speicher-Linearität zu erreichen/verbessern. Damit kommen manche wertvollen älteren Prge. nicht klar, Bspe. dafür waren BlowUp, TrueDisk sowie offenbar vorher auch schon manche GK-Treiber.
Mein Vorschlag dazu war damals ein Schalter im MiNT.ini - leider scheint das nicht weitergegeben worden zu sein, war dem H. wohl zu stressig.
Ich wollte hier aber kein OT-Thema aufmachen, mir kam nur der Gedanke, daß die oben im Thread genannten Probleme vielleicht damit zusammenhängen könnten.