EmuTOS 1.2.1 und VOFA ET4000 auf 520ST

[sportingt]

Guten Abend Frank,

jetzt haben wir die Ursache und Lösung!
Ja ich hatte immer einen ST-Gering Monitor dran.
Ich habe jetzt einfach einen ATARI/VGA Adapter reingesteckt. und den auf hohe Auflösung geschaltet.
Es ging sofort.
Echt doof. Normal arbeite ich fast immer mit ST-hoch. Hatte aus Platzgründen, nur einen Monitor am Tisch,
Um zwei Eingänge zu nutzen, einmal Video in, um den Bootvorgang zu sehen, und an der VOFA den VGA Eingang.
Wäre nie auf die Idee gekommen, dass EmuTOS mit geringer Auflösung nicht den Treiber korrekt starten.
Habe das in der EmuTOS doku nicht gelesen oder überlesen. Kleine Ursache, große Wirkung.

Danke Frank für die Übergangslösung!
Vielleicht gibt es dazu ja auch noch eine Erklärung, warum das EmuTOS dazu eine hohe Auflösung braucht, das ATARI TOS jedoch mit beiden Auflösungen die Emulator.PRG korrekt ausführt.

und Grüße an alle Beteiligten.
Thorsten

[czietz]

Danke Euch beiden fürs Eingrenzen des Fehlers. Ich gucke mir an, was EmuTOS hier macht. (Aufgrund meiner Todo-Liste wirds aber ein bisschen dauern. )

[czietz]

Ich habe bereits eine ziemlich fundierte Idee, woran es liegt und eine potenzielle Lösung. Allerdings kann ich heute Abend nicht testen. @Lukas Frank oder @sportingt : Möchte einer von Euch eine vermutlich gefixte EmuTOS-192k-Version testen? (Sonst mache ich das, aber halt eventuell erst in einigen Tagen.)

[Lukas Frank]

Ja hänge die mal hier an oder einen Link ...

[czietz]

Ja hänge die mal hier an oder einen Link ...

Danke. Siehe Anhang.

[Lukas Frank]

Heute nicht mehr, habe ganz schlimme Männergrippe oder Corana. Bin ja fünfmal geimpft und auch gegen Grippe, es geht mir dreckisch ....

[Lukas Frank]

@czietz ... funktioniert.

Sehr schön, wo war denn das Problem?

[czietz]

Danke für den Test. Ich werde den Fix voraussichtlich in den nächsten Tagen in die offiziellen EmuTOS-Sourcen einbauen.

Was war der Fehler? Zusammengefasst: Das EMULATOR.PRG von Nova-VDI schaltet TOS (per Setscreen XBIOS-Call) immer in den Monochrom-Modus. Falls ein Farbmonitor angeschlossen ist, schaltet es per direktem Hardwarezugriff kurz darauf Shifter und Glue zurück in den Farbmodus. Ich denke, das passiert, damit die TOS-internen Variablen auf 640x400x2 gestellt werden.

Nun gibt es - sowohl in Atari TOS als auch in EmuTOS - eine Erkennung in jedem Vertical-Blank-Interrupt, ob die Einstellung des Shifters zum angeschlossenen Monitor passt, um sonst durch den Reset zu gehen. (Das schützt Festfrequenz-Röhrenmonitore.) EmuTOS erkennt schon bevor das Nova-VDI den Shifter wieder zurückstellt, dass etwas nicht stimmt und löst eben den Reset aus.

Nun ist diese Erkennung kurzzeitig blockiert, so wie es in Atari TOS auch implementiert ist.

[Lukas Frank]

Sollte Idek dann die Atari ST und Mega STE Nova Treiber anpassen? Beim Atari Falcon und beim Atari TT gibt es das Problem ja nicht vermute ich? Und macht das dann Probleme unter einem Atari TOS?

Bei mir steht es unter 256 Farben auf Mittel siehe das Bild unter Atari TOS ...

[czietz]

Es gibt ein kleines Restrisiko eines Resets auch unter Atari TOS, nachdem der VBL von TOS wieder entsperrt wurde und bevor EMULATOR.PRG den Shifter wieder auf Farbmodus zurücksetzt. Insofern wäre es vermutlich sicherer, wenn das Nova-VDI den VBL sperren würde, bis der Shifter zurückgesetzt ist.

Aber da der EMULATOR.PRG unter Atari TOS in der Praxis nicht abstürzt, sollte er es unter EmuTOS auch nicht tun. Entsprechend werde ich den gefundenen und von Dir bestätigten Fix wie versprochen einbauen.

[czietz]

Oh, ich habe die Rückmeldung vergessen.

In EmuTOS-Snapshot 20231214-174428-bb217bd4 (https://sourceforge.net/projects/emutos/files/snapshots/) und allen neueren Snapshots ist der Fix enthalten.

Danke, @sportingt und @Lukas Frank fürs Melden und Testen!