Software > Alternative Betriebssysteme
Reboot bei MiNT
ari.tao:
So, jetzt habe ich mal dieses Teil
--- Zitat --- http://home.arcor.de/zabruder/atari/system/mint030.prg.gz
--- Ende Zitat ---
in den trunk_1-19-cur eingesetzt:
Gratuliere, @HelmutK 8)! 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:
--- Zitat ---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!
--- Ende Zitat ---
Mir völlig unverständlich: wenn überhaupt, dann sollte es umgekehrt sein: mit meinem kernel geht die Tastatur!
--- Zitat ---
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!
--- Ende Zitat ---
Dann wären also in XaAES keine Änderungen mehr nötig?
--- Zitat ---
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
--- Ende Zitat ---
sysinfo sollte laufen. Memory-violation kommt nur wenn memory-protection an ist (->mint.ini).
--- Zitat ---
PS1: Leider hast Du, @HelmutK , beim Einzippen alle TimeStamps aktualisiert. Bitte noch mal erneuern, mit den orig. TimeStamps!
--- Ende Zitat ---
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?
--- Zitat ---
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]
--- Ende Zitat ---
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. >:D
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. ::)
-------
--- Zitat ---Dann wären also in XaAES keine Änderungen mehr nötig?
--- Ende Zitat ---
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.
-------
--- Zitat ---TOS-FS ... Ist das wichtig?
--- Ende Zitat ---
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?! :-X :P
-------
--- Zitat ---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 ...
--- Ende Zitat ---
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:
--- Zitat von: ari.tao am Mo 14.11.2016, 01:26:03 ---Eine Möglichkeit, die BootMeldungen während der AUTO\-Phase zu loggen, habe ich nicht :(. Das gibt´s mW. nur rudimentär unter MAGX.
--- Ende Zitat ---
Es gibt das Programm Automore von Thomas Binder:
http://archive.3rz.org/MAUS-OEPT/FR/st/AUTOMRR6.LZH
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln