Software > Alternative Betriebssysteme

Reboot bei MiNT

<< < (14/24) > >>

Lukas Frank:
Also bei mir geht es auf echter Hardware, habe es aber auch mal mit Hatari gemacht ...



Vielleicht kommt das alte MTOS nicht mit den Kernel Versionen ab 020 zurecht, keine Ahnung ...

Das alte gem.sys hängt mit dem 020 MiNT Kernel auf einem Mega ST mit PAK68/2. Mit der gem.sys Version 4.1 geht es, allerdings macht die FPU auf der PAK68/2 Probleme. Ein Problem vom MiNT, die FPU läuft ansonsten einwandfrei ...

Starting up the idle process (pid 0) ...pid 0 (MiNT): halt: coprosessor protocol violation
Fatal Error. You must reboot the system.

ari.tao:

Hallo @HelmutK ,
ich habe nach Rückkehr von der Reise noch eine genze Menge Tests unternommen, um MiNT_1.18.0 (oder höher) zum Laufen zu bringen. Bevor ich nun möglicherweise wieder verreisen muß, hier nun der Stand der Dinge. Das obige Teilergebnis (aus #58) unterliegt übrigens auch dem, was ich unten erläutern werde. Also:

  Verschiedene Varianten von 1-18-0 & 1-19-cur auf e: eingerichtet
    M) MultiTOS_4.12 läuft grundsätzlich
    2) NAES_2 + TeraDesk läuft grundsätzlich
    S) SoloMiNT/SinglGEM läuft mit den gewohnten Macken (ie. mäßig stabil);
       aber außerdem ein großes Problem mit der Tastatur!
    C) Einen CLI zu benutzen gelingt nur sehr mangelhaft
       (mit MCMD, aber gar nicht mit sh.tos oder mit der Mupfel).
    X) Während alle obigen Varianten problemlos auf 1024x768x4 starten,
       macht's XaAES + Thing nur in 640x480; nur mit einem Trick lief es
       auch in 1024x768x4: Indem zunächst 2) gebootet & TeraDesk beendet
       wurden und sodann mit dem NAES-Menue das XaAES nachgeladen wurde...
    G) Geneva7 war bisher überhaupt nicht zur Mitarbeit zu bewegen, auch
       nicht mit dem Trick für X. Das beste Ergebnis war noch, daß das Logo
       erscheint, aber die Menue-Leiste nicht (& nichts geht mehr).

  Tja, und alle diese Ergebnisse gab es nur bei Warmstart (wenn also noch
  Speicher durch die TrueDisk belegt war), bei Kaltstart stürzen beide Mints
  mit 2 Bomben ab und beenden sich so schnell, daß ich die letzten Zeilen
  nicht mehr lesen kann... (irgendwas mit ´realloc´).
  Das alles gilt sowohl für 000 als auch für 030.
  Um dem Einwand zu begegnen, die Probleme rührten von älteren installierten
  Programmen her, habe ich sodann alles abgestrippt, also nur noch MiNT und
  BlowUp im AUTO\, keine ACCs etc. Das Ergebnis ist cum grano salis das
  gleiche, bis auf eine Verschlechterung, die aufgefallen ist:
     s) GEM=ROM bleibt nach WarmStart wie G) mit kaputter MenueLeiste hängen

  "WarmStart" meint: Erst kalt von f: gebootet, dann per ResetKnopf von e:.
  Ganz ohne BlowUp geht meistens auch der Kaltstart von e: - außer GEM=ROM.

Im Anhang ein ScreenShot von 2). Und ja, ich habe den Test auch ohne ACCs wiederholt (mit gleichem Ergebnis).
Der seltsame Umstand, daß ein Stück belegten Speichers (die _inaktive_ Truedisk) zum Erfolg führt, das ´nackte´ System aber abstürzt, deutet imho darauf hin, daß MiNT einen Bug in der Speicher-Verwaltung hat, der sich dann auf den BlowUp-Screen auswirkt. In MiNT_1.15.9 war noch alles ok, Probs iZhg. mit BlowUp kenne ich schon von MiNT_1.15.12 - was dazu führte, daß ich bei der stabilen & zuverlässigen v1.15.9 geblieben bin.

