Some info about XP modesetting that might possibly be useful
Hello,
Not sure how helpful this is, but this page might have useful information about how the Windows XP video driver modesets: https://web.archive.org/web/20070217203935/http://wiki.onmac.net/index.php/Developers/Technical_Information
XOM itself might also be somewhat helpful, but it’s a giant hackjob from what I can tell (it does fun things like detecting the GPU model by checking the screen resolution). It does allow Windows XP to run on EFI using NTLDR, which means there’s some sort of CSM going on here, but its pseudo-CSM implementation seems to be far more limited than yours.
Thanks for the info! Will look into it.
I think the issue might actually be related to the SeaBIOS VGA driver trying to set an unsupported mode from the list it has hardcoded using CRTC. Maybe passing the mode list from UEFI GOP will work.
UEFI GOP doesn't support changing the resolution after ExitBootServices unlike legacy BIOS, you can see this by booting up Windows in safe mode on a UEFI system.
It might also be helpful to know that when you boot the Debian installer, regardless of whether it's in graphical or text mode, the message Undefined video mode number: 314 appears on the screen. This seems to imply some sort of issue with the way VESA modes are set up.
Alpine Linux CD seems to display absolutely nothing on the VESA framebuffer (not sure if it's supposed to though), while Debian displays the installer in QEMU but not on the port of csmwrap I recently began for the original Apple TV (an EFI-based machine, but 32 bit and locked to Apple EFI executables). Some of that might be me doing something wrong, but it might also be an issue on other real hardware.
Also, if the OS is writing to the legacy VGA ports or locations in memory, it probably won't work for now (some PCI configuration space changes might allow you to work around that). In my experience, VMs tend to leave those ports enabled on UEFI platforms for whatever reason.
I think the issue might actually be related to the SeaBIOS VGA driver trying to set an unsupported mode from the list it has hardcoded using CRTC. Maybe passing the mode list from UEFI GOP will work.
Nah it's not the case. SeaBIOS VGA actually tries to emulate any resolution larger than initial EFI GOP mode by stride (linebytes) of VBE LFB property. So OS would see extra space on screen as non-scanout region.
When it's functioning, it looks like:
UEFI GOP doesn't support changing the resolution after ExitBootServices unlike legacy BIOS, you can see this by booting up Windows in safe mode on a UEFI system.
csmwrap's VBIOS never interact with GOP, it just takes framebuffer location and resolution & pixel format from GOP initially.
The problem is Windows tried to set a mode which is not even on VBE's supported mode reporting.
Alpine Linux CD seems to display absolutely nothing on the VESA framebuffer (not sure if it's supposed to though), while Debian displays the installer in QEMU but not on the port of csmwrap I recently began for the original Apple TV (an EFI-based machine, but 32 bit and locked to Apple EFI executables). Some of that might be me doing something wrong, but it might also be an issue on other real hardware.
Yup, it seems like EFI GOP's initial resolution is critical.
Also, if the OS is writing to the legacy VGA ports or locations in memory, it probably won't work for now (some PCI configuration space changes might allow you to work around that). In my experience, VMs tend to leave those ports enabled on UEFI platforms for whatever reason.
Yes, that's why I did this:
https://github.com/FlyGoat/csmwrap/commit/9ff579d0f408be6a73c198c7457c5954cf44c1e1
On the Apple TV port, I don't properly read the VGA arbitration code and just hardcoded the NVIDIA card's bus/dev/func in hopes of taking a shortcut and avoiding a PCI implementation. Guess I can't do that, I will fix in my port.
On the Apple TV port, I don't properly read the VGA arbitration code and just hardcoded the NVIDIA card's bus/dev/func in hopes of taking a shortcut and avoiding a PCI implementation. Guess I can't do that, I will fix in my port.
What's your issue on PCI implementation? Apple's implementation didn't provide proper PCI protocols? Or difficulties on glue up IA32 posix-uefi port?
SeaBIOS standard VGA mode setting seems to also use those VGA ports to access the CRTC.
https://github.com/coreboot/seabios/blob/master/vgasrc/stdvgamodes.c#L456
SeaBIOS standard VGA mode setting seems to also use those VGA ports to access the CRTC.
https://github.com/coreboot/seabios/blob/master/vgasrc/stdvgamodes.c#L456
csmwrap is not using this code path, we are actually using a variant of cbvga, see:
https://github.com/FlyGoat/seabios-csmwrap/blob/507f99b8955dc220bf2dcd5df09d7fdf979fe91a/vgasrc/cbvga.c#L187
Thanks
On the Apple TV port, I don't properly read the VGA arbitration code and just hardcoded the NVIDIA card's bus/dev/func in hopes of taking a shortcut and avoiding a PCI implementation. Guess I can't do that, I will fix in my port.
What's your issue on PCI implementation? Apple's implementation didn't provide proper PCI protocols? Or difficulties on glue up IA32 posix-uefi port?
The Apple TV’s EFI has a verification process that makes it so that it only supports loading Apple EFI executables. However, the Apple EFI bootloader intended to boot the stock OS (essentially Mac OS X) does zero verification, so getting low code execution is as easy as creating a static Mach-O executable that parses the Mac OS X kernel arguments structure. I don’t have boot services in that environment so I have to implement all the hardware stuff manually (thankfully the BIOS memory regions are unlocked by default on the Apple TV) and when I did the rest of the implementation of loading SeaBIOS I just glossed over the part of your code that did PCI arbitration. I’ll have to implement my own PCI read/write functions in order to do the same thing you did with the PCI protocols that are part of boot services.
When it's functioning, it looks like:
can it do some centering?
When it's functioning, it looks like:
can it do some centering?
No... There is no way to set line offset in VBE mode info...
No... There is no way to set line offset in VBE mode info...
hmmm but looks like in vesa you need to get screen start address and bytes per scanline before write to screen now? you just mapping old video modes in new one but with big next scanline displace as for new video mode you maybe can just return address in "center" of screen as screen start address with same bytes per scanline or not?
No... There is no way to set line offset in VBE mode info...
hmmm but looks like in vesa you need to get screen start address and bytes per scanline before write to screen now? you just mapping old video modes in new one but with big next scanline displace as for new video mode you maybe can just return address in "center" of screen as screen start address with same bytes per scanline or not?
Seems not working with ntldr.
Seems not working with ntldr.
may it wants some aligned value?
or it think all videomodes starts from same address? and gets it only once?
If NTLDR (or anything else) is using the standard VGA I/O ports or memory addresses instead of reading that address from VESA, then there’s likely no chance of centering the address doing anything.
Seems not working with ntldr.
may it wants some aligned value?
or it think all videomodes starts from same address? and gets it only once?
@NS-Clone If you need this couldn't you just modify the source code to add a SetMode call to the GOP driver for the mode you want ?
Seems like using the existing legacy VGA ROM is being worked on currently though.
But on GPUs which don't support it (RX 9000 and Intel 12th gen+) it will be a very complex task but those will also require stuff like 0xA000 (along with other ones for text mode) and VGA IO ports to be faked too.
Seems like using the existing legacy VGA ROM is being worked on currently though.
I experimented with it a bit on the Apple TV without success, but this is beyond me. To the best of my understanding, using the legacy VGA ROM should work but its location might vary on laptops. Coreboot's testbios utility might also prove useful in loading the VGA ROM.
"But on GPUs which don't support it (RX 9000 and Intel 12th gen+) it will be a very complex task but those will also require stuff like
0xA000(along with other ones for text mode) and VGA IO ports to be faked too."
If this problem can be solved, this project will be pure gold. For me, biggest problem will be solved about retro OSes.
@DistroHopper39B isn't setting the video mode the only thing missing on the SeaBIOS VGA driver (they do support some ancient ATI card tho), which isn't too important ?
Using the stock VGA BIOS might fix modesetting on XP and other OSes it doesn’t work correctly on.
@DistroHopper39B Even after fixing the VGA IO ports ? I thought SeaBIOS VGA mode setting works just that it doesn't actually change it which causes black border
Some OSes don’t seem to like SeaBIOS VGA, for example the XP installer just freezes (If I had to guess, it tries to set an unsupported text mode).
Could also be something on the chipset and/or GPU needs to be setup for the 0xB8000 text memory to work.
No... There is no way to set line offset in VBE mode info...
hmmm but looks like in vesa you need to get screen start address and bytes per scanline before write to screen now? you just mapping old video modes in new one but with big next scanline displace as for new video mode you maybe can just return address in "center" of screen as screen start address with same bytes per scanline or not?
Seems not working with ntldr.
Regarding improving support for more video modes, what about integrating PluMGMK into CSMWrap's seabios, to emulate unsupported color palletes? Is it possible to do?
This is a rewrite of the Windows 3.1 SVGA driver, designed to support ALL available 8-bit, 16-bit, 24-bit or 32-bit graphic modes on any system providing the VESA BIOS Extensions (hence the VBE in the name). It is based on the Video 7 SVGA driver included in the Win16 Driver Development Kit, with most of the hardware-specific code gutted out, and with support added for multi-byte pixels.
https://github.com/PluMGMK/vbesvga.drv