GeForce emulation

[Vort]

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.

[sskras]

Impressive :)

[MrPepka]

Nice. Does 3D acceleration work too or only 2D?

[Vort]

I did not tried to implement 3D yet.
It is possible to go this way, but I think it is more important to make sure that operating systems activate 2D acceleration successfully and at least display cursor and text, so it is possible for user to interact with OS.
It may look easy, but for some reason GeForce cards have lots of ways for doing the same things. For example, right now I'm having problem with activation of mouse cursor in Windows XP. I know how Ubuntu turns it on and off, I know how Windows 95 turns it on and off, but Windows XP uses different approach - it somehow turns cursor on once during boot and then never really turns it off, but instead moves cursor offscreen, to (-77, -77) coordinates. update: I found fragment of code in driver which is responsible for turning cursor on (nvHalDacCursorEnable_NV10 function), forced driver to execute it and cursor appeared on screen, so it looks like I was wrong and XP actually uses the same mechanism as 95 (bit 0 of register 0x00600810), but something prevents it from working correctly.

[Vort]

A few things have changed since my first post:

1. Initially I thought that for good compatibility with various operating systems it will be enough to have only GeForce 6800 emulation, but this forum post helped me to understand that this is not the case: for Windows 9x, card compatible with 45.23 driver is needed. That's why I implemented option, which allows to switch card models: right now model=geforce3, model=geforcefx5900 and model=geforce6800 are supported.
2. After several fixes in main repository, modifications to main BIOS are not needed anymore: BIOS-bochs-latest works just fine. Original video BIOSes, however, are still required: here is collection of files, corresponding to implemented models: GeForceBIOSes.zip.
3. Operating systems support was improved and extended: despite having several features unimplemented, 2D acceleration mostly works from Windows 95 to Windows 7. Today last bugs preventing Windows 7 x64 driver (185.93) from loading were fixed:

[lyons88]

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.

[lyons88]

would you mind sharing your .bochsrc file, I'm have trouble with setting it up?

[Vort]

PCI is always little-endian

Lots of interaction with card is done via MMIO and I saw mentions at envytools of some flag which switches endianness of GeForce card. It may not matter, I'm saying it just in case.

would you mind sharing your .bochsrc file, I'm have trouble with setting it up?

Here is what I use for Windows 98 SE: Windows98_geforce.bxrc.zip.

[lyons88]

PCI is always little-endian

Lots of interaction with card is done via MMIO and I saw mentions at envytools of some flag which switches endianness of GeForce card. It may not matter, I'm saying it just in case.

would you mind sharing your .bochsrc file, I'm have trouble with setting it up?

Here is what I use for Windows 98 SE: Windows98_geforce.bxrc.zip.

Thanks, got it working with GF and a minimal .bochsrc!

Pretty cool stuff thanks for working on GeForce Emulation. If you checkout the DingusPPC Discord server https://discord.gg/TmQDUTK we discuss many things in the #emutalk section. Maybe someone over there will want to port GF work to Dingus.

[Randrianasulu]

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 ;) )

[lyons88]

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!

[Vort]

If black screen happens without driver installed (XP has no default driver for 6800), then it is most likely problem with VESA mode switch. You can try simpler test first - VBETest (version 5.1a or 5.3a) in DOS 6.22. It is glitchy by itself, but can give overall idea about what VESA code is doing.
In cases when XP is loading with driver installed, you can look in more detail what is happening by changing logging in Bochs like so: debug: action=ignore, geforce=report. Then you can look for example at lines like RAMIN read from 0x00000000, value 0x55 (copying of BIOS code) and execute_command: chid 0x00, subc 0x07, method 0x0d0, param 0x024002d0 (FIFO software request for mode switching) - these are one the first things driver (93.71) is doing.

[lyons88]

I'm stuck in the VBE code, a bunch of stuff about CRTC and such I just don't
understand I'll post a patch over at the qemu mailing list and see if anyone can help out!

[obsolete-is-better]

Can Bochs GeForce 6800 emulation support 2 screens currently?

[Vort]

There is no multi-monitor support in Bochs right now.
I saw such feature in VirtualBox, some ideas for implementation can be taken from there.
However, I think it is more important to focus on other tasks.

[lyons88]

There is no multi-monitor support in Bochs right now. I saw such feature in VirtualBox, some ideas for implementation can be taken from there. However, I think it is more important to focus on other tasks.

I'm having difficulties porting to Qemu, I just have the basic 640x400, 640x480, 800x600 4 bit working with the SeaBIOS and Windows on qemu-system-x86 but issues with Linux CD boot menus and graphics mode with text overlays in GRUB not rendering correctly. @Vort do you do email or some form of communication I can we can share code so I can pick you brain about code changes needed to port this to qemu? Really great work, emulation of 3D graphics acceleration is about the most challenging task I can think of without Whitepapers to guide you, thank you for undertaking this task!

[aqua-rgb]

There is no multi-monitor support in Bochs right now. I saw such feature in VirtualBox, some ideas for implementation can be taken from there. However, I think it is more important to focus on other tasks.

I'm having difficulties porting to Qemu, I just have the basic 640x400, 640x480, 800x600 4 bit working with the SeaBIOS and Windows on qemu-system-x86 but issues with Linux CD boot menus and graphics mode with text overlays in GRUB not rendering correctly. @Vort do you do email or some form of communication I can we can share code so I can pick you brain about code changes needed to port this to qemu? Really great work, emulation of 3D graphics acceleration is about the most challenging task I can think of without Whitepapers to guide you, thank you for undertaking this task!

Well, nice porting for GeForce emulation on QEMU, but I can't port GeForce emulation from Bochs to QEMU that much. so where is QEMU that has GeForce emulation that you ported it? I need to know!

[vruppert]

Bochs currently only emulates the AGP bus, but Qemu provides a chipset with PCI Express bus. So you need to find out how the PCIe variant of the GeForce 6800 handles the features that use AGP in Bochs.

[Vort]

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 work with 640x480x16 mode (0-3-1-1), then refining support to pass heavier tests with XP should be pretty easy.

[fuel-pcbox]

Some people are just averse to the forum format Bochs is currently exclusively using, myself included. We'd much rather have an IM-style format for communicating with devs than this.

[Vort]

IM conversations are usually not public and not accessible by Google and Internet Archive. People can't find them and without archive copies they can be easily lost (owner of IM service may decide to delete some data, or IM service itself can be closed).
Also it is harder to organize IM discussions - to split them into different topics, which is easily done with forum topics and tags in Issues.

[fuel-pcbox]

Most people don't care about that, they just want to be able to stream of consciousness interact with other developers. Also, you can literally set up an IRC channel to be publicly logged, just do that! I, and I'm sure others too, will thank you.

[lyons88]

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.

[Vort]

is there any source of geforce bios collection for x86 other than poweruptech who only seems to have GF6200+ VBOIS?

The Retro Web for example.

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.

I suggest to make advancements starting from simpler goals, then proceed with more complex goals.
If there are problems with getting high bpp modes in DOS, then there is no much sense in trying to get interesting results from Windows 7.

Does it route through CTRC?

EDID is read via CRTC, right.
There are several ports, corresponding to several supported displays.
These ports are specified in BIOS for particular card.
I remember get-edid tried to read information with BIOS calls, so I made tests with DOS version instead, since DOS is more suitable for such tasks.
For Linux I used i2cdetect or something like that, it required activation of some kernel module and I don't remember in details how I used it.
Overall, DDC mechanism in GeForce looks messy and it may be better to find easier tasks first.

[lyons88]

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.

[aqua-rgb]

@lyons88 Do you have any chance for fork this QEMU repository but with GeForce emulation? it means I can't find your QEMU repository with GeForce emulation I can test for it.

EDIT: Also, I can't port GeForce emulation from Bochs to QEMU, I'm lazy for porting from Bochs to QEMU for it. :/

[hkevinli]

Very impressive stuff. Brings back childhood memories of poring through hardware reviews and hunting for bargain parts to build my first computer. Keep up the good work!

Toy Solider demo: https://www.nvidia.com/en-us/geforce/community/demos/

[Vort]

@binarymaster

Oh nice, so there's a chance DWM / Aero will be figured out 👍

With #596, Windows Aero works now. With glitches, however:

[sskras]

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).

[Vort]

I don't know how well particular 3.0 features are implemented, but, in general, yes, it should be supported:

[lyons88]

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.

[Randrianasulu]

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.

[sskras]

@lyons88, I thought maybe it's more worth putting the discoveries on some dedicated place like nvwiki ?

It has a beginnings of register table for eg. NV3 chipset, IIUC:
https://nvwiki.org/index.php/NV3_configuration#PCI_configuration_registers

The nvwiki seemingly allows requesting the account creation. Though I don't know the process myself.

Pinging @starfrost013 as the main editor of it.

[sskras]

PS. Possibly the nVidia ROMs / flashing / hacking guides from the Mac Elite Wiki can be transferred here too. Eg:
http://themacelite.wikidot.com/wikidownloads2#:~:text=Original%20NVIDIA%20PPC%20ROMs
http://themacelite.wikidot.com/nvidia-general-flashing
http://themacelite.wikidot.com/nvidia-section
http://themacelite.wikidot.com/nv-rom

Just a thought. Unsure what do you @lyons88 think of that too.

[lyons88]

/* --- 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.

[Randrianasulu]

Tried my custom livecd with kernel 4.2.0 and mesa 17.0.7 (mostly Slackware 14.1):

Some xscreensavers worked (glplanet, gltext, glsnake)

[Vort]

Thanks. I tried heavier OpenGL load yesterday: Minecraft 1.0.
Good news: it starts and displays UI elements, bad news: no cubes are visible:

Minecraft 1.0 main menu

Minecraft 1.0 game world

[Vort]

With #623 applied, Windows 7 Aero looks much better:

[Torinde]

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?

newer GeForce models in future

I suggest GF700/Titan Z (the last for XP), GF10/Titan Xp (the last for Win10x86/Win8/Win7x86) and RTX3090Ti (the last for Win7x64)

[Vort]

Thanks.

Where does the 3D emulation run? Host CPU (how many threads?) or host GPU?

Right now it runs on host CPU in the same thread where guest CPU is emulated.
In future it is planned to move FIFO processing into separate thread.
Splitting load into several threads is possible as well, but I think it is better to implement such change for Voodoo 3 first.
Rendering on GPU is not planned, because of compatibility reasons: with CPU-only rendering, Bochs can run on very large variety of hardware.

I suggest GF700/Titan Z (the last for XP), GF10/Titan Xp (the last for Win10x86/Win8/Win7x86) and RTX3090Ti (the last for Win7x64)

I think it is better to leave ray tracing / AI support for far future.
I was thinking about support for GeForce 10 Series, but it is probably better to start with simpler card - GeForce GTX 285, which is the last for default Win7 driver (295 is actually two cards in one, which makes little sense for emulation).

Also it may make sense to go little deeper into the past and add RIVA (NV4) support, but I'm not sure about it yet, more discussion is needed.

[Torinde]

with CPU-only rendering, Bochs can run on very large variety of hardware

Understood. On the other hand - I assume OpenGL is also supported practically everywhere?

There are DOSBox patches supporting such Low-level Voodoo emulation with OpenGL rendering and I assume Geforce will benefit even more from higher performance (although I assume in Bochs CPU performance will limit the overall result).

[Vort]

Understood. On the other hand - I assume OpenGL is also supported practically everywhere?

I saw person trying to run Bochs on mobile device with 3 MB of RAM (#353).
Also I made almost fully functional builds for Windows 95 (#401).
So right now emulation theoretically can run even on ISA video cards.
I think it is nice property to have.

Closely related topic is running Bochs inside of Bochs.
I did not tried to make OpenGL-based emulation, but I assume it may require from host slightly larger set of features than will be available for guest, which makes nested emulation impossible.

Overall, I like the idea of GPU emulation, but I still think it is more suitable for other branches/forks and other emulators.

although I assume in Bochs CPU performance will limit the overall result

Right. It is hard to find 3D software, which runs well on 20-200 million IPS (~MHz) CPU.

[Torinde]

Those two examples are interesting, yes.

As for the nested emulation - if performance is not a goal, then host doesn't need larger set of features - I think even the first examples of simulators and emulators were for not yet existing hardware under development. Or like emulating 80-bit floating point on 64-bit hardware.

[fysnet]

Vort,

I have been following along with your work. It's quite impressive.

Out of curiosity, I tried booting Bochs with UEFI and your geforce emulation. The screen is blank throughout the boot.
(I am booting my own custom OS and all debugging/serial out says everything boots to my desktop and beyond, it just never shows anything to the screen, UEFI or otherwise.) (See below for an edit)

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,

romimage: file="C:/qemu/u64/OVMF-pure-efi.fd", address=0x0, options=none
vgaromimage: file=C:/bochs/bochs/bios/VGABIOS-lgpl-latest.bin
pci: enabled=1, chipset=i440fx, slot1=cirrus
vga: extension=cirrus, update_freq=5, realtime=1

boots just fine (i.e.: the screen is shown).

However, when changing to i440bx (chipset=i440bx), nothing is shown, when using UEFI.

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 geforce emulation? It shouldn't matter the OS, since the UEFI never shows its boot logo anyway, which should be enough of an indication if it works or not.

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:

00000062709i[BIOS  ] AcpiTimerLibConstructor: Unknown Host Bridge Device ID: 0x7190

00000073150i[BIOS  ] ASSERT /home/jenkins/.jenkins/workspace/edk2/rpms/build/edk2-gf0064ac3af.EOL.no
00000073243i[BIOS  ] nore.updates/OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.c(65): ((BOOLEAN)
00000073243i[BIOS  ] 0==1))

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 geforce emulation.

[Vort]

First, have you tried booting UEFI with your geforce emulation?

No, I made very little tests with UEFI at all.
The reason is simple: OVMF firmware is not "real".
I don't like to guess if problems come from emulation or from firmware.
It is much more preferable to have configuration, which matches real hardware.
However, UEFI was developed in 2006, while i440fx and i440bx were made in 1996 and 1998, so there is almost no chance to have proper UEFI firmware for them.
Such situation may change with development of PCIe support, which may be required by newer GeForce cards.

what do you recommend for someone who would like to program the other side of the emulation, the actual OS driver?

First of all, you need real video card for it - emulation has simplifications and there is almost no chance that driver tested only in emulation will work on real hardware.
Next, I suggest to learn how video BIOS works. Many years ago I made simple driver just by looking at BIOS disassembly and at logs from intercepted IO port accesses from VESA calls.
For more complex things you may look at sources for nv and nouveau drivers.

[fysnet]

For future reference, it doesn't look like we will get EDK2 UEFI and Bochs to work together when using i440bx.
Look at the code linked here:
https://github.com/tianocore/edk2/blob/1c74842bd07a48070d1cf3458f0b6b377e3ec8b9/OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.c#L40-L67
This code only checks for the i440fx (ID = 0x1237, the ID we use), and the MCH ID used with QEMU (0x29C0 ?), and then the CLOUDHV_DEVICE_ID entry (0x0D57 ?). It never checks for a i440bx entry.

On a different note, I noticed the following in Bochs' pci.cc:

Bochs/bochs/iodev/pci.cc

Lines 84 to 91 in 3608cfd

	if (BX_PCI_THIS chipset == BX_PCI_CHIPSET_I430FX) {
	init_pci_conf(0x8086, 0x0122, 0x02, 0x060000, 0x00, 0);
	} else if (BX_PCI_THIS chipset == BX_PCI_CHIPSET_I440BX) {
	if (DEV_agp_present()) {
	init_pci_conf(0x8086, 0x7190, 0x02, 0x060000, 0x00, 0);
	BX_PCI_THIS pci_conf[0x06] = 0x10;
	BX_PCI_THIS pci_conf[0x10] = 0x08;
	init_bar_mem(0, 0xf0000000, agp_ap_read_handler, agp_ap_write_handler);

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.

[Vort]

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.

This is what datasheet states:

[fysnet]

Indeed it does. Thank you.

Edit: Somehow I missed it, the 0x7191 is at:

Bochs/bochs/iodev/pci.cc

Lines 617 to 625 in 1d4940a

	void bx_pci_vbridge_c::init(void)
	{
	Bit8u devfunc = BX_PCI_DEVICE(1, 0);
	DEV_register_pci_handlers(this, &devfunc, BX_PLUGIN_PCI, "i440BX PCI-to-AGP bridge");
	init_pci_conf(0x8086, 0x7191, 0x02, 0x060400, 0x01, 0);
	pci_conf[0x06] = 0x20;
	pci_conf[0x07] = 0x02;
	pci_conf[0x1e] = 0xa0;
	}

It will teach me :-) Anyway, thank you.

[obsolete-is-better]

I found something for the leadtek GeForce collection:

https://web.archive.org/web/20000608013056/http://www.leadtek.com/gfdrv.htm
https://web.archive.org/web/20000831093247/http://ftp.ncku.edu.tw/Vendors/Leadtek/graphics/geforce/bios.zip

[Vort]

Thanks. I think, however, that it will be enough for now to have single card from Celsius family implemented - NV15 (GeForce 2 Pro). I did not announced it properly, but it mostly works now (model=geforce2, VBIOS).