Software > Alternative Betriebssysteme
Reboot bei MiNT
HelmutK:
--- Zitat ---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)
--- Ende Zitat ---
Das würde aber Speicher kosten. Außerdem optimiert der Compiler für den jew. Prozessor.
--- Zitat ---
-------
@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.
--- Ende Zitat ---
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
--- 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.
--- Ende Zitat ---
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:
--- Zitat --- Das würde aber Speicher kosten. Außerdem optimiert der Compiler...
--- Ende Zitat ---
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:
--- Zitat von: ari.tao am Sa 05.11.2016, 12:43:12 ---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_
--- Ende Zitat ---
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.
--- Zitat ---
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);
--- Ende Zitat ---
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
--- Zitat ---
PS1: Daß man xaaes.log vor jedem Neustart von Hand löschen muß, ist etwas lästig.
--- Ende Zitat ---
Ich will aber die Historie. Ich lösche es dann einmal die Woche.
--- Zitat ---
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.
--- Ende Zitat ---
Ja, das könnte man verbessern. Diese Diskussion kenne ich allerdings nicht.
--- Zitat ---
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.
--- Ende Zitat ---
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.
-------
--- Zitat ---War die horizontale Auflösung zufällig 1024 und 640?
--- Ende Zitat ---
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
--- Zitat ---http://home.arcor.de/zabruder/atari/system/xaaes030.km.gz
--- Ende Zitat ---
für 1.18.0 oder für einen Deiner Kernels?
(Btw. wären .ZIPs für mich bequemer als .GZs).
-------
--- Zitat ---Ich will aber die Historie. Ich lösche es dann einmal die Woche.
--- Ende Zitat ---
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!).
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln