Reboot bei MiNT

[ari.tao]

Neee, geht eben nicht - wie geschildert - oder jedenfalls sehr mangelhaft!
Also gut, noch ein letzter Test (vor der Reise) mit GEM=ROM; Ergebnis:
SoloMiNT/SingleTOS bootet hoch mit TeraDesk (ist bei mir so eingerichtet auf e: ), aber dann erfolgt Dauer-Refresh im Fenster B:\ (bekanntlich Überlauf des TastaturBuffers) und läßt sich mit keinem Trick stoppen! Nach DoppelKlick auf den Editor folgt ein unerwarteter Desk-Refresh und das System bleibt (ohne den Editor geladen zu haben) hängen!
-------
An MülltiTOS ist überhaupt nix gut, ich habe es bloß im System installiert, weil es ja schließlich original von Atari ist! Ich benutze NAES_2 + MiNT_1.15.9 + THING und MAGX_6.21 mit MAGXDESK oder JINNEE ... Wenn ich ein neueres MiNT und/oder XaAES zum Laufen kriege, würde mich das freuen! Leider sind alle bisherigen Versuche fehlgeschlagen.
Noch ein allerletzter Versuch (auch ohne BlowUp!), mit GEM=u:\n_aes\n_aes.prg -q ; Ergebnis:
Nach einer fürchterlichen Liste mit Fehler-Meldungen steigt MiNT aus und es folgt Dauer-Reset!
-------
Wie gesagt ist BlowUp bei mir leider unverzichtbar, und zwar, weil es als letztes übrig blieb: Mit ScreenWonder habe ich eine größere Katastrophe erlebt, auch ScreenBlaster hat sich letztlich nicht so bewährt und alles andere (zB. Videlity & Co.) war sowieso bloß schrottig.
BlowUp _nach_ MiNT zu starten, wie früher unter 1.14.2 empfohlen, wäre vielleicht möglich, aber ggü. 1.15.9 nur ein Workaround und wirklich ein Rückschritt! Ich bitte darum, daß Ihr das auf die Reihe kriegt!

[Lukas Frank]

Wie schon geschrieben auf einem ST/STE mit mint000 Kernel läuft es bei mir. Scheint ein Ding vom Kernel größer 020 zu sein. Der 020 Kernel läuft bei mir über eine PAK020 auch nicht ...

[ari.tao]

Nein, nein. Ich habe ja (-> obige Anhänge) auch mint000 benutzt!

PS: Wie, @Lukas Frank , geht eigtl. das ´verstecken´ im Forum?

[HelmutK]

mint000.prg auf einem Falcon? Kann ja wohl nicht gehen.

Hast Du immer noch das step-by-step im mint.ini? Würde ich abstellen, dann hab ich auch oft diese repeats, auch auf dem TT, überhaupt ist das schlecht, wenn man das MiNT-menu aufruft, hat irgendwas mit dem TOS-keyboard-handler zu tun, der immer meint, es wäre eine Taste gedrückt. Also nichts berühren bis MiNT fertig ist mit booten.

Hier steht auch noch was:

http://wiki.sparemint.org/index.php/Installation_guide#1._Make_sure_you_have_a_clean_system

[ari.tao]

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). Das MiNT_1.15.9 im Anhang oben ist auch eine ST-Version!

Hab´jetzt leider keine Zeit mehr für weitere Tests.
    cia, bello!

[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]

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).

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]

    S) SoloMiNT/SinglGEM läuft mit den gewohnten Macken (ie. mäßig stabil);
       aber außerdem ein großes Problem mit der Tastatur!

Schon mal meinen kernel probiert?

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

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

    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...

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

  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.

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.

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.

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

Abhilfe? Vorschläge?

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 :

Schon mal meinen kernel probiert?

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.

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

Ja klar.

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

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.

Dann kann es ja auch an BlowUp liegen.

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!

