bigdos.prg und der 68060

[1ST1]

Die gepatchte Version crasht im 060-Modus. Im 030er geht sie noch.

[1ST1]

Sicherheitshalber habe ich auch nochmal Bigdos.prg und Bigdos-f.prg nacheinander in d:\auto (sonst leer) ausprobiert. Auch die crashen, habe ich eigentlich erwartet, aber das Crashverhalten ist anders. Bigdos-f scheint sauber durch das xbra-Zeugs durchzulaufen, man kann sogar noch sehen, wie ACCs (von c:) geladen werden, es crasht erst danach.

[1ST1]

Und der Vollständigkeit halber noch Bigdos Version 6. Das crasht wie die Falcon-Version erst nach dem Laden der ACCs.

[czietz]

Schade. Ich bin jetzt auch auf Reisen und kann nicht weiter Fehler suchen.

Dinge, die ich den Screenshots entnehmen kann: Ja, ich habe den ersten Fehler in BIGDOS-P.PRG entfernt. Dafür stürzt es jetzt an anderer Stelle ab. 

BIGDOS-F.PRG und Version 6 crashen -- wie Du auch schon gesehen hast -- erst, wenn BigDOS schon installiert ist. An "Basepage: $000F8860" ist erkennbar, dass der aktuelle Prozess zum Zeitpunkt des Absturzes nicht mehr BIGDOS-F.PRG/BIGDOS.PRG ist, sondern etwas anderes. Vielleicht der Desktop? Im Falle von BIGDOS-F.PRG ist auch der Program Counter nicht innerhalb des Codes von BigDOS sondern an anderer Stelle. Vielleicht in einem Accessory? D.h. irgendwas anderes stürzt ab, wenn BigDOS schon geladen ist.

Wie gesagt, das ist alles irgendwie stochern im Nebel, solange man den Quelltext zu BigDOS nicht hat.

[Lukas Frank]

1ST1 sollte doch wohl zum testen alles andere weglassen also ausser BigDOS gar nichts anderes. Wenn es dann mal läuft kann man ja weiter sehen ...

[1ST1]

Genau das habe ich doch gemacht... Wie du weiter oben sehen kannst, habe ich einen Autoordner auf D: extra dafür angelegt.

Jetzt habe ich aber einen witzigen Effekt... Die Falcon-Version von Bigdos lief eben gerade. Aber ohne Screenblaster, immerhin. Das muss ich noch näher untersuchen.

Außerdem habe ich jetzt eine XBoot III Version, die auf dem 060 läuft. Aber ich habe eben testweise den 060 zu sehr hochgetaktet (100 Mhz geht noch stabil, 105 will er nicht), er will nach Bootlogo und ROM ins RAM kopieren nicht mehr, sprich vermutlich ab dann wo der gespeicherte Takt eingestellt wird. Wie resettet man das wieder?

[1ST1]

Fürs Protokoll: Wenn man es mit dem Takt auf der CT60(e) zu sehr übertrieben hat, muss man im 060 Modus ALTERNATE beim Reset drücken und warten, bis das Biest anfängt zu booten, dann läuft er wieder mit 66 Mhz. Puh...

Und jetzt zum Ausgangsproblem...

Außerdem, ich weiß nicht warum, aber momentan läuft sogar Bigdos-f zusammen mit NVDI und Screenblaster. Ich weiß nicht, was ich momentan anders mache, außer dass ich jetzt eine 060-taugliche Version von XBOOT 3 habe. Vorher habe ich im 030 Modus mit XBoot meine Config eingestellt, durchgebootet, xboot.prg nach prx umbenannt und im 060 Modus gebootet, Also eigentlich bei Patches, Speicherresistenten Programmen usw. nichts anders als jetzt.

Dann bin ich jetzt erstmal zufrieden und kann die Sachen machen, die ich mit der ct60 eigentlich endlich mal ausprobieren und erforschen wollte, sprich diverse Demos die eonen 040 oder 060 vorraussetzen, Doom, Quake, Duke Nukem, Worms und solche Sachen. (Doom hatte ich schon zum Laufen gebracht, aber es gibt da noch verschiedene Versionen der doom.ttp, badmood-ttps, diverse Wadfiles, usw.)

Achso, ja, und endlich mal ein MiNT installieren...

Jetzt fehlt mir eigentlich nur noch ein Supervidel...

[1ST1]

Noch ein Hinweis: bigdos-f muss als allerletztes Programm in den Auto-Ordner. Bigdos-f scheint die Kontrolle über das Starten von GEM zu übernehmen. Programme, die hinter bigdos-f liegen, werden nicht ausgeführt.

[goetz @ 3rz]

Noch ein Hinweis: bigdos-f muss als allerletztes Programm in den Auto-Ordner. Bigdos-f scheint die Kontrolle über das Starten von GEM zu übernehmen. Programme, die hinter bigdos-f liegen, werden nicht ausgeführt.

Das halte ich angesichts von:

BIGDOS.PRG (für den Falcon z. Z. BIGDOS-F.PRG) kommt möglichst als erstes
Programm nach dem Boot-Selektor in den AUTO-Ordner. Auf jeden Fall vor alle
Programme, die im GEMDOS-Trap hängen und kein XBRA benutzen. BIGDOS.PRG
installiert sich selber am Ende der XBRA-Kette. (Das klappt mindestens mit
MetaDOS, CHK_OFLS, NVDI, Overscan, AES-Font und HSModem.) Overscan muß nach
NVDI und vor Big-DOS stehen!

(Quelle: bigdos.txt)

… für eine eher „mutige“ These.

[1ST1]

Mag sein, dass du das für mutig hälst. Es ist aber so. Mutig wäre von dir, das Gegenteil zu beweisen. Schließlich habe ich es getestet. Selbst wenn du bigdos-f.prg als erstes in den Auto-Ordner tust, wird nach dessen Ausführung SOFORT GEM gestartet. Und das selbst, wenn du alle PRX dahinter in PRG umbenennst. KEINES davon wird noch gestartet. KEIn Xboot, kein NVDI, kein Screenblaster, keine TOS-Patches, kein HSModem, kein Letemfly, kein Selectrix, kein MidiCom, kein MetaDOS, kein ROMRAM/ROMSPEED/..., kein WinX, nichts davon. Es ist übrigens auch davon unabhängig, ob ein normales TOS 4.04 zum Einsatz kommt, oder das CT60 gepatchte TOS 4.04 1.03. (Andere TOS-Versionen, sprich TT, MegaSTE oder so habe ich nicht getestet, dort ist ja auch die Falcon-Version nicht notwendig da es ja keine Falcons sind.) Muss ich ein Youtube-Video einstellen, damit du es mir glaubst?

Jetzt habe ich tatsächlich fast noch vergessen, zu erwähnen, dass es sich bei dieser Erkenntnis um keinen Aprilscherz handelt.

[KarlMüller]

Mag sein, dass du das für mutig hälst.

Es ist Mutig von Dir ein Programm zunutzen was sich nicht an das hält was der Autor schreibt. Denn Big-DOS übernimmt nicht die Kontrolle beim Starten vom GEM oder dem Auto-Ordner. Das von Dir beschrieben Verhalten deutet für mich auf einen Fehler hin.

Zudem hat Rainer Seitel selbst geschrieben das Big-DOS 6 besser für den Falcon ist.

[goetz @ 3rz]

Mag sein, dass du das für mutig hälst. Es ist aber so. Mutig wäre von dir, das Gegenteil zu beweisen. Schließlich habe ich es getestet.

Mag ja gerne sein, dass nach Big-DOS nix mehr läuft, das wäre dann ein Bug. Das ist aber was anderes als das was du schriebst, nämlich dass Big-DOS die Kontrolle beim Start von GEM zu übernehmen scheint. Aber bevor weiter über Sinn und Intention gestritten wird: hast du mal den Autor mit einem Bugreport angeschrieben?

[1ST1]

Das ist mir egal, solange es so funktioniert. Bigdos scheint aber irgendwie die Kontrolle über den Start von GEM und dem Desktop zu übernehmen, denn ohne Bigdos erscheint beim Starten von GEM keine weitere Meldung, mit Bigdos wird angezeigt, welche ACCs gerade geladen werden. Ich habe inzwischen auch noch einen anderen Fehler auf Bigdos zurückführen können, der tritt sowohl auf dem Falcon als auch auf dem TT auf: Das Löschen leerer Ordner klappt hin und wieder nicht. Lasse ich Bigdos weg, gehts. Die Vorteile überwiegen aber die Nachteile, so oft lösche ich keine Ordner, und notfalls kann ich mir mit Kobold oder Diskus behelfen. Den Autor (Rainer Seitel, Piratenpolitker, aus Rastatt bei Karlsruhe) hatte ich wegen Freigabe des Quelltextes angeschrieben, aber bisher keine Rückmeldung bekommen.

[goetz @ 3rz]

Das ist mir egal, solange es so funktioniert.

Darf es ja gerne sein, nur hattest du halt als These rausgehauen, Big-DOS würde das als „Feature“ (d.h. gezielt) machen. Das hat der Autor aber wohl nicht so vorgesehen - deshalb ist’s ein Bug.

Den Autor (Rainer Seitel, Piratenpolitker, aus Rastatt bei Karlsruhe) hatte ich wegen Freigabe des Quelltextes angeschrieben, aber bisher keine Rückmeldung bekommen.

Ich kann ihn ja fragen, wenn ich ihn wieder sehe - wird aber Herbst werden.

[1ST1]

Das ist mir egal, solange es so funktioniert.

Darf es ja gerne sein, nur hattest du halt als These rausgehauen, Big-DOS würde das als „Feature“ (d.h. gezielt) machen. Das hat der Autor aber wohl nicht so vorgesehen - deshalb ist’s ein Bug.

Naja, wenn du es ja so genau weißt, dann erkläre es mir doch mal:

Reihenfolge der Bilder:
1. ct60e-TOS 4.04-103 mit BIGDOS-F
2. Falcon-4.04-TOS mig BIGDOS-F
3. ct60e-TOS 4.04-103 ohne BIGDOS-F
Die Startreihenfolge wurde nicht verändert! Gleich kommt noch Versuch 2...

[1ST1]

Versuch 2, Teil 1

Vorgehensweise: Bigdos an den ANfang des Autoordners verschieben, also direkt hinter Xboot, und dann mal starten...
Du siehst, ct60e-Tos ist aktiv, es zeigt an welce AUTO-Ordner-Programme gestartet werden, BIGDOS und sonst nix, und dann START GEM. Danach zeigt BIGDOS die geladenen ACCs an. Danach meckert das Kontrollfeld Cops dass WDIALOG nicht geladen wurde, und der Falcon kommt in Standardauflösung hoch, und das Color.CPX kann die Farben nicht setzen, weil COPS manges WDIALOG dioe CPXe nicht lädt.

[1ST1]

Versuch 2, Teil 2.

Bigdos-f wieder nach hinten geschoben, gebootet, Autoordner-Sachen werden wieder abgearbeitet, Bigdos ganz hinten vor GEM-Start, ACCs werden angezeigt, Screenblaster will Auflösung wissen, Desktop kommt und ich kann Laufwerk Q öffnen, das ist die Compactflash die vom PC mit langen Dateinamen beschrieben wurde, siehe z.B. den Syste~1 Ordner und die beiden LNK-Dateien, die am PC Verknüpfungen zur Softwaresammlung auf meinem Server verlinken.

Und jetzt erklär mir das mit der Aussage von Rainer Seitels Webseite. Es ist wie es ist, es funktioniert und das ist IMHO so Ok. Auch wenns anders dokumentiert ist.

[atari-inside]

Mal eine off-topic Zwischenfrage...

Du hast da jede Menge Programme im AUTO Ordner, als auch Accessories und CPX(es) - viele davon kenn ich gar nicht... aber sie scheinen dir wichtig zu sein...

