Are you loading any sound card software into memory? If so did you try to replace it with UNISOUND?
I assume the game in question runs in protected mode, since I can imagine this problem being some sort of weird interaction between the DOS extender and hardware (although 0.3s is a long time, esp. for a 486-40). Is it possible to run this game without EMM386? So that the game doesn't have to use VCPI or DPMI calls.

What is the CPU exactly? A Cyrix perhaps? Did you try switching the fast A20 gate (if you have such option in BIOS) on/off to see if changes anything?

Interesting. I look forward to seeing others' ideas.

Does your BIOS have ISA 16-bit & 8-bit wait states that can be increased? Disabling video BIOS shadowing seems like it would have the effect of breaking up consecutive bus accesses for the sound card, so maybe wait states would accomplish something similar.

Do you have more than 16 MB RAM? Maybe some of the RAM manipulation you have been doing has the side effect of moving the sound buffer around in memory.

Does the BIOS have a memory relocation option? Try disabling that.

Thanks for help!

Deunan wrote on 2024-05-22, 23:42:

Are you loading any sound card software into memory?

No TSR, only initializing software. One of the cards (ESS688) is fully jumpered and needs no software at all. Last time I tried, it had the stutter too. I'll check again.

I assume the game in question runs in protected mode, since I can imagine this problem being some sort of weird interaction between the DOS extender and hardware (although 0.3s is a long time, esp. for a 486-40). Is it possible to run this game without EMM386? So that the game doesn't have to use VCPI or DPMI calls.

Game specifically demands EMS. (Wing Commander Privateer)

What is the CPU exactly?

AMD 486DX-40

Did you try switching the fast A20 gate (if you have such option in BIOS) on/off to see if changes anything?

No bios option.

jakethompson1 wrote on 2024-05-22, 23:58:

Does your BIOS have ISA 16-bit & 8-bit wait states that can be increased?

I have actually gone yolo and set all available wait states to the lowest and highest values. Running with zero or lowest wait state options seems to make it a hit and miss issue at slower ISA bus clocks. Running ISA Bus at 13.3 MHz works like a charm, no matter the wait states.

Disabling video BIOS shadowing seems like it would have the effect of breaking up consecutive bus accesses for the sound card, so maybe wait states would accomplish something similar.

I am using a CFcard which I plan to move to VLB IO (in the mail). Somehow I wonder if the high speed of the CF card will load the buffer without enough of a break for the game to render properly. That is why I tried to increase buffers. Maybe I should decrease them instead. This is an intro and the stutter happens when there are multiple laser sounds coming. But then why only with ESS?

Do you have more than 16 MB RAM?

No, it is 8MB.

Does the BIOS have a memory relocation option? Try disabling that.

No. Unless it has a very cryptic title. "Byte swap" is still unaccounted for...

Maybe some of the RAM manipulation you have been doing has the side effect of moving the sound buffer around in memory.

What I try to reminding me of again and again during all the tinkering: Bus speed cures it. Why?

ux-3 wrote on 2024-05-23, 05:21:

Game specifically demands EMS. (Wing Commander Privateer)

Ah, Origin. They always used their own DOS extender, earlier than others but it was also more finicky. Add their own in-house iMuse system to that.

So this might be a game bug, as in the problem is in the DOS extender code, you just happened to find how to trigger it. Well since you need EMS try a different memory manager. I assume you are using EMM386 from DOS? Is it DOS 6.20 or 6.22? IIRC the EMM386 is locked to the DOS version so you'd have to swap the OS. DOS 6.0 might be worth considering as well, or even 5.0 if you don't need disk compression and menus in CONFIG.SYS.
Then there is EMM386 from Win3 (and 3.1/3.11) which should not be locked to particular DOS version. Worth trying those out. And lastly there are memory managers made by others, I don't have much experience with those but if you are looking for a solution it might be worth investigating.

Deunan wrote on 2024-05-23, 08:56:

And lastly there are memory managers made by others,

Quarterdeck QEMM was a great thing.

WCP definitely seems to be a bit picky. I can't get digital audio to work on it at all, from any of my soundcards (2x ESS1868 + YMF719 + YMF718).

The same copy of the game works fine on two other systems with two (different) genuine SB16 cards.

megatron-uk wrote on 2024-05-23, 15:20:

WCP definitely seems to be a bit picky. I can't get digital audio to work on it at all, from any of my soundcards (2x ESS1868 + YMF719 + YMF718).

The same copy of the game works fine on two other systems with two (different) genuine SB16 cards.

WC Privateer sound has been working on all of my retro machines, with virtually all of the sound cards I have tried. This topic here is about one scene in the intro, and the issue isn't even sound, that plays fine. It also works on an ESS Solo-1 PCI.
But I am not sure which version I am using atm. I do have the original box with 1.44 floppies in the shelf, could be that one. I don't see "righteous fire" anywhere inside the game. Have to check if it is in folder as RF.exe or some such. Not sure if the speech pack is installed either.

Edit: RF and Speech are installed. They will likely have patched the game.

My copy is the combined WCP and Strike Commander combo release. Both are on the same cd, along with the Righteous Fire expansion.

What equivalent Wing Commander engine does Privateer use? WC2? I don't have any issues in WC1/2/3.

What exact point in the intro cinematic is the problem? CF cards don't (generally) do multi sector reads, so if it is streaming digital sound perhaps that is an underlying issue? Maybe increasing the bus speed and increasing the buffers param masks that issue? That's grasping at straws though.

megatron-uk wrote on 2024-05-23, 22:28:

What exact point in the intro cinematic is the problem?

Buddy says: "Prepare to go to hell". Then the ship turns. Then you see through the front window and see heavy laser exchange. During this laser exchange, the picture freezes once or twice.

CF cards don't (generally) do multi sector reads, so if it is streaming digital sound perhaps that is an underlying issue? Maybe increasing the bus speed and increasing the buffers param masks that issue?

Buffer increase only helps from the moment when the buffers are moved from high to low mem. Bus speed increase works. Video Bios shadow off works.

I am pretty sure CF is much faster at reading than anything from back then, except for ram disk or a filled buffer. Will see how VLB IO works.

(I could try to create a ram disk and test)

Does using SmartDrive make any difference?
If it's too much of a memory hog, it can use EMS if available.

The SmartDrive replacement in Helix Multimedia Cloaking package doesn't take up memory in conventional memory, at all, except for that 1KB stub.

Maybe there are other HDD cache utilities, too.
Central Point PC Tools 7 had pc-cache utility, I remember.

The reason is simple, really. CF cards have low-latency (between below 1ms to 12 ms), but no buffer.
Older models had an 1KB or 2KB buffer, still, but that was decades ago.

So holding a small HDD cache in PC memory still makes sense.
Especially if multiple files are being read in DOS (games tend to use many resources stored in multiple files, spread across multiple sectors).

An IDE caching controller could do same, of course, but could be a bit slower sometimes (ISA bus is slower than PC memory).

Edit: Also, I remember that PIO mode 4 used to be unstable.
A modern 486 may support PIO-4 already, but maybe can be forced manually to use a lower PIO mode.

Jo22 wrote on 2024-05-24, 07:52:

Does using SmartDrive make any difference? […]
Show full quote

Does using SmartDrive make any difference?

The reason is simple, really. CF cards have low-latency (between below 1ms to 12 ms), but no buffer.

So holding a small HDD cache in PC memory still makes sense.
Especially if multiple files are being read in DOS (games tend to use many resources stored in multiple files, spread across multiple sectors).

Interesting finds:

With "smarddrive c", the stutter is gone...

BUT... with "smartdrive c-" it is gone too. ^^

So it seems it isn't caching that helps, but again bumping things around in himen. (I am not saying that I understand this.)

Maybe due to some weird design decisions you have a region of ram that is always working at ROM speed (waitstates) no matter if ROM or RAM is mapped in there.

I dont recall any programs able to measure ram speed by region with enough granularity 🙁 Afaik cachechk can do it in 1MB increments?

My VLB controller card was in the mail today. Hooking up drive C through it changed nothing. It didn't even get faster 🙁

vstrakh wrote on 2024-05-23, 09:02:

Deunan wrote on 2024-05-23, 08:56:

And lastly there are memory managers made by others,

Quarterdeck QEMM was a great thing.

QEMM has the ability to do shadowing. I would disable the shadowing in the BIOS and try making QEMM do it with the ROM= parameter. I think this is a memory map issue.

rasz_pl wrote on 2024-05-25, 12:22:

Maybe due to some weird design decisions you have a region of ram that is always working at ROM speed (waitstates) no matter if ROM or RAM is mapped in there.

I dont recall any programs able to measure ram speed by region with enough granularity 🙁 Afaik cachechk can do it in 1MB increments?

Manifest can show you speed by region. It comes with QEMM.

kingcake wrote on 2024-05-25, 18:13:

QEMM has the ability to do shadowing. I would disable the shadowing in the BIOS and try making QEMM do it with the ROM= parameter. I think this is a memory map issue.

I did exactly that with Emm386. And the moment I did it, the stutter was back.

I don't have QEMM.

ux-3 wrote on 2024-05-25, 18:41:

kingcake wrote on 2024-05-25, 18:13:

QEMM has the ability to do shadowing. I would disable the shadowing in the BIOS and try making QEMM do it with the ROM= parameter. I think this is a memory map issue.

I did exactly that with Emm386. And the moment I did it, the stutter was back.

I don't have QEMM.

Download QEMM 8 from Win World. Even if you don't use it as a memory manager, the included manifest program will tell us much more about your memory map and the speed of you memory regions in the map. If you are unwilling to write a few disk images then this issue isn't important enough to be solved.

Also: Are you using the DMA= parameter? If not, try adding DMA=64 to your EMM386 line.

kingcake wrote on 2024-05-25, 19:06:

Also: Are you using the DMA= parameter? If not, try adding DMA=64 to your EMM386 line.

Are you refering to the D parameter? There is no DMA parameter in the description. I tried D=64, made no difference.

kingcake wrote on 2024-05-25, 18:54:

Download QEMM 8 from Win World.

OK, but how do I write these disk images? I do have an USB floppy drive and am on Win 11.