Lässt sich das evtl. mit hatari (1.9) oder aranym reproduzieren?

Ich habe weder hatari noch aranym (kämpfe immer noch mit dieser LabTop-Dose). Ansonsten siehe oben (bei Lukas Frank).

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

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!).

[HelmutK]

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)

Das würde aber Speicher kosten. Außerdem optimiert der Compiler für den jew. Prozessor.

-------
@HelmutK :

Schon mal meinen kernel probiert?

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.

Z.B.: http://home.arcor.de/zabruder/atari/xamint14.zip (glaub ich)
oder: http://www.fairlite.co.uk/FreeMiNT//builds/freemint/helmut-04112016.tar.bz2

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.

Ich meinte das XaAES-boot-log. Man muss da im 1.18er wohl noch loglvl setzen (siehe example.cnf).

Ich könnte mir das mit BlowUp mal angucken, aber momentan bin ich leider etwas im Stress.

[ari.tao]

Das würde aber Speicher kosten. Außerdem optimiert der Compiler... 

Ist halt immer die Frage, ob sich der ganze Aufstand für die wenigen Prozentchen lohnt....
-------
Habe loglvl = 1 gesetzt (danke für den Hinweis!) => xaaes.log wird jetzt produziert,
aber die Meldungen sind zT. rätselhaft.
Alles weitere morgen.

[ari.tao]

Anbei die xaaes.log.Files.
Zwei Zeilen verstehe ich überhaupt nicht:
  1) Die erste Zeile, denn moos_w.adi steht definitiv _nicht_ in meinem XAAES\
  2) Die Zeile mit xa_form.mfd, denn das gibt´s anscheinend _nirgends_

xaaes.log ist das zu X) gehörige File (mit video = 0x801a);
für novideo.log wurde kein ´video =´ gesetzt (sollte 1 als Default erzeugen, also die in BlowUp voreingestellte Auflösung 1024x768x4, produziert wird stattdessen ein Hänger mit BlueScreen & blinkendem Cursor);
video5.log gehört zu einem weiteren Versuch (mit Video = 5), denn 5 ist der von BlowUp benutzte Screen-Treiber (gemäß ASSIGN.SYS);
zum Schluß noch das von mir benutzte xaaes.cnf

PS1: Daß man xaaes.log vor jedem Neustart von Hand löschen muß, ist etwas lästig.
PS2: Es gefällt mir gar nicht, wenn während der Boot-Phase ein Prg. ungefragt einen Schreibzugriff macht (ie. zB. einen Ordner 640480.4 erzeugt); den Grund habe ich in der Diskussion über die Boot-Selektoren schon dargelegt.
PS3: Ist ja sehr hübsch, daß sich XaAES wieder sauber deinstalliert, wenn ´was fehlt; aber was nutzt das, wenn danach nicht fortgefahren werden kann, sondern ein Kaltstart fällig ist?! Es sollte doch wenigstens das normale TOS kommen.

[HelmutK]

Anbei die xaaes.log.Files.
Zwei Zeilen verstehe ich überhaupt nicht:
  1) Die erste Zeile, denn moos_w.adi steht definitiv _nicht_ in meinem XAAES\
  2) Die Zeile mit xa_form.mfd, denn das gibt´s anscheinend _nirgends_

Das hier?

sysfile_exists: 'u:\e\MINT\1-18-0\XAAES\moose_w.adi'
sysfile_exists: 'u:\e\MINT\1-18-0\XAAES\moose.adi'

Das sind nur Meldungen der Funktion namens sysfile_exists(). Finde ich auch nicht allzu syntaktisch gelungen.

xaaes.log ist das zu X) gehörige File (mit video = 0x801a);
für novideo.log wurde kein ´video =´ gesetzt (sollte 1 als Default erzeugen, also die in BlowUp voreingestellte Auflösung 1024x768x4, produziert wird stattdessen ein Hänger mit BlueScreen & blinkendem Cursor);
video5.log gehört zu einem weiteren Versuch (mit Video = 5), denn 5 ist der von BlowUp benutzte Screen-Treiber (gemäß ASSIGN.SYS);

