Well, since you're back, maybe you can answer another question. The Genesis and SNES have dedicated (perhaps not fully, but enough) sound hardware, where the PCE controls sound generation within the CPU. That's my understanding, anyway. Does the task of sound generation, particularly for HuCard games where the soundtrack and sound effects must all by CPU generated and coordinated, put a significant strain on the CPU? Does that limit the available computing horsepower for other tasks?
Yes and no. Well, actually no.
First. The CPU itself doesn't generate the signals and such for the audio unit. The audio unit is a separate device just like any other audio chip. It just happens to be located on the CPU dye for cost saving measures - you don't have to fabricate another chip, the system board doesn't need extra address lines and logic decoder chips. As far as the CPU (and programmer) is concerned, the audio chip is external like any of the other chip in the system or cd unit.
Second. Most(all) PCE games keep the instruments simple in design - they change channel registers once every frame at the fastest. Most of the time it's about every 4-5 frames for register changes. This means the music engine only takes about 1-2% CPU resource. If you add PCM samples, then you start to eat a little more. About 4-5% cpu resource per sample being played. Most games only use one channel/PCM effect at a time and mostly for a drumkit or such. SF2 uses two and Batman uses two. And games like Bomberman 93/94 use not PCM samples. The drums and such are all done/modeled with 'noise' modes of channel 5 or 6. The PCE could have played samples at 1% cpu resource if it weren't for a bug in the audio chip. The audio unit channels
actually hold PCM samples, just really small ones. You could treat that as a buffer and refill it at like less than 1khz to get really high playback rates (32khz, 44khz, 112khz and such), but the bug in the audio unit causes a sound blip when the channel DAC is turned off for sample reloading. At 1khz, the small spike in audio it causes a low cycle but loud tone - rendering the method unusable. The SGX and coregrafx I fix this bug, but Duo and later models do not. Enough of my ranting about that
I've been doing a lot of audio/music research this year. Looking into how hucards create instruments, etc. Talking with David Shadoff, who did the MML functions for Magickit over 7 years ago, all the games he looked at used a version of Hudson's MML player for music engine. The developers didn't bother creating their own. Bloody Wolf is the only game that really stands out in how it does some if it's instruments, but for all I know it could still be using a revision of Hudson's player. The system card has this player build into it's bios routines.
The real kicker is that the PCE is capable of playing MOD style music. Yet only two games did something like that. One was that boxing game, but it was reeeeaaallly generic in design and the other was Batman. Batman basically had 1 MOD channel where it could bend a sample into frequencies for notes like a MOD player does. The main instrument that's used for that channel is the 'bass guitar' and some other super r-type-ish sounding instrument. The drums are fixed frequency samples. The PCE is also capable of doing more complex instruments because of the TIMER chip and yet (again) no game ever does this. This isn't some secret knowledge or anything. I'm really at a loss there. Anyway, the PCE is capable of doing up to 6 MOD channels, though you really only need 4. The player code has to be extremely optimized since doing it all in software eats up gobs of cpu resource. I think the fast version I calculated base on my player code was about 26-27% cpu resource - 7khz stereo 4 channel. Not bad at all
Also, and this is completely random, I'm sure... how difficult is the PCE to program for compared to its compatriots? It certainly seems like there are many PCE games that do little to exploit the CPU, merely relying on lowest common denominator capabilities.
From what I could gather, it was more of a style of development. As CCovell put it, the PCE has that 8bit charm in a lot of it's games early games. Even as the games advanced, the game mechanics and over design were usually kept more simplified. It's target audience I guess. Not all games are like that, but overall you kinda get that feeling. It's just a charm about the games. Later games tend to be more sophisticated. Like Seiya Monogatari, Xanadu, Xanadu 2, etc. Not just in design, but hardware interface too. Earlier CD games are really bad at efficient design of code. Unnecessary loads time (really, longer than should be because of the design of the load structure), inefficient memory usage - i.e. most of the time no compression and wasted/empty ram/space. Stuff like that. If you look at Gate of Thunder, it's amazing. Not only does it efficiently store data as a single block for fast loading, it also uses 'real' compression so that the CD ram goes further, and the code is fast enough to decompressed sprites in real time on the fly - that's extremely impressive(I did a lot of research on GOT). The game script which controls all the events is optimized for minimal chance of flicker and sprite positioning. Basically a professionally build game. LOT is the same. Red really knew what they were doing. To top it off, it would have easy to make other shooters using either of the two game engines. Too bad they never did.
Edit: Heh - Chris beat me to it
