Reboot bei MiNT

[Arthur]

Stimmt ja, ich hätte es dann wohl mal mit dem 020er probiert.

[mfro]

Der Patch ist ein patch der wohl schon bei anderen Tos Versionen angewendet worden ist.

Auf dem TT wird ja für's Booten von Platte die DMAread() XBIOS-Funktion verwendet.

Also habt ihr wahrscheinlich die gepatcht?

[tuxie]

Genau die haben wir gepatscht, und wir vermuten auch das es daran liegt.

[KarlMüller]

Genau die haben wir gepatscht, und wir vermuten auch das es daran liegt.

Ist das der welcher im TosPatch drin ist?

Schonmal das TOS2.06/3.06 Listing von Markus Fritze angeschaut?

[tuxie]

Muß ich nachfragen, ich selbst habe den Patch nicht eingebaut.

[Lukas Frank]

Ich habe mal ein MultiTOS mit dem 1-19er Kernel von Helmut gebastelt zum probieren.

Bei mir mit der PAK68/2 und TOS 3.06 drauf bootet Mint nicht durch und landet ohne Fehlermeldung auf dem Single TOS Desktop. Egal ob ich von Diskette also A:\ oder von C:\ boote. Unter Single TOS ist alles wunderbar.

Auf der PAK sitzt ein c´t IDE Interface mit CF Karte.

Das TOS kennt ja nur zwei Massenspeicher Ports je Rechner also ...

- Falcon: IDE, SCSI
- Atari TT: SCSI, ACSI
- ST Book: IDE, ACSI
- ST, STacy (TOS 2.06): IDE, ACSI

Anstatt das TOS 3.06 zu patchen müsste man doch besser eine dritte Schnittstelle hinzufügen, also ein IDE Port oder besser zwei wegen der MonSTer im ST mit PAK. Platz beim TOS 3.06 müsste doch noch sein aber das ist bestimmt ein schwieriges Unterfangen ...

[tuxie]

Wir haben in der Zwischenzeit eine Lösung gefunden, es gibt nämlich zwei wege das Bootproblem zu lösen. Die Version die wir erst hatten war eleganter und man konnte auch weiter vom SCSI Booten.
Die zweite Version ersetzt die Autoboot Routinen vom TOS 2,06 was aber zur Folge hat das man nicht mehr von SCSI Booten kann. (so ist es beim PAK Tos 3.06, da der ST eh kein SCSI hat).

[Lukas Frank]

Die zweite Version ersetzt die Autoboot Routinen vom TOS 2,06 was aber zur Folge hat das man nicht mehr von SCSI Booten kann. (so ist es beim PAK Tos 3.06, da der ST eh kein SCSI hat).

Und wieso klappt das mit mint.prg dann nicht auf der PAK ?

Wir haben in der Zwischenzeit eine Lösung gefunden, es gibt nämlich zwei wege das Bootproblem zu lösen. Die Version die wir erst hatten war eleganter und man konnte auch weiter vom SCSI Booten.

Was ist denn genau die erste Lösung ?



Ich hatte mal Epoms mit dem 512kB EmuTOS gemacht aber damit bootet die PAK nicht !?!

[tuxie]

D.h. du hast mit der pak das gleiche Problem das wenn es gebootet war das du nach einem reboot nicht mehr von IDE automatisch booten kann ?

Wie die andere Lösung im detail aussieht kann ich dir nicht genau sagen.

[Lukas Frank]

Du meinst doch den Reboot vom EasyMiNT Installer, das ist das erste Mal wenn mint bootet ...

Probiere doch mal meine Bootdiskette im Anhang ein paar Beträge zuvor !

Mit der PAK klappt das booten mit mint.prg überhaupt nicht ...

[tuxie]

Nein ich rede nicht vom Installer, ich rede davon das wenn ich aus einem laufenden Mint reboote kann ich nicht mehr, von IDE booten. Und nein hat nix mit Treiber zu tun weil es ein level tiefer liegt das Problem.

Mein Mint ist fertig installiert und eingerichtet, läuft 1a und kann damit Arbeiten aber sobald ich mit dem alten Patch reboote oder reset drücke dann macht der tt keinen Autoboot mehr.