Es kommt mit BlowUp:

invalid screen-type:1023
ERROR: k_init failed!

bzw.:

invalid screen-type:639
ERROR: k_init failed!

von vq_extnd->work_out[0]. XaAES erwartet hier 1 oder 4, sonst ist's nichts. Da sollte laut toshyp:

work_out[0]   genaue Spezifikation des Bildschirms

stehen. War dir horizontale Auflösung zufällig 1024 und 640? Das wären dann die Werte von v_opnvwk für work_out[0]. Sieht für mich nach einem Bug in BlowUp aus.

Was sagt sysinfo unter VDI->Erw. Workst in der ersten Zeile wenn BlowUp aktiv ist?

Ich hab jetzt den Abbruch an der Stelle rausgenommen, vielleicht geht's ja:

http://home.arcor.de/zabruder/atari/system/xaaes030.km.gz

PS1: Daß man xaaes.log vor jedem Neustart von Hand löschen muß, ist etwas lästig.

Ich will aber die Historie. Ich lösche es dann einmal die Woche.

PS2: Es gefällt mir gar nicht, wenn während der Boot-Phase ein Prg. ungefragt einen Schreibzugriff macht (ie. zB. einen Ordner 640480.4 erzeugt); den Grund habe ich in der Diskussion über die Boot-Selektoren schon dargelegt.

Ja, das könnte man verbessern. Diese Diskussion kenne ich allerdings nicht.

PS3: Ist ja sehr hübsch, daß sich XaAES wieder sauber deinstalliert, wenn ´was fehlt; aber was nutzt das, wenn danach nicht fortgefahren werden kann, sondern ein Kaltstart fällig ist?! Es sollte doch wenigstens das normale TOS kommen.

Normalerweise kommt dann von xaloader die Frage ob man eine shell starten will. Dann noch den TOS-desktop zu starten, dürfte wohl nicht möglich sein. Das geht nur mit GEM=ROM.

[ari.tao]

Ahh, nun verstehe ich die ersten beiden Zeilen in xaaes.log; da müßte also eigtl. stehen:
     Die Funktion ´sysfile_exists´ sucht: .....
Zur Zeile mit ´xa_form.mfd´ (mitten im xaaes.log) hast Du Dich nicht geäußert.
-------

War die horizontale Auflösung zufällig 1024 und 640?

Nein, die ist nicht zufällig 1024, sondern absichtlich so (wie beschrieben);
und nein, 640 war nicht anvisiert, ich habe ´5´ nur versucht in der Hoffnung, daß dann vielleicht der BildschirmTreiber mit der ID = 5 benutzt wird (das ist nach Auskunft von SYSINFO_5.02 die ID, die BlowUp sonst immer nutzt). Eine ´offizielle´ Falcon-Auflösung von 1024x768x4 gibt´s ja leider nicht; eben darum wird wohl die für externe GK vorgesehene ID 5 benutzt. Ich denke, daß BlowUp sich auf BIOS- oder GDOS-Ebene in´s System einhängt, lange vor jedem v_openvwk/work_out? Unter VDI/Erw.Workst sagt SYSINFO: Wert = 4 in der ersten Zeile, wenn BlowUp aktiv ist. Ich habe nicht den Eindruck, daß BlowUp da buggy ist, zumal TOS-AES, NAES, MAGX & GENEVA das alle richtig verstehen.
Ist

http://home.arcor.de/zabruder/atari/system/xaaes030.km.gz

für 1.18.0 oder für einen Deiner Kernels?
(Btw. wären .ZIPs für mich bequemer als .GZs).
-------

Ich will aber die Historie. Ich lösche es dann einmal die Woche.

