When compiling on VS 2010 it fails with "..\src\winres.rc(169): error RC2104: undefined keyword or key name: ID_LINEWISE"

collector wrote:

When compiling on VS 2010 it fails with "..\src\winres.rc(169): error RC2104: undefined keyword or key name: ID_LINEWISE"

I committed a change that removed the ID_LINEWISE constant and the reference in winres.rc. Git pull the latest commit and try again.

Thank you for improvements to the pci emulation (and to ide)! The S3/PCI device works great under this new code. However, it doesn't recognize the V1 emulation. It is probably due to my porting of code bits into a vanilla SVN build, but the S3 works fine, so I'm assuming that the pci code port is not at fault. Would you consider to verify that the V1 works for you? If it does, then it will isolate the cause to missed bits instead of a current V1 incompatibility. 😀

I mentioned this back on page 10. If there are major changes afoot in PCI emulation, perhaps it is worth exploring again?

Jorpho wrote:

I found this QEMU guide just now: http://gunkies.org/wiki/Installing_Windows_95_on_Qemu […]
Show full quote

I found this QEMU guide just now:
http://gunkies.org/wiki/Installing_Windows_95_on_Qemu

Like DOSBox-X, it seems Windows 95 on QEMU also doesn't recognize the PCI bus right off the bat. What is interesting is that the guide recommends using Intel's PCI drivers instead of the ones that come with Windows.
http://downloadcenter.intel.com/confirm.aspx? … lName=&lang=eng

Perhaps this might make some difference in regards to stability?

truth5678 wrote:

Thank you for improvements to the pci emulation (and to ide)! The S3/PCI device works great under this new code. However, it doesn't recognize the V1 emulation. It is probably due to my porting of code bits into a vanilla SVN build, but the S3 works fine, so I'm assuming that the pci code port is not at fault. Would you consider to verify that the V1 works for you? If it does, then it will isolate the cause to missed bits instead of a current V1 incompatibility. 😀

What do you mean by V1? The Voodoo 3DFx emulation?

I know that so far I've hardly modified the code, except to remove the OpenGL translation and to transition the code to the new PCI emulation system I just wrote. I'm not sure how to test the voodoo emulation.

Jorpho wrote:

I mentioned this back on page 10. If there are major changes afoot in PCI emulation, perhaps it is worth exploring again?

Jorpho wrote:

I found this QEMU guide just now: http://gunkies.org/wiki/Installing_Windows_95_on_Qemu […]
Show full quote

I found this QEMU guide just now:
http://gunkies.org/wiki/Installing_Windows_95_on_Qemu

Like DOSBox-X, it seems Windows 95 on QEMU also doesn't recognize the PCI bus right off the bat. What is interesting is that the guide recommends using Intel's PCI drivers instead of the ones that come with Windows.
http://downloadcenter.intel.com/confirm.aspx? … lName=&lang=eng

Perhaps this might make some difference in regards to stability?

I noticed what Windows 95 autodetects on install is strongly affected by whether or not there is a PnP BIOS, and what the PnP BIOS reports.
That's why DOSBox-X's ISA PnP BIOS emulation is written to report "devices" that at first glance seem blindingly obvious and redundant, but there a reason for each one:

1. PCI bus. Windows 95 will not probe ports 0xCF8-0xCFC to detect the PCI bus. It must be told by the PnP BIOS that there is a PCI bus, then it will auto-install the driver for it and enumerate PCI devices.
2. ISA bus. Windows 95 will not install the driver needed to do ISA Plug & Play enumeration unless told by the PnP BIOS that there is an ISA bus (meaning, physical ISA slots)
3. The APM bios. If the install program failed to detect the APM bios, you can get Windows 95 to auto-install the APM BIOS by listing it as a "device" through the PnP BIOS.

So, if you want to install Windows 95 and magically have it see the PCI bus and PnP devices, you must run it in DOSBox-X with the Plug & Play BIOS enabled. If you don't, then you have to manually install the PCI driver and APM BIOS driver (I don't think there's a way to manually install the PnP enumerator). Intel's PCI drivers are not necessary.

TheGreatCodeholio wrote:

I know that so far I've hardly modified the code, except to remove the OpenGL translation and to transition the code to the new PCI emulation system I just wrote. I'm not sure how to test the voodoo emulation.

I'm eager to test your new PCI emulation with the Voodoo 3DFx emulation (V1 emulation). I forgot to include that the V1 emulation is detected in 95! It is seen by the operating system, but I can't run 3dfx games, such as UT99 and GLQuake. The games start, but they don't activate the V1 emulation (according to a message that would otherwise appear in the console window). Before applying your pci code, a console message would log that the V1 is active along with the display resolution, but after applying the pci code, then this message is absent and the game will report an error, such as GL not found.

