I tested it with win95c and Colin Mc rae Rally.

Voodoo is in Hardware list and Game started but the only thing it does is chance Resolution and then i get back to Desktop in Black/White

I noticed there is no entry in .conf for "Glide"
is this entry still used ?
On other versions of Dosbox i had this to set "Glide=emu"

And "voodoo" an only set to false,software or auto, but not to "opengl" anymore ?

Sammy wrote:

I tested it with win95c and Colin Mc rae Rally. […]
Show full quote

I tested it with win95c and Colin Mc rae Rally.

Voodoo is in Hardware list and Game started but the only thing it does is chance Resolution and then i get back to Desktop in Black/White

I noticed there is no entry in .conf for "Glide"
is this entry still used ?
On other versions of Dosbox i had this to set "Glide=emu"

And "voodoo" an only set to false,software or auto, but not to "opengl" anymore ?

When I imported the voodoo emulation from Taewoong's branch I found compiling the glide emulation and OpenGL code troublesome, so I removed them in this branch and left only the software rasterization code alone, sorry about that. I'm still not certain how to test Windows 95 and voodoo drivers.

You download this package: http://www.falconfly.de/downloads/webrelease-glide240.zip
In Glide\Bin\Win32 there are 29 test programs. If you run Test00.exe, you should get an empty blue screen (not the windows BSOD, but Glide rendered empty blue screen 😁). The same files in Bin\DOS do this from DOS...

gulikoza wrote:

You download this package: http://www.falconfly.de/downloads/webrelease-glide240.zip
In Glide\Bin\Win32 there are 29 test programs. If you run Test00.exe, you should get an empty blue screen (not the windows BSOD, but Glide rendered empty blue screen 😁). The same files in Bin\DOS do this from DOS...

Hm, apart from some redraw bugs I've noticed lately, I saw the program come up with the 3Dfx logo, and then a blue screen with a badly alpha-blended "Press a key to quit". That was with cycles=max though, let me try a fixed cycles count...

1enable pci bus=true
2
3voodoo=software

That's about right...

I've tested some Dosbox versions G1, Daum, Dosbox-x and find out that the game only runs once after install...

I've had to reinstall the game every Time i leave dosbox

Not using the same mountings to play as you did for install is the usual reason for that.

That's a brilliant insight on the 3dfx emulation! I tried modifying V1 code line by line but never found the source of the "broken text problem" (only obvious to me in d3d games). It's a reproducible problem but doesn't affect all text, so it doesn't seem to be a product of the V1 emulation itself. A mame developer posted about alpha blending problems (a possible cause of the broken text) and other anomalies which were related to DMA transfers to the V1 in emulation. These must be difficult timing issues, but your post renews hope. 😀

truth5678 wrote:

That's a brilliant insight on the 3dfx emulation!... A MAME developer posted about alpha blending problems (a possible cause of the broken text) and other anomalies which were related to DMA transfers to the V1 in emulation.

As usual, if there's actual bugs to resolve upstream, please let me know. 😀

collector wrote:

Not using the same mountings to play as you did for install is the usual reason for that.

The Problem was Daemon Tools...
When i restart dosbox and Win95C inside the image was still mounted but Windows hang if the Game access Data on CD.

Workaround: After booting Windows i hand to unmount and remount the Image and then start the Game.
Or uncheck the "automount" option, so every time windows boots up DT has now Image mounted.

TheGreatCodeholio wrote:

Sammy wrote:

I tested it with win95c and Colin Mc rae Rally. […]
Show full quote

I tested it with win95c and Colin Mc rae Rally.

Voodoo is in Hardware list and Game started but the only thing it does is chance Resolution and then i get back to Desktop in Black/White

I noticed there is no entry in .conf for "Glide"
is this entry still used ?
On other versions of Dosbox i had this to set "Glide=emu"

And "voodoo" an only set to false,software or auto, but not to "opengl" anymore ?

