10
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!
Neueste Beiträge