atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: michschmi am Di 05.04.2011, 11:37:35
-
Hallo,
wie legt man das System Directory (sysdir) in Mint 1.16 oder Mint 1.17 fest. Eine entsprechende Variable scheint es in mint.cnf nicht zu geben; eigentlich ist die Festlegung dort auch zu spät. da Mint ja bereits vorher wissen will, woher es die Informationen Mint.cnf und Device-Treiber herbeziehen soll.
Wie stellt Mint daher fest, welches das Bootlauferk ist? Übernimmt es Werte vom Festplattentreiber ?
Ich nutze den Stemulator und boote von P:\, wobei P:\ ein Ordner namens C:\Programme\Stemulator\Home ist.
Möglicherweise funktioniert Mint ab 1.16 auch pfadbezogen so nicht mehr.
Ich bekomme folgende Fehlermeldung:
no <boot>/mint or <boot>/mint/1-17-0 folder found
-
Hi,
mint.prg setzt das Systemverzeichnis folgendermaßen:
<Bootlaufwerk>/mint/<Versionsnummer>/
Du könntest es mal mit "setenv SYSDIR <Pfad zum Systemverz.>"
in der mint.cnf probieren...
Gruß,
Latz
-
3.1.2 Die neue sysdir Strategie
-------------------------------
Um die Installtion und Konfiguration von FreeMiNT zu vereinfachen, gibt es
jetzt ein sogenanntes "System-Verzeichnis", kurz <sysdir>. Der Kernel wird
xdd/xfs Module sowie Konfigurationsdateien (MINT.INI und MINT.CNF) nur noch
ausschliežlich aus diesem Verzeichnis laden.
Standardm„žig heižt <sysdir> so:
"<bootdrive>/mint/<VERSION>" oder, falls dieses Verzeichnis nicht existiert:
"<bootdrive>/mint".
ACHTUNG: Wenn kein <sysdir> gefunden wird, wird FreeMiNT den Bootprozess
abbrechen, eine Fehlermeldung ausgeben und zu TOS zurckkehren.
<VERSION> steht fr die Kernel-Version und ist als 8+3-Verzeichnisname
kodiert. Fr den FreeMiNT 1.16.0 beta Release Kernel gilt somit folgendes:
<VERSION>=1-16-0
Somit ist es m”glich, in Zukunft mehrere FreeMiNT-Installationen parallel zu
betreiben.
Beispiel 1:
Das Bootlaufwerk sei C:. Dort existiere ein Ordner namens MINT. In diesem
Ordner sind all die xdd/xfs Module und die MINT.CNF
==> <sysdir> ist: "C:\MINT"
Beispiel 2:
Das Bootlaufwerk sei C:. Dort existiere ein Ordner namens MINT. Jetzt erzeugt
man in diesem MINT-Ordner einen Ordner names 1-16-0 und kopiert all seine
xdd/xfs Module und die MINT.CNF dorthin.
==> <sysdir> ist: "C:\MINT\1-16-0"
Falls man diese 2. M”glichkeit verwendet, was ich w„rmstens empfehle, kann man
ein zuknftiges FreeMiNT-Release 1.16.1 parallel benutzen, einfach indem man im
MINT-Ordner einen weiteren Ordner 1-16-1 erstellt und die entsprechenden Kernel-
Module und Konfigurationsdateien dorthin kopiert.
Beim n„chsten Booten muss man einfach nur noch den Kernel ausw„hlen, den man
verwenden will. Er wird dann automatisch das richtige Systemverzeichnis
ausw„hlen.
Ich hoffe, diese Option ist besonders ntzlich fr alle alpha- und beta-Tester.
Damit drfte eine l„stige Umkonfiguration entfallen.
Nach dem Booten kann man immer nachsehen, welches das <sysdir> ist. Es findet
sich immer in der Umgebungsvariablen $SYSDIR, unter /kern/sysdir oder auch mit
'sysctl kern.sysdir'.
-
@afalc060
den Text kenn ich schon fast auswendig :) . Leider steht dort nirgends, wie Mint das Sysdir ermittelt.
@latz
das geht leider nicht, denn Mint 1,16 und Mint 1,17 setzt das SysDir BEVOR es überhaupt die Mint.cnf auswertetet. Da muß bereits was im Kernel-Modul (mintxx.prg) passieren.
Ich vermute sehr stark, dass Mint die Lage des Treibers im LowLevel-Bereich auswertet, denn mit HDDriver oder CBHD kann ich ja durch Definition im Setup das Bootlaufwerk festlegen.
Schade, wird wohl nichts mit "Pimp your Mint" ;)
-
wie mint das sysdir ermittelt steht genau dort in der anleitung. einfach nochmal lesen ::)
-
Also ich denke auch das das SysDir fest im Kernel verankert ist!
-
wie mint das sysdir ermittelt steht genau dort in der anleitung. einfach nochmal lesen ::)
Dort steht "
Der Kernel wird
xdd/xfs Module sowie Konfigurationsdateien (MINT.INI und MINT.CNF) nur noch
ausschliežlich aus diesem Verzeichnis laden"
das steht da eben nicht. Da steht nur, wo man nachsehen kann, wenn ein Mint 1.16/17.x gestartet ist, was das Sysdir ist. Dass man nachschauen kann,heißt überdies für mich, dass das sysdir auch etwas anderes als C:\ sein kann.
Da steht aber nicht, woher der Kernel sich die Variable <bootdrive> zieht. So kann es ja Nutzer geben, die von Z: booten. Dann ist Bootdrive Z: und die Frage bleibt nach wie vor, wie ermittelt Mint dann Z: ?
Bis 1.15.12 war es so, dass Mint das Laufwerk als "Bootdrive" hergenommen hat, von dem aus Mint(np).prg gestartet wurde und dann auf diesem Laufwerk wahlweise nach den Ordnern "Mulititos" oder "Mint" gesucht hat. Mit Auslesen der mint.cnf konnte mann dann beliebig verzweigen (z.B.auf O: etc. und alle Programme von dort starten lassen) Das scheint aber in 1,16/17 anders geworden zu sein... :(
-
Also ich denke auch das das SysDir fest im Kernel verankert ist!
kann nicht sein, denn nicht jeder Nutzer bootet von C: . Ich befürchte aber, dass Techniken darin verankert sind, die das Bootlaufwerk vor Auswertung von mint.cnf ermitteln. Nur wie ???
-
Gut dann frage ich mal, wer hat das MiNT verzeichnis schon woanders gehabt ausser auf C ? Ich nicht!
-
Gut dann frage ich mal, wer hat das MiNT verzeichnis schon woanders gehabt ausser auf C ? Ich nicht!
auf den Milan hatte ich das Mint-Hauptsystem auf C:\. Zu dieser Zeit (2000/01) gab es aber öfters betas, die recht buggy waren. Um diese zu testen, hab ich auf F:\ noch eine zweite Umgebung eingerichtet und bei Bedarf von F: gebootet. Hat immer funktioniert :)
Seinerzeit gab es aber noch kein 1.16/17.x ;)
-
Gemdos Funktionsnummer 25, Dgetdrv
liefert das aktuelle Laufwerk.
lw%=GEMDOS(25)
Dabei gilt: 0 = A, 1 = B, 2 = C, 3 = D ... usw
Direkt, zb so
print chr$(gemdos(25)+65)
gibt direkt A,B,C,D,E, usw aus.
um nun das aktuelle verzeichnis, auf einem individuellen laufwerk zu erfahren. könnte man so vorgehen:
path$=space$(256)
path%=v:path$
r%=gemdos(71,l:path%,add(gemdos(25),1))
print path$
aber da mint ja erstmal als normaler gemdos-prozess gestartet wird, erhält es auch seine kommandozeile. darüber kann man auch imho das laufwerk, von dem der prozess gestartet wurde abfragen.
aber um ganz sicher zu wissen wie es gemacht wird, könnte man in die mint-quellen gucken ;)
-
das laufwerk von wo gebootet wurde, kann man auch noch bestimmen.
old%=gemdos(32,0)
print chr$(word{$446}+65)
r%=gemdos(32,l:old%)
-
Also ich denke auch das das SysDir fest im Kernel verankert ist!
kann nicht sein, denn nicht jeder Nutzer bootet von C: . Ich befürchte aber, dass Techniken darin verankert sind, die das Bootlaufwerk vor Auswertung von mint.cnf ermitteln. Nur wie ???
Wer behauptet denn dass das Bootdrive C: sein muß?
-
Ich gehe jetzt mal davon aus ! Das Mint nach dieser Systematik das Systemdir festlegt
Bootlaufwerk:/mint/kernelversion....
Es wird nicht gehen das mint verzeichnis auf D zu legen und dann von C zu booten.
Maped der HD-Driver eigentlich das Laufwerk um? Ich hab das noch nie benutzt! Also wenn man von D bootet, wird dann D zu C ?
-
dann würden doch die ganzen pfadangaben im desktop zb nicht mehr stimmen.
-
Deswegen frag ich ja!
-
Also ich denke auch das das SysDir fest im Kernel verankert ist!
kann nicht sein, denn nicht jeder Nutzer bootet von C: . Ich befürchte aber, dass Techniken darin verankert sind, die das Bootlaufwerk vor Auswertung von mint.cnf ermitteln. Nur wie ???
Wer behauptet denn dass das Bootdrive C: sein muß?
niemand, aber alle Beispiele, auch die in der doku geben halt nur Infos dazu, wie Mint startet, wenn Bootdrive C: ist. Aber wie Mint das ermittelt, wird nicht gesagt. :(
Da aber allgemein von <bootdrive> gesprochen wird, gehe ich stark davon aus, dass Mint auch andere Bootdrives ermitteln, kann.
Aber möglicherweise kann es keine gemappten Verzeichnisse, die als Bootlaufwerk dienen, erkennen.
In meinr Stemulator-Konfog gibt es kein C: (nur zum Booten das VerzeichnisC:\Programme\Ste...\Home. Das ist als Atari-LW P:\ gemappt. Im Stemulator selbst komme ich da nicht drübr raus. Zugriffe auf P: erfolgen dann im o.g. Verzeichnis C:\...\Home.
Nun, ich denke, ich muß dan wirklichbei 1.15.12 bleiben. Möglicherweise haben die Programmierer nicht an die Möglichkeit gedacht, dass ein Emu Mint nutzt (Stemulator ist aber auch der einzige, der das kann).
-
Deswegen frag ich ja!
ich hatte das auf dem milan so, dass auf F: ein (nicht ganz komplette) Test-Umgebung lag. In den betreffenden inf-Files waren dann alle Pfade auf F:\ gestellt.
Wollte ich dann mit F: booten, habe ich erst im HD-Driver C: als Bootlaufwerk weggenommen und F: als Bootlaufwerk definiert, mit der folge, dass der Sys-Treiber auf C: verschwunden ist und auf F: geschrieben wurde.
Grund für den Umstand war, dass der Milan-Blaster-Treiber an einer bestimmten Position im Auto-Ordner sein mussten, und ich nur für Tests einer Mint-Beta nicht den ganzen AUTO-Ordner mehrmals umkopieren wollte, bis wieder alles passte. Und zum Testen brauchte ich keinen Sound ;)
-
Ich gehe jetzt mal davon aus ! Das Mint nach dieser Systematik das Systemdir festlegt
Bootlaufwerk:/mint/kernelversion....
Es wird nicht gehen das mint verzeichnis auf D zu legen und dann von C zu booten.
Maped der HD-Driver eigentlich das Laufwerk um? Ich hab das noch nie benutzt! Also wenn man von D bootet, wird dann D zu C ?
das geht mit 1.16/17 wohl nicht mehr, denn in der Doku steht ja, dass Mint unter Mint oder Mint\<Version> alles erwartet; also *.cnf und Device-Treiber.
Bis 1.15.12 war es möglich, das auf dem Bootlaufwerk nur ein Ordner namens Mint/Multitos lag und darin nur eine mint.cnf.
Wenn dann darin die Verzeichnis- und Pfad-Wechsel für die Treiber und das AES richtig konfiguriert waren, konnte man auch sein Mint und das AES auf D,F oder Z haben oder auch Mint auf X: und AES auf Z: (hatte ich auf dem Milan kurzzeitig auch mal (mint auf C: und Naes auf G: ; man muß ja alles mal testen und Mint war mit dem Milan Neuland für mich; da wollte ich schon wissen, was möglich war). Bis Mint 1,15,12 wurde alles noch durch das Abarbeiten der mint.cnf gesteuert.
-
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
-
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
-
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.
-
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 :'(
-
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.
-
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?
-
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 :'(
-
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.
-
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...?
-
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?
-
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.
-
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.
-
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 ;-)
-
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 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.
-
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.