That's a RIVA128-based card and that core is mentioned in the OP. Main issue I see with getting those cards into PCem is the lack of good register-level documentation - nVidia was always very secretive about how their stuff works. My first nVidia card was a GeForce2 MX400 that replaced my Diamond Mo...

Likely a separate issue, I just did two floppy software installs under Windows 95 OSR2 (the 5 disks for Micrografx Picture Publisher 5.0 and the 24 disks of Office 4.3c) and didn't run into that issue at all - this issue seems to only affect Windows 3.1x and some UNIXes (Possibly Windows 3.0 as well).

A similar issue affects Mandrake Linux 8.0, dmesg shows that the es1371 is detected but the AC97 codec is detected as "unknown": Screenshot from 2020-12-09 22-09-01.png Ignore the funky colors, seems to be an issue with the S3 ViRGE/DX on XFree86 3.3.6 (not sure if it's a PCem bug or a leg...

In PCem v17, BeOS 5.0 will detect the sound card but outputs silence when the Sound Blaster PCI 128 or Ensoniq ES1371 sound cards are used despite the mixer settings being maxed out: Screenshot from 2020-12-09 20-08-32.png Hardware configuration: System: [Socket 7] Shuttle HOT-557 CPU: Pentium 200 R...

In PCem v17, occasional "Cannot read from drive A" messages appear when installing programs from floppy under Windows for Workgroups 3.11: Screenshot from 2020-12-09 16-27-26.png Screenshot from 2020-12-09 16-49-26.png Clicking on "Retry" once will allow the installation to conti...

Main reason I'd see for adding the AWE64 would be to have a BeOS-compatible sound card since the ES1371 is detected but completely silent and the OS doesn't have support for non-PnP SoundBlasters (I really should get around to making a report for that issue with the ES1371 since it affects Linux too...

As of v17-final, the fatal()/crash when starting X11 on Mandrake 6.1 has been resolved, the SVGA detection is still broken but that's just a minor issue with a known workaround.

PCem v17-dev commit e8e0cf4 fatals with "launch area write, command=cc800206" during KDE startup on Mandrake 6.1 when using a Voodoo Banshee Test system: System: Gigabyte 686BX CPU: Pentium II/233 RAM: 64MB Video: 3dfx Voodoo Banshee (reference) 16MB Sound: Sound Blaster AWE32 HDD: 2GB IDE...

I recall the Mach64GX having a few emulation issues last time I tested it but getting other drivers is always worth a try (ATi was not exactly known for 100% stable drivers back in the day).

Looks like a bug in the S3 ViRGE driver you're using, you can try another 2D card such as the Trio64. The S3 ViRGE/DX and Voodoo2 are both 3D cards (though the ViRGE was infamously slow and isn't quite as feature-filled as the Voodoo cards were) and the ViRGE is your 2D card as well. If a game asks ...

The fact that Grim Fandango's FMVs didn't slow down in v17-dev - not conclusive of a performance boost but supports that something was done which made the code faster. It's likely some tweaks were done along the way to emulating the P6 core CPUs (Pentium Pro and Pentium II)

Your best bets for solving the slowdown issue are to emulate a slower CPU and/or wait for v17 to be released since the recompiler's definitely faster in the new version.

I have retested this OS with v17-dev commit 302d05c and the issue still occurs.

NFS III's FMVs are fine for me in v16 and v17-dev commit 302d05c but Grim Fandango will slow down to 72-80% in v16 (but v17's fine). What is your host CPU? It is likely you're running into a recompiler performance issue (which has been improved in v17-dev).

Just tested v17-dev commit 302d05c and the issue still occurs.

Just checked v17-dev commit 302d05c and the same issues with 3dfx mode occur there as well. Did my tests with a Voodoo1 though.

I have retested Solaris 2.5.1 and 2.6 in v17-dev commit 0cbe6ae and the issue still occurs.

Never really liked Bochs and could never get VMware or VirtualBox working well for games myself. I've gotten almost all of my DX8/9-era stuff running in Wine though (Linux is my primary OS these days). I am a bit curious on the possibility of emulating the ATi Mach32 or the S3 805 at some point in t...

Tested my collection of Windows Chicago betas using the following configuration: Machine: AMI 486 clone CPU: i486DX2/66, Recompiler off RAM: 8MB Video: Tseng ET4000AX Sound: Sound Blaster 16 HDD controller: Adaptec AHA-1542C FDDs: 1x3.5" 1.44M (A) + 1x1.2MB 1.2M (B) CD-ROM: PCemCD 4x Mouse: Mic...

I can say for a fact that sound works on NT 3.1 and 4.0 - I did quite a bit of testing on the sound cards in PCem v16. On Windows NT 3.1 I would recommend using a Sound Blaster 2.0 (or a 16 if you have the necessary driver disk, which can be found with a Google search) and on 4.0 I would recommend a...

In PCem v15 and v16-dev commit 6822f80, Solaris 2.5.1-8.0 display "tripled" graphics in 1024x768x8 mode and in other modes a section of the framebuffer is repeated over and over again. It almost appears as if the first 256k of the framebuffer is being repeated continuously. Screenshot from...

The emulator crashes when changing resolution in Windows 98SE with a Matrox Mystique. I haven't installed any updated drivers yet, only DirectX 9.0c and I'm not sure if that updates the driver. Otherwise it's using the default driver that comes with 98 SE. Anything in pcem.log? (On Windows it will ...

A little Matrox-focused testing (commit 895e05f): Advanced/ZP,Pentium Overdrive/166,64MB,Matrox Mystique,SB AWE32,IDE,PS/2 mouse: Working: - Screamer II with Mystique patch: Some recompiler slowdown in the menus but otherwise close to perfect - Screamer Rally Somewhat working: - Croc (Win95): Lots o...

Some games I tested: Tandy 1000SL/2,8086/8,640K,Builtin video,Tandy audio,MFM,Serial mouse,MS-DOS 3.30 Working: - Space Quest: The Sarien Encounter - King's Quest III: To Heir is Human - Space Quest II: Vohaul's Revenge - Police Quest: In Pursuit of the Death Angel - Zak McKracken and the Alien Mind...

In PCem v14, v15 and v16-dev commit 6e158be, Mandrake Linux 5.x and Red Hat Linux 5.x hang (or at least stop accepting input) right after the mouse probe: Screenshot from 2020-03-21 14-03-05.png This hang does not occur when using a serial mouse Red Hat 4.x is unaffected as it asks for a mouse type ...

The battery of tests I put PCem through so far: AMI 286 clone,286/16,2MB,ET4000,IDE,Serial mouse: Working: - IBM OS/2 1.0 - MS-DOS 3.30A - Windows 1.04 (using EGA driver) - Windows 2.03 (using VGA driver) AMI 286 clone,286/16,4MB,ET4000,IDE,Serial mouse: Working: - IBM OS/2 1.1 - Microsoft OS/2 1.1c...

I have just tested NeXTSTEP 3.1, 3.2 and 3.3 in v16-dev commit 6e158be and the issue still occurs. 4.2 is likely affected as well but has better ATAPI support than 3.x and does work with an IDE system.

I have performed some additional tests and found that the issue becomes a bit less severe (the keyboard response times are a bit shorter but still measured in seconds) when using the Adaptec AHA-1542 SCSI controller instead of IDE, the Tseng ET4000AX instead of an S3 Trio and disabling IDE in the BI...

I just tested this OS with the WinChip interpreter and this issue does not occur.

@omarsis81 I did not as my real 386DX/33 (which has an Adaptec 1542 and a SCSI CD-ROM) is dedicated to games at the moment and my P166's video card is too new. I did figure out the image I was using (which I've had since the Virtual PC 5.x era) had SETUP and INITIAL INFs dated 2003 - hence the image...