Hardware > Emulatoren

AtariX => MagicOnLinux

<< < (72/77) > >>

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.

KarlMüller:

--- Zitat von: don_apple am Mo 26.01.2026, 21:42:58 ---Was sagt "xcode-select -p"?

--- Ende Zitat ---
/Library/Developer/CommandLineTools


--- Zitat von: don_apple am Mo 26.01.2026, 21:42:58 ---Und "which cmake"?

--- Ende Zitat ---
/usr/local/bin/cmake

AndreasKromke:
Schau an: Der NFM16M.SYS wird anscheinend gar nicht geladen. Ich habe ihn nicht im Speicher gefunden und deshalb einfach mal umbenannt, und - voilà - nichts. Man kann auch nicht den NFM16.SYS statt des MFM16.SYS verwenden, dann stürzt das System ab. Die sind wohl nicht kompatibel.

Bleibt jetzt die Frage, warum der NVDI-Treiber nicht geladen wird und wo das VT52-Zeugs eigentlich liegt, das dann aktiv ist. Und ob man versucht, das NVDI zum Laden seines Treibers zu bringen, oder sich mit dem MFM-Treiber anzufreunden. Das ist irgendwo ein übler Konzeptfehler.

don_apple:

--- Zitat von: KarlMüller am Di 27.01.2026, 18:21:27 ---
--- Zitat von: don_apple am Mo 26.01.2026, 21:42:58 ---Was sagt "xcode-select -p"?

--- Ende Zitat ---
/Library/Developer/CommandLineTools

--- Ende Zitat ---
OK, das ist denke ich der Grund warum das nicht funktioniert.

Führe mal bitte

--- Code: ---sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

--- Ende Code ---
aus (anschließend nochmal mit xcode-select -p verifizieren das der Pfad geändert wurde) und versuche dann nochmal "cmake -G Xcode .."

AndreasKromke:
Ich wäre Euch dankbar, wenn Ihr folgenden "patch" ausprobieren könntet, um die VT52-Problematik zu vermeiden (alle Daten sedezimal, was fälschlicherweise mal von irgendeinem Ignoranten als "hexadezimal" bezeichnet wurde. Dämlich.):

Adresse 0x44ed6: Byte 62 -> 60.
Adresse 0x39bdc: 21fc 0004 5110 0070 -> 2039 0004 5110 4e71
Adresse 0x44cc6: 21fc 0004 5030 0586 21fc 0004 4ffe 0592 -> 2039 0004 5030 4e71 2039 0004 4ffe 4e71

Hintergrund: Das NVDI biegt Cursconf() sowie VBL-Cursorblinken und conout und raw_conout auf eigene Routinen um. Und die funktionieren nicht, d.h. der Code für die jeweiligen Grafik-Modi existiert gar nicht im NVDI.

Ursache ist vermutlich, daß NVDI eigentlich seine N**.SYS-Treiber laden sollte, tut es aber nicht, vielleicht weil es die M**.SYS-Treiber findet und denkt, das paßt scho. Vielleicht könnte man auch versuchen, das NVDI statt des MVDI zu laden, d.h. der Kernel müßte vor der VDI-Initialisierung schauen, ob es ein NVDI.PRG gibt, und das dann stattdessen laden. Dann würde aber bereits die Begrüßungsformel ("Willkommen bei NVDI 5.03") ins Leere laufen. Das könnte kompliziert werden.

PS: Ihr könnt auch versuchen, den angehängen "patch" mit bspatch zu applizieren (bspatch NVDI.PRG NVDI_PT.PRG NVDI.patch) . Das prüft aber vermutlich nicht, ob die Originaldaten die erwarteten sind. Also auf eigene Gefahr!

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete