Sound fix in CSB4Win

[DjArcas]

Just got this, and started looking through the code... I noticed the sound was playing at the wrong speed...

changing these two lines of code

WavBuf->nSamplesPerSecond = 7000;
WavBuf->nAvgBytesPerSec = 7000

to this

WavBuf->nSamplesPerSecond = 5000;
WavBuf->nAvgBytesPerSec = 5000

fixed it tho...

As an aside tho... *why* did you convert the *atari* version. Tho I had an ST, and loved it to bits (er, literally), the 16 colours, palette switching on a vblank, all that, is going to make improving this a pain... ah well

[Paul Stevens]

I chose the Atari version because I was familiar with the Atari. Moreover,
I had some hardware documentation for the ST which made it possible
to decipher some of the hardware-dependent code in the program. Moreover,
it never occurred to me that the Amiga version was significantly different.

It is only of historical interest now. You are welcome to translate the Amiga
version. ; - )

I think that you will find that major improvements are going to come with
dificulties unrelated to the particulars of the Atari hardware.

PAul

P.S. I will check out that samples per second business. I have no idea where
I came up with the 7000. I am quite sure that the game as a whole played
at 60 Hertz in US and 50 Hertz in Europe. Several people from overseas
complained that my program was too fast. But I am convinced that it is working
as it did on the Atari here in the US. You don't suppose the same clock is
used for the sound as for the vertical sync? It is about the ratio you say I
am off.

[DjArcas]

The main things about the Amiga version that differed, is that it doesn't change the palette twice per vertical retrace... (look at what the mouse cursor does as you move it around.. and the Amiga had a flesh coloured (well, brown) hand, too)

I'm looking into changing that (I'd like to have each champion's attack button in that champions colours, fo no very good reason)

And, as for translating... HELL no... I'm quite quite amazed you did what you did (this won't stop me figuring out a fair old few things you didn't tho *wink*)...

My eventual goal is to have the same game, but abstract it, so that people can write entirely new adventures for it... new monsters, levels, the works... :)

Adam

[Paul Stevens]

Ah, but you are very abitious. I wish you well. I have already been
there and have one t-shirt..

Feel free to ask for clarifications and hints and whatever I might be able
to provide. Unfortunately I know very little about the program that I wrote !!!
I did manage to figure out why the event queue works. I puzzled over it
for a couple of months thinking that it couldn't work and I added a lot of
debug code to prove that it didn't work. It works.

I did a side-by-side comparison of the sounds from the PC version
of DM and my CSB for Windows. I agree that 7000 samples/second is
too high. But I found that 5000 was too low for my taste. So I compromised
and set it to 6000. Thanks for the tip.

Good luck,

PAul ---- prsteven@facstaff.wisc.edu

[Joe Jackson]

Hi.

[DjArcas]

Uhm... hi

[ChristopheF]

Sorry to bring back up a 10 years old topic... but I have some news.
I made some research about the playback frequency of sounds in the Atari ST versions of DM & CSB. Here is what I found by studying in detail a disassembly of the game code and some technical documentation.

In order to play digital sounds, the game engine programs Timer A of the MK68901 MFP chip so that an interrupt is triggered periodically.
A new sound sample is played during each interrupt until the sound playback is complete and the interrupt is then disabled.
While the MFT chip itself is clocked at 4 MHz, it has a separate clock source for the reference signal used by the timers: a 2.4576 MHz crystal.

The game configures Timer A in the following way:
The Timer A control byte is set to $01 which means that it will work in delay mode and with prescaler = 4.
When the sound of the opening dungeon doors is played on the main screen (where you choose Prison / Resume), the Timer A data byte is set to 145 ($91).
When any other sound in the game is played, the Timer A data byte is set to 112 ($70). This value is found in each of the sound descriptors in item 562.

This gives the following results:
Playback frequency of dungeon entrance door sound: 2.4576 MHz / (4 * 145) = 4237 Hz
Playback frequency of all other sounds: 2.4576 / (4 * 112) = 5486 Hz

If you listen carefully to the original game, you will notice that the door sound is not played at the same speed for the entrance door and for doors inside the dungeon.
Also, there is no difference in sound playback frequency between a US (NTSC) and European (PAL) Atari ST computers.

These values differ from the 6000 Hz value that is used by CSBwin for sound playback. I'm certainly nitpicking here, but I think this should be changed in CSBwin for the sake of accuracy

[Bit]

Now, that's what I call research
I took for both - (not spotting that one, but always having a light feeling of an oddity - and not listening to the original one) 5000 Hz - more than a halftone ... tsktsktsk