SystemDir (sysdir) unter Mint 1.16 oder 1.17 festlegen

[michschmi]

Aaaalso,
ich habe hier auf dem Falcon das "offizielle" MiNT 1-17-0 auf
C:\mint\1-17-0\ und zum testen den daily build auf D:\mint\1-18-cur\.
Auf beiden Partitionen ist ein auto-Ordner, in dem sich das entsprechende
kernel befindet.
Beim booten von HDDriver drücke ich dann einfach "D"; es wird von
Laufwerk D gebootet, SYSDIR ist dann D:\mint\1-18-cur\ und alles
funktioniert.
Alle anderen Pfade (ACCPATH, Desktop...) kann man in mint.cnf
oder in xaaes.cnf anpassen; ich habe z.B nur einen TeraDesk-Ordner,
beide MiNT-Versionen verwenden dasselbe TeraDesk.

Aber beschreibe Dein Problem mal in der MiNT mailing-list,
das lässt sich garantiert regeln!
Latz

bestätigt im Prinzip meine Befürchtung, dass nicht daran gedacht wurde, dass auch aus Verzeichnissen gebootet werden könnte und damit alfalcs Hinweis. Mint wertet die Boot-Info des Treibers aus und befüllt damit die Variable <bootdir>.
Möglicherweise wurde das auch bwusst ignoriert.
Für echtes Mint (mit entsprechenden Paketen) gibt es im Stemulator eh keine Verwendung, weil eben keine Festplattentreiber und Dateisysteme genutzt werden können (man kann lediglich noch eine Ramdisk definieren; alle anderen Laufwerke werden über das Stemulator-Hauptprogramm eingebunden)
Mintxx.prg dient im Prinzip nur zum Erstellen einer relativ modernen Multitasking-Umgebung durch Nachstarten eines AES-Derivats (ich nutze hier wahlweise Naes oder Xaaes 0.960).

Wäre zwar schön gewesen, wenn es funktioniert hätte, aber da auch mit Mint 1,15,12 alles Nötige funktioniert, ist das ok.
Das Originale Multitos (Gem.sys) von Atari läuft auch nur bis einschließlich Mint 1.15.5

[HelmutK]

MiNT bootet  immer von dem Laufwerk, von dem es gestartet wurde. Da wird nichts irgendwie gedreht.

Wenn auf Atari-Seite irgendein Host-Ordner P: ist, dann müsste MiNT seine Sachen auf (atari-)P:\mint\... suchen. Wenn es die da nicht findet, handelt es sich um einen Fehler vom Emulator oder Benutzer.

Also wenn MiNT überhaupt startet, müsste es auch seine Sachen finden.

Vielleicht klappt's ja ,MiNT im Host auf C: zu installieren.

[michschmi]

MiNT bootet  immer von dem Laufwerk, von dem es gestartet wurde. Da wird nichts irgendwie gedreht.

Wenn auf Atari-Seite irgendein Host-Ordner P: ist, dann müsste MiNT seine Sachen auf (atari-)P:\mint\... suchen. Wenn es die da nicht findet, handelt es sich um einen Fehler vom Emulator oder Benutzer.

Also wenn MiNT überhaupt startet, müsste es auch seine Sachen finden.

Vielleicht klappt's ja ,MiNT im Host auf C: zu installieren.

wie bereits im Start-Post geschrieben, kommt der Fehler immer, egal ob ein Verzeichnis mint oder mint\<version> heißt. C: gibt es in meiner Konfig wie beschrieben nicht (und das ist auch ganz bewußt so, denn C: ist Windows, da leg ich sicherlich keine Atari-Software ins Root )

