GeForce emulation #496
Replies: 20 comments 35 replies
-
|
Impressive :) |
Beta Was this translation helpful? Give feedback.
-
|
Nice. Does 3D acceleration work too or only 2D? |
Beta Was this translation helpful? Give feedback.
-
|
A few things have changed since my first post:
|
Beta Was this translation helpful? Give feedback.
-
|
I have somewhat ported the VGA part of the GeForce cards from Bochs to qemu, with the GF6800 + the 6800 VBIOS I get good display video @640x480 in Windows XP splash/loading screen. After that the screen is black! |
Beta Was this translation helpful? Give feedback.
-
|
Can Bochs GeForce 6800 emulation support 2 screens currently? |
Beta Was this translation helpful? Give feedback.
-
I think such discussions should be public so other people can learn from them.
I think it is better to start with original GeForce BIOSes. GeForce 3 BIOS tries to work on almost everything and there are not much changes needed to make GeForce BIOSes work properly in MS-DOS.
I suspect AGP support is not that much required for GeForce emulation to work properly. Most likely, it is enough to not advertise it in PCI configuration space and that's it.
I remember some Linux LiveCDs were using not only video memory writes, but also reads, if you implemented only writes, that may be the cause. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks is there any source of geforce bios collection for x86 other than poweruptech who only seems to have GF6200+ VBOIS?
Qemu does some weird things with VGA I have not figured out yet.
I’ll gave VESA mode a try and see how it goes, I was able to get basic VGA support for Windows 7 but only with safe boot also enabled. I can’t install newer nVidia drivers than whatever and updated windows 7 ships with or pulls in update on the install. The drivers installer do not recognize the card proper and refuse to install and Device manger doesn’t see the drivers in the extracted Nvidia folder as valid so it’s just the basic Win7 VGA driver in 4 bit color.
I had about 200 lines of code in my Geforce3.c when I got VGA working, now it has grown to 1000+ lines and all that code is useless and it didn’t add any of the functionally I was looking for.
Get-edid from linux read-edid package finds 1 i2c bus, not sure if that is a qemu standard device or my i2c implementation but it can’t find an EDID on that bus, so it switches to VBE mode and the Leadtech VBOIS you linked in you GF bios collection reports VBE 3.0 but when it reads LB I think it should return 0x03 or 0x07 on that 3 bit bus but it returns no DDC1 or DDC2 compatibility and I can’t figure out exactly what it reads to se tit?
Does it route through CTRC?
case 0x37: /* DDC SDA/SCL read */
case 0x3e: /* DDC data read */
/* Read-only registers */
return;
case 0x3f: /* DDC SDA/SCL write */
case 0x51: /* DDC alternate */
{
bool scl = (value & 0x20) != 0;
bool sda = (value & 0x10) != 0;
if (index == 0x3f) {
geforce_ddc_write(s, scl, sda);
s->crtc.reg[0x3e] = geforce_ddc_read(s) & 0x0c;
} else {
s->crtc.reg[index - 1] = (sda << 3) | (scl << 2);
}
}
break;
… On Aug 28, 2025, at 8:08 AM, Vort ***@***.***> wrote:
do you do email or some form of communication I can we can share code so I can pick you brain about code changes
I think such discussions should be public so other people can learn from them.
For example, you can create issue or discussion in your fork of QEMU on GitHub and @ ping me there.
However I doubt that I will be able to develop two emulations at the same time.
800x600 4 bit working with the SeaBIOS
I think it is better to start with original GeForce BIOSes. GeForce 3 BIOS tries to work on almost everything and there are not much changes needed to make GeForce BIOSes work properly in MS-DOS.
Bochs currently only emulates the AGP bus, but Qemu provides a chipset with PCI Express bus.
I suspect AGP support is not that much required for GeForce emulation to work properly. Most likely, it is enough to not advertise it in PCI configuration space and that's it.
but issues with Linux CD boot menus and graphics mode with text overlays in GRUB not rendering correctly
I remember some Linux LiveCDs were using not only video memory writes, but also reads, if you implemented only writes, that may be the cause.
By the way, do you know that you can force Windows XP into using of VESA mode by booting into safe mode (F8 key)?
If you will be able to make vbetest.zip <https://github.com/user-attachments/files/22024401/vbetest.zip> work with 640x480x16 mode (0-3-1-1), then refining support to pass heavier tests with XP should be pretty easy.
—
Reply to this email directly, view it on GitHub <#496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAX7TVYDIGEZMA7QPZP5FVD3P3WMVAVCNFSM6AAAAABYKCAVGGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRUGQ4DANY>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
BTW we have maintained a WikI for nVidia and ATI/AMD BIOS and GOP/EFI ROMs for over 20 years with a lot of the OEM and retail ROMs as well as custom mods made over the years for the Mac OS.
http://themacelite.wikidot.com/
If anyone is interested in this old stuff I’ve been working on getting these cards working in Qemu-system-ppc in PCI Passthough Mode and emulation. No huge success yet it’s just something I work on because I have a good understanding of it.
I was about to pass a real OEM APPLE GF6600 to qemu-system-ppc64 with the PSeries machine type and get the FCODE ROMs to run and display video in SLOF and Linux PPC64LE in console mode on the TTY.
I was able to get my emulated GF3 to initialize the display in Openbios with custom mods with the full FCODE ROM but Openbios has issues deploying it’s console when an FCODE ROM is used rather than built in FDCOE for display devices like vga std in Qemu.
Openbios just expects it will be running on that graphics adapter or ATY,Rage and has builtin FCODE to get the console up on them.
I did not think to try linux ppc here to see if I could get to the tty in VGA mode. The Nouveau drivers have a special kernel args for loading a VBIOS from a file and that has worked for me in the past to get display out of cards with the wrong VBOIS or FCODE on the card.
Mac OS X doesn’t really play nice with VGA and expects everting to suuport OpenGL, but I have had luck with the emulated ATY,Rage and removing some of the drivers so it doesn’t try to do any 2d/2d acceleration because that’s mostly unimplemented on our rage because the leaked whiteparper for the Rage 128 doesn’t cover that. However it works at least as well as Qemu’s vga std with full ’NDRV’ support.
I’d love to feed the source code of linux’s old Rage128 driver to an AI and see what we can get working there as far as acceleration, Balaton Zoltan was able to get 2d acceleration working somewhat with MorphOS but I guess had no interest in the Mac OS.
Just stuff I’ll be working on for sometime yet.
… On Aug 28, 2025, at 8:08 AM, Vort ***@***.***> wrote:
do you do email or some form of communication I can we can share code so I can pick you brain about code changes
I think such discussions should be public so other people can learn from them.
For example, you can create issue or discussion in your fork of QEMU on GitHub and @ ping me there.
However I doubt that I will be able to develop two emulations at the same time.
800x600 4 bit working with the SeaBIOS
I think it is better to start with original GeForce BIOSes. GeForce 3 BIOS tries to work on almost everything and there are not much changes needed to make GeForce BIOSes work properly in MS-DOS.
Bochs currently only emulates the AGP bus, but Qemu provides a chipset with PCI Express bus.
I suspect AGP support is not that much required for GeForce emulation to work properly. Most likely, it is enough to not advertise it in PCI configuration space and that's it.
but issues with Linux CD boot menus and graphics mode with text overlays in GRUB not rendering correctly
I remember some Linux LiveCDs were using not only video memory writes, but also reads, if you implemented only writes, that may be the cause.
By the way, do you know that you can force Windows XP into using of VESA mode by booting into safe mode (F8 key)?
If you will be able to make vbetest.zip <https://github.com/user-attachments/files/22024401/vbetest.zip> work with 640x480x16 mode (0-3-1-1), then refining support to pass heavier tests with XP should be pretty easy.
—
Reply to this email directly, view it on GitHub <#496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAX7TVYDIGEZMA7QPZP5FVD3P3WMVAVCNFSM6AAAAABYKCAVGGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRUGQ4DANY>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
With #596, Windows Aero works now. With glitches, however: |
Beta Was this translation helpful? Give feedback.
-
|
Do I get it right that the models being emulated in reality support VBE 3.00 ? Judging according to Universal VBE Video Display Driver (for Windows NT Architecture). |
Beta Was this translation helpful? Give feedback.
-
|
I found the register that sit this and added them to the qemu code when Debain PPC64 BE nouveau drivers complained. I’ll dig up the registers if anyone cares?
… On Sep 3, 2025, at 6:39 PM, Andrew Randrianasulu ***@***.***> wrote:
I don't know about PPC specifics. What is the main problem with it? Big endianness? Code itself is a good enough documentation. xemu is almost QEMU as far as I can see, many approaches can be taken from there. For newer cards, RPCS3 can be used as reference. Some ideas can also be taken from envytools project and from official NVIDIA header files. (Code from my fork is now merged into main Bochs branch by the way)
PCI is always little-endian, just getting OpenBIOS to support FCode ROMs is an issue SLOF complies better. We've gotten OpenBIOS to support the FCode so it runs to end0 but we get no EDID for a connected display, so their is some issue the Openbios and the EDID/I2C code, SLOF works fine tho. PCI Passthough works fine in qemu-system-x86, so it's just really a matter of sorting out the FCODE and OpenBIOS so they are compatible. Shorter debug times helps.
In recent NetBSD commit I saw comment about endiannes for MMIO:
***@***.*** <NetBSD/src@3a309eb>
first thing we need to make sure register access uses host byte order
* so we can recycle as much of xf86-video-nv as possible
whole commit add some framebuffer/console accel support for mobile gf5200 variants, as far as I can tell (probably for ppc laptops, knowing aithor's history ;) )
—
Reply to this email directly, view it on GitHub <#496 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAX7TVZ7DRGHZPOUXGEGSO33Q5U3JAVCNFSM6AAAAABYKCAVGGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZQGEYDOMA>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
/* --- Big-endian control registers (NV04+) --- */
#define NV_PMC_BOOT_1 0x000004u /* PMC boot/BE control acks */
#define NV_PBUS_PCI_NV_19 0x00001804u /* PBUS config - BE control mirror */
#define NV04_PFIFO_BIG_ENDIAN 0x00002104u /* PFIFO big-endian control (NV04+) */
#define NV10_PGRAPH_BIG_ENDIAN 0x004006F0u /* PGRAPH big-endian control (NV10+) */
… On Sep 4, 2025, at 10:45 PM, Andrew Randrianasulu ***@***.***> wrote:
I found the register that sit this and added them to the qemu code when Debain PPC64 BE nouveau drivers complained. I’ll dig up the registers if anyone cares?
[…]
I care, at least from public documentation point (sorry, I mostly keep my main desktops offline, unless I try to work on something specific). So, please dig and post your findings.
—
Reply to this email directly, view it on GitHub <#496 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAX7TV67YYXSTH6Z66LFWIT3RD2LTAVCNFSM6AAAAABYKCAVGGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZRGM2DGMY>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
Tried my custom livecd with kernel 4.2.0 and mesa 17.0.7 (mostly Slackware 14.1): Some xscreensavers worked (glplanet, gltext, glsnake)
|
Beta Was this translation helpful? Give feedback.
-
|
With #623 applied, Windows 7 Aero looks much better: |
Beta Was this translation helpful? Give feedback.
-
|
Amazing! Where does the 3D emulation run? Host CPU (how many threads?) or host GPU? I assume you're not using guest Mesa like SoftGPU?
I suggest GF700/Titan Z (the last for XP), GF10/Titan Xp (the last for Win10x86/Win8/Win7x86) and RTX3090Ti (the last for Win7x64) |
Beta Was this translation helpful? Give feedback.
-
|
Vort, I have been following along with your work. It's quite impressive. Out of curiosity, I tried booting Bochs with UEFI and your So I went investigating a little and found that the UEFI doesn't show to the screen at all, no matter the display driver if the chipset is i440bx instead of i440fx. For example, boots just fine (i.e.: the screen is shown). However, when changing to i440bx ( The UEFI must only work on i440fx, or I must build the UEFI with a flag to indicate i440bx, I don't know, I didn't try. Anyway, two questions for you. First, have you tried booting UEFI with your Second, and this is coming from someone who has very little knowledge in actual video display other than Legacy VGA and VESA Frame buffers, what do you recommend for someone who would like to program the other side of the emulation, the actual OS driver? I am sure you are learning a considerable amount doing the emulation. I would like to learn doing the OS Driver side. Where would you recommend I start? Thank you, and quite impressive work. Ben Edit: After more investigation, it doesn't make it past the ACPI initialization code. From the log: This may have to do with the fact that Bochs doesn't set up the ACPI correctly (#560). However, UEFI boots just fine when i440fx is used, though now you can't use |
Beta Was this translation helpful? Give feedback.
-
|
For future reference, it doesn't look like we will get EDK2 UEFI and Bochs to work together when using On a different note, I noticed the following in Bochs' pci.cc: Lines 84 to 91 in 3608cfd In line 88, shouldn't 0x7190 actually be 0x7191? The 7190 is a BX without AGP, the 7191 is a BX with AGP, and the 7192 is a BX with AGP disabled. Just curious.
|
Beta Was this translation helpful? Give feedback.
-
|
Indeed it does. Thank you. Edit: Somehow I missed it, the 0x7191 is at: Lines 617 to 625 in 1d4940a It will teach me :-) Anyway, thank you. |
Beta Was this translation helpful? Give feedback.
-
|
I found something for the leadtek GeForce collection: |
Beta Was this translation helpful? Give feedback.












Uh oh!
There was an error while loading. Please reload this page.
-
Bochs is a useful tool for learning how computer hardware and software work.
I was using it successfully for figuring out how DOS and Windows 95 games interact with hardware.
However, starting with Windows XP, problems began to appear.
Besides slowdowns, which are understandable, incomplete support of modern technologies started to show up.
Voodoo 3 card, which is fully supported in Windows 95, has no official drivers for Windows XP and with unmodified Windows 7 x64 can work only in VESA mode.
And even when Windows 7 x64 is forced to accept unofficial drivers, there is no way to use modern features like Windows Aero.
Such situation made me thinking about implementing of emulation for more modern video card.
I started to look which card has official support for Windows 7 x64 and at the same time has drivers available for older operating systems.
According to Wikipedia, GeForce 6800 is a good candidate because it has support ranging from Windows 95 to Windows 8.
Adjacent candidates, GeForce 7 series - lacks support for Windows 95, GeForce FX series - lacks support for Windows 7.
Another benefit of GeForce 6800 is that it is available in two variations - NV40 (AGP) and NV45 (PCIe), which allows to develop NV40 emulation with already available AGP support and then with minimal changes to obtain test card for helping with PCIe implementation (#444).
Because Voodoo 3 emulation is already quite complex, I had concerns that it may be not easy to even start making progress with GeForce 6800 emulation. Luckily, I have access to simpler card, GeForce 3 Ti 500 (NV20), so I decided to check how much efforts are needed to get at least some result.
According to Pareto principle, chances to achieve simple goals in a reasonable time looked pretty good.
It is usually hard to figure out what is wrong when nothing works, so I decided to get emulation to the point when bugs can be tracked visually - in other words, operating systems boot successfully and display at least something on screen.
To my surprise, DOS started to work right away. It was needed to make some changes for VBE support, but overall it was fine.
Next goal was Ubuntu 10.04.4, because I read that it was the first version with nouveau driver. It was nice choice, because early versions of nouveau required almost no hardware acceleration features.
Ubuntu 12.04.5 uses nouveau as well, but with acceleration this time. Available source code allowed to approximately figure out what OS expects from video card.
Ubuntu OSes had downside however - very slow loading speed, so I decided to go Windows route next. Windows XP default driver turned out to be more demanding than nouveau, but not that much.
The most problems came from Windows 95. Even with oldest driver, 23.11, it required significant amount of features to be implemented correctly to get past hangs in the boot process. However, reward is appropriate - it boots fast, which allows for faster testing cycles.
This is the point where GeForce 3 Ti 500 emulation is at this moment.
With code from my geforce branch, original video BIOS and modified main BIOS (or fresh i440fx; to avoid #485), Windows 95 just boots. Not much else.
Windows 95 screenshot
Next, emulation can be improved (by me or someone else) by looking at image output and modifying code to match expected result. Another possibility is to start code migration from xemu project. It has pretty good implementation for XGPU from Xbox (NV2A), but it lacks some features required by PC drivers and it has no software rendering implemented.
Beta Was this translation helpful? Give feedback.
All reactions