MiNT+BlowUP

[HelmutK]

So - neuer Thread!

Das dürfte es sein:

  BLOW :    C6B28H      813864

Es hätte wahrscheinlich

cp /kern/cookiejar cookie.txt

gereicht.

Dann werde ich das mal demnächst angehen.

Kannst Du kein Foto vom Bildschirm machen beim booten (step-by-step)?

Wenn da noch andere Programme Probleme mit der Bildschirmverschiebung haben, die aber erst nach MiNT gestartet werden: Erstmal Pech! Sonst bräuchte man dafür eine neue Konfigurations-variable in mint.ini. Aber Du kannst das ja jetzt schön mit dem Test-kernel testen.

[ari.tao]

Das hat man gerne, erst frech werden - & dann gleich neue Aufträge verteilen! Knurrr. Und ein Link auf die Vergangenheit wäre wohl auch angebracht:
   http://forum.atari-home.de/index.php?topic=13120.100#lastPost
Wenn der Viewer nicht mit kern\ funzt, warum sollte dann cp gehen?!
Fotos sind aufwändig. Lieber schreib´ ich Dir den einzelnen Step ab, der Dich interessiert - aber, warum steht denn nicht die gesamte BildschirmAusgabe auch in MiNTs boot.log?!
Ich dachte, BlowUp funzt doch jetzt mit Deinem neuen Kernel - was gibt´s denn noch zu tun? Was bedeutet denn:
     "Das dürfte es sein:  BLOW :    C6B28H      813864 " ?
Daß es zw. Bildspeicher & RamDisk immer ein Gerangel um den besten Platz gab, das weiß ich noch aus uralten Zeiten (als CB sein ´Scheibenkleister´ schrieb). RamDisks & TOSloader (zB. GEMRAM) werden _vor_ MiNT gestartet!

PS: Nach MiNT die Sintflut! (Zitiert frei nach Mme. Pompadur)

[tuxie]

Soll nur eine Anmerkung sein, wenn man vom Kernel aus etwas Speichern möchte, nicht cp oder so verwenden sondern cat

cat /kern/cookiejar >> /u/c/blowup.txt

ausgaben vom kernel haben meist keinen Dateianfang und kein dateiende, daher kommt hier cat zum einsatz. Vielleicht hilft das ja.

[ari.tao]

Danke, @tuxie!
Ich habe zwar nicht Deinen Rat befolgt, aber er hat die entscheidende Idee gezündet:
Per Drag & Drop u:\kern\cookiejar in ein normales Verzeichnis gezogen erzeugt eine Kopie cookieja - und die kann ganz normal im Viewer angeschaut werden.
Da steht nun ua. drin:
      0x424C4F57   (BLOW):    0x000C6B28
Aber das ist ja schon bekannt?
Wenn aber das Kopieren geht - warum dann nicht das direkte Anschauen?!

[tuxie]

Da es keine Datei ist, sondern ein Stream. Und mit CAT kann man den Stream in eine Datei Speichern. Mal kann ihn sich auch mit

tail -f /kern/cookiejar anschauen.

[mfro]

das hat mit Stream oder nicht Stream nichts zu tun.

Je nach Desktop versucht der schlauer zu sein als das Betriebssystem. Das kernfs Filesystem erzeugt directory inodes mit "readonly" Dateiberechtigungen und 0 B Größe für das /kern Verzeichnis.

Bei mir (Teradesk) macht ein Doppelklick auf /kern/cookiejar (der so eingerichtet ist, daß er viewer.app startet) nichts vernünftiges (wahrscheinlich, weil viewer.app die Dateigröße auswertet), während ein direkter Aufruf von QED aus der bash-Shell mit cookiejar als Argument die Datei sauber öffnet (Drag & Drop auf das QED-Icon geht auch, habe ich gerade festgestellt).

[ari.tao]

Sach ich doch die janze Zeit, daß Drag´nDrop geht, aber DoppelKlick nich (mit Thing_1.29). Geht auch schon mit MiNT_1.15.9; all die Jahre hab´ich mich geärgert, daß ich den Inhalt von kern\ nicht ansehen konnte - aber Drag´nDrop kam mir nicht in den Sinn. Die Kopien sind alle readonly.

[ari.tao]

Das nächste kleine Problem:
Ich habe in MiNT.cnf gesetzt:
      setenv TOSRUN c:\multitos\miniwin.app
aber wenn ich eine .TOSse doppelklicke, poppt nicht das MiniWin-Fenster auf, sondern ein anderes mit dem Titel "MINIWIN" und dem Text:
      ERROR: No such file or directory
Mach ich was falsch? Miniwin läuft sonst problemlos überall.
Wenn er wenigstens sagen tät, wie das Ding heißt, das er nicht findet...
(Ein Problem von klein/GROSS-Schreibung?)

[Lukas Frank]

In den Builds im Tools Ordner gibt es TOS2WIN ...

Ich nutze gerne die Tools von Vincent ->   http://vincent.riviere.free.fr/soft/m68k-atari-mint/archives/mint/

[Nervengift]

Ich habe die Variable "TOSRUN" in der "xaaes.cnf" gesetzt. Aber keine Ahnung ob das einen Unterschied macht. Ich nutze auch TOS2WIN. Das läuft bei mir unter easymint (MiNT 1.19) im Zusammenhang mit Thing 1.29 aber auch nur mit einem Trick. Man muss die ausführbaren Dateien im TOS2WIN-Ordner entsprechende Rechte zuweisen, dass man die ausführen kann. Seitdem läuft's soweit, aber ich bekomme oft beim Doppelklicken unter MiNT 1.19 nur ein Consolefenster mit dem Inhalt "Programm terminate. Hit key to close window." Oder so ähnlich. Öffnet man das Programm stattdessen in TOS2WIN direkt über die Menüzeile, geht's ohne Probleme. Ich denk, das ist aber eine separate Baustelle.