Dass  Mint immer von dem Laufwerk bootet, von dem es gestartet wurde, scheint so nicht mehr zu stimmen (für Ver. 1.16/17), da mit mint 1,15.12 der Start reibungslos funktioniert (für Mint 1.15.12 stimme ich deiner Aussage zu (so steht es auch in der Doku zu 1.15.12).  Möglicherweise liegt es daran, dass P: eben keine Laufwerkstruktur hat, sondern ein Windows-Verzeichnis ist, mit all den Problemen, die Mint damit haben mag.

Übrigens funktioniert auch 1.16.x nicht Demzufolge hast sich mit 1,16/17 irgendetwas verändert, was die Funktionalität auf dem Stemulator verhindert.

Hier nochmal der Fehler

no <boot>/mint or <boot>/mint/1-17-0 folder found

Es gibt aber im Verzeichnis C:\Programme\Stemulator\Home\ einen Ordner 'Mint' und darin eine Mint.cnf
Auf der atari-Seitwe ist obiger Ordner (C:\Programme\Stemulator\Home\) als Laufwerk P: ansteuerbar. Alle sonstigen Autostart-Programme und ACCs werden von P: ordentlich geladen.

Übrigens: Auch mit Mint 1,15.5 funktioniert der Start ohne Probleme

Von daher ist deine Aussage kein Lösungsansatz für mich 

[HelmutK]

Dann muss P:\mint\1-17-0 klappen. Der Auto-Ordner liegt ja wohl auch auf P:\auto?

Im Programm steht:

   * Initialize sysdir
   *
   * from 1.16 we ignore any multitos folder
   * from 1.16 we default to \mint
   * from 1.16 we search for \mint\<MINT_VERSION>
   *           for example "\\mint\\1-16-0"   for 1.16.0 version
   *                    or "\\mint\\1-16-cur" for cvs-current of 1.16 line
   */

Und dann kommt nur Dsetpath("\\mint...");

Was dann schief geht.

[michschmi]

Da fällt mir nochwas ein. Welches TOS setzt 1,16/17 voraus. Ist vielleicht TOS 2,06 zu wenig,weil irgendwelche Gemdos-Aufrufe plötzlich fehlen?

Eigentlich sollte aber das doch nicht am TOS scheitern?

[michschmi]

Dann muss P:\mint\1-17-0 klappen. Der Auto-Ordner liegt ja wohl auch auf P:\auto?

Im Programm steht:

   * Initialize sysdir
   *
   * from 1.16 we ignore any multitos folder
   * from 1.16 we default to \mint
   * from 1.16 we search for \mint\<MINT_VERSION>
   *           for example "\\mint\\1-16-0"   for 1.16.0 version
   *                    or "\\mint\\1-16-cur" for cvs-current of 1.16 line
   */

Und dann kommt nur Dsetpath("\\mint...");

Was dann schief geht.

nein geht nicht, auch schon getestet 

[HelmutK]

Da fällt mir nochwas ein. Welches TOS setzt 1,16/17 voraus. Ist vielleicht TOS 2,06 zu wenig,weil irgendwelche Gemdos-Aufrufe plötzlich fehlen?

Eigentlich sollte aber das doch nicht am TOS scheitern?

TOS 1.0 ;-)

Vielleicht liegt's an Groß/Kleinschreibung? Also P:\MINT\? Lässt  sich aber von fern schwer klären.

[michschmi]

Ich hab die Datei-Struktur nochmal aus dem Archiv original nach P: kopiert. Da gibt es nun \MINT\1-17-0 und... Mint startet....etwas

Nach einer langen Liste von pid-Ausgaben mit allem möglichem Krams der "failed" ist, kommt:

parse cnf: can't open u:\p\MINT\1-17-0\mint.cnf 

.
.
.
System halted!

Verstehe ich jetzt nicht, denn ich habe die im Archiv befindliche MINT.CNF genommen und etwas abgeändert p für c und die Zeilen

cd u:/
GEM = u:/N_AES/NAES.SYS

eingefügt.

Da die Mint.cnf nicht gelesen wird, kann ich wohl die pid-Ausgaben nicht in eine Datei umleiten...?

[michschmi]