Könntest Du dann bitte wenigstens jeweils eine TrennZeile (zB. ~~~~~~~...) dazwischenfügen? Noch besser fände ich einen weiteren Wert ´NewFile´ für loglvl, für den dann der File immer neu erstellt wird.
-------
Bei der Diskussion um SchreibZugriffe während der BootPhase ging es darum, daß in manchen Fällen eine Gefahr für den Inhalt der HD besteht (zB. wenn durch einen Fehler zwei HDs zugleich als IDE-Master eingehängt sind).
-------
Daß MiNT im Falle, daß GEM=Irgendwas fehlschlägt, zu wenig an Info ´rausgibt, das hatten wir ja schon mal festgestellt. Mein Vorschlag wäre, in diesem Falle nicht nur besser zu informieren, sondern dann auf GEM=ROM zu regredieren (und nicht auf INIT=sh oä.) und erst danach (wenn also auch das fehlschlägt) einen CLI zu bemühen. Zumindest aber würde ich erwarten, daß der WarmStart per ResetTaster funzt (und nicht ein KaltStart nötig ist).
Übrigens, wenn schon eine Beendigung von MiNT nötig ist, könnte man dann nicht wenigstens drei Sekunden spendieren, damit die letzten Bildschirm-Meldungen noch gelesen werden können? (ie. eine kleine WarteSchleife in den TermVec einbauen). Oder wenigstens alles nach mint.log schreiben (und den sauber schließen!).

[HelmutK]

Ahh, nun verstehe ich die ersten beiden Zeilen in xaaes.log; da müßte also eigtl. stehen:
     Die Funktion ´sysfile_exists´ sucht: .....
Zur Zeile mit ´xa_form.mfd´ (mitten im xaaes.log) hast Du Dich nicht geäußert.

Da sucht XaAES nach dem Hintergrund-Bild. Kann man ignorieren.

-------
BIOS- oder GDOS-Ebene in´s System einhängt, lange vor jedem v_openvwk/work_out? Unter VDI/Erw.Workst sagt SYSINFO: Wert = 4 in der ersten Zeile, wenn BlowUp aktiv ist. Ich habe nicht den Eindruck, daß BlowUp da buggy ist, zumal TOS-AES, NAES, MAGX & GENEVA das alle richtig verstehen.

Nee, dann stimmt das. Muss was anderes sein.

für 1.18.0 oder für einen Deiner Kernels?
(Btw. wären .ZIPs für mich bequemer als .GZs).

Ich werde wohl kaum XaAES für 1.18 verbreiten gz ist vorgegeben, läuft alles script-gesteuert, sorry.

-------

Ich will aber die Historie. Ich lösche es dann einmal die Woche.

Könntest Du dann bitte wenigstens jeweils eine TrennZeile (zB. ~~~~~~~...) dazwischenfügen? Noch

Ist doch:

~~~~~~~~~~~~ XaAES start up ~~~~~~~~~~~~~~~~

besser fände ich einen weiteren Wert ´NewFile´ für loglvl, für den dann der File immer neu erstellt wird.

loglvl ist numerisch. Kannst ja in mint.cnf exec rm xa_boot.log reinschreiben.

-------

Bei der Diskussion um SchreibZugriffe während der BootPhase ging es darum, daß in manchen Fällen eine Gefahr für den Inhalt der HD besteht (zB. wenn durch einen Fehler zwei HDs zugleich als IDE-Master eingehängt sind).

Also wenn XaAES startet ist der eigentliche boot-Prozess aber ziemlich weit fortgeschritten, oder was meinst Du?

-------