Abhilfe? Vorschläge?

KarlMüller:

--- Zitat von: ari.tao am So 18.09.2016, 15:56:31 ---Doch, doch. Die 000er, also die ST-Versionen sollten _überall_ laufen! Sind halt bloß nicht optimiert für die späteren Prozessoren (also etwas lahmer).

--- Ende Zitat ---
Das Wort "sollten" ist zu beachten. Wenn man sich mal den Quelltext von FreeMiNT anschaut sieht man das an einigen Stellen abgefragt wird für welchen Prozessortyp es compiliert wird.

Bei der 68000 Version werden z.B. die CPU Caches nicht vorbereitet.

Mag sein das dies in älteren FreeMiNT Versionen anderst gelöst wurde. Um sicher zugehen also immmer die entsprechende Version nehmen.

HelmutK:

--- Zitat von: ari.tao am Do 03.11.2016, 05:50:10 ---
    S) SoloMiNT/SinglGEM läuft mit den gewohnten Macken (ie. mäßig stabil);
       aber außerdem ein großes Problem mit der Tastatur!

--- Ende Zitat ---

Schon mal meinen kernel probiert?

--- Zitat ---
    C) Einen CLI zu benutzen gelingt nur sehr mangelhaft
       (mit MCMD, aber gar nicht mit sh.tos oder mit der Mupfel).


--- Ende Zitat ---

Was heißt CLI? INIT=/bin/sh oder was?


--- Zitat ---
    X) Während alle obigen Varianten problemlos auf 1024x768x4 starten,
       macht's XaAES + Thing nur in 640x480; nur mit einem Trick lief es
       auch in 1024x768x4: Indem zunächst 2) gebootet & TeraDesk beendet
       wurden und sodann mit dem NAES-Menue das XaAES nachgeladen wurde...


--- Ende Zitat ---

Was steht im boot-log (xa_boot.log und boot.log in C:/mint)?


--- Zitat ---
  Tja, und alle diese Ergebnisse gab es nur bei Warmstart (wenn also noch
  Speicher durch die TrueDisk belegt war), bei Kaltstart stürzen beide Mints
  mit 2 Bomben ab und beenden sich so schnell, daß ich die letzten Zeilen
  nicht mehr lesen kann... (irgendwas mit ´realloc´).
  Das alles gilt sowohl für 000 als auch für 030.
  Um dem Einwand zu begegnen, die Probleme rührten von älteren installierten
  Programmen her, habe ich sodann alles abgestrippt, also nur noch MiNT und
  BlowUp im AUTO\, keine ACCs etc. Das Ergebnis ist cum grano salis das
  gleiche, bis auf eine Verschlechterung, die aufgefallen ist:
     s) GEM=ROM bleibt nach WarmStart wie G) mit kaputter MenueLeiste hängen

  "WarmStart" meint: Erst kalt von f: gebootet, dann per ResetKnopf von e:.
  Ganz ohne BlowUp geht meistens auch der Kaltstart von e: - außer GEM=ROM.


--- Ende Zitat ---

Dann kann es ja auch an BlowUp liegen. Lässt sich das evtl. mit hatari (1.9) oder aranym reproduzieren? Bei hatari 2.0 bombt MiNT bei mir übrigens auch.


--- Zitat ---
Der seltsame Umstand, daß ein Stück belegten Speichers (die _inaktive_ Truedisk) zum Erfolg führt, das ´nackte´ System aber abstürzt, deutet imho darauf hin, daß MiNT einen Bug in der Speicher-Verwaltung hat, der sich dann auf den BlowUp-Screen auswirkt. In MiNT_1.15.9 war noch alles ok, Probs iZhg. mit BlowUp kenne ich schon von MiNT_1.15.12 - was dazu führte, daß ich bei der stabilen & zuverlässigen v1.15.9 geblieben bin.


--- Ende Zitat ---

Oder BlowUp. Lässt sich das auch nach MiNT starten?


--- Zitat ---
Abhilfe? Vorschläge?

--- Ende Zitat ---

Nö :)

ari.tao:
@KarlMüller :
Ich bin doch ´sicher gegangen´: In einer FensterEcke des ScreenShots siehst Du MINT030.PRG prangen! (original aus der Distribution nach e:\auto\ kopiert).
Aber das ist imho völlig unnötig: der 68030 ist afaik ´abwärts-kompatibel´ zum 68000, dh. Prge., die auf dem ST korrekt laufen, tun dies auch auf dem Falken. MiNT000 darf da keine Ausnahme sein (sonst wäre das imho ein Hinweis auf einen Bug in diesem MiNT). Oder umgekehrt: Ein jedes MiNT000, auch aus neuerer Produktion, sollte ´aufwärts-kompatibel´ sein!
Aber danke für den Hinweis, ich werde das mal im Auge behalten.
Im Übrigen fände ich es besser, wenn es nicht gar so viele MiNT-Varianten gäbe: Die Verzweigung auf unterschiedliche Proz. sollte imho innerhalb eines `Ein_Kernal_für_alle´ stattfinden! (Gemeint ist: für 68000 bis 68030)
-------
@HelmutK :

--- Zitat ---Schon mal meinen kernel probiert?
--- Ende Zitat ---
Welchen meinst Du denn? Ich habe schon mehrere verschiedene gesichtet. Irgendwann habe ich auch schon mal einen davon ausprobiert - weiß aber nicht mehr, welchen (und mit keinem besseren Ergebnis). Also häng mal den an, den ich jetzt testen soll.

--- Zitat ---Was heißt CLI? INIT=/bin/sh oder was?
--- Ende Zitat ---
Ja klar.

--- Zitat ---Was steht im boot-log (xa_boot.log und boot.log in C:/mint)?
--- Ende Zitat ---
Die Boot.LOGs für 2) und X) siehe Anhang. Sie sind unauffällig. Im Falle der geschilderten Abstürze wird kein Boot.LOG erzeugt.
XaAES ließ sich in X) trotz einiger Mühe:
      logfile = e:\mint\1-18-0\xaaes\xaaes.log in xaaes.cnf
nicht zu einem LogFile bewegen.

--- Zitat ---Dann kann es ja auch an BlowUp liegen.
--- Ende Zitat ---
Sagen wir lieber: Am Zusammenwirken von BlowUp und MiNT_1.18.0 - denn mit 1.15.9 funzt es ja perfekt. Und mit TOS_4.04 und MAGX_6.21 ebenso!

--- Zitat ---Lässt sich das evtl. mit hatari (1.9) oder aranym reproduzieren?
--- Ende Zitat ---
Ich habe weder hatari noch aranym (kämpfe immer noch mit dieser LabTop-Dose). Ansonsten siehe oben (bei Lukas Frank).

--- Zitat ---Oder BlowUp. Lässt sich das auch nach MiNT starten?
--- Ende Zitat ---
Ja, sowohl danach als auch mit exec aus dem mint.cnf - aber dann bleibt es in beiden Fällen anscheinend unwirksam, jedenfalls erscheint, ähnlich wie im Fall X), die im BlowUp voreingestellte Auflösung nicht, sondern bloß 640x480.
Könnte mal jemand die BlowUp-Quellen anschauen? (Ich habe nur sehr geringe C-Kenntnisse, und leider auch keine Doku zu den verwendeten Video-Regs).
Übrigens, warum ich BlowUp allen anderen vorziehe (auch ScreenBlaster, obwohl der einen vorzuglichen VMG hat), hat iW. vier Gründe:
  1) Es ist OpenSource (wie schon bemerkt)
  2) Es ist ohne Verdongelung mit der Hardware (iGgs. zu S-Blaster)
  3) Sogar sein Demo (ohne HW-Mods!), verbessert bereits das Video
  3) Mit nur zwei sehr simplen HW-Mods bekommt man 1024x768x4 + 800x608x8
Hinter dieser Leistung bleiben andere (Videlity, CentScreen etc.) weit hinter zurück (und vor ScreenWonder (& ScreenResolutionCard) würde ich dringend warnen!).

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete