Reboot bei MiNT

[HelmutK]

Kannst Du mal diesen experimentellen kernel testen?

http://home.arcor.de/zabruder/atari/system/mint030.prg.gz

Der stürzt jedenfalls mit hatari 2.0 nicht mehr ab.

Wenn er nicht läuft: nochmal starten mit StepbyStep, und dann erzählen, bitte.

[ari.tao]

Kommt ja, kommt ja - aber im Moment bin ich zum umfallen müde, also a kleins bissle Geduld bitte! Habe viel zu erzählen.
Bis später also.

[ari.tao]

Hatha der Stand der Dinge:
Zunächst mal zu dem "kleinen bisschen, das sich geändert hat":
Mit dem trunk_1-19-cur ging die Tastatur plötzlich wieder - und zwar richtig, nicht bloß mit Macken wie oben mit 1-18-0 - aber das nur im Fall X) (also für XaAES_1.8.4) - in den anderen Fällen geht die Tastatur überhaupt nicht! ^*
Auf diese Weise ermutigt, hatte ich die Intuition, video ganz wegzulassen (das war früher mit 1-18-0 ein Mißerfolg, so.); dann sollte lt. Doku als Default video = 1 eingesetzt werden.
Zu meiner Verblüffung gab es stattdessen video = 0, und, oh Wunder: 1024x768x1 - da hat nun also zum ersten Mal BlowUp mit XaAES zusammengearbeitet!
Das weitere war einfach: Mit Video aus {0-4} erscheinen alle 5 Auflösungen von BlowUp!
Leider ist das alles, wie früher, nur mit dem Warmstart-Trick möglich. Bei Kaltstart die gewohnten Abstürze von MiNT. Und noch ein Wermutstropfen: Sehr viele (aber nicht alle) altbewährte APPs stürzen ab mit Mem.-Violation (´private´ nicht beachtet), zB. Kobold oder SysInfo. Da aber Memory protection abgeschaltet ist (oder irre ich mich da?), dürfte das doch gar nicht gemeldet werden!!
LOGs -> Anhänge. 4p-xaaes.gif = Snapshot mit 16 Farben, hi-xaaes.img.pf = Snapshot in hi-Color (habe leider keinen GIF-Konverter dafür); 4p-naes.gif = Snapshot von 1-19-cur + NAES2 + TeraDesk als Bsp. für die Konfigs. _ohne _Tastatur_!

Dann habe ich mal ganz frech mein altes AUTO\ benutzt (ie. mit NVDI und allem pipapo):
Gleiches Resultat!

Nun werde ich mich mal dem Helmut-Build zuwenden.

Edit.: Fehler ^* korrigiert!

PS1: Leider hast Du, @HelmutK , beim Einzippen alle TimeStamps aktualisiert. Bitte noch mal erneuern, mit den orig. TimeStamps!
PS2: Wie xctrl da hineingeraten ist, das ist mir völlig unklar. Das wird bei mir normalerweise gar nicht als ACC mitgebootet, sondern bei Bedarf nachgeladen.
PS3: Das boot.log von MiNT sollte doch wohl besser im sysdir erscheinen und nicht im c:\mint\; außerdem wäre es gut, wenn die Version im Namen erschiene, Vorschlag: mb119c.log (dann sind noch 2 Lettern frei zum durchnumerieren; letzteres gilt auch für xa_boot.log, Vorschlag: xb184b.log !

[mfro]

... Da aber Memory protection abgeschaltet ist (oder irre ich mich da?), dürfte das doch gar nicht gemeldet werden!!

Memory protection ist nur abgeschaltet, wenn das in mint.ini so steht (MEM_PROT=NO). Wie das binary heißt, ist MiNT neuerdings egal.

[ari.tao]

Ah, das hatte ich mal so dahinein geschrieben - muß unterwegs verlorengegangen sein. Danke.

[ari.tao]

So, jetzt habe ich mal dieses Teil

http://home.arcor.de/zabruder/atari/system/mint030.prg.gz 

in den trunk_1-19-cur eingesetzt:
Gratuliere, @HelmutK  ! Der Kaltstart geht für X) (die andern hab ich noch nicht getestet) und der Reset mit Wechsel zu einer andern Partition & Wiederherstellung der Trude geht auch wieder !! Was hast Du geändert? Woher stammt dieser Kernel?
Hat dieser Kernel auch noch das TOS-FS ??