Daß MiNT im Falle, daß GEM=Irgendwas fehlschlägt, zu wenig an Info ´rausgibt, das hatten wir ja schon mal festgestellt. Mein Vorschlag wäre, in diesem Falle nicht nur besser zu informieren, sondern dann auf GEM=ROM zu regredieren (und nicht auf INIT=sh oä.) und erst danach (wenn also auch das fehlschlägt) einen CLI zu bemühen. Zumindest aber würde ich erwarten, daß der WarmStart per ResetTaster funzt (und nicht ein KaltStart nötig ist).
Übrigens, wenn schon eine Beendigung von MiNT nötig ist, könnte man dann nicht wenigstens drei Sekunden spendieren, damit die letzten Bildschirm-Meldungen noch gelesen werden können? (ie. eine kleine WarteSchleife in den TermVec einbauen). Oder wenigstens alles nach mint.log schreiben (und den sauber schließen!).

Man kann nicht ein gecrashtes System mit anderen Parametern weiterlaufen lassen, man sollte dann sich so schnell wie möglich verabschieden. Schon gar nicht mit GEM=ROM nochmal anfangen, sehe ich jedenfalls nicht.

Wer sagt, dass noch irgendein Vektor angesprungen wird?

Leider kann das boot.log erst geöffnet werden, wenn die Filesystem-Initialisierung fertig ist, sonst klappt das mit der Umlenkung nicht.

So ein Fall, dass es vorher crasht, ist aber auch extrem selten glaube ich.

[ari.tao]

PraeScriptum: Die Seltenen, das sind die Wertvollen, so sagt man.

Ich werde wohl kaum XaAES für 1.18 verbreiten

Hätte ja sein können, daß es trotzdem mit 1.18 läuft?

gz ist vorgegeben, läuft alles script-gesteuert, sorry.

Dann solltet Ihr das Script ändern. Ich kann mich noch gut erinnern, wie mühsam es damals war, die nötigen Entpacker aufzutreiben, zu installieren & anzuwenden (iGgs. zu LHZ & ZIP). Kein Wunder, wenn das viele abschreckt. Nach den paar Monaten hier im Forum habe ich tatsächlich den Eindruck, daß ich einer von wenigen bin, die die Vorzüge von MiNT zu schätzen wissen. Und wenn ich sehe, wie mühsam es selbst für mich ist (mit meiner jahrzehntelangen Erfahrung in Sachen MiNT), auf eine neuere Version upzudaten, dann kann ich die anderen verstehen. Ein Installer (wie zB. EasyMiNT) ist da kaum eine Lösung, der erhöht ja eher die Komplexität des ganzen, als daß er sie mindert. Da müßte imho mal dringend a la Occam rasiert werden! Die ganze Malaise begann mit der Un*x-Suppe - ein MultiUser-System auf einem PersonalComputer produziert doch wohl multiple Persönlichkeiten... Ach, jetzt hab´ich mich aber in´s OffTopic verirrt.
-------

~~~~~~~~~~~~ XaAES start up ~~~~~~~~~~~~~~~~

war in XaAES_1.5.5 (warum werden eigtl- Version & Datum nicht in´s LogFile geschrieben?) noch nicht drin. Na, 1.18 ist wohl abgehakt (hatte ich schon erwähnt, daß der Reset-Knopf nach X) beim Rück-Wechsel nach f: zum Kaltstart führt?); werde mir jetzt vermehrt 1.19.cur ansehen. Von den beiden Links, die Du angegeben hast, habe ich diesen hier:    http://home.arcor.de/zabruder/atari/xamint14.zip
herunterladen können, der andere zeigt in´s Nirvana!
Auch  http://home.arcor.de/zabruder/atari/system/xaaes030.km.gz
ist geangelt. Tests demnächst.
-------

Kannst ja in mint.cnf exec rm xa_boot.log reinschreiben.

Gerne doch, wenn Du mir mal bitte den rm rüberschiebst. Ist nicht in meiner Sammlung.
Ach ja, ein tos.xfs könnte ich auch noch gebrauchen (dann liefe die TrueDisk vielleicht auch mit neuerem MiNT?).
-------

Also wenn XaAES startet ist der eigentliche boot-Prozess aber ziemlich weit...?

Darum geht es nicht, sondern: Wenn der bezogene Fehler früh genug bemerkt wird (ie. vor einem Schreib-Zugriff), dann besteht Hoffnung, daß man mit dem Schrecken davonkommt - andernfalls ist mit einiger Sicherheit einiges an Arbeit fällig (und uU. sogar das Plättle kaputt!).
-------

Wer sagt, dass noch irgendein Vektor angesprungen wird?

Wenn ein Prg., zB. XaAES, sich selber herunterfährt & beendet, dann doch wohl per pterm. Dann aber wird auch TermVec durchlaufen, und außerdem kann ein ErrorCode an das aufrufende Prg., zB. MiNT, zurückgegeben werden, also könnte zu SoloMiNT/SingleGEM anstatt zu TOS regrediert werden.
Wenn aber ein echter Crash auftritt (also eine ErrorException, zB. zwei Bömbchen), dann muß ein ErrorManager ran. Seit geraumer Weile hat MiNT afaik einen eigenen (und das ist grundsätzlich richtig so!); warum kriegt der keine ordentliche Fehler-Behandlung gebacken?! (zB. die erforderliche Pause!)

PS1: Lange bevor MiNT sich des Themas annahm, habe ich, aufbauend auf den M2.TDI-Quellen, meinen eigenen ErrorHandler gebaut. Wg. der Konkurrenz paßt er nun leider nicht mehr zu MiNT, funzt aber immer noch sehr gut unter TOS oder MAGX.
PS2: Occam´s razor: Entia non sunt multiplicanda praeter necessitatem!

[HelmutK]

PraeScriptum: Die Seltenen, das sind die Wertvollen, so sagt man.

Nehme mal an, das ist das von unten in deutsch?

gz ist vorgegeben, läuft alles script-gesteuert, sorry.

Dann solltet Ihr das Script ändern. Ich kann mich noch gut erinnern, wie mühsam es damals war, die
nötigen Entpacker aufzutreiben, zu installieren & anzuwenden (iGgs. zu LHZ & ZIP). Kein Wunder, wenn

Das ist meine Geschichte, die Sachen von freemint.org von Alan. Es gibt da kein "ihr". Wenn das wirklich so ein Problem ist, kann ich das nat. auch als zip hochladen, frag einfach noch mal.

das viele abschreckt. Nach den paar Monaten hier im Forum habe ich tatsächlich den Eindruck, daß ich einer von wenigen bin, die die Vorzüge von MiNT zu schätzen wissen. Und wenn ich sehe, wie mühsam

Du meinst wirklich  Du kannst mich da übertreffen?

es selbst für mich ist (mit meiner jahrzehntelangen Erfahrung in Sachen MiNT), auf eine neuere Version upzudaten, dann kann ich die anderen verstehen. Ein Installer (wie zB. EasyMiNT) ist da kaum eine Lösung, der erhöht ja eher die Komplexität des ganzen, als daß er sie mindert. Da müßte imho mal dringend a la Occam rasiert werden! Die ganze Malaise begann mit der Un*x-Suppe - ein MultiUser-System auf einem PersonalComputer produziert doch wohl multiple Persönlichkeiten... Ach, jetzt hab´ich mich aber in´s OffTopic verirrt.

Diesen EasyMiNT-hype hab ich nie verstanden. So schwer ist ja nun auch nicht, sich das zu kopieren. Naja..

Interessant dieser Herr Ockham

-------

~~~~~~~~~~~~ XaAES start up ~~~~~~~~~~~~~~~~

war in XaAES_1.5.5 (warum werden eigtl- Version & Datum nicht in´s LogFile geschrieben?) noch nicht drin. Na, 1.18 ist wohl abgehakt (hatte ich schon erwähnt, daß der Reset-Knopf nach X) beim Rück-

Wird doch:

XaAES v1.8.4 Beta (m68040, Sep 16 2016 13:38) (MultiTasking AES for MiNT)

Wechsel nach f: zum Kaltstart führt?); werde mir jetzt vermehrt 1.19.cur ansehen. Von den beiden Links, die Du angegeben hast, habe ich diesen hier:    http://home.arcor.de/zabruder/atari/xamint14.zip
herunterladen können, der andere zeigt in´s Nirvana!
Auch  http://home.arcor.de/zabruder/atari/system/xaaes030.km.gz
ist geangelt. Tests demnächst.

Und der: http://www.freemint.org/builds/freemint?
Tests sind immer wichtig, aber wenn MiNT 1.19 schon nicht bootet mit BlowUp, wird das wohl nicht viel bringen. Ich hab gestern mal auf aranym und hatari bisschen mit BlowUp experimentiert, ohne Erfolg, ist mir jetzt auch zu viel Gerödel. Auf hatari läuft das setup nicht, auf TOS2.6, schmeißt es 2 Bomben, auf XaAES kommt eine Fehlermeldung wg. 0-Pointer im rsc, aber sonst läuft es immerhin irgendwie. Nach dem Start des Auto-Programms von MiNT aus hängt alles (Neustart).

Letztlich musst Du wohl selbst nach der Ursache suchen. MiNT ist schließlich keine Firma
Also Sourcen runterladen, kompilieren, usw. Steht hier: http://wiki.sparemint.org/index.php/How_to_contribute

-------

Kannst ja in mint.cnf exec rm xa_boot.log reinschreiben.

Gerne doch, wenn Du mir mal bitte den rm rüberschiebst. Ist nicht in meiner Sammlung.
Ach ja, ein tos.xfs könnte ich auch noch gebrauchen (dann liefe die TrueDisk vielleicht auch mit neuerem MiNT?).

http://home.arcor.de/zabruder/atari/rm.zip

Du brauchst aber letztlich einiges von dem Unix-Kram von hier:

http://gentoo.atariforge.org/files/

tos.xfs gibt's nicht, das ist eingebaut.

-------

Also wenn XaAES startet ist der eigentliche boot-Prozess aber ziemlich weit...?

Darum geht es nicht, sondern: Wenn der bezogene Fehler früh genug bemerkt wird (ie. vor einem Schreib-Zugriff), dann besteht Hoffnung, daß man mit dem Schrecken davonkommt - andernfalls ist mit einiger Sicherheit einiges an Arbeit fällig (und uU. sogar das Plättle kaputt!).

Ich hab ja immer INIT=/bin/ksh und starte XaAES dann von da.

-------

Wer sagt, dass noch irgendein Vektor angesprungen wird?

Wenn ein Prg., zB. XaAES, sich selber herunterfährt & beendet, dann doch wohl per pterm. Dann aber wird auch TermVec durchlaufen, und außerdem kann ein ErrorCode an das aufrufende Prg., zB. MiNT, zurückgegeben werden, also könnte zu SoloMiNT/SingleGEM anstatt zu TOS regrediert werden.
Wenn aber ein echter Crash auftritt (also eine ErrorException, zB. zwei Bömbchen), dann muß ein ErrorManager ran. Seit geraumer Weile hat MiNT afaik einen eigenen (und das ist grundsätzlich richtig so!); warum kriegt der keine ordentliche Fehler-Behandlung gebacken?! (zB. die erforderliche Pause!)

Wenn XaAES sich nach einem Fehler sauber beenden kann, kommt von xaloader die Abfrage nach /bin/sh. Mehr ist nicht drin. Wenn MiNT beim booten Probleme bekommt, kommt die MiNT-interne shell. Wenn's crasht, ist nichts garantiert.

[ari.tao]