Könntest du mal kurz umreissen wozu du diese von Nutzen sind? Vielleicht auch Links dazu schicken?

AUTO:
BIGDOS --?
DRVIN --?
FALC_SND --?
FPATCH --? Still necessary?
LETEMFLY --?? Dialog Boxes to move around?
MC-DRV16 --??
PCSOUNDC --??
ROMSPEED --??
SBLANKER --??
SBLASTER --?? ScreenBaster?
SB_HUTU --??
SCC --??
SELECTRIC --?? Alternative File Chooser..?
WINX --??
ZMAGXSND --??

ACC:
CHMELEO01-04 --??
KUBIS --??
MC_TALK4 --??
MIDI_COM --??
PAULA --??
VIBRAX --??

CPX:
3DBUTTON --??
BASIC000 --??
BASIC030 --??
BOOT --??
BOOTREG --??

Die Liste der CPX(es) endet im Bild bei "C"... - da hast offenbar jede Menge...

 

[1ST1]

Mal eine off-topic Zwischenfrage...
AUTO:
BIGDOS --? -> Bigdos
DRVIN --? -> hsmodem
FALC_SND --? -> stellt den Lautsprecher ab und Systemlautstärke auf recht leise, ganz als erstes im Autoordner
FPATCH --? Still necessary? -> Ohne ct609 auf jeden Fall. Könnte aber sein dass es eine neuere Version gibt.
LETEMFLY --?? Dialog Boxes to move around? -> genau. Funtzt aber unter TOS 4.04 nicht mit so vielen PRGs wie unter 3.06/2.06/1.0x
MC-DRV16 --?? -> HSMODEM
PCSOUNDC --?? -> muss ich nachsehen, wird aktuell nicht verwendet
ROMSPEED --?? -> wie romram, romspeed, gemram, usw. Kopiert ROM ins RAM, für WinX, unter ct60e TOS funzt das nicht, im 030 Modus aber füe mich erforderlich. ct60e TOS hat zumindestens die notwendigsten Patches daraus.
SBLANKER --??  -> Screenblaster-Screensaver (schaltet dunkel)
SBLASTER --?? ScreenBaster? -> Ja
SB_HUTU --?? -> muss ich nachsehen, meine auch irgendwas für Screenblaster
SCC --?? -> HSMODEM
SELECTRIC --?? Alternative File Chooser..? -> Ja, super!!!
WINX --?? -> TOS/GEM-Patches, benötigt ROMRAM, ROMSPEED, GEMRAM, etc. siehe oben
ZMAGXSND --?? -> Irgendsowas was im Desktop Samples abspielt, wollte ich mal ausprobieren... (Magic Sound heißt das glaub ich)

ACC:
CHMELEO01-04 --?? -> Kann ACCs nachladen und wieder rauswerfen
KUBIS --?? -> Tetris CLone
MC_TALK4 --?? -> Midicom
MIDI_COM --?? -> Midicom ST-Netzwerk über Midi
PAULA --?? -> Modplayer (Amiga MOD Files)
VIBRAX --?? -> Weiß ich jetzt gerade nicht

CPX:
3DBUTTON --?? -> Gehört zu WIniX, glaub ich, oder zu WDIALOG
BASIC000 --?? -> Basic-Interpreter, mehr nur ein lustiger Gag
BASIC030 --?? -> Das gleiche mit 68030 Unterstüztung
BOOT --?? -> Macht irgendwelche Botflags, muss nachsehen
BOOTREG --?? -> dito

Die Liste der CPX(es) endet im Bild bei "C"... - da hast offenbar jede Menge...

 

Ja, ich hab noch mehr. Habe aber das aussortiert was ich bestimmt nicht brauche und in einen Unterordner auto\more\ und auto\acc und auto\cpx versteckt... Bei den CPXen habe ich noch nicht aussortiert, ist aber nur das aktiv (naja halbwegs) was ich brauche.

[atari-inside]

Wow - vielen Dank für deine ausführlichen Anmerkungen!