[HelmutK]

Bei Verwendung einer Grafikkarte darf der Bildschirmspeicher nicht verschoben werden. Du hast zwar keine GK, aber ich nehme an, BlowUp hat ähnliche Bedürfnisse. Der Bildschirmspeicher wird also in diesem kernel nicht verschoben. Da crasht es auch in hatari 2.0, das dürfte aber ein Fehler in hatari sein.

Aber irgendwie auch Glück, also dank an hatari.

Jetzt brauch ich von Dir den Inhalt von /kern/cookiejar, und wenn's geht, die ganzen Bildschirmausgaben, die jetzt beim booten kommen.

TOS-FS ist nur im 000-kernel. Ist das wichtig?

Wenn ich eine Lösung hab, kommt die ins CVS, und dann kannst Du ja vielleicht den 000-kernel nehmen.

[HelmutK]

Mit dem trunk_1-19-cur ging die Tastatur plötzlich wieder - und zwar richtig, nicht bloß mit Macken wie oben mit 1-18-0 - aber das nur im Fall X) (also für XaAES_1.8.4) - in den anderen Fällen geht die Tastatur überhaupt nicht!

Mir völlig unverständlich: wenn überhaupt, dann sollte es umgekehrt sein: mit meinem kernel geht die Tastatur!

Auf diese Weise ermutigt, hatte ich die Intuition, video ganz wegzulassen (das war früher mit 1-18-0 ein Mißerfolg, so.); dann sollte lt. Doku als Default video = 1 eingesetzt werden.
Zu meiner Verblüffung gab es stattdessen video = 0, und, oh Wunder: 1024x768x1 - da hat nun also zum ersten Mal BlowUp mit XaAES zusammengearbeitet!
Das weitere war einfach: Mit Video aus {0-4} erscheinen alle 5 Auflösungen von BlowUp!

Dann wären also in XaAES keine Änderungen mehr nötig?

Leider ist das alles, wie früher, nur mit dem Warmstart-Trick möglich. Bei Kaltstart die gewohnten Abstürze von MiNT. Und noch ein Wermutstropfen: Sehr viele (aber nicht alle) altbewährte APPs stürzen ab mit Mem.-Violation (´private´ nicht beachtet), zB. Kobold oder SysInfo. Da aber Memory

sysinfo sollte laufen. Memory-violation kommt nur wenn memory-protection an ist (->mint.ini).

PS1: Leider hast Du, @HelmutK , beim Einzippen alle TimeStamps aktualisiert. Bitte noch mal erneuern, mit den orig. TimeStamps!

Die Zeiten bleiben erhalten:
unzip -v helmut-20092016
Archive:  helmut-20092016.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       0  Stored        0   0% 09-20-2016 02:08 00000000  auto/
  333087  Defl:X   175229  47% 09-20-2016 02:08 bb687108  auto/mint000.prg
  334456  Defl:X   177498  47% 09-20-2016 02:08 96b96e77  auto/mint020.prg
...

Oder was meinst Du?

PS3: Das boot.log von MiNT sollte doch wohl besser im sysdir erscheinen und nicht im c:\mint\; außerdem wäre es gut, wenn die Version im Namen erschiene, Vorschlag: mb119c.log (dann sind noch 2 Lettern frei zum durchnumerieren; letzteres gilt auch für xa_boot.log, Vorschlag: xb184b.log !
[/size]

Das ist Absicht: Ich will nicht 20 logfiles überall rumfliegen haben, so weiß ich immer wo es ist. Es wird übrigens immer ein backup (boot.loh) angelegt vorher.

[ari.tao]

-^^- Und _ich_ will nicht, daß so etwas irgendwo in die Walachei geschrieben wird, und schon gar nicht auf meine hl. System-Partition  ! So was muß Objekt-orientiert platziert werden, also nahe am ´Tatort´! Such Dir bitte ein anderes Plätzchen dafür, Vorschlag: SYSDIR$DOKU\ (da will ich das sowieso haben) oder, noch besser, laß bitte den Anwender auswählen, wo es hin soll!
Meine Ataris sind als Entwickler-Maschinen eingerichtet, das bedeutet: Getrimmt auf maximale Sicherheit bei größtmöglicher Flexibilität und schnellstmöglichem Turnaround. Ein jeder Test ist immer auch ohne zusätzliche Hürden schon Arbeit genug.
Für boot.loh besteht keine Notwendigkeit. Wegrasieren  .
-------
Ad TimeStamps: In jedem Deiner .ZIPs haben alle Files & Folders das gleiche, aktualisierte Datum . Das ist nicht gut! Die orig. Data müssen beim Einpacken erhalten bleiben! Sonst ist es später mühsam, Änderungen zu erkennen.
-------
Ad MEM_PROT: Das hatte ich mit mfro schon geklärt. Läuft alles wieder.
-------

Dann wären also in XaAES keine Änderungen mehr nötig?

Doch, doch - aber nicht für _den_ Bug, der jetzt erledigt ist.
-------
Ad Tastatur: Sorry, war wohl mein Fehler ; vmtl. habe ich nochmals aus Versehen den kaputten Kernel erwischt. Die Wiederholung der Tests ergab: 2), S) und sogar auch C) funzen jetzt! Ohne die bekannten Tastatur-Macken! Mit M) und G) gibt´s noch Probleme: In MTOS das auch schon früher aufgetretene mit dem Überlauf des TastaturBuffers, dagegen Geneva findet sein JAR30 nicht; bzgl. letzterem habe ich zwar einen Verdacht, vermag ihn aber noch nicht festzunageln.
-------

TOS-FS ... Ist das wichtig?

Ja! Hab´ich doch oben schon mal erläutert.
Wenn ich die TruDi auch hier wieder in Gang kriege (zur Erinnerung: Die ist System-übergreifend Reset-fest!), dann fehlt wohl nur noch ein letzter Baustein, dann habe ich meine gewohnte ArbeitsUmgebung auch mit XaAES beisammen . Dieser letzte Baustein ist der AuflösungsWechsel. Danach könnte man sich mal die Macken in XaAES ansehen.
-------
Ad u:\kern\cookiejar : Dessen Inhalt bleibt leider verborgen. Wenn man in kern\ doppelklickt, dann gibt´s zwar keinen Absturz mehr (wie bei früheren MiNTzen üblich) und auch keine Meldung ´falscher AES-Aufruf´ (wie mit 1-15-9 plus NAES2 üblich), aber es geschieht einfach - nichts.
Es wäre übrigens nett, wenn die Namen in kern\ nach GEMDOS-Regeln vergeben wären! (Nebenfrage: Kann man u: exklusiv (ich meine: als einziges LW) für LangNamen anmelden?)
Da ich nicht weiß , ob Dir mehr an der Funktion von kern\ gelegen ist oder mehr am Inhalt des CookieJar, habe ich Dir des letzteren Inhalt (und etwas mehr) in eine Datei gepackt (-> Anhang BIOX.OUT) und auch gleich noch die Tööle, mit der das hergestellt ist (-> BIOX.ZIP); 8ung, BIOX.TOS ist ein archaisches Ding, braucht ab & zu einen Tastendruck und scheint zum Schluß zu hängen - dem ist aber nicht so, Geduld! Gebrauch auf eigenes Risiko.
Eine Möglichkeit, die BootMeldungen während der AUTO\-Phase zu loggen, habe ich nicht . Das gibt´s mW. nur rudimentär unter MAGX. Du willst wohl alle meine Geheimnisse auf einmal wissen?!
-------