[ari.tao]

Hallo @Lukas Frank , ich habe mal das MultiTOS ausprobiert auf meinem F30:
Leider bleibt MiNT_1.19.alfa hängen nach der Meldung "Loading external modules..."!
Was mache ich falsch?
Nach dem Hänger führt der Reset-Knopf zum Dauer-Reset, also Kaltstart nötig.

[Lukas Frank]

Lade dir mal den aktuellen Snapshot build vom trunk ->   http://www.freemint.org

... und ersetze das mint.prg im Autoordner und alle Dateien im Mint Ordner ausser der mint.cnf.

Das ist eine Bootdiskette, wenn das ganze von Platte laufen soll müssen die Pfade in der mint.cnf und gem.cnf angepasst werden.

[ari.tao]

Auf dem F30 ist der Klops zu groß zum Entpacken, und auf dem Labtop fehlt mir der Entpacker für bz2.
Die Pfade sind bereits angepaßt.
Welche sind denn die ´external modules´, die er vermißt?
Vielleicht kann ich sie aus 1-18-0 ergänzen?

[Nervengift]

Welche sind denn die ´external modules´, die er vermißt?

Die Treiber? *.xxd und *.xif?

Du hast den richtigen Kernel in den Autoordner gelegt? Das Verzeichnis "c:\mint\1-19-cur\" ist vorhanden? Darin die besagten Treiber und die mint.cnf, mint.ini und das Verzeichnis "xaaes"? Was steht in der mint.cnf und in der mint.ini? Fragen über Fragen.

[Lukas Frank]

Das sollte jetzt gehen ...

Passt alles auf eine HD Diskette.

Mint läuft auch ganz ohne die einzelnen Treiber und Zusätze, vielleicht ein Fehler im mint.prg der ersten Diskette von mir, keine Ahnung ...

[Lukas Frank]

Welche sind denn die ´external modules´, die er vermißt?

Die Treiber? *.xxd und *.xif?

Du hast den richtigen Kernel in den Autoordner gelegt? Das Verzeichnis "c:\mint\1-19-cur\" ist vorhanden? Darin die besagten Treiber und die mint.cnf, mint.ini und das Verzeichnis "xaaes"? Was steht in der mint.cnf und in der mint.ini? Fragen über Fragen.

Da ist kein XaAES, das ist MultiTOS von Atari mit dem aktuellen Mint Kernel ...

[ari.tao]

Hab´ die Prozedur soeben mit dem neuen MultiTOS.ZIP wiederholt:
Gleiches Ergebnis! Mit beiden Kernels.
-------
Jetzt geh´ ich erstmal in die Sonne, vielleicht schaue ich heute Abend nochmal vorbei.

[Nervengift]

Da ist kein XaAES, das ist MultiTOS von Atari mit dem aktuellen Mint Kernel ...

Das wird nicht funktionieren. Seit MiNT 1.16.x wird folgende Ordnerstruktur von dem Kernel vorausgesetzt: \mint\1-1x-x\

Wenn der entsprechende Versionsunterordner nicht im MiNT-Ordner vorhanden ist, findet MiNT seinen ganzen Krams nicht mehr.

Hab´ die Prozedur soeben mit dem neuen MultiTOS.ZIP wiederholt:
Gleiches Ergebnis! Mit beiden Kernels.

Welches sind denn die beiden Kernels?

[Nervengift]

Nur \mint\ geht auch, aber der Ordner muss vorhanden sein:

http://sparemint.org/sparemint/mint/kernel/1.16.1/readme.txt

The <sysdir> defaults to "<bootdrive>/mint/<VERSION>" or, if this directory
doesn't exist, "<bootdrive>/mint".

Ansonsten:

If no <sysdir> is found FreeMiNT will stop the booting procedure,
      display an error message and then return to TOS.

Aber:

After the kernel has booted you can also lookup what your <sysdir> is. The
<sysdir> setting is available through the environment variable $SYSDIR, under
/kern/sysdir or through 'sysctl kern.sysdir'.

Vielleicht könnte das klappen mit dem zusammengefummelten Multitos, wenn Du diese Variable anpasst?