AtariX => MagicOnLinux

[AndreasKromke]

Es ist gruselig! Auch ohne NVDI ist ein Fehlkonzept im VDI/XBIOS, das bei den "großen" Bildschirmtreibern, also bei denen mit VT52-Code, zum Durcheinander führt. Das kann man folgendermaßen testen:

- 16M Farben einstellen, kein NVDI
- VT52.PRG deaktivieren
- Mit Strg-B die Shell öffnen
- SID oder SD starten
- Mit Strg-C den Debugger beenden

Ergebnis: Ein bunter Cursor, grün und rosa.

Die Ursache: Xbios Cursconf(), hier mit den Unterfunktionen "cursor hide" und "cursor show". Eigentlich gehört das ins BIOS, nicht ins XBIOS, weil es den VT52 betrifft. Und Cursor ein/aus kann man auch über Esc-e und Esc-f machen. Cursconf springt aber direkt ins MVDI, auf die Sequenzen esc_e und esc_f, unter Umgehung (!) des Grafiktreibers. Die Kernel-Routine kann aber diesen Modus nicht und macht den Bildschirm seltsam.

Ich habe dann in meiner Naivität das Cursconf() geändert, so daß es über con_state springt, genau wie das BIOS Bconout. Aber, ach, es erschien nur seltsamer Mist auf dem Bildschirm. Es sieht so aus, als ob con_term gerade auf die Routine zeigt, die das Zeichen nach dem Esc verarbeitet, statt auf die Grundroutine, die auf Esc wartet. Es müßte also jemand mittendrin in einer Esc-Sequenz das Cursconf() aufgerufen haben. Wie das? Ich hab's erstmal aufgegeben.

Ich habe spaßeshalber mal NVDI aktiviert, und hier läuft dann eine Cursor-Blink-Routine, die, wie die interne, Byte-Zugriffe statt 32-Bit-Zugriffe aufs VRAM macht und damit einen grünen Cursor erzeugt. Aber das ist eine andere Geschichte.

[AndreasKromke]

(gelöscht)

[don_apple]

@AndreasKromke Ich habe jetzt mal einen Debug-build von magiclinux gemacht, und wenn ich magiclinux starte gibt es einige Meldungen auf der Konsole (siehe angehängte debug.txt).

Vielleicht ist das ja für dich interessant um ggf. Fehler im Code zu finden und zu bereinigen.

Die letzte Warnung

Code: [Auswählen]

(17:55:57) DBG-WRN hostpath2HostFD() : fstatat("GEMSYS/MAGIC/STOP/") -> No such file or directory
läßt sich relativ einfach beheben, indem man den Ordner "STOP" im rootfs erstellt. Vielleicht kannst du das ja im Upstream-Repo anpassen das da der Ordner gleich vorhanden ist.

Edit: die beiden Warnungen vom shutdown.prg

Code: [Auswählen]

(17:55:57) DBG-WRN m68k_write_memory_32() -- 68k vec 0x00000008 := 0x0016e736 (bus error) by process C:\GEMSYS\GEMDESK\shutdown.prg
(17:55:57) DBG-WRN m68k_write_memory_32() -- 68k vec 0x00000008 := 0x007cb4a0 (bus error) by process C:\GEMSYS\GEMDESK\shutdown.prg
konnte ich jetzt auch beheben, indem ich das shutdown.prg durch die version aus den aktuellen Snapshots von https://tho-otto.de/snapshots/magicmac/ ersetzt habe.

[AndreasKromke]

Die Meldungen sind irrelevant. Ich habe sie nur deshalb als ERR oder WRN statt INF definiert, damit sie überhaupt angezeigt werden.

Ich habe übrigens Cursconf() reparieren können, im Kernel. Es sollte jetzt ohne NVDI keinen Cursor-Salat mehr geben. Leider hat das nichts an den Fehlern mit NVDI geändert. Startet man z.B. MCMD unter NVDI in 16M Farben, kriegt man einen grünen Cursor in doppelter Breite.

[Thorsten Otto]

Hätte mich auch gewundert wenn das nicht der Fall wäre Die Routinen in NVDI sind ja praktisch die gleichen. Vermutlich passiert das auch auf echter Hardware, mit Treibern für Grafikkarten.

[Lukas Frank]

Bei meinem Atari TT mit Matrix TC1208E und NVDI 5.03TC als Treiber ist die 16,7M Farben Darstellung einwandfrei ...

Edit: Nova Treiber mit MACH64 ist bei 16,7M Farben auch in Ordnung auf einem 030 Mega ST

[AndreasKromke]

Danke für die Vergleichstests! Kam mir auch in den Sinn, leider habe ich keine Hardware mehr.

Ich widme mich erstmal dem grünen Cursor in 16M Farben. Dazu kann ich die Byte-Zugriffe aufs VRAM rückverfolgen (Zugriffe sollten hier fürs Blinken immer 32-bit sein).

[AndreasKromke]

Das NVDI-VT52-Zeugs kann eigentlich nie funktioniert haben. Der Cursor hat zwei (!) Probleme. Einmal blinkt er grün. Wenn man bei Programmadresse 0x45206 den Befehl von 0x548b -> 0x528b ändert, ist das Grün weg. Das ist die Cursor-Routine, die im NVDI.PRG liegt und byteweise schreibt, seltsamerweise horizontal immer mit einem Byte Lücke. Das funktioniert wohl irgendwie bei den alten Grafik-Modi. Diese Cursor-Routine wird bei Cursconf() aufgerufen, das NVDI hängt nämlich auch in Cursconf().