-^^- Wohl wahr; aber nach einem Crash geht es noch um zwei Dinge, nämlich evtl. Arbeit zu retten, sowie noch möglichst viel Info über die Crash-Ursache zu erfahren - da geht noch viel, auch mit einem korrupten System, wenn man sich darauf beschränkt! Vielleicht sollte ich mal meinen ErrorHandler in´s Forum stellen ? (Wie gesagt, derzeit gut für TOS & MAGX, aber leider nicht für MiNT).
-------
Danke @HelmutK , für die vielen Links. Auch hier:
   http://vincent.riviere.free.fr/soft/m68k-atari-mint/
gibt es noch viel interessantes zum Thema.
Leider kriege ich beim Anblick von C-Code Pickel (bin halt M2-Freak  ); da müßte mir schon einer ne komplette Entwicklungs-Umgebung auf den Falcon zaubern und mich life einweisen, eh ich da anbeiße... (Habe noch so viele andere offene Baustellen). Im Moment sehe ich meinen Beitrag eher beim Testen. Mein Interesse an 1-18-0/1-19-0 ist eher auf die Zukunft gerichtet (auf F30 & TT bin ich ja mit 1-15-9 sehr zufrieden).
Danke auch für rm, funzt in mint.cnf (aber nicht in xaaes.cnf); gibt´s Doku dazu?
-------

Es gibt da kein "ihr".

Schade. Aber kannst ´Ihr´ ja als pluralis majestatis lesen  .
Ich blicke da noch nicht überall durch, wer hier im Forum wo engagiert ist...
Vielleicht kannst Du Anregungen weitergeben? oder vielleicht liest ja jmd. mit.
-------
Beim Entpacken der .BZ2s bin ich gescheitert . Zwar habe ich bunzip2.ttp (und damit früher auch schon Erfolg gehabt), aber bei den dicken Klöpsen beschwehrt es sich über zu wenig Speicher (obwohl mein TT 32MB hat - keine Ahnung, woran das liegt). Ein .ZIP wäre hilfreich, den kann ich auf der Lab-Dose auspacken (so habe ich das mit 1-18-0 gemacht). LangNamen sind auch nicht so gut.
Die .GZs habe ich entpacken können, die waren klein genug.
-------

...auf TOS2.6...

... kann BlowUp nicht laufen - es ist nur für den Falcon!! Hast Du schon Hatari_2.0 installiert? Kann der jetzt ´Falcon´? Dann wird der auch für mich interessant.

tos.xfs gibt's nicht, das ist eingebaut.

Wirklich? Wie komme ich da dran? NEWFATFS ist default! Gibt´s etwa ein OLDFATFS ?

Ich hab ja immer INIT=/bin/ksh und starte XaAES dann von da.

Würde ich ja gerne mal versuchen - aber siehe unten, und oben C).
Ich habe nur sh, kein ksh.
-------
Die Ergebnisse meiner neuesten Tests waren eher frustrierend . Unter XaAES habe ich offensichtlich das falsche moose.adi; Logs &c. -> Anhänge. Ansonsten das gleiche wie schon mit 1-18-0 - außer, daß überhaupt keine Tastatur-Eingabe geht; da ist offenbar noch mehr falsch. Reset macht in 1-19-cur _nur_noch_Kaltstart_. Das finde ich gar nicht mehr lustig ! Wenn man, wie ich, zwischen den Welten springen will/muß (von NAES zu TOS zu MAGX zu... und zurück) ist das eine große Arbeits-Erschwernis!

PS: Übersetzung des dem Schotten Occam zugeschriebenen lateinischen Zitats:
Die Dinge dürfen nicht vermehrt werden, außer wenn es notwendig ist.

[mfro]

...auf TOS2.6...

... kann BlowUp nicht laufen - es ist nur für den Falcon!! Hast Du schon Hatari_2.0 installiert? Kann der jetzt ´Falcon´? Dann wird der auch für mich interessant.

BlowUp läuft auf dem neuen Hatari. Und funktioniert sogar - meistens.