I tested this with and without the opengl translation (such as in software mode). I'll verify this again. 😀

Edit: verified that V1 in software mode (no opengl translation) does not typically report a log message, even though it is functioning (under the old pci emulation). However, this mode does not yet work under the new pci emulation, at least as ported to SVN. GLQuake would show the same GL not found error. I've used GLQuake, but I haven't found a simple tool that verifies the V1 emulation in dos (a better method than running GLQuake each time).

If anyone wants to try out the newest features but doesn't want to go through the process of building it in Windows (which is a bit of a hassle), I've uploaded my own build of revision 666 here. I'll be keeping builds mostly updated.

http://goo.gl/Ra0A26

Keep up the good work!

In the absence of updated Daum builds, has anyone tried to build it on OSX?

I mean to but always get sidetracked. PM me a reminder tomorrow evening (GMT) 😉

Tried each of the PCI emulation commits in order by time and I believe this commit, "massive rewrite, cleanup of PCI bus emulation", is the one leading to an inactive V1 emulation, at least in my case. The previous ones don't cause any issue. I'll continue to test!

Edit: I'm looking at this section from the old pci code since the V1 is mapped to a different address space under the new code (although this does not necessarily point to a problem):

1-		Bit32u address_space=(((Bit32u)VOODOO_INITIAL_LFB)&0xfffffff0) | 0x08;	// memory space, within first 4GB, prefetchable
2-		registers[0x10] = (Bit8u)(address_space&0xff);		// base addres 0
3-		registers[0x11] = (Bit8u)((address_space>>8)&0xff);
4-		registers[0x12] = (Bit8u)((address_space>>16)&0xff);
5-		registers[0x13] = (Bit8u)((address_space>>24)&0xff);

Truth5678, git has a very good regression testing option called bisect (in case you don't know about that). It's a very good way to quickly find the culprit and more organized than aimless trying through git commits.

Continued looking at the pci emulation question. Attached are two images, one from the original and the other from the new pci emulation. There are differences in the values that are written to the registers which shows that the V1 emulation is not sending the (presumably) expected series of bytes with the new pci emulation (at least in my case).

Posted a patch to workaround use of the V1 emulation while running Codeholio's new pci emulation. This was only tested in my dosbox build. The modified code also suggests the place in code to implement a fix instead of use of this workaround.

The above workaround is not necessary, this attached patch fixes the issue between the V1 and the new PCI emulation. The patch corrects a typo error, otherwise all of Codeholio's code is perfect. This probably resulted from the lack of having a simple test of the V1 emulation. 😀

Thanks Codeholio!!

truth5678 wrote:

The above workaround is not necessary, this attached patch fixes the issue between the V1 and the new PCI emulation. The patch corrects a typo error, otherwise all of Codeholio's code is perfect. This probably resulted from the lack of having a simple test of the V1 emulation. 😀

Thanks Codeholio!!

I see... it needs to act on the value written even if it doesn't change config bytes.

Just to confirm, writes to bytes 0x40, 0xC0, and 0xE0 trigger actions but do not change the value read back? Does anyone have a Voodoo card they can verify this on?

Also, looking over the SST write code, I think I see another issue that needs to be fixed: Writes to bytes 0x10-0x13 (the LFB base) are not being handled properly. All byte writes are being handled as if the upper 8 bits of the 32-bit LFB address. I will push another change I think is necessary to improve emulation.

Is there anything I can download on the internet to test Voodoo 3Dfx emulation?

http://www.falconfly.de/artwork.htm

Down on the bottom there are various 3dfx tech demos. They should work to test it out.

If that's not enough, there's always demos of games.

https://archive.org/details/UnrealTournament for Windows
https://archive.org/details/Carmageddon_1020 for DOS

Glide SDK tests are the simplest voodoo applications available. You can get DOS & WIN32 executables:

http://www.falconfly.de/reference.htm

Laucian: The Carmageddon demo you linked to seems to be a "free" demo that only supports 320x200x256 color graphics. It mentions the full retail version will have SVGA graphics.

I found a copy of the "reference" 3Dfx drivers and managed to get some DOS demos to talk to GLIDE2X.OVL. The only changes I needed to make (not sure if this is because of the particular version I found) was that I had to add Pentium Model Specific Register emulation to DOSBox and code to ignore undefined registers because GLIDE2X.OVL appears to assume MSRs and MTRR registers are present. So far, the demos in 3Dfx mode look good!