Im NFM16M-Treiber gibt es, genau wie in MFM16M, dann wieder eine richtige Cursor-Routine, die aber bei Cursconf() nicht aufgerufen wird (wenn überhaupt?) - gleicher Fehler wie im Kernel.

Das zweite Problem ist der Cursor, der Spuren hinterläßt, vorher grün und mit meinem Hack schwarz.

Eigentlich könnte man gleich 0x44EB4 auf 0x4e73 (rte) patchen und damit die Behandlung von Cursconf() im NVDI ganz rauswerfen. Das allein bringt aber nix, wäre nur eine Zusatzmaßnahme.

Bleibt als nächstes die Frage, warum nicht die Cursor-Routine vom Treiber ausgeführt wird.

Wie kann das je funktioniert haben?

Das NVDI-"Disassembly" hat übrigens rund 117k Zeilen ...

[Thorsten Otto]

Das NVDI-"Disassembly" hat übrigens rund 117k Zeilen ...

Von 5.03? Ja, meins auch. Allerdings sind grosse Teile davon (das ganze Vektor-Font-Gedöns, diverse Hilfs-Funktionen) wohl ursprünglich mit Pure-C geschrieben. Bei 4.12 sind es übrigens "nur" rund 55k Zeilen.

[KarlMüller]

Die Mac Version nebst IKEA genormter Bauanleitung gibt's hier:

Hmm... irgendwas klemmt da bei mir:

Code: [Auswählen]

labdev:~/tmp/MagicOnLinux/build $ cmake -G Xcode ..
CMake Error:
  Xcode 1.5 not supported.

Kann jemand sagen wie man das umschiffen kann? Ich habe hier ein 15.7.3. Laut den Verzeichnissen in SDK ist MacOS14.5 bis MacOS26.2 instlliert.

[don_apple]

Die Mac Version nebst IKEA genormter Bauanleitung gibt's hier:

Hmm... irgendwas klemmt da bei mir:

Code: [Auswählen]

labdev:~/tmp/MagicOnLinux/build $ cmake -G Xcode ..
CMake Error:
  Xcode 1.5 not supported.

Kann jemand sagen wie man das umschiffen kann? Ich habe hier ein 15.7.3. Laut den Verzeichnissen in SDK ist MacOS14.5 bis MacOS26.2 instlliert.

Was sagt "xcode-select -p"?

Und "which cmake"?

[Thorsten Otto]

Ich habe dann in meiner Naivität das Cursconf() geändert, so daß es über con_state springt, genau wie das BIOS Bconout. Aber, ach, es erschien nur seltsamer Mist auf dem Bildschirm.

Ich hab mir gerade mal die Änderungen in HOSTBIOS.S angeschaut. Dort wird immer noch genaus das gemacht (über con_state zu springen). Funktioniert das jetzt doch?

Ansonsten, falls con_state wirklich gerade im ESC-Modus ist, könnte man es auch vorher mit einem 0-byte in d1 Aufrufen. Das sollte den ESC-Modus zurücksetzen, und würde auch im normalen Modus nichts ausgeben. Würde nur nicht funktionieren, wenn gerade eine ESC-Sequenz mit Parametern bearbeitet wird (ESC-Y zB.)

[AndreasKromke]

Ich hab mir gerade mal die Änderungen in HOSTBIOS.S angeschaut. Dort wird immer noch genaus das gemacht (über con_state zu springen). Funktioniert das jetzt doch?

Ich war falsch über con_state gesprungen und habe nach der Korrektur meine Nachricht hier nicht dahingehend revidiert.

PS: Mit dem Deaktivieren von Cursconf() in NVDI ist zwar der grüne Cursor weg, aber er blinkt gar nicht mehr und ist meist unsichtbar. Irgendwo ist da eine Nebenwirkung. Es bleibt wohl nur übrig, das Zeugs tiefer zu analysieren.

[Thorsten Otto]

NVDI 3.x hatte ich mal angefangen zu rekonstruieren (aber noch nicht zuende gebracht). Denke mal daß dieses VT52-Zeug in 5.x nicht viel anders ist. Bei Interesse kann ich dich mal zum github repo einladen, vlt. hilft es ja weiter (dazu brauchtest du dort allerdings wohl einen Account). NVDI 2.51 ist dort auch (komplett).

Ansonsten vermute ich mal, daß es einfach nicht vorgesehen war, daß NVDI unter MagiC ohne VT52.PRG läuft

[AndreasKromke]

Ich nehme an, daß das Problem im Doppeltreiber liegt. MVDI hat eine Cursor-Routine, der MFM16M hat eine weitere, in NVDI.PRG ist eine dritte, und in NFM16M liegt die vierte. Das schafft Raum für Mistverständnisse.

[Thorsten Otto]

Kann schon sein. Wobei dein Fix theoretisch funktionieren sollte. Wenn statt Cursconf() Bconout() zum Ein-/ausschalten des Cursors benutzt wird, passiert ja eigentlich nichts anderes.

Was ich mir vorstellen könnte ist, daß NVDI selber V_HID_CNT erhöht, und dann die eigentliche Routine aufruft, wodurch der Zähler dann nochmal erhöht wird. Das würde zumindest erklären warum er unsichtbar bleibt.