Bei Verwendung einer Grafikkarte darf der Bildschirmspeicher nicht verschoben werden. Du hast zwar keine GK, aber ich nehme an, BlowUp hat ähnliche Bedürfnisse. Der Bildschirmspeicher wird also in diesem kernel nicht verschoben. Da crasht es auch in hatari 2.0 ...

Den Verdacht hatte ich von Anfang an. Vermutlich haben noch weitere Kandidaten ähnliche Bedürfnisse: RamDisks (einschl. TruDi), TOS_loader, vielleicht sogar Geneva...

PS1: Zum Schreibstil: Zitierungen sparsam verwenden! Mit Occam rasieren!
PS2: Jedes Mal .TXT, .ZIP &c. durch .pdf kaschieren zu müssen, ist doch recht lästig. Ob wir @Johannes  bewegen könnten, die Liste der Dateitypen a weng zu erweitern?

[KarlMüller]

Eine Möglichkeit, die BootMeldungen während der AUTO\-Phase zu loggen, habe ich nicht . Das gibt´s mW. nur rudimentär unter MAGX.

Es gibt das Programm Automore von Thomas Binder:
http://archive.3rz.org/MAUS-OEPT/FR/st/AUTOMRR6.LZH

[HelmutK]

-^^- Und _ich_ will nicht, daß so etwas irgendwo in die Walachei geschrieben wird, und schon gar nicht auf meine hl. System-Partition  ! So was muß Objekt-orientiert platziert werden, also nahe am

Eben darum ist es so wie es ist.

´Tatort´! Such Dir bitte ein anderes Plätzchen dafür, Vorschlag: SYSDIR$DOKU\ (da will ich das

Nö, warum? Und was bitteschön soll SYSDIR$DOKU\  sein?

sowieso haben) oder, noch besser, laß bitte den Anwender auswählen, wo es hin soll!
Meine Ataris sind als Entwickler-Maschinen eingerichtet, das bedeutet: Getrimmt auf maximale Sicherheit bei größtmöglicher Flexibilität und schnellstmöglichem Turnaround. Ein jeder Test ist immer auch ohne zusätzliche Hürden schon Arbeit genug.
Für boot.loh besteht keine Notwendigkeit. Wegrasieren  .

Na was Du alles weist! Ts ...
Wenn Dir der Ort der boot.log nicht passt, kannst Du ja einen symlink zu einer Dir genehmen Stelle anlegen (weiß nicht ob das geht). Oder einen patch an die MiNT-mailing-Liste schicken, vielleicht wird der ja akzeptiert. Oder einen Computer nehmen, der Dateien sicher abspeichern kann.

-------
Ad TimeStamps: In jedem Deiner .ZIPs haben alle Files & Folders das gleiche, aktualisierte Datum . Das ist nicht gut! Die orig. Data müssen beim Einpacken erhalten bleiben! Sonst ist es später mühsam, Änderungen zu erkennen.

Das sind genau die Zeiten aus dem tar-Archiv. Was bringt Dich zu der Unterstellung, ich hätte da irgendwas verändert? Und welche Zeiten hättest Du gerne?

-------

TOS-FS ... Ist das wichtig?

Ja! Hab´ich doch oben schon mal erläutert.
Wenn ich die TruDi auch hier wieder in Gang kriege (zur Erinnerung: Die ist System-übergreifend

Wie gesagt: Dann könnte der 000-kernel gehen, wenn alles im CVS ist.

Reset-fest![/b]), dann fehlt wohl nur noch ein letzter Baustein, dann habe ich meine gewohnte ArbeitsUmgebung auch mit XaAES beisammen . Dieser letzte Baustein ist der AuflösungsWechsel. Danach könnte man sich mal die Macken in XaAES ansehen.