so hier mal ein Screenshot der Version 1.16.0, da sind die Fehlerausgaben weniger, aber das Ergebnis dasselbe

Vielleicht hat jemand dafür eine Lösung?

[HelmutK]

so hier mal ein Screenshot der Version 1.16.0, da sind die Fehlerausgaben weniger, aber das Ergebnis dasselbe

Vielleicht hat jemand dafür eine Lösung?

Das nicht, aber -15 heißt ungültiges Laufwerk.

[Arthur]

Ich finde es gut das die Dateistrucktur vorgegeben ist und das Bootdir nicht auf C: festgelegt ist. So kann man anderen bei Problemen leichter helfen. Bei Atari hat sich auch niemand darum gekümmert das der Autoordner und die ACC's im Root stehen müssen und nicht im 58sten Unterordner. Schätze das Stemulator irgndwelche nicht TOS-Techniken anwendet. Wenn eine 68K CPU (Stemulator, MagiC etc.) schon mehr als 16MB adressieren kann dann ist das doch ein Wunder das etwas drauf läuft.

[HelmutK]

Ich finde es gut das die Dateistrucktur vorgegeben ist und das Bootdir nicht auch C: festgelegt ist. So kann man anderen bei Problemen leichter helfen. Bei Atari hat sich auch niemand darum gekümmert das der Autoordner und die ACC's im Root stehen müssen und nicht im 58sten Unterordner. Schätze das Stemulator irgndwelche nicht TOS-Techniken anwendet. Wenn eine 68K CPU (Stemulator, MagiC etc.) schon mehr als 16MB adressieren kann dann ist das doch ein Wunder das etwas drauf läuft.

Das Problem ist ja auch weniger die Dateistruktur (mint.cnf wird ja scheinbar sogar gefunden), sondern das Filesystem. In 1.15 wird noch auf aufs TOS-FS zurückgegriffen, danach nicht mehr, außer  ganz am Anfang. z.B. um mint.ini zu lesen, was ja scheinbar auch klappt.

Jemand müsste extra für diesen Emulator ein MiNT machen, das das TOSFS benutzt (der code ist noch da glaube ich), weiß aber nicht ob's dann geht.

Aber aranym ist sowieso besser ;-)

[gstoll]

Vielleicht hat jemand dafür eine Lösung?

Also ich würde hin gehen im STemulator, denn Haken bei "Im MultiTOS Modus starten" löschen. Bei "Extras" die "MiNT Directory Funktionen" auch deaktivieren und bei "Laufwerken" für das Laufwerk C ein neues Verzeichnis mit einer aktuellen FreeMiNT Version installieren und C als Bootlaufwerk setzen.

Prinzipjell könntest Du das mit C Dir sparen und ein anders Laufwerk nutzen, da man im STemulator jedes Laufwerk zum Bootlaufwerk machen kann.

Ich habe dies nicht getestet, deshalb wenn Du es versuchst entsprechend Daten vorher sichern!

Gerhard

[michschmi]

Ich finde es gut das die Dateistrucktur vorgegeben ist und das Bootdir nicht auch C: festgelegt ist. So kann man anderen bei Problemen leichter helfen. Bei Atari hat sich auch niemand darum gekümmert das der Autoordner und die ACC's im Root stehen müssen und nicht im 58sten Unterordner. Schätze das Stemulator irgndwelche nicht TOS-Techniken anwendet. Wenn eine 68K CPU (Stemulator, MagiC etc.) schon mehr als 16MB adressieren kann dann ist das doch ein Wunder das etwas drauf läuft.

Das Problem ist ja auch weniger die Dateistruktur (mint.cnf wird ja scheinbar sogar gefunden), sondern das Filesystem. In 1.15 wird noch auf aufs TOS-FS zurückgegriffen, danach nicht mehr, außer  ganz am Anfang. z.B. um mint.ini zu lesen, was ja scheinbar auch klappt.

Jemand müsste extra für diesen Emulator ein MiNT machen, das das TOSFS benutzt (der code ist noch da glaube ich), weiß aber nicht ob's dann geht.