[HelmutK]

So eine 1. Testversion:

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

Die fragt den BLOW-cookie ab und schreibt die frühen boot-Meldungen nach X:/mint/early.log.

Wäre nat. schön, wenn es eine allgemeine Lösung gäbe, aber ich glaube nicht, dass ich um den cookie herumkomme.

030-Version bei Bedarf.

[ari.tao]

Danke, @Lukas Frank , für den Link zu den Tools von Vincent.Da habe ich tatsächlich noch nicht alle kopiert.
Deine Erfahrungen mit TOS2GEM kann ich nur bestätigen, @Nervengift ! Eben wg. dieser unerfindlichen Meldungen "Program terminate..." benutze ich TOS2GEM nicht, sondern bevorzuge MiniWin.APP .
Da das Thema von allgemeinerem Interesse zu sein scheint (und hier OffTopic ist), habe ich dafür einen neuen Thread eingerichtet:
   http://forum.atari-home.de/index.php?topic=13257.0
Mein Posting #7 oben war nicht deshalb geschehen, weil es mir an Ersatz mangelt, sondern weil ich unsere MiNTzer darauf aufmerksam machen wollte, daß ich
    iZshg. mit MiniWin einen weiteren Bug im akt. MiNT oder XaAES vermute!

[ari.tao]

Jetzt also wieder zurück zum Thema:
Ich denke, @HelmutK , daß es der falsche Weg ist, für BlowUp einen Sonderfall in MiNT einzubauen (durch Abfrage des BLOW-Cookies). Hatte es sich nicht gezeigt, daß auch die Reboot-Probleme (sowohl auf Falcon als auch unter Hatari) zugleich mit dem BlowUp-Problem verschwunden sind?! Inzwischen kommt hinzu, daß Dein Kernel (MiNT030, 385.144 B. vom 13.11.16) nicht nur auch auf dem TT kein Reboot-Problem hat, sondern auch mit der TrueDisk bestens zusammenarbeitet (Falcon & TT). Ich vermute mal, daß auch GEM2RAM oder TOSloader damit zurechtkommen. Warum also diesen Erfolg zurücknehmen?
Auf meinem TT (mit CrazyDots-GK & deren orig. Treibern) läuft also Dein MiNT-Kernel jetzt auch, aber leider nicht mit XaAES030.km (538400 B. vom 11.11.16). Das steigt aus nach der Meldung
    "invalid Screen-type:2",
ganz egal, welchen Wert ich für video im .CNF eingetragen habe.
Dies XaAES hat _auf_dem_Falcon_ auch noch ein Problem beim Fenster-Verschieben; ich dachte, das sei schon behoben worden?

[HelmutK]

Ich hatte doch anfangs nach den log-files gefragt. Nachdem da ewig nichts kam, hab ich eben nur BlowUp berücksichtigt. Wenn Du eine allgemeine Lösung hast, seh ich mir das gerne mal an.

Dass hatari nicht läuft, halte ich für einen hatari-bug, und finde nicht, dass der in MiNT abgefangen werden sollte.

Zu XaAES hab ich ein eigenes Thema eröffnet.

[ari.tao]

-^^- wo, hab ich da was übersehen?
-------
Ich hatte Dir doch die LOG-Files alle geschickt! Welche denn noch? Wolltest Du auch die, mit denen BlowUp dann endlich lief? Mit der TrueDisk gab es an den Log-Files nichts besonderes zu sehen, die ließ sich ja starten, bloß Inhalt & Funktion waren kaputt!
Und was Hatari angeht: Findest Du das nicht bemerkenswert, daß mit MiNT030, 385.144 B. vom 13.11.16 gleich drei oder vier Bugs auf einmal verschwunden sind?!
Die ´allgemeine Lösung´ wäre dann vielleicht, das was Du für BlowUp eingerichtet hast, unabhängig von BlowUp für alle einzurichten?

[HelmutK]

Naja, direkt nach log-files hab ich nicht gefragt, aber gemeint:

"Aber Du kannst das ja jetzt schön mit dem Test-kernel testen."

Die Bildschirmverschiebung ganz raus zu schmeißen, nur weil einige Programme da Probleme haben, halte ich für übertrieben. Und bei mir läuft alles

[ari.tao]

Was ist denn der Nutzen der Bildschirm-Verschiebung?
Ich halte diese zwei Punkte für wichtiger:
1) Backward-Kompatibilität (ie. möglichst viele alte Prge. ´mitnehmen´)!
    Denn unsere Ataris sind museal.
2) Keine Sonderfälle unnötig einbauen!
    Denn das erhöht sonst die Entropie.

[HelmutK]

Der Sinn ist, dass der RAM-Speicher für MiNT linear ist, und nicht der BS-Speicher irgendwo in der Mitte.

[ari.tao]

-^^- Ich habe nicht nach dem Sinn, sondern, jenseits aller Ideologie, nach dem Nutzen gefragt. Was ist denn der Nutzen davon, dass der RAM-Speicher für MiNT linear ist?
Ich dachte, dass der BS beim Boot immer entweder am oberen oder am unteren Ende des verfügbaren RAMs angelegt wird? Früher war das mal so nmE. Aber wenn ein Prg. (wie zB. mein Grau-Demo) einen zweiten Screen braucht, dann landet der sowieso mitten im Gelände!