simplest method for 32x sound?

[pw_32x]

I've been experimenting with sound on the 32X and nothing I try works. Sometimes I get clicking.
What's the most basic way to get anything out of the 32x sound?

I've got the same commonly used init code.

Code: Select all

#define SAMPLE_RATE      22050
#define SAMPLE_MIN       2
#define SAMPLE_CENTER    517
#define SAMPLE_MAX       1032
	

   // init the sound hardware
    MARS_PWM_MONO = 1;
    MARS_PWM_MONO = 1;
    MARS_PWM_MONO = 1;
    if (MARS_VDP_DISPMODE & MARS_NTSC_FORMAT)
        MARS_PWM_CYCLE = (((23011361 << 1) / (SAMPLE_RATE) + 1) >> 1) + 1; // for NTSC clock
    else
        MARS_PWM_CYCLE = (((22801467 << 1) / (SAMPLE_RATE) + 1) >> 1) + 1; // for PAL clock
    MARS_PWM_CTRL = 0x0185; // TM = 1, RTP, RMD = right, LMD = left

	unsigned short sample = SAMPLE_MIN;
	unsigned short ix;

	// ramp up to SAMPLE_CENTER to avoid click in audio (real 32X)
	while (sample < SAMPLE_CENTER)
	{
		for (ix = 0; ix < (SAMPLE_RATE * 2) / (SAMPLE_CENTER - SAMPLE_MIN); ix++)
		{
			while (MARS_PWM_MONO & 0x8000); // wait while full
			MARS_PWM_MONO = sample;
		}
		sample++;
	}

And after that, I just want to feed the output the simplest way possible. Eventually I'll take a better look at the interrupt driven dma style of playing but right now I just want to play a tone or something.

Code: Select all

void main ()
{
    while (1)
    {
    	// somehow feed a tone to the audio hardware
    	// set something to MARS_PWM_MONO, maybe?
    }
}

Maybe I'm being naive and it's not so simple

[Chilly Willy]

The simplest (IMHO) is to make a double-buffer that is DMAed to the PWM registers by one of the SH2 DMA channels, then make routines to fill those buffers. Here's my XM player examples for the 32X - one uses the secondary SH2 in a loop watching the DMA registers to see when to fill the buffers, and the other uses the DMA transfer done interrupt on the secondary SH2 to see when to fill the buffers.

https://www.mediafire.com/file/kbru3l9u ... op.7z/file
https://www.mediafire.com/file/7z2m4uwo ... tr.7z/file

Note that these are kinda old, and the interrupt driven version may have problems on certain 32X boards with the buggy SH2 revision chips. The code in Doom 32X Resurrection shows the latest unified interrupt code with the proper DMA interrupt handling to work on all models of the 32X. So I suggest you also look at the D32XR code after you understand the examples posted above.

[pw_32x]

(...several years pass...)

and the interrupt driven version may have problems on certain 32X boards with the buggy SH2 revision chips.

I was curious about what kind of bugs. I've been porting the old Tandy CoCo game Downland to various platforms and I'm currently porting it to the 32X. This time I can't avoid getting sound to work, so I've been spending time studying the xmplayer code.

In my experiments on 32X hardware I've noticed that if I pause the music with the start button, the sound effect playback is erratic. In the sense that it doesn't always fire. In start_sfx(), the mixer data pointer is set to sound data, but do_sfx() never sees the data field as anything other than null, so MixSamples() is never called. Multiple calls to start_sfx() keeps using up mixers because it sees the other mixer data fields as non-null, and eventually runs out. But everything works when the song is playing. From what I can see the music playback should be independent.

I'm a bit stumped on that one. Could it be weirdness due to cached/uncached pointers?

Downland doesn't have any music, just sound effects. I imagine a workaround would be to play a silent track but that irks my sensibilities.

Note that these are kinda old, and the interrupt driven version may have problems on certain 32X boards with the buggy SH2 revision chips. The code in Doom 32X Resurrection shows the latest unified interrupt code with the proper DMA interrupt handling to work on all models of the 32X. So I suggest you also look at the D32XR code after you understand the examples posted above.

I was quite happy working with the xm-player until I hit that snag. Any idea what it could be? I guess I'll start looking at the d32xr code.

[pw_32x]

(...12 hours pass...)

I slept on it and I had the feeling that maybe the sfx_mixers might not have been consistently cache cleared before being used. Since the call to start_sfx() is done on the main CPU while do_sfx() is done on the secondary, I figured do_sfx() was using stale mixer data. Most functions that use the mixers call CacheClearLine but it turns out that stop_sfx() and do_sfx() don't. So I added the calls and things seem to work perfectly now.

I also realized that I could've run the sound DMA interrupt on the main CPU, as Downland is far from being a taxing game, but I don't need to anymore.