Auflösungswechsel wird von XaAES nicht unterstützt.

-------
Es wäre übrigens nett, wenn die Namen in kern\ nach GEMDOS-Regeln vergeben wären!

Was für GEMDOS-Regeln? Das orientiert sich ohnehin an Unix, so dass davon möglichst viel läuft.

(Nebenfrage: Kann man u: exklusiv (ich meine: als einziges LW) für LangNamen anmelden?)

Keine Ahnung was Du meinst, u: ist kein Laufwerk, sondern root sozusagen.

PS1: Zum Schreibstil: Zitierungen sparsam verwenden! Mit Occam rasieren!

Mein Zitierstil ist vorbildlich. Ich darf mal zitieren:

Dein Zitierstil ist aber sehr vorbildlich!

[HelmutK]

Ich seh gerade: Das boot.log wird immer nach C: geschrieben. Das ist natürlich ein Fehler, und wird demnächst behoben.

[ari.tao]

-^^- Ah, danke. Nach Rückkehr zur Sachlichkeit kann ich ja Deine obige Polemik jetzt ignorieren und hoffen, daß Du auch die anderen Argumente etwas ernster nimmst.
Zum Stil: Mit Humor, Ironie und mitunter sogar Zynik kann ich umgehen, nur bei Polemik habe ich eine empfindliche Seele. Und nochmal zum Stil (->Beitrag #61 von Gaga):
   http://forum.atari-home.de/index.php?topic=9655.60
Und ein letztes Mal zum Stil: "Le style est le homme meme" (oder so ähnlich, bin nicht gut im Frz. und weiß leider auch nicht, wer´s gesagt hat ).
-------
Üblicherweise wird u: als Pseudo-LW bezeichnet, denn man kann es mit einem Dir.-Fenster öffnen und weiter in darin befindliche Objekte verzweigen. Wenn ich so kern\ öffne, dann erscheinen darin Namen, zB. cookiejar, buildinfo oder filesystems, die nicht a la GEMDOS dem 8+3-Schema unterliegen. Vielleicht ist das ja schon der Grund, warum man sie (zumindest ohne den ´Langnamen.Zusatz´) nicht öffnen kann?! Allerdings, auch die in kern\ versammelten Objekte mit kürzeren Namen lassen sich nicht öffnen  .
Die Un*x-Suppe ist eine Plage, ein Bärendienst für einen PersonalComputer!
-------

  Auflösungswechsel wird von XaAES nicht unterstützt.

Das ist doch wohl hoffentlich nur vorübergehend?! 
-------

Was bringt Dich zu der Unterstellung, ich hätte da irgendwas verändert?   

Ich unterstelle gar nix; die TimeStamps sind ja nachprüfbar; und wenn Du sie schon so übernommen hast - um so schlimmer! (wenn auch nicht unbedingt für Dich).

Und welche Zeiten hättest Du gerne? 

Die Zeiten der Entstehung/Herstellung selbstverständlich.
Edit.: Gemeint ist: Bei jedem einzelnen File das Datum der letzten _inhaltlichen_ Änderung.
-------
Den Anfang von #110 ignorier ´ ich mal.

Intermediäres Scriptum:
   Dich soll´n die Kakerlaken
       fest in die Waderln zwaacken,
            wenn Du mein flähentliches Sähnen nicht erhäören tust!
-------

Es gibt das Programm Automore von Thomas Binder

Das habe ich - aus anderen Gründen - schon selbst hier im Forum empfohlen für Leute, die bisher noch keinen Batcher im AUTO\ haben. (Allerdings war die letzte Version afaik die Nr. 7 vom 13.06.99, nicht die Nr. 6 vom 18.06.97). Ich selber benutze lieber den MCMD (v2.59 vom 22.06.90 (sic!)) von AK (lag früher MAGX bei); der kann zwar io-Umleitung für jedes aufgerufene Prg., aber leider kein Protokoll - dafür kann er andere Dinge, die AutoMore nicht kann, zB. kann er bedingte Sprünge und hat drei BATch-Stufen und hat ein spezielles Verhalten im AUTO\, das die (leider nur implizite) Unterscheidung erlaubt, ob auf einem F30 oder anderswo gebootet wurde. Damit habe ich mein Plättle mit acht bootbaren Parts mit unterschiedlichen Systemen so eingerichtet, daß ich problemlos damit sowohl vom Falcon als auch vom TT und auch von fast allen anderen ´echten´ Ataris booten kann: Wenn mir irgendein Atari zugeflogen kommt (mit TOS >= 1.4), dann CardReader (Yamaha) dran (evtl. via LINK97), und los geht´s! Mindestens eine von den achten tut´s immer! Ich kann aber niemandem empfehlen, das nachzumachen, nicht einmal den ´Profis´: Aufwand & Komplexität! Mein ´Fuhrpark´ hat eine dementsprechend opulente Innenausstattung.
Deshalb habe ich die og. Tests {2, M, S, C, G, X} auch zunächst nur  mit einem extra eingerichteten ´mageren´ AUTO\ gemacht, das lediglich zwei Prge. enthält, nämlich BlowUp + MiNT. Dafür einen Logfile zu schreiben, kenne ich nun wirklich keine sinnvolle Möglichkeit. MiNT kann ja ´intern´ seinen eigenen, es ginge also nur um die trivialen Start-Meldungen der genannten zwei Prge., die aber imho völlig uninteressant sind.

Wenn mir die Start-Meldungen beim Booten zu schnell über den Bildschirm huschen, füge ich an geeigneter Stelle einen Aufruf meines Break.PRG ein (-> Anhang; Benutzung auf eigenes Risiko!) - das bleibt einfach in einer WarteSchleife bis daß keine StatusTaste mehr aktiv ist (zB. CapsLock). Das geht grundsätzlich auch in MiNT.cnf (per exec) oder in xaaes.cnf (per run); leider aber nicht mehr, wenn ein Abbruch oder gar Absturz passiert (der ja auch in einem LogFile (-> MiNT!) nicht mehr sichtbar wird).
-------
PS: Humor ist, wenn man trotzdem lacht.

[HelmutK]

Äh, der für mich wichtigste Grund, weiter mit Dir zu kommunizieren ist, dass ich meinen Umgang mit Trollen optimieren will.

Ansonsten kannst Du wohl froh sein, dass ich mich mit Deinen Problemen überhaupt beschäftige, mir ist das fast egal, ob MiNT auf einem anderem als meinen Rechnern läuft. Ich bin da für nichts in irgendeiner Weise verantwortlich oder so. Das ist Open Source!

Du könntest also etwas mehr Respekt demonstrieren.

Wie soll ich denn wissen, wann irgendeine Datei in irgendeinem Archiv inhaltlich verändert wurde, und wie soll ich die Zeiten da alle setzen. Denk doch erst mal bevor Du was postest, wenn möglich. Ich wollte Dir mit den zips einen Gefallen tun, und werde nur angepisst!

Usw.

[Arthur]

Bleibt locker... bisher waren es doch interessante und konstruktive Beiträge.

[ari.tao]

Habe dieser Tage wenig Zeit.
Werde aber noch antworten, demnächst.

[ari.tao]

Edit: Beitrag vorläufig wieder gelöscht.
-------
PS: Einen Yogi kann man nicht beleidigen (es sei denn, der will das so).

[mfro]

@ari.tao : falls dein Ziel war, @HelmutK von weiterer Hilfe abzuhalten, hast Du genau den richtigen Ton gefunden, denke ich.

Gratuliere!