Most likely the system is too fast and those games crap out because of their programming. Use a slowdown utility or one to disable caches and the issues will go away.

Yep, speed sensitivity.
Another very speed sensitive game is Day of the Tentacle.
The Sound Blaster 2.0 is even more sensitive than SB Pro, even non sensitive games like Mortal Kombat 2 will scramble on a Pentium with a SB2.

You can use SETMUL to disable L1 cache to slow down to 486 speeds with these games.

ok will try that and let you know but i try that with the terminator and slow down about 15 to 25% and it still does it but will mess around see with both games and let ya know and I also try them both in dosbox and there no issues there with them

James-F wrote:

Yep, speed sensitivity. Another very speed sensitive game is Day of the Tentacle. The Sound Blaster 2.0 is even more sensitive t […]
Show full quote

Yep, speed sensitivity.
Another very speed sensitive game is Day of the Tentacle.
The Sound Blaster 2.0 is even more sensitive than SB Pro, even non sensitive games like Mortal Kombat 2 will scramble on a Pentium with a SB2.

You can use SETMUL to disable L1 cache to slow down to 486 speeds with these games.

does setmul work with moslow

I don't see why not.

moslow was no use with sound for terminator but setmul worked when disabled l1 cache

are you afraid of the dark - no luck with moslo or setmul or even going into bios and disabling l1 and/or l2 cache

I checked again with my SB2.0 and indeed it is very sensitive to the bus speed and sometimes disabling L1 and L2 is not enough, because the bus speed is still the same.
Prince of Persia 1/2 FM music is known to scramble with the older SB cards on a Pentium.
What board revision number do you have (bottom left corner), and does it have a 14.318 Mhz oscillator on board?

Here are some old links about that:
Sound Blaster Pro - speed sensitive?!
Re: Sound Blaster Pro 1 and Prince of Persia
The Adlib, SB 1.0, 2.0 and SBPro1 lack an oscillator on board and the YM-3812 OPL2 chip is extremely speed sensitive, much more than the OPL3.

By my book, it is another black point to the SBPro1 CT1330A, its basically useless in a Pentium. 😵

Here is pics of card

If there is a BIOS option to increase 8-bit (and 16-bit) IO wait states then use that.

This is the same as?: http://www.pcguide.com/ref/mbsys/bios/set/adv … ecov8Bit-c.html
This didn't help.

Interesting why some games are more sensitive than others, testing with SB 2.0 as it is extremely sensitive (OPL2, no Oscillator).
DOTT was fixed with L1, L2 disabled (very slow) and CPU at 133Mhz but it was still scrambled on 233Mhz with both caches disabled.

I will test with a non MMX...

EDIT:
Nope, non-MMX at 100Mhz did not fix the scrambled FM with the SB 2.0.
I still had to disable L1 cache and sometimes both (DOTT) for the OPL2 to sound right.
I put back in the SBPro2 CT1600 and everything is fine, except DOTT which still needs L1 disabled (only).

I don't have a 486 to test it on but I can tell that on a Pentium the SB 2.0 (can't speak about SB1.0 and SBPro1) is completely useless when it comes to FM music.

what is DOTT and guessing to play it, I will need either a slower pc or would a sb16 card work better

James-F wrote:

This is the same as?: http://www.pcguide.com/ref/mbsys/bios/set/adv … ecov8Bit-c.html This didn't help. […]
Show full quote

This is the same as?: http://www.pcguide.com/ref/mbsys/bios/set/adv … ecov8Bit-c.html
This didn't help.

Interesting why some games are more sensitive than others, testing with SB 2.0 as it is extremely sensitive (OPL2, no Oscillator).
DOTT was fixed with L1, L2 disabled (very slow) and CPU at 133Mhz but it was still scrambled on 233Mhz with both caches disabled.

I will test with a non MMX...

EDIT:
Nope, non-MMX at 100Mhz did not fix the scrambled FM with the SB 2.0.
I still had to disable L1 cache and sometimes both (DOTT) for the OPL2 to sound right.
I put back in the SBPro2 CT1600 and everything is fine, except DOTT which still needs L1 disabled (only).

I don't have a 486 to test it on but I can tell that on a Pentium the SB 2.0 (can't speak about SB1.0 and SBPro1) is completely useless when it comes to FM music.

OPL2 needs longer delays so it's the first one to break, it's not even hard to break it. But breaking OPL3 requires things to go seriously wrong to begin with, if a game meant for OPL2 does not work even on a OPL3 when used in fast machine.

Yeah, well games are coded badly so that on faster systems they are not able to write slowly enough to the card and the music breaks.
Lucas uses some kind of calibration loop but apparently it does not scale well for faster machines (I recall there were patches to fix DOTT).
It could be just a standard case of delay value rolling over a variable or something.

Nothing a quick hex editing would not fix.

James-F wrote:

By my book, it is another black point to the SBPro1 CT1330A, its basically useless in a Pentium. 😵

Yup, from a practical point-of-view it is. But it really is just a software problem, not a hardware problem. And it can be fixed. I've patched the broken code in the Crystal Dream demo, for example.

The readme.txt file on my "Are You Afraid of the Dark" CD specifically mentions
garbled sound when using the SB Pro 2

E. VIDEO/SOUND CARD COMBINATION PROBLEMS You may experience unusual cases where a particular video card, sound card, and co […]
Show full quote

E. VIDEO/SOUND CARD COMBINATION PROBLEMS
You may experience unusual cases where a particular video card,
sound card, and computer combination causes a problem even though
each individual component normally works smoothly. In particular, if
you have a Sound Blaster Pro 2.0, a Pentium 90, and one of a number
of video cards you may experience extremely garbled sounds. These
problems are hardware problems which will occur with any game
similar to Are You Afraid of the Dark, and cannot be handled from the
software side. You may wish to contact your hardware component's
manufacturers to try to solve the problem.

So they knew it was a problem even back then.
I'll attach the readme.txt to this message in case anyone is interested in the rest of it.

The problem they describe there, may be a different problem. Various SVGA cards at the time were notorious for their 'bus mastering' implementation on the PCI bus. They basically get exclusive access to the bus to perform fast DMA transfers and such. It gives them better video card performance, but at the same time the bus is starved, so things like harddisk transfers and DMA transfers to eg sound cards will get stalled.

skitters wrote:

The readme.txt file on my "Are You Afraid of the Dark" CD specifically mentions garbled sound when using the SB Pro 2 […]
Show full quote

The readme.txt file on my "Are You Afraid of the Dark" CD specifically mentions
garbled sound when using the SB Pro 2

E. VIDEO/SOUND CARD COMBINATION PROBLEMS You may experience unusual cases where a particular video card, sound card, and co […]
Show full quote

E. VIDEO/SOUND CARD COMBINATION PROBLEMS
You may experience unusual cases where a particular video card,
sound card, and computer combination causes a problem even though
each individual component normally works smoothly. In particular, if
you have a Sound Blaster Pro 2.0, a Pentium 90, and one of a number
of video cards you may experience extremely garbled sounds. These
problems are hardware problems which will occur with any game
similar to Are You Afraid of the Dark, and cannot be handled from the
software side. You may wish to contact your hardware component's
manufacturers to try to solve the problem.

So they knew it was a problem even back then.
I'll attach the readme.txt to this message in case anyone is interested in the rest of it.

basically in order to play this game on a dos machine is to change sound card to one that work and if so, what would the best sound card for dos, win 3.11 and win 95 since my Pentium 1 machine has all those three on it

Scali wrote:

The problem they describe there, may be a different problem. Various SVGA cards at the time were notorious for their 'bus mastering' implementation on the PCI bus. They basically get exclusive access to the bus to perform fast DMA transfers and such. It gives them better video card performance, but at the same time the bus is starved, so things like harddisk transfers and DMA transfers to eg sound cards will get stalled.

I think they mean that some components are just not able to work together when simultaneously in a system, maybe due to absurdly high ISA bus clock speeds found in some clones. The clock (and thus the bus) speed can be much higher than any card ever expected, and any additional card in the system will add some (capacitive) load to the bus so it's even harder for the cards to react to bus signals in time.

On some motherboards you can even select a divisor for ISA clock to accomodate several CPU FSB speeds, but it may be done automatically as well.

SB16 should work reasonably well.

Jepael wrote:

I think they mean that some components are just not able to work together when simultaneously in a system, maybe due to absurdly high ISA bus clock speeds found in some clones. The clock (and thus the bus) speed can be much higher than any card ever expected, and any additional card in the system will add some (capacitive) load to the bus so it's even harder for the cards to react to bus signals in time.

As far as I know, the ISA bus should never be clocked higher than 8.33 MHz, and there is handshaking on the I/O read/write instructions, so it should never be possible for the CPU to complete an in/out instruction before the connected ISA card has finished the transfer. CPU speed doesn't matter. The transfer takes as long as it takes (there would be no way to make the rep ins/outs work reliably if there was no handshaking). See chapter 18 here: http://www.intel.com/content/www/us/en/archit … l-1-manual.html

So the only way an ISA card doesn't work in a system is when the implementation of the ISA bus is somehow broken. Either the clockspeed is too high, so the handshaking between CPU and peripheral breaks, or the handshaking itself is not implemented properly in the chipset (we are talking about modern systems that implement ISA via a bridge to the PCI bus).

On a properly implemented ISA bus, it simply is not possible that reads or writes get corrupted because the CPU is 'too fast'.
The 'normal' problem is that the sound card needs some time to respond to the commands written to the I/O ports, and the timing is done with delay loops, which break down when the CPU is too fast.

I had to check DOTT adlib driver.

It does calibration by executing tight counting loop between two timer interrupts, and the timer interrupt will then read how far the CPU was able to count and divides the count by some magic number to get some kind of calibration value.

Only problem is that with a CPU that counts slightly faster than expected, the counter gets too large before the timer interrupt triggers, and the division result won't fit into 16-bit word so CPU generates a division by zero exception.

But it was interesting to note, that with a CPU that counts much faster than expected, the counting loop reaches a terminal count before timer interrupt triggers so the calibration value is never calculated and it is left to zero, the result indicating you have a extremely slow PC.