Aber aranym ist sowieso besser ;-)

@ Arthur

klar wendet kein Emu (egal ob Stemulator oder MagicPC) komplett Tos-Techniken an. Liegt halt in der Natur der Dinge, denn wenn ich im Stemulator von 2Gig Speicher nur 256MB freilassen will und das im Emu auch noch funktoinieren soll, dann hat das sicher etwas zu bedeuten.

@HelmutK

Danke für die gesicherte Info bezüglich der Mint-Versionen. Ich denke, ich kann mit 1,15.12 ganz gut leben. Es war halt nur ein Test und evtl. hätte es wirklich neue Funktionen gegeben, die ich zu schätzen gewusst hätte, aber auch so ist das dann ok. Eric Smiths Multitos (gem.sys) läuft ja auch mit Mint 1,15,12 nich mehr, aber mit Mint 1,15,5. Dafür ist es eben ein Emu. Aber dass ich die (lästige) Drucker-Problematik los bin, ist schon einiges Wert und solange es Menschen wie Gerhard gibt, die auch einen Minderheiten-Wunsch in kurzer Zeit umsetzen, ist das doch sehr, sehr gut. Danke nochmal, dafür!!!
Ich hatte mal eine version von Aranym; das hatte mir gar nicht gefallen. Die Anpassung der CNF-Dateien (oder wie die hiessen) war echt sehr umständlich damals. Toll war aber, dass ein Tos 4.04 lief

@ Gerhard

ich denke, das geht nicht, da es ja immer ein Windows Lauferk bzw. Verzeichnis auf einem Windows-System ist und nirgends eine TOS- oder RAW-Kennung gefunden werden wird.
Ich werds aber mal testen und dann berichten (morgen oder übermorgen ) Mint-Directory-Funktionen hatte ich nie aktiviert. Ich hatte in Thing immer 8+3 Namen.

Den Haken bei P: als Bootlaufwerk hatte ich schon gesetzt, das führte aber zu genau derselben Fehlermeldung wie als Bild und Beschreibung gepostet.

[michschmi]

Vielleicht hat jemand dafür eine Lösung?

Also ich würde hin gehen im STemulator, denn Haken bei "Im MultiTOS Modus starten" löschen. Bei "Extras" die "MiNT Directory Funktionen" auch deaktivieren und bei "Laufwerken" für das Laufwerk C ein neues Verzeichnis mit einer aktuellen FreeMiNT Version installieren und C als Bootlaufwerk setzen.

Prinzipjell könntest Du das mit C Dir sparen und ein anders Laufwerk nutzen, da man im STemulator jedes Laufwerk zum Bootlaufwerk machen kann.

Ich habe dies nicht getestet, deshalb wenn Du es versuchst entsprechend Daten vorher sichern!

Gerhard

ich habs getestet: Verzeichnis auf E:\Test\ . Darin Auto-Ordner und Mint-Ordner mit mint.cnf und im Stemulator das Startlaufwerk umdefiniert

Die Ergebnisse waren wie im Screenshot, einige Posts früher, beschrieben.

Dann nochmal auf C: direkt Autoordner und Mint-Ordner gelegt und C: als Bootlaufwerk abgemeldet. Wieder dasselbe Ergebnis.

Ich denke, man kann nun davon ausgehen, dass, wie Helmut geschrieben hat, durch das veränderte Dateisystem, welches der Kernel ab 1,16 erwartet, es nicht mehr möglich ist auf Emulatoren (aranym vielleicht ausgenommen , da es Dateisysteme anbietet) nicht funktioniert.

Das ist aber auch ok. Da Mintnp.prg sowieso nur die Umgebung für N-aes/Xaaes bereitstellt, und sonst keine Mint-Tools laufen können, macht das nicht wirklich was. Es gibt ja mit 1,15,12 eine Möglichkeut wie es im Stemulator funktioniert.