<< Newer Article #64 Older >>

Hacking in the core again

You may remember recently I complained about the state of the sound system in MAME. Well, after some discussion on the list, I've decided it's time for another round of "clean up the core and see if I can avoid breaking anything". We'll see how it goes.

The basic gist is that the sound cores should work more like the CPU cores, in that you should be able to list multiple sound cores in your machine driver and have them just work. But that's not the way things were written originally. From its earliest days, MAME has only supported multiple instances of sound cores through a fairly hacky mechanism.

Take, for instance, Gyruss. Gyruss uses 5 AY-8910 sound chips, plus a DAC driven by a separate sound CPU. The way MAME currently works is that you create two sound chip entries in your Gyruss machine driver. The first entry says, "yes, I have some AY-8910's, go look in the special AY-8910 configuration structure to find out how many and what the clock speed is". The second entry says "oh, and I also have some DAC's, go look in the special DAC configuration structure to find out how many".

So in essence, each sound chip has its own configuration structure, and these structures vary from chip to chip. Inside these structures is a bunch of important information, such as how many chips there are, what clock speed they run at, what volume to play back at, etc. The problem is that each structure is different. A number of sound cores don't even support more than a single chip, so there might not be an entry in the configuration for the number of chips. Other sound cores assume a clock and don't let you specify one. Furthermore, in almost every case, if a clock is specified, it is only a single clock for all sound chips. There is at least one game (Blue Print, I believe) which has two identical chips clocked at different frequencies.

So, things need to change. Rather than initializing the AY-8910 core once for all 5 chips in Gyruss, we should instead initialize the AY-8910 core five times, each time creating a new chip. The clocks for each chip need to be independently specified. This involves going through and modifying every sound core to work this way. Then it involves visiting every driver in MAME to change the way the sound chips are configured.

Since I'm visiting every sound core again, I've also decided to fix another annoyance. The code in sndintrf.c looks a lot like how the CPU interfacing code looked like before I cleaned it up a year or two ago. It references a number of external functions for each sound core, and contains large difficult-to-maintain lists of these functions. Instead, it should only reference a single get_info function for each sound core. That function can be called to return pointers to all the other needed functions. This properly pushes all the sound core information into the sound core itself, rather than piling a bunch of that information into the single gross file sndintrf.c.

In the end, this should have little net effect on MAME's operation as a whole. But the internal structure will be a lot cleaner as a result, and that's important to code geeks like myself!