Phantom wrote:I'm not sure exactly what kind of FM chip is present in the Mega Drive
It's a YM2612, which is a bit different. As far as I remember, the YM3812 is the one used on old PC soundcards (like Adlib and SoundBlaster cards) isn't it?
Storminator16 wrote:Will it have a menu with screenshots?
It'll have more than screenshots, if you take the time to fill the disc out fully. At the very least, you'll be able to add additional descriptions for each game, such as the blurb from the back of the box (in multiple languages, if you like), features the game has (languages, players supported, whatever else they put on the back of the box), the release date, developer and publisher of the game, and maybe a couple of other bits of information. And that's just the text-based stuff...
Would Game Genie support be interesting? Will there be any analog control? I'm going to work on the latter two
Go for it.
The coder formerly known as Warmtoe wrote:Does your level of KOS have SPUDMA support in it? So long as the samples are put onto a 32byte boundary you could use DMA to transfer the data over in one lump - rather than trickle feeding it - I think that may be quicker than with store queues - anyway, if you make sure the memory area is 32 byte aligned, we could take that option later.
No, SPU DMA is completely broken in KOS 1.2.0.
I'm not sure if DMA will actually be faster than store queues. It'd certainly be faster than the current way, which is shoving the data out one sample at a time, because we're generating a block of data in main memory which has to be copied over to SRAM. However, if we're generating that data anyway, we may as well use store queues. With DMA, we're doing:
Generate sound -> main RAM, flush the cache, transfer DMA -> SRAM (in parallel)
With Store Queues, we're doing:
Generate sound -> store queue -> SRAM (in parallel)
At best, I think they'd be around the same speed. With store queues we don't have to worry about cache coherency, although it might make generating the sound more difficult.
Is there any way to shift the sound emulation out to the ARM? That is 2 meg of memory and a whole processor that we just aren't using - if you are going to attack the generation of sound - which sounds right - then would it be possible to move this whole thing out there - and just have the main loop basically send the number of frames to generate.
I think the ARM is too slow. We could probably use it for something, but I think the sound generation code is far too CPU-intensive to run on the ARM. We could try to use the sound hardware to generate the sound, but then we'll end up with something like the Smash Pack, and we all know how bad that sounds.
Might be worth a try though. For now, I'm just going to try to modify what we already have. It might be possible to shift the FM or PSG over to the ARM, although Heliophobe said it was too slow to emulate the PSG (as found in the SMS), so...
By-the-way BA - is there any code for this sound emulation method of yours yet?
What can I help with?
Not much code yet. All I've really done is remove most of the sound generating code, and all of the DC sound output code. I'm working on getting DAC emulation running by itself using an SDL version of Genesis Plus (which I should probably have included in the source release actually - it's really quite good), preferably without using the FM cores at all (should be faster). Once I've done that, and it sounds reasonable, I can start working on getting sound output on the Dreamcast side.
I'm not sure if there's anything you can help with for the sound code. Each part kinda relies on the previous part, and it's not really the kind of thing you can easily split up for multiple people.
