atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: tuxie am Sa 03.09.2016, 19:40:33
-
Hallo,
kann mir jemand sagen was beim letzten EasyMint beim Reboot über das menu alles gemacht wird ? Habe ein Problem das ich nach dem Reboot nicht mehr vom IDE Laufwerk Booten kann und nun möchte ich herausfinden warum. (nur beim Reboot über Mint)
-
Bin mir nicht sicher da schon ewig lang her. Nach dem Einrichten der LNX bzw. EXT2-Partition wurde nach dem Reset auch dort einige Dateien rüber kopiert meine ich.
-
Betrifft nur das IDE Interface am TT, ACSI oder SCSI ist von dem problem nicht betroffen, nachdem Mint hochgefahren ist und man rebootet den TT dann steht die Autoboot funktion nicht mehr zur Verfügung. Irgendwas verdreht Mint so das es zu diesem Problem gibt. Werde mich aber dazu mit den Entwicklern mal kurzschließen.
-
Denkbar wärs. Mal den Kernel für den Falcon ausprobiertt?
-
Nicht das es am IDE-Patch für das TT-TOS liegt.
-
Wenn der EasyMiNT Installer das erste Mal rebootet wird einfach das mint.prg im Autoordner abgearbeitet ...
Bei mir am Mega ST mit IDE und Alternate Ram klappt das mit EasyMiNT. Hat bestimmt nichts mit ACSI, SCSI oder IDE zu tun ...
-
@Lukas Frank , Mint ist bei mir bereits installiert, und wenn ich in Mint bin und reboote neu,dann greift er nicht mehr auf das IDE interface zu.
@Arthur , ja ich denke auch das durch irgendetwas der Patch fürs Auto boot nicht mehr funktioniert. Nur die Frage ist "WARUM". Muß herrausfinden was Mint macht das es den Patch zerlegt. Schalte ich den Rechner aus, und starte ihn neu dann funktioniert es einwandfrei. Auch wenn ich nur in Tos bin oder auch Magic funktionieren auch Reboots. Was wir uns noch vorstellen können ist, das die MMU in der CPU umkonfiguriert wird von Mint und damit der Zugriff auf 00F0xxxx nicht mehr Funktioniert wie es soll.
Stellt sich die Frage nutzt Mint die normale Memorytabelle wie TOS auch oder verbiegt Mint irgendwas wodurch die MMU umkonfiguriert wird.
-
Ingo, evtl. mal einen anderen HDD-Treiber ausprobieren... falls noch nicht gemacht. Gibt es eigentlich einen Cookie für die IDE-Schnittstelle und wertet MiNT den vielleicht aus?... Nur so eine Idee.
-
Frage doch mal HelmutK ...
-
Ich? Dafür bin ich nun wirklich nicht der Experte. Oder was das ironisch gemeint?
Und mit EasyMiNT kenn ich mich schon gar nicht aus, tut mir leid.
Zu MMU: MiNT benutzt und verändert die natürlich, aber nur wenn MEMPROT an ist (so wie ich das sehe).
Zu IDE: Mir persönlich ist noch nie was spezielles zu IDE im Quellcode begegnet, oder ich hab's vergessen. Schätze auch dafür ist der HD-Treiber zuständig.
Debug-kernel würde wohl nicht viel bringen, da es ja gar nicht erst bootet.
Ist denn das LW ganz weg, oder kann es nur nicht booten?
Vielleicht ändert ja der EasyMiNT-Installer die Laufwerk-Konfiguration (drvmap oder so), und dann versucht er vom falschen LW zu booten ...
Kannst Du nicht einfach an der Stelle einfach mal Shift-Alt-Ctrl-Del drücken für Coldboot?
-Helmut
-
Ihr denkt alle einen Level zu weit Unten oder oben je nachdem wie man es sieht.....
Bevor überhaupt ein HD Driver geladen werden kann, wird ein bootblock in den Speicher kopiert und ausgeführt, erst dann wird der Festplattentreiber geladen, und dieser Block wird, nachdem Mint gestartet war, nicht mehr kopiert, das ist quasi der erste Test um herauszufinden auf welchem Gerät etwas Bootbares liegt..
Memory Protection habe ich schon versucht ein/aus aber immer das selbe.. Sobald Mint oben war und ein Warmstart durchgeführt worden ist egal ob mit reboot, Strg-Alt-Ent oder Reset Taste kann der TT nicht mehr von IDE Interface booten. Booten heißt er kennt das gerät das device oder das interface nicht mehr. Läd man aber den Treiber von Diskette nach dann funktioniert alles supi.
Tos3.06 kennt kein IDE; kann daher normalerweise nicht Booten, wir haben dafür das Tos gepatcht, funktioniert mit Tos und Magic wunderbar aber sobald Mint gestartet war, hat es sich ausgebootet. Also bis zum Treiber laden kommt er gar nicht, es existiert auch kein Lesezugriff auf das Device. (Activity LED bleibt generell aus)
Irgendwas Stellt Mint an was dem TT die Möglichkeit nimmt von IDE zu Booten und wir wissen noch nicht was es ist. wenn man wüsste was es ist, könnte man mit einem kleinen Patch des Reboot Prozesses dies wieder gerade biegen.
-
Hab mal ein kleines Video gemacht
https://www.youtube.com/watch?v=KNOFMh-qsLo
-
Hallo Ingo,
1.Hast Du mal unterschiedliche HDD-Treiber ausprobiert?
2.Oder mal die Programmflags für ST- oder Fast-RAM geändert?
-
ja hab ich und hat nix mit dem HDDriver zu tun da es ein ganzes level weiter oben ist, der spielt hier noch keine Rolle da er noch nicht geladen wird.
Selbst wenn kein HD Driver installiert ist, erfolgt ein kurzer Zugriff um ihn zu Laden, und selbst dieser Zugriff fehlt.
-
ja hab ich und hat nix mit dem HDDriver zu tun da es ein ganzes level weiter oben ist, der spielt hier noch keine Rolle da er noch nicht geladen wird.
Ist aber vor dem Reset und vor MiNT schon geladen... Wer weis schon was dann dadurch alles durcheinander kommt. Ein Kaltstart (Reset) hilft auch nicht? Dann hätte ich vom Gefühl her gesagt es liegt an der TT-IDE-Karte.
-
Lieber arthur, bitte lies dir alles was ich bereits geschrieben habe durch und schau dir das Video an, habe alles mehrfach erklärt und nein es liegt nicht am IDE Interface, gibt dafür keine technische Erklärung warum nur bei mint das so sein soll. Mint verbiegt irgendwas und ich muss rausfinden was das ist, damit man ein Patch dafür rausbringen kann.
-
Denkbar wärs. Mal den Kernel für den Falcon ausprobiertt?
-
Ohne zu wissen was da gepatcht wurde, und wie das IDE-Interface funktioniert, ist das schwierig.
MiNT alloziert beim Start den ganzen zur boot-Zeit freien RAM für sich und verschiebt den Bildschirmspeicher, so dass keine Lücken entstehen. Bei vorhandener Grafikkarte wird der Bildschirmspeicher von MiNT als normaler Speicher benutzt. Der code dafür ist u.a. in init_mem() in memory.c
Allerdings denke ich, dass das alles auch beim Warmstart passiert, und so genau weiß ich das alles sowieso nicht. Vielleicht überschreibt MiNT ja diesen Loader-Bereich, weil er nicht ordentlich mit Malloc angefordert wurde?
Was käme denn, wenn man nach dem fehlgeschlagenen reboot HD-Driver von Diskette startet? Sind die Laufwerke dann da?
Sorry, wenn das alles Quatsch ist, für diese Low-Level-Sachen bin ich nicht der Experte, würde mich aber schon interessieren.
-Helmut
-
Der Patch ist ein patch der wohl schon bei anderen Tos Versionen angewendet worden ist. Und ja wie schon geschrieben wenn man HDDriver von diskette Lädt dann sind auch die Laufwerke wieder da. Es wird mit sehr hoher Wahrscheinlichkeit der Block der für das Autoboot von IDE ins Ram kopiert wird überschrieben oder zerstört. Pakman will sich den Patch nochmal ansehen, vielleicht finden wir eine möglichkeit oder ggf. eine Möglichkeit das dieses problem durch extra ausführen von einem Code beim reboot Process behebt.
-
Denkbar wärs. Mal den Kernel für den Falcon ausprobiertt?
Welcher sollte das sein ? Nutze wie auf dem Falcon mint030.prg... kenne keinen anderen für den Falcon..
-
Stimmt ja, ich hätte es dann wohl mal mit dem 020er probiert.
-
Der Patch ist ein patch der wohl schon bei anderen Tos Versionen angewendet worden ist.
Auf dem TT wird ja für's Booten von Platte die DMAread() XBIOS-Funktion verwendet.
Also habt ihr wahrscheinlich die gepatcht?
-
Genau die haben wir gepatscht, und wir vermuten auch das es daran liegt.
-
Genau die haben wir gepatscht, und wir vermuten auch das es daran liegt.
Ist das der welcher im TosPatch drin ist?
Schonmal das TOS2.06/3.06 Listing von Markus Fritze (http://www.sarnau.info/posts/2015/atari_st_bios_listing/) angeschaut?
-
Muß ich nachfragen, ich selbst habe den Patch nicht eingebaut.
-
Ich habe mal ein MultiTOS mit dem 1-19er Kernel von Helmut gebastelt zum probieren.
Bei mir mit der PAK68/2 und TOS 3.06 drauf bootet Mint nicht durch und landet ohne Fehlermeldung auf dem Single TOS Desktop. Egal ob ich von Diskette also A:\ oder von C:\ boote. Unter Single TOS ist alles wunderbar.
Auf der PAK sitzt ein c´t IDE Interface mit CF Karte.
Das TOS kennt ja nur zwei Massenspeicher Ports je Rechner also ...
- Falcon: IDE, SCSI
- Atari TT: SCSI, ACSI
- ST Book: IDE, ACSI
- ST, STacy (TOS 2.06): IDE, ACSI
Anstatt das TOS 3.06 zu patchen müsste man doch besser eine dritte Schnittstelle hinzufügen, also ein IDE Port oder besser zwei wegen der MonSTer im ST mit PAK. Platz beim TOS 3.06 müsste doch noch sein aber das ist bestimmt ein schwieriges Unterfangen ...
-
Wir haben in der Zwischenzeit eine Lösung gefunden, es gibt nämlich zwei wege das Bootproblem zu lösen. Die Version die wir erst hatten war eleganter und man konnte auch weiter vom SCSI Booten.
Die zweite Version ersetzt die Autoboot Routinen vom TOS 2,06 was aber zur Folge hat das man nicht mehr von SCSI Booten kann. (so ist es beim PAK Tos 3.06, da der ST eh kein SCSI hat).
-
Die zweite Version ersetzt die Autoboot Routinen vom TOS 2,06 was aber zur Folge hat das man nicht mehr von SCSI Booten kann. (so ist es beim PAK Tos 3.06, da der ST eh kein SCSI hat).
Und wieso klappt das mit mint.prg dann nicht auf der PAK ?
Wir haben in der Zwischenzeit eine Lösung gefunden, es gibt nämlich zwei wege das Bootproblem zu lösen. Die Version die wir erst hatten war eleganter und man konnte auch weiter vom SCSI Booten.
Was ist denn genau die erste Lösung ?
Ich hatte mal Epoms mit dem 512kB EmuTOS gemacht aber damit bootet die PAK nicht !?!
-
D.h. du hast mit der pak das gleiche Problem das wenn es gebootet war das du nach einem reboot nicht mehr von IDE automatisch booten kann ?
Wie die andere Lösung im detail aussieht kann ich dir nicht genau sagen.
-
Du meinst doch den Reboot vom EasyMiNT Installer, das ist das erste Mal wenn mint bootet ...
Probiere doch mal meine Bootdiskette im Anhang ein paar Beträge zuvor !
Mit der PAK klappt das booten mit mint.prg überhaupt nicht ...
-
Nein ich rede nicht vom Installer, ich rede davon das wenn ich aus einem laufenden Mint reboote kann ich nicht mehr, von IDE booten. Und nein hat nix mit Treiber zu tun weil es ein level tiefer liegt das Problem.
Mein Mint ist fertig installiert und eingerichtet, läuft 1a und kann damit Arbeiten aber sobald ich mit dem alten Patch reboote oder reset drücke dann macht der tt keinen Autoboot mehr.
-
Hallo @Lukas Frank , ich habe mal das MultiTOS ausprobiert auf meinem F30:
Leider bleibt MiNT_1.19.alfa hängen nach der Meldung "Loading external modules..."!
Was mache ich falsch?
Nach dem Hänger führt der Reset-Knopf zum Dauer-Reset, also Kaltstart nötig.
-
Lade dir mal den aktuellen Snapshot build vom trunk -> http://www.freemint.org
... und ersetze das mint.prg im Autoordner und alle Dateien im Mint Ordner ausser der mint.cnf.
Das ist eine Bootdiskette, wenn das ganze von Platte laufen soll müssen die Pfade in der mint.cnf und gem.cnf angepasst werden.
-
Auf dem F30 ist der Klops zu groß zum Entpacken, und auf dem Labtop fehlt mir der Entpacker für bz2.
Die Pfade sind bereits angepaßt.
Welche sind denn die ´external modules´, die er vermißt?
Vielleicht kann ich sie aus 1-18-0 ergänzen?
-
Welche sind denn die ´external modules´, die er vermißt?
Die Treiber? *.xxd und *.xif?
Du hast den richtigen Kernel in den Autoordner gelegt? Das Verzeichnis "c:\mint\1-19-cur\" ist vorhanden? Darin die besagten Treiber und die mint.cnf, mint.ini und das Verzeichnis "xaaes"? Was steht in der mint.cnf und in der mint.ini? Fragen über Fragen. ;D
-
Das sollte jetzt gehen ...
Passt alles auf eine HD Diskette.
Mint läuft auch ganz ohne die einzelnen Treiber und Zusätze, vielleicht ein Fehler im mint.prg der ersten Diskette von mir, keine Ahnung ...
-
Welche sind denn die ´external modules´, die er vermißt?
Die Treiber? *.xxd und *.xif?
Du hast den richtigen Kernel in den Autoordner gelegt? Das Verzeichnis "c:\mint\1-19-cur\" ist vorhanden? Darin die besagten Treiber und die mint.cnf, mint.ini und das Verzeichnis "xaaes"? Was steht in der mint.cnf und in der mint.ini? Fragen über Fragen. ;D
Da ist kein XaAES, das ist MultiTOS von Atari mit dem aktuellen Mint Kernel ...
-
Hab´ die Prozedur soeben mit dem neuen MultiTOS.ZIP wiederholt:
Gleiches Ergebnis! Mit beiden Kernels.
-------
Jetzt geh´ ich erstmal in die Sonne, vielleicht schaue ich heute Abend nochmal vorbei.
-
Da ist kein XaAES, das ist MultiTOS von Atari mit dem aktuellen Mint Kernel ...
Das wird nicht funktionieren. Seit MiNT 1.16.x wird folgende Ordnerstruktur von dem Kernel vorausgesetzt: \mint\1-1x-x\
Wenn der entsprechende Versionsunterordner nicht im MiNT-Ordner vorhanden ist, findet MiNT seinen ganzen Krams nicht mehr.
Hab´ die Prozedur soeben mit dem neuen MultiTOS.ZIP wiederholt:
Gleiches Ergebnis! Mit beiden Kernels.
Welches sind denn die beiden Kernels?
-
Nur \mint\ geht auch, aber der Ordner muss vorhanden sein:
http://sparemint.org/sparemint/mint/kernel/1.16.1/readme.txt (http://sparemint.org/sparemint/mint/kernel/1.16.1/readme.txt)
The <sysdir> defaults to "<bootdrive>/mint/<VERSION>" or, if this directory
doesn't exist, "<bootdrive>/mint".
Ansonsten:
If no <sysdir> is found FreeMiNT will stop the booting procedure,
display an error message and then return to TOS.
Aber:
After the kernel has booted you can also lookup what your <sysdir> is. The
<sysdir> setting is available through the environment variable $SYSDIR, under
/kern/sysdir or through 'sysctl kern.sysdir'.
Vielleicht könnte das klappen mit dem zusammengefummelten Multitos, wenn Du diese Variable anpasst?
-
Keine Ahnung, ich habe keinen Rechner mit 030 CPU ...
Bei mir geht die erste Diskette auf dem Mega STE, die zweite bombt bei mir.
-
Ich habe noch eine ganze Reihe von Versuchen unternommen, das Ding in Gang zu bringen, auch mit 1-18-0, aber alles vergebens, er bleibt immer wieder nach der selben og. Meldung hängen... Wenn ich zurück gehe auf 1-15-9, geht alles, MTOS, NAES, GENEVA, STOS...
Was sind denn nun die ´external modules´?
(nfs & keytable werden vorher geladen, also handelt es sich offenbar nicht um Treiber).
-
Warning: since version 1.16.0 FreeMiNT ignores "multitos" folder in the root of your boot-drive (done for backward compatibility with MultiTOS).
http://wiki.sparemint.org/index.php/User_manual (http://wiki.sparemint.org/index.php/User_manual)
Hattest Du mal die mint.ini entsprechend angepasst, so dass keine Treiber geladen werden?
http://wiki.sparemint.org/index.php/Mint.ini (http://wiki.sparemint.org/index.php/Mint.ini)
Und die Treiber müssten die externen Module sein. ;) Normalerweise kannst Du ab MiNT 1.16.x das auch übers Bootmenü steuern. Siehe den Link ganz oben. Im Grunde alles ganz einfach. ;D
-
im Ordner \mint\1-1x-CUR\xxx befinden sich die Kernel Module
xif, xdd Dateien.
Das Verzeichnis muß dem der Kernelversion entsprechen und darf auch nicht umbenannt werden. also 1-19-CUR z.b.
-
Hab´ ich doch alles so: c:\mint\1-19-cur\ etc., gefüllt mit den Dateien aus dem .ZIP .
xif gibt´s da nicht. Die beiden xdd sind drin.
MiNT.ini sagt mir, daß es automatisch erzeugt wird und nicht editiert werden darf.
-
MiNT.ini sagt mir, daß es automatisch erzeugt wird und nicht editiert werden darf.
Ignorieren und editieren! >:D
Hab´ ich doch alles so: c:\mint\1-19-cur\ etc., gefüllt mit den Dateien aus dem .ZIP .
xif gibt´s da nicht. Die beiden xdd sind drin.
Welche Dateien befinden sich in "c:\mint\1-19-cur\"? Poste am besten mal einen Screenshot. Und am besten auch den Inhalt der mint.ini und der mint.cnf.
-
Die mint.ini muss man auch nicht von Hand Editieren, einfach wenn die Meldung kommt die linke Shift Taste drücken und schon kommt man in die Einstellungen ...
-
_^^_ Weiß ich doch, hab´ ich auch so gemacht...im Anhang:
1) MiNT.CNF
2) ScreenShot aller relevanten Dirs. plus MiNT.ini
3) Zwei Fotos der Bootsequenz ab MiNT-Start bis Hänger
-
Prüf mal bitte die Pfade die müssen
u:\c\xxxx
lauten. Zumindest die Pfade in der mint.cnf
-
Daran liegt es nicht. Die erste Diskette läuft ja mit dem mint000.prg bei mir ohne Probleme. Zudem ist es mint egal ob / oder \ , manchmal geht / sogar besser ...
-
Rufe doch mal das ini auf und schalte mal zum Probieren XDD und XIF laden beide auf aus ...
-
Habe xdd und xfs beide auf ´no´ gesetzt (xif gibt es nicht); Ergebnis:
Jetzt macht er zwei Zeilen mehr, nämlich:
Starting up the update daemon ... done!
Starting up the idle process (pid 0) ... done!
Danach hängt er wieder!
Reset-Knopf einmal: alles dunkel, nix rührt sich,
noch einmal: Kaltstart statt Warm-Reset, genauer: Start von e: anstatt von der Default-Partition, aber mit neuer TrueDisk (dh. die bestehende, normalerweise reset-feste Truedisk wurde ausgehängt!)
Dieses Reset-Verhalten deutet imho darauf hin, daß MiNT resvalid & resvector nicht richtig behandelt! (Wenn man sich (wie MiNT es ausgiebig tut) in System-Vektoren einhängt, muß man _sofort_ auch die Wieder-Aushängung in resvector installieren!)
Könnten die Hänger ihre Ursache im Speicher-Management von MiNT haben?!
Edit.: Ein Prg., daß sich aufhängt, ohne einen Seufzer zu lassen, ist imho sowieso ziemlich unanständig. Da fehlen auf jeden Fall ein paar Sicherheits-Abfragen!
-
Für mich sieht das so aus als ob das "multitos" abstürzt, MiNT kommt bis zum Schluss. Was ist denn mit einem der gängigeren GEM=/INIT=-Varianten? Geht denn z.B. INIT=/bin/bash (falls vorhanden)?
Und was soll das?
exec u:\cmd\break.prg
exec u:\cmd\vt_cls.prg
exec u:\cmd\vt_norm.tos
?
-Helmut
-
Und was soll das?
exec u:\cmd\break.prg
exec u:\cmd\vt_cls.prg
exec u:\cmd\vt_norm.tos
Wo soll das denn sein ?
gem.cnf
---------------
# gem.cnf
# Last Modified on 0/0/1980 00:00
#======================================================
setenv PATH=.,A:\MULTITOS,A:\MINT
setenv ACCPATH=A:\
setenv ACCEXT=ACC,ACX
setenv GEMEXT=PRG,APP,GTP
setenv TOSEXT=TOS,TTP
setenv SHSHOW=A:\MULTITOS\VIEWER.APP
setenv SHPRINT=A:\MULTITOS\LPR.APP
setenv TOSRUN=A:\MULTITOS\MINIWIN.APP
---------------
mint.cnf
---------------
setenv PATH /sbin;/bin;/usr/sbin;/usr/bin
setenv SLBPATH /c/mint/slb
setenv HOSTNAME saturn
setenv TMPDIR u:/tmp
#
# MultiTOS
GEM=A:\MULTITOS\GEM.SYS
echo Setup complete, now booting the system...
echo
---------------
In der mint.cnf die "setenv" Sachen kann man wegmachen denke ich, die Treffen je nicht zu.
-
_^^_ Das sind schlicht drei kleine (seit langem bewährte) Zusätze, 1. eine Gelegenheit zur Pause (damit man die letzten MiNT-Meldungen noch sehen kann, die sonst sehr schnell vom Schirm verschwinden), 2. ein Screen-Blanking (zum sauberwischen), 3. um den Alfa-Cursor wieder auf Home & die Schriftfarbe auf schwarz zu setzen etc.
Damit Du beruhigt bist, habe ich die drei kurzerhand wieder ausgehängt und den Test wiederholt. Selbstverständlich ist das Ergebnis unverändert!
-------
Das MTOS, das ich benutze, ist die Version 4.1ß; ist ebenfalls altbewährt (startet problemlos mit MiNT_1.15.9 und anderen). Um auch hier alle Eventualitäten auszuschließen, habe ich es mal eben durch die Version aus Eurem ZIP ersetzt und den Test noch einmal wiederholt. Selbstverständlich ist das Ergebnis unverändert!
-------
GEM=... ganz ausgehängt (um SoloMiNT/SingleGEM zu starten, wie Eric Smith es tat) führte auch zu keiner Änderung!
-------
\bin\bash ist bei mir nicht vorhanden (bin nicht so der Unox-Freak). Könnte es mal mit INIT=c:\u\bin\sh oder INIT=u:\bin\sh versuchen?
Geht aber nicht vor frühestens heute Abend!
-------
Mein GEM.CNF ist ebenfalls altbewährt. Von Diskette booten will ich nun wirklich nicht! Das kann mal jmd. anders machen.
-
Habe soeben, wie vorgeschlagen, die vier setenv ´rausgenommen: Ergebnis dito.
Habe zusätzlich GEM= durch INIT= ersetzt: Ergebnis unverändert.
Habe statt GEM=... dann noch INIT=u:\bin\sh gesetzt: Immer der gleiche Hänger!
Jetzt weiß ich nix mehr, was ich noch verändern könnte.
-------
Noch eine Idee, da anscheinend die spezifizierten Pfade/Dateien nicht gefunden werden: Stimmt etwas nicht in der jetzigen MiNT-Version mit der Umwandlung von Groß- in Klein-Schrift (oder umgekehrt)?
-
Wo liegt denn /bin - ext2? Vielleicht stimmt ja mit dem ext2fs was nicht. Kopier mal /bin/sh nach c:/bin/sh und gib das in mint.cnf an.
-
Ich habe kein ext2, nur FAT16 (und eine FAT32).
u:\bin\ == c:\u\bin\
-------
Soeben ausprobiert: INIT=c:\u\bin\sh
Ergebnis: Der übliche Hänger!
-
Endlich etwas Licht am Ende des Tunnels!
Zunächst die guten Nachrichten:
1) INIT=c:\u\bin\sh lief endlich. Hintergrund su.
2) Dann startete auch GEM=c:\multitos\gem_41.sys und lief teilweise. Weiteres su.
Nun die schlechten Nachrichten:
3) Das gem.sys aus dem .ZIP (= MTOS_4.0) hängt sofort nach dem Start!
4) Ein ScreenShot war nicht möglich.
5) Es gab während des MiNT-Boots und auch unter MTOS_4.1 diverse Fehler-Meldungen.
Und nun die ganz schlechten Nachrichten, Hintergrund & weiteres:
6) Obwohl mit der sh die Tastatur-Benutzung lief, ging diese nicht unter MTOS_4.1.
Maus-Benutzung war unter MTOS_4.1 nur teilweise möglich (zB. kein DoppelKlick zum Start von
Prgen., aber das Menue ´öffnen´ funzte!)
7) Der Teil-Erfolg war erst möglich, nachdem ich BlowUp ausgehängt hatte.
Das aber ist auf meinem Falken unverzichtbar !!!
Im Anhang BlowUP & MTOS_41
Hinweise: Das MiNTnp ist das 1.15.9 (mit dem MTOS bis auf gewisse Bugs einigermaßen läuft); die Neon-Icons sind von mir (habe sie benutzt, weil sie grade installiert waren auf e: und ich das NEWDESK.CNF nicht auch noch anpassen müssen wollte); auch das ALERT.ACC ist eine neuere Version, war aber gar nicht installiert (ist afaik ohnehin nur für SoloMiNT/SingleTOS gut).
PS: Ich muß jetzt leider drei Wochen Pause machen (muß nach Hannover reisen).
Ich hoffe, Ihr habt bis dahin alle angesprochenen Probleme gelöst ;) !
-
Geht doch! Ich war schon drauf und dran, ein spezielles Test-Setup zu erstellen, das erübrigt sich ja jetzt glücklicherweise.
Zu MTOS-Tastatur: MTOS läuft wahrscheinlich im Supervisor-Modus, so dass das nicht geht. Probier mal mit meinem kernel GEM=ROM (hier müsste die Tastatur jetzt gehen), und versuch das MTOS dann vom TOS-Desktop zu starten. Oder halt Ausschau nach nohog.acc. Vielleicht geht ja auch GEM=MTOS mit meinem kernel.
Was ist denn eigentlich so toll am Multitos? Ich hab das vor 80 Jahren mal kurz probiert, und bin dann sofort auf XaAES (0.6 oder so) umgestiegen.
Zu BlowUp: Hab ich nie benutzt, kenn ich nicht. Ich würde es mal nach MiNT starten, oder aus mint.cnf heraus.
-Helmut
-
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!
-
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 ...
-
Nein, nein. Ich habe ja (-> obige Anhänge) auch mint000 benutzt!
PS: Wie, @Lukas Frank , geht eigtl. das ´verstecken´ im Forum?
-
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
-
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!
-
Also bei mir geht es auf echter Hardware, habe es aber auch mal mit Hatari gemacht ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13120.0;attach=12184;image)
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.
-
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?
-
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.
-
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ö :)
-
@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!).
-
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.
-
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.
-
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.
-
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.
-
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.
Isthttp://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!).
-
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.
-
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!
-
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.
-
-^^- 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 >:D); 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 :o. 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.
-
...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.
-
Was heißt ´meistens`?
-
Was heißt ´meistens`?
Ich hab' damit rumgespielt und konnte mein Hatari-Fenster schön größer und kleiner machen.
Bis Hatari abgeschmiert ist.
-
-^^- Wohl wahr; aber nach einem Crash geht es noch um zwei Dinge, nämlich evtl. Arbeit zu retten,
Nee, wichtiger ist nicht noch mehr kaputt zu machen.
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
Das macht MiNT ja normalerweise auch: Es wird ein CPU-dump ausgegeben, so dass man die crash-Stelle finden kann.
´s Forum stellen :-\? (Wie gesagt, derzeit gut für TOS & MAGX, aber leider nicht für MiNT).
Wegen mir eher nicht.
-------
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
Auf dem falcon dürfte das sowieso nicht viel Spaß machen, der braucht dann für jeden build einen Tag, auf meinem 50€-PC geht das in 1 Minute (aranym oder cross).
Danke auch für rm, funzt in mint.cnf (aber nicht in xaaes.cnf); gibt´s Doku dazu?
https://linux.die.net/man/1/rm
Also ehrlich ...
-------
Es gibt da kein "ihr".
Schade. Aber kannst ´Ihr´ ja als pluralis majestatis lesen ;).
Ja - sehr gerne!
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.
Ich blick auch nicht durch.
-------
Beim Entpacken der .BZ2s bin ich gescheitert :o. 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
Was brauchst Du denn jetzt in zip-Form?
(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.
Ich würde mir die Unix-Sachen (tar,gz,bzip2, etc.) auf dem falcon installieren, und dann nur eine shell starten, das könnte gehen. bzip2 ist bekannt dafür, sehr resourcenhungrig zu sein. Daher wird das z.B. bei OpenBSD auch nicht verwendet, soviel ich weiß.
-------
...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.
Ja, eine Beta-Version. Da stürzt MiNT aber ab. Die Tage probier ich mal die release-Version. Vielleicht ist ja die Absturzursache hier die gleiche wie bei Dir (ich weiß: sehr optimistisch).
tos.xfs gibt's nicht, das ist eingebaut.
Wirklich? Wie komme ich da dran? NEWFATFS ist default! Gibt´s etwa ein OLDFATFS ?
OLDTOS ist nur in meinem 000-kernel vorhanden (extra für hatari), und in minthat, aber das läuft irgendwie nicht.
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.
Geht auch, wenn die sh halbwegs was taugt.
-------
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!
Das weißt Du doch inzwischen wohl, dass da was faul ist!
PS: Übersetzung des dem Schotten Occam zugeschriebenen lateinischen Zitats:
Die Dinge dürfen nicht vermehrt werden, außer wenn es notwendig ist.
Da kann ich mein GL wohl zurückgeben ...
-
-^^- Wohl wahr; aber nach einem Crash geht es noch um zwei Dinge, nämlich ,,,
Nee, wichtiger ist nicht noch mehr kaputt zu machen.
Das sehe ich etwas anders, denn: Wenn auch nur der geringste Verdacht besteht, daß auf einer Partition etwas kaputt ging (etwa ´verlorene Cluster´), dann muß ich sowieso die ganze Partition überprüfen...
Das macht MiNT ja normalerweise auch: Es wird ein CPU-dump ausgegeben,
Habe trotz zwei Bömbchen noch keinen Dump gesehen, und auch nicht den Inhalt der TOS-ErrorArea.
...für jeden build einen Tag, auf meinem 50€-PC geht das in 1 Minute (aranym oder cross).
Boah. An 50€ würde es nicht scheitern - wohl aber am mangelnden Platz in meinem Gehäuse.
https://linux.die.net/man/1/rm
Danke!
Was brauchst Du denn jetzt in zip-Form?
Am besten den trunk-Klops aus
http://www.freemint.org/builds/freemint?
und den Helmut-Klops (mit 000 und 030), den Du getestet haben möchtest.
tar,gz,bzip2
Habe ich ja (wenn auch vermutlich eine ältere Version); hätte ich gerne auch auf der Lab-Dose (die hat ja genug Resourcen), aber da scheitert´s am Henne-Ei-Problem...
... 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!
Das weißt Du doch inzwischen wohl, dass da was faul ist!
Das ist doch das Thema dieses Threads?!
Die TrueDisk ist mir aus gleichem Grund wertvoll - sie ist nämlich System-übergreifend Reset-fest - aber von 1-19-cur wird die schlafende Trude gekillt!
-
Habe trotz zwei Bömbchen noch keinen Dump gesehen, und auch nicht den Inhalt der TOS-ErrorArea.
Das liegt daran, dass der noch nicht installiert ist, sonst würden auch keine Bomben kommen.
Was brauchst Du denn jetzt in zip-Form?
Am besten den trunk-Klops aus
http://www.freemint.org/builds/freemint?
und den Helmut-Klops (mit 000 und 030), den Du getestet haben möchtest.
Gut, mach ich noch. Aber erstmal muss es ja einen kernel geben, der überhaupt bootet.
Die TrueDisk ist mir aus gleichem Grund wertvoll - sie ist nämlich System-übergreifend Reset-fest - aber von 1-19-cur wird die schlafende Trude gekillt!
Und wenn Du die mal weglässt?
-
--^^-- Habe ich doch - das waren die ´Kaltstarts´.
Einen Warmstart ohne Trude habe ich auch schon mal versucht: Gleiches Ergebnis wie bei Kaltstart.
-------
Der ErrorHandler sollte doch im StartUp des Prgs. (ie. des MiNT-Kernels) installiert werden, also vor fast allen anderen Aktivitäten...! (Vielleicht sogar als allererstes).
-
Ja, könnte man evtl.
Ich guck gerade Deine log-files durch: Laut BOOT.LOG ist es doch bis zum XaAES gekommen, nur mit dem Maus-Treiber stimmt was nicht. War das jetzt mit BlowUp?
Laut XAAES.LOG hat sonst aber alles geklappt mit 640x480)!
Und was war bei XA_BOOT.LOG anders, da ist er nur bis zu Loading config gekommen?
-
Wieso anders? Die drei Logs werden doch zusammen erzeugt.
Das ist mit & ohne BlowUp das gleiche.
Erstmal muß der moos.adi iO. kommen, und möglichst auch die Tastatur, deshalb brauche ich mal ein vollst. 1-19-cur, und nicht bloß diesen zusammengeschusterten Rest.
Laut XAAES.LOG hat sonst aber alles geklappt mit 640x480)!
Wg, BlowUp sollte da aber 1024x768 stehen!
-
Also XA_BOOT.LOG enthält:
~~~~~~~~~~~~ XaAES start up ~~~~~~~~~~~~~~~~
XaAES v1.8.4 Beta (m68030, Nov 5 2016 13:58) (MultiTasking AES for MiNT)
Part of freemint (http://sparemint.org).
stack is long-aligned:274630
PRG: km=172000, base=172160, text=172260 -> 1D57DC(406908), kentry:0.21,dos_version=40
home_path: 'u:\e\MINT\1-19-CUR\XAAES\'
Loading config u:\e\MINT\1-19-CUR\XAAES\xaaes.cnf
und XAAES.LOG:
sysfile_exists: 'u:\e\MINT\1-19-CUR\XAAES\moose_w.adi'
moose_w.adi not found
sysfile_exists: 'u:\e\MINT\1-19-CUR\XAAES\moose.adi'
lang='de' (from AKP) code=1.
load adi modules
Loading AES Device Drivers:
load_adi: enter (0x121264, 0x121164, moose.adi)
Module moose.adi error, reason: Nothing (possibly from other kernel)
load_adi: return -1
...
Bei mir steht das alles in einer Datei:
~~~~~~~~~~~~ XaAES start up ~~~~~~~~~~~~~~~~
XaAES v1.8.4 Beta (m68040, Nov 5 2016 18:26) (MultiTasking AES for MiNT)
Part of freemint (http://sparemint.org).
stack is long-aligned:4F6462C
PRG: km=4ED2000, base=4ED2160, text=4ED2260 -> 4F4B9B8(497496), kentry:0.21,dos_version=40
home_path: 'u:\c\mint\1-19-cur\xaaes\'
Loading config u:\c\mint\1-19-cur\xaaes\xaaes.cnf
keyboard#0=aradenum
keyboard#1=germand
keyboard#2=britsh_pl
keyboard#3=russian
include: 'xa_run.cnf'
sysfile_exists: 'u:\c\mint\1-19-cur\xaaes\moose_w.adi'
sysfile_exists: 'u:\c\mint\1-19-cur\xaaes\moose.adi'
...
Das moose_w.adi von meinem aranym hab ich angehängt. Was ist das für ein Datei-System, hat das evtl. ein x-bit für executable? Das muss dann bei dem adi auch gesetzt sein meine ich.
Und was war da jetzt mit BlowUp? Ich denk dann bootet MiNT nichtmal.
-
Doch, siehe oben X)!
Aber nur warm (mit 1-18-0), und die Auflösung stimmt nicht (also BlowUp anwesend, aber unwirksam).
PS: Habe eben gerade noch das vorletzte Posting editiert, als Du schon geschrieben hast.
-
Seltsam, daß das bei Dir in einer Datei steht, bei mir sind´s immer reproduzierbar zwei...
(Haben ja auch verschiedene Namen!)
Datei-System, hat das evtl. ein x-bit für executable?
Nein, ist bloß das NewFatFS von FN, siehe mint.log .
-
Ja hab ich gemerkt.
XaAES 1.8.4 gibt es aber nur für MiNT 1.19. Also irgendwas stimmt hier aber nicht!
>Sektsam, daß das bei Dir in einer Datei steht, bei mir sind´s immer reproduzierbar zwei..
Versteh ich jetzt auch nicht. Also MiNT schreibt C:/mint/boot.log, XaAES .../xa_boot.log und es benutzt auch C:/mint/boot.log für manche Sachen, also insgesamt schon 2. Wo kommen die denn genau her bei Dir?
Vielleicht liegt das XaAES-Problem ja hier dran:
k_init:vdo=30000 vm=801A video=-32742
Falcon video: videomode -32742(801A),mode=5,nvmode=803A
Hast Du mal die 000 oder sto-Version von XaAES probiert?
Könnte sein, dass Dein moose.adi für die falsche kernel-Version ist. Probier mal das von mir.
-
Nee, drei, wie gesagt.
mint.cnf + xaaes.cnf waren doch auch im Anhang.
Sonst gibt´s weiter nix.
Ich probiere jetzt mal das neue moos.adi (aus Deinem letzten Anhang)
-
Ubs, so geht das nicht, wenn wir uns ständig gegenseitig überholen...
Für den neuen Test brauche ich sowieso ein paar Minütle...
Vielleicht liegt das XaAES-Problem ja hier dran:
k_init:vdo=30000 vm=801A video=-32742
Falcon video: videomode -32742(801A),mode=5,nvmode=803A
Dazu kann ich nix sagen, außer, daß es ja keine Falcon-Std.Auflösung für 1024x768 gibt, das hatten wir ja oben schon mal besprochen. Und der Hinweis auf CentScreen, den ich irgendwo las, der nutzt mir nix für BlowUp...
Edit.: Immerhin zeigt das, daß ein ähnliches Problem wie bei BlowUp offenbar für CentScreen schon mal gelöst wurde?!
-
Ich mach jetzt erstmal was anderes :)
Die zip-Archive finden sich hier:
http://home.arcor.de/zabruder/atari/system/TIME.html
-
-^^- danke.
Welchen helmut soll ich denn jetzt nehmen? den neueren?
-------
Das neue moos.adi hat etwas geholfen. Jetzt funzt x) unter 1-19-cur genauso, dh. mit den gleichen schon beschriebenen Macken bzgl. BlowUp & Tastatur, wie unter 1-18-0; Logs im Anhang (die .CNFs sind geblieben).
-
Guck ich mir später an. Das mit den 2 logfiles ist wegen:
logfile = e:\mint\1-18-0\xaaes\xaaes.log
in xaaes.cnf. Würde ich weglassen.
-
Hab´ ich so gemäß Example.CNF gemacht.
Kann ich ändern.
-
Mit trunk keine Änderung des Verhaltens im Fall X).
Edit.: Doch, ein kleines bißchen hat sich geändert - berichte ich später.
-
Hier:
13:08:27: PROCESS "xctrl" KILLED: MEMORY VIOLATION. (PID 018) Type: private PC: 00E0CFE2 Addr: 002F8028 BP: 00658000 OS: 007B4EE2$
Lass xctrl (ist das ein Kontrollfeld-Accessory?) mal weg. Ich mein mit sowas hatte ich auch schon Probleme.
Thing zu nehmen finde ich in der Situation auch ziemlich mutig.
-
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.
-
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.
-
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 !
-
... 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.
-
Ah, das hatte ich mal so dahinein geschrieben - muß unterwegs verlorengegangen sein. Danke.
-
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 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 ??
-
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.
-
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.
-
-^^- 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. ::)
-------
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?! :-X :P
-------
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?
-
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 (http://archive.3rz.org/MAUS-OEPT/FR/st/AUTOMRR6.LZH)
-
-^^- 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. >:D
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!
-
Ich seh gerade: Das boot.log wird immer nach C: geschrieben. Das ist natürlich ein Fehler, und wird demnächst behoben.
-
-^^- 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?! ??? :-[ :o >:( :( :'(
-------
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.
-
Ä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.
-
Bleibt locker... bisher waren es doch interessante und konstruktive Beiträge.
-
Habe dieser Tage wenig Zeit.
Werde aber noch antworten, demnächst.
-
Edit: Beitrag vorläufig wieder gelöscht.
-------
PS: Einen Yogi kann man nicht beleidigen (es sei denn, der will das so).
-
@ari.tao : falls dein Ziel war, @HelmutK von weiterer Hilfe abzuhalten, hast Du genau den richtigen Ton gefunden, denke ich.
Gratuliere!