When I imported the voodoo emulation from Taewoong's branch I found compiling the glide emulation and OpenGL code troublesome, so I removed them in this branch and left only the software rasterization code alone, sorry about that. I'm still not certain how to test Windows 95 and voodoo drivers.

Is it planned to put OpenGL back again in later Versions?
This is the "killer feature" for me...

In Software mode i feel only to get 5-15 frames, Games are just playable as a slideshow.

In OpenGL mode game runs like on real Hardware.

I hope someone could optimize Dosbox for windows stability (Dosbox-X is on a good way) , and more stability in fast 3DFX rendering.

But thanks to any new version of Dosbox and all the great work of you Coders. 😁

Stiletto wrote:

truth5678 wrote:

That's a brilliant insight on the 3dfx emulation!... A MAME developer posted about alpha blending problems (a possible cause of the broken text) and other anomalies which were related to DMA transfers to the V1 in emulation.

As usual, if there's actual bugs to resolve upstream, please let me know. 😀

Thanks! It will be interesting to examine the 2005 to 2006 mame source for slowing down the dma transfers to the V1 emulation (http://aarongiles.com/?p=136). However, I haven't yet found a trace of this implemented in the dosbox patch. My hope is that the bug is on the dosbox end.

I have wondered if the mission of the mame project is consistent with work toward an opengl (or another 3d accelerated api) translation mode in the V1 emulation. 😀

truth5678 wrote:

That's a brilliant insight on the 3dfx emulation! I tried modifying V1 code line by line but never found the source of the "broken text problem" (only obvious to me in d3d games). It's a reproducible problem but doesn't affect all text, so it doesn't seem to be a product of the V1 emulation itself. A mame developer posted about alpha blending problems (a possible cause of the broken text) and other anomalies which were related to DMA transfers to the V1 in emulation. These must be difficult timing issues, but your post renews hope. 😀

The "redraw bugs" I was referring to were the sometimes incomplete screen updates I was seeing on my end. Sometimes only part of the screen updated, sometimes little "slivers" failed to update. I tracked that down to some strange problem with SDL and my Linux X11 configuration and Intel graphics chipset, has nothing to do with DOSBox as far as I can tell.

I meant that while the 3Dfx emulation alpha-blends the text onto the screen, it looks like they're letting it scale, which when you use white aliased text on transparent alpha, doesn't look too good. What I saw seems to show that it otherwise works.

I noticed also that if 3Dfx emulation is enabled, you can get a minor speed boost by going to the [log] section of your dosbox.conf and setting sst=false, or else you'll get a crapflood of debug messages about what's being sent to the chip and your 3D will lag badly.

Sammy wrote:

The Problem was Daemon Tools... When i restart dosbox and Win95C inside the image was still mounted but Windows hang if the Game […]
Show full quote

collector wrote:

Not using the same mountings to play as you did for install is the usual reason for that.

The Problem was Daemon Tools...
When i restart dosbox and Win95C inside the image was still mounted but Windows hang if the Game access Data on CD.

Workaround: After booting Windows i hand to unmount and remount the Image and then start the Game.
Or uncheck the "automount" option, so every time windows boots up DT has now Image mounted.

Why are you using daemon tools? I just demonstrated a few pages ago in this topic that you can abuse ISA Plug & Play and IDE emulation to trick Windows 95 into seeing 16 CD-ROM drives. 😀

TheGreatCodeholio wrote:

The "redraw bugs" I was referring to were the sometimes incomplete screen updates I was seeing on my end. Sometimes only part of the screen updated, sometimes little "slivers" failed to update. I tracked that down to some strange problem with SDL and my Linux X11 configuration and Intel graphics chipset, has nothing to do with DOSBox as far as I can tell.

I meant that while the 3Dfx emulation alpha-blends the text onto the screen, it looks like they're letting it scale, which when you use white aliased text on transparent alpha, doesn't look too good. What I saw seems to show that it otherwise works.

Thank you for your expertise and informative reply! This is good news that the 3dfx emulation is intact for the glide test. I wish I had a real V1 device to compare the emulation with, at least for this case. However, there is an observable bug in the text generated by d3d5 and d3d6 games, where the text is created along the pixel pipeline in the V1 emulation. I was unable to find the cause in that part of the emulation, so I was fairly certain it occurred before the pipeline.

It could be that direct3d calls the V1 in a unique way and that isn't observable from the glide tests or 3dfx games; although now I think it could be a timing issue, at least this is the next plausible cause of the bug, a bug which is very reproducible but not observed in all text on screen. There are d3d tests which I ran, but they don't clearly reproduce the problem and the tests don't seem appropriate for a d3d5 card. Once I greatly slowed the screen updates and observed the d3d text printed to screen correctly and then breaking. 😀 From your post, I then thought that this may be related to a timing issue, just as Aaron noted on the alpha blending issue. It is possible that the V1 emulation is receiving an extra command before it has time to finish the previous command, and therefore predictably breaking the text. At least I documented one possible cause, otherwise an alternative reason is the compatibility of the emulation with d3d, and that reason would not be trivial (at that point the s3/virge becomes a simpler option, at least from the standpoint of porting code).

TheGreatCodeholio wrote:

Sammy wrote:

The Problem was Daemon Tools... When i restart dosbox and Win95C inside the image was still mounted but Windows hang if the Game […]
Show full quote

collector wrote:

Not using the same mountings to play as you did for install is the usual reason for that.

The Problem was Daemon Tools...
When i restart dosbox and Win95C inside the image was still mounted but Windows hang if the Game access Data on CD.

Workaround: After booting Windows i hand to unmount and remount the Image and then start the Game.
Or uncheck the "automount" option, so every time windows boots up DT has now Image mounted.

Why are you using daemon tools? I just demonstrated a few pages ago in this topic that you can abuse ISA Plug & Play and IDE emulation to trick Windows 95 into seeing 16 CD-ROM drives. 😀

But this will only Work with Dosbox-X ?..
At the Moment i am using Dosbox-G..

Just to let you know I'm still here, I did some brainstorming on where I want to take DOSBox-X next development wise.
I won't be able to do it until the next weekend because of work, but I thought I'd throw my plans for the next 4-6 months out here if you want to know what I plan to work on.

DOSBox-X (coming months):

- New CPU core: the 8088 core (also 8086). New core implementation that will develop into the 286, 386, 486, etc. core rewrites as time goes on, eventually replacing the current CPU core code entirely. I think it's weird that despite DOSBox targeting old DOS games, nobody ever thought to add a core that limits itself to only 8088 and 286 instructions, in case certain games relied on quirks that the 386 and higher cannot execute correctly. Future plans: the 286 core will also emulate 286 quirks like the LOADALL instruction, and the 386 core the 386 version of LOADALL as well as route FPU errors to INT 13 instead of INT 16 (stuff like that).

- Runtime option: dosbox.conf to control whether FPU is present or not, except to ignore the setting if cputype=pentium since by that point programmers generally assumed the FPU was present due to Intel's integration of components. Current DOSBox emulation of the FPU is weird and a bit flawed and unrealistic. For example, it was actually quite rare for 386-class systems to have an FPU, it was far more common for Windows 3.1 and 95 to have to turn on the FPU "emulation" that triggered software emulation, and that's what DOSBox needs to emulate. And there is a flaw with EFLAGS emulation where even if you set cputype=386 the AC flag can be toggled which causes games and Windows 3.1 to report a 486 regardless. And I vaguely recall a bug with the FSTENV instruction where DOSBox interpreted both forms as the 16-bit form even if 32-bit override or some silly nonsense.

- Pentium Model Specific Register emulation: Instead of just bullshitting RDMSR/WRMSR, add code to emulate the Pentium's model specific registers. That includes writing the Time Stamp Counter with WRMSR.

- PC floppy controller emulation: First test code in DOSLIB to talk to an actual controller, play with the drive, then begin writing emulation in DOSBox-X. The code needs to have conditionals for both 3.5" and 5.25" type drives. DOSBox-X emulation must have an "enable" option for the FDC, and options to specify either drive presence and type. During development, we need to see if any fancy vm86 trickery is needed for Windows 95 to "see" the controller (same hacks as IDE needed?). If so, then just like IDE emulation, we add "fakeio" and "fakevm86io" options. Note that getting Windows 95 to use it's native protected mode floppy driver would eliminate the last warning in the System dialog box about MS-DOS compatibility fallback for drive A: . I/O needs to support DMA and PIO modes. Proceed carefully. Out of all standard PC hardware the FDC is the worst and most finicky part to talk to. Code needs to emulate time delays related to motor on/off, drive select, head movement, disk rotation, read delays waiting for sector to pass under the head, etc. etc. Code needs to be added to the "imgmount" command so that when mounting a disk image to the floppy drive (either "a" or "0") the user can add something like -fdc 0 to say that the disk image should also be attached to the first floppy drive on the cable for FDC emulation (much like we do now with the -ide switch to specify which controller and master/slave setting to attach to). As development progresses, if enabled in dosbox.conf, the FDC emulation would also randomly fail reads and writes sometimes to emulate the fickle unreliable nature of floppy disk media (which is why most FDC implementations are written to retry up to 3 times on failure).

- DOSLIB: Re-add commands to play with multiple mode (testing and setting). Re-add read/write test routines for ALL modes: C/H/S single, C/H/S multiple, LBA single, LBA multiple, LBA48 single, LBA48 multiple, etc. DOSBox-X needs to implement ATAPI TEST, NOP commands, and ATA sleep/idle/power state/device reset commands like any real IDE device would.

- Windows 3.1 and Windows 95: Make sure the DOS VM can capture/restore EGA and VGA state correctly for all standard INT 10h modes 0 through 19 (non-VESA modes). If it can't, then work to make sure it can. I also remember from real Windows 95 installations that, if you ran various DOS games that used VGA Mode X unchained 256-color mode, and hit Alt+Enter to exit fullscreen mode, the DOS VM was reliable at capturing a frozen "screenshot" of the game screen despite the use of Mode X, while Windows 3.1 wasn't savvy enough to do that. Hitting Alt+Enter to return to the game was successful at restoring the display as well and resuming the game.

- CGA emulation: Most VGA cards emulate CGA 320x200x4-color mode apparently by using odd/even mode, just like the alphanumeric mode. At the very least, this is what I noticed my S3 ViRGE card doing. In other words, you could consider even/odd bytes of the CGA bytes to exist in VGA planes 0 and 1 in the same way VGA alphanumeric mode works. DOSBox-X's emulation should reflect this. BUT, you have an alternate implementation work as it does now when machine=cga because CGA does not have "planes". VGA draw code should reflect this: VGA-type CGA rendering, unless machine=cga, then use current code. Future research: what SVGA cards don't use odd/even mode for CGA 320x200x4-color? Is the Tseng ET4000 chip the odd man out again?

- Investigate claims that disk and CD-ROM swapping still cause crashes. Is it in general? Or just Win32 builds? Could it be related to the bug you found in GCC where if you have multiple constructors, and have one constructor call another, that double allocation or other weird issues crop up?

- Re-integrate Taewoong's OpenGL-based 3dfx emulation, if possible. People on the DOSBox forums want the option back to specify voodoo=opengl for performance. That means some additional work:
1. configure.ac on Linux needs to detect Mesa3D libraries, conditionally enable OpenGL if they are available, or disable voodoo=opengl if not
2. The Windows version needs to interface with Windows OpenGL.
3. configure.ac autodetect OpenGL on Mac OS X how??
4. I hear the 3Dfx emulation has had many updates and fixes since Taewoong's integration??

- Whatever happened to the guy that wanted the Brazillian thousands separator key or whatever it was?

- ISA/PCI device "separation". Devices that normally connect as ISA devices (like Sound Blaster) will add themselves to a list of ISA devices instead of directly hooking into the I/O port callback table. I/O port callbacks will be set up so that, unless claimed by other I/O callbacks, they take a "slow path" that queries each PCI and ISA device to ask if they wish to "claim" the I/O cycle. If only one devices does, then that device's I/O callback is written into the I/O port callback so that I/O emulation is as fast as before for that device. I/O callback code will provide an "invalidation" function for devices that change I/O ports (I/O slots are changed back to the "slow path"). Some devices like the voodoo and S3 emulation will add themselves as PCI devices, who will be queried the same way. PCI configuration space will invalidate I/O and mem ranges they once owned when the BARs are modified so that the guest OS can reconfigure PCI devices as needed. Eventually, the only code to have direct I/O assignment will be "motherboard" emulation, and the emulated motherboard will take on the task of querying ISA/PCI devices to claim I/O cycles. Part of this changeover will also direct ISA devices to call into the "motherboard" to signal ISA IRQ lines rather than directly to the PIC, to allow the motherboard emulation to direct the signals.

- PCI IRQ routing emulation. PCI devices will signal interrupts using emulated INT#A, INT#B, INT#C, INT#D lines. The motherboard emulation will be allowed to dictate how the PCI IRQ lines are routed, on most motherboards, the A-D lines are rotated once per PCI slot for example. Basic motherboard emulation will contain control registers to dictate how PCI INT A-D map to PIC IRQs (Intel PIIX style). For guest OSes like Windows 95 and Linux, this will also necessitate what I understand are PCI BIOS calls to query IRQ routing information. Like real PCI-based motherboards, if an IRQ is assigned to PCI, the IRQ signal from the ISA bus will be ignored. If the user has disabled PCI emulation, then the motherboard simply routes ISA IRQs directly to the PIC (in the style of 486-class and earlier motherboards).
Since PCI IRQ routing is an important part of PCI emulation, there will be no option to disable it independently of disabling PCI emulation. Additional options will be added to dosbox.conf to allow the user to specify which IRQs are assigned to PCI including the ability for INT# signals to share IRQs if ISA devices are more important, or if not specified, use the typical Intel PIIX and mid-1995 BIOS type settings where INT#A = IRQ5, INT#B = IRQ9, INT#C = IRQ10, INT#D = IRQ11.

Just wanted to drop in and say how fascinating your posts are, and that I have been following this thread with great interest, despite my not being able to understand quite all of it.

you really have taken Dosbox to a whole new level CodeHolio. Great work.

That's an incredible plan! Thank you! I look forward to all your work on existing and new additions to the emulator. Your work on the FPU, Pentium, and PCI/ISA emulation will be especially interesting and informative on the inner-workings of PC (sub)systems. I'll test and help in any ways I am able, and if not, I'll try my best to learn so I can. 😀

I could help with the configure script for detecting opengl, if you wish. Also, I hope you receive the 3dfx updates from others, but I have a few 3dfx patches:

1. Patch for workaround of framebuffer artifacts in hardware emulation mode (most recent version should include any major updates from the mame team; I couldn't find any other additions, the remainder appeared to be related to coding style): V1 hardware emulation fix for direct3d

2. An optional addition for gamma control: V1 emulation: gamma & dithering

3. Another optional addition for scaling the window: 3dfx-based Scaling in DOSBox.

4. This patch is incomplete, but if the video output is not centered at lower resolutions, it may provide hints to identify the issue: VIDEO Fullscreen centering in OpenGL mode (SDL1)

Maybe I'm off-topic, but kekko's 3dfx hardware emulation work/patch might interest you : 3dfx voodoo chip emulation
(not updated since ages, however...)

PS : your plan is a very interesting read ! 😀