Genesis Plus/DC Emulation Discussion

DcSteve · Post by **DcSteve** » Wed Aug 10, 2005 8:29 am

The sound is apparently the most difficult part of this emulator to optimize because of all of its different intricasies. In pvr3, the sound is almost synced but skips and loops every 3-5 secs. Another illegal emu based from this one had to do cpu underclocking to fix some of the looping but wasnt as in sync as pvr3 is. Im wondering- if gfx rendering is shut off for the purpose of sound testing, can genesis+dc play all the audio channels and dac sounds of games at a good khz without any loops, delays, or skips whatsoever.

BlackAura · Post by **BlackAura** » Wed Aug 10, 2005 10:08 am

Not with the current sound system. It will eventually skip, no matter how fast the rest of the emulator runs, because the CPU emulation is not synchronised to the sound (it's synchronised to the video). Stef had a patch that skipped frames based on the sound output, and that did prevent skipping (and had the nice extra effect of behaving just like standard automatic frameskipping). Instead, it just drops the occasional frame, which is less noticeable. However, it can still be way out of sync - it just stays exactly as far out of sync as it was, doesn't skip, and doesn't drift like it does without skipping.

I think that around 22KHz is a reasonable sampling rate using mono sound. Using stereo, 11KHz is more like it. I personally prefer 22KHz mono to 11KHz stereo, so that's probably what we're going to end up with. Unless I can massively speed it up, of course.

DcSteve · Post by **DcSteve** » Thu Sep 15, 2005 11:50 am

Then there is the DAC channel which is used for the "SEEEEGGGAAAA" in sonic 3 and other voicing in games.

alb3530 · Post by **alb3530** » Thu Sep 15, 2005 12:16 pm

Yeah,in DAC's case the voice is inside the cartridge,right?But what about the other channels?Don't they work some way like mids?

Alexvrb · Post by **Alexvrb** » Sun Sep 18, 2005 7:36 pm

alb3530 wrote:But what about the other channels?Don't they work some way like mids?

Yes, but for example, what a MIDI sounds like is dependent on the sample set. Long story short, it has been done on an emulator before (see also: Sega Smash Pack), and the results are mediocre at best.

BlackAura · Post by **BlackAura** » Tue Sep 20, 2005 8:32 am

No, the MD doesn't use MIDI or anything like it. It uses FM synthesis, which you can't really emulate except by doing FM synthesis in software. That's kind of slow, which is probably why Sega didn't bother. They basically had some pre-generated sounds, and played them back instead of properly emulating the sound hardware, which resulted in it sounding like crap.

DARKGATE · Post by **DARKGATE** » Fri Sep 23, 2005 12:07 am

blackaura for answer at my question, emulator have six button support yes?

but i don't understand why there are problems for support six button, the PAD dreamcast have the TRIGGER L-R
the buttons are A-B-X-Y-L-R are six
I have read wich the genesis emu for GP32 is perfect, and i think wich on dreamcast you can made a work marvelous

you are the only wich can give us a good genesis emu.
Bye.

BlackAura · Post by **BlackAura** » Fri Sep 23, 2005 1:36 am

There are six button Dreamcast pads, which can be rigged up in one of two ways - either as six actual buttons (A, B, C, X, Y, Z, in the same order as a Genesis controller), or as a standard pad with L and R moved to where C and Z should be. That means that, if I want to support six-button Dreamcast controllers as well, I would need to add support for those mappings as well. That's a total of three and, ideally, I would like to be able to detect which one to use automatically.

I do have 6-button support working. Kind of. It works find on the PC version, and it seems to work on every game I know of that supports 6-button pads. I haven't got any 6-button Dreamcast pads, so I don't have code to support those.

And one of the Street Fighter games (I forget which one, but it's ROM image is larger than 4MB) doesn't work, because the cartridge uses some extra hardware to allow it to have more than 4MB of ROM.

I'll see if I can release a new version at some point, but I've been rather busy of late, and I've been working on other stuff too. It might take a while.

Sweater Fish · Post by **Sweater Fish** » Fri Sep 23, 2005 2:12 am

For the six button thing, why not just have both Dreamcast L and R and Dreamcast Z and C work as Genesis Z and C at the same time? That way you wouldn't have to detect anything. Not many controllers have both and even if they do, it does no harm to have two versions of a button to choose from. And I think that if analog L and R on a normal controller work then so will the controllers with digital L and R buttons on the face, so you shouldn't have to detect anything there either. Those digital L and R buttons look to the Dreamcast exactly like analog L and R that just happen to go from 0 to 100% with nothing inbetween.

...word is bondage...

Pyrite · Post by **Pyrite** » Fri Sep 23, 2005 3:20 am

Yeah but then you'd have to use the analog stick to acess the menus.

Post by **Christuserloeser** » Fri Sep 23, 2005 10:10 am

...or a key kombination with START + ... + ...

alb3530 · Post by **alb3530** » Fri Sep 23, 2005 9:06 pm

...and the analog thumb pad could be used in this combination,once it's supposed to do nothing during the gameplay

BlackAura · Post by **BlackAura** » Sat Sep 24, 2005 3:08 am

once it's supposed to do nothing during the gameplay

But the analog stick does do something. I have it rigged up to the D-Pad, which works surprisingly well on some games.

Post by **Quzar** » Thu Oct 27, 2005 1:55 pm

It hasn't been pointed out yet publically, but the newest version of fame, with more bugs removed has become slower than c68k. This is according to Stef D.'s Bench68k test, which has two m68k programs written in 68k asm to calculate prime numbers, and do a bubble sort. FAME now falls behind c68k in both of these by about 5-10%.

Stef's benchmarks would probably not show the same results since my compile of c68k is quite a bit faster than his. I was waiting to see him on msn to send him the benchmark program with my compile of c68k and the newest fame.

Also, that is only in raw benchmarks, it is 100% up to the program to show how fast fame works for it. This however does show a drastic speed decrease for fame, as the first version was about 2x faster than c68k at these benchmarks. Now it is slightly slower.

Also, FAZE doesn't exist so there is no reason to be talking about it. For all we know it will be just like FAME, faster at first but horribly buggy, then by the time it gets mostly de-bugged, it is slower. (not to mention 3+x bigger than c68k) BA will release it when it is ready, and there probably isn't much you can do to help (at least based on your track record).

BlackAura · Post by **BlackAura** » Thu Oct 27, 2005 7:05 pm

Would a faster sh4 z80 cpu like FAZE really get GP's sound to the level that BA wants it (close to synced sound w no skipping)? If not, would it be safe to assume that emulating the FM Synthesis with what is currently available will never be accurate or close to it without skipping?

The answers are no, and no.

DcSteve · Post by **DcSteve** » Thu Oct 27, 2005 9:15 pm

What is nessessary to get sound to the level you want: a better written sound code, a faster 68k and a faster z80 cpu?

Post by **Quzar** » Thu Oct 27, 2005 9:46 pm

Time. The sound code in pvr5 is pretty much as fast as the OSD sound can go, pretty much free. The other two things are always helpful, but it is doubtfull either will happen.

The only improvement I could imagine happening to sound is to get rid of some internal mixing(which would probably require a whole aica per-channel volume changing deal to be written) since you could send quite a bit more sound for free per frame.

BA: did you ever get dma sound stuff working right in there? that system doesn't seem to lend itself very well to spu dma since there is no garuntee for alignment. Have you moved to a system that would send the exact number of samples needed per frame instead yet?

BlackAura · Post by **BlackAura** » Thu Oct 27, 2005 11:05 pm

I did have a DMA-based system working, using four frames of sound data. It was still synchronised to the video, so it had some major problems.

Essentially, the problem is that the Dreamcast's video hardware does not output at 60 frames per second. It outputs 59.94 frames per second, while the sound code was outputting 1/60th of a second worth of sound per frame. So, assuming a sampling rate of 24KHz, we were generating 400 samples per frame, while the sound hardware was consuming 400.4004 samples. That means that we're generating 24 samples per second more than we needed. Since the buffer is only 1200 samples (three frames) in length, the output position in the buffer would overtake the playback position once every 50 seconds. When playing, the sound is absolutely fine for about 30 seconds, and then sounds terrible for the remaining 15 seconds as it's playing bits of data from three frames ago, and bits of data from the current frame.

I've not tested this on a VGA box (because I don't have one). VGA should run at exactly 60Hz, so there should be no problem with that system. If anyone has an old copy of GP/DC with the problem I described above (it's one of the source-only versions after PVR test 3), I would appreciate if they could try it on a VGA box to see if it has the same problem.

In theory, running a sampling rate of 23976Hz should fix the problem. We just put out 400 samples per frame, and it should work. I never got around to trying this out though. We'd also have to put some detection code in there to only use 23976Hz on an NTSC or PAL-60 TV, and use 24000 for VGA and PAL. Still, if the calculations aren't exactly correct, or if there are any variations for any other reason (such as the emulation slowing down), it screws up. A single frame taking 1/30th of a second instead of 1/60th of a second will cause the same distortion to come back, but this time only another slow frame will fix it.

To fix that, we use Stef's sound synchronisation. Basically, it monitors the sound output, and uses that to automatically skip frames. So it takes care of auto frameskip for us. If you have n buffers, you can tolerate n-2 skipped frames without any sound glitches. 3 buffers should work fine, and make the audio in perfect sync with the video (no more lag). Gens uses 8, and I can't say I've ever noticed any lag issues with Gens.

It's also possible to speed the sound generator up a bit too. First, only the DAC needs to be updated as often as it is. There's no benefit in updating the FM synth more than once a frame, and generating the FM sound in smaller chunks hurts performance. So the FM and PSG emulation can be run once per frame, at the end of the frame, while the DAC can be run as required. It'll break Afterburner 2, but that's OK. I can always stick a workaround in there for it. Similarly, we don't actually need stereo sound. It'd be nice, but I'd rather double the sampling rate and be stuck with mono sound. 12KHz stereo wors as well as 24KHz mono, but 24KHz mono sounds much better.

However, that's all academic at the moment. I don't really have time to work on it right now, and I won't for several weeks. I'm too busy sorting everything else out, and everything's been kinda chaotic since I finished Uni a couple of months ago.

Speaking of which, I have some stuff I need to do.

Post by **Quzar** » Thu Oct 27, 2005 11:27 pm

Very interesting. I'm in need to fix the way all the sound rendering in NeoDC works. Right now it's based pretty much on an arbitrary number of samples and i just check it a bunch of times randomly.

Horribly unscientific, but it works(barely).

Where does the magic 23976 number come from? i have a feeling i've seen it before somewhere (maybe in an SMS discussion, although that could have just been a similar number). I'd have to guess that it's the closest to 400 per frame at 59.97fps? why not 23988 though?

Also, why 400 samples per frame? just to get close to what 24khz gives you?

BlackAura · Post by **BlackAura** » Fri Oct 28, 2005 3:10 am

Currently, the emulator uses 24000Hz, which is the number Stef chose because of two important properties:

1 - It's evenly divisible by 60 and 50, to give an integer number of samples per frame (400, or 480) in both NTSC and PAL emulation modes.

2 - The number of samples per frame is an integer multiple of 16. Given 16-bit samples, that means it's always a multiple of 32 bytes - the same size as the SH-4's cache line, the store queue size, and the DMA size. Ideal for DMA transfers.

23976Hz is simply 400 (samples per frame) x 59.94 (frames per second). Pretty much the simplest way to get a sample rate that works at 59.94FPS while still being a multiple of 16 samples.

Looking around, 23976Hz (or similar numbers) actually show up quite often, especially in regard to TV broadcasts, For example, the framerate of an NTSC (progressive scan) DVD is 23.976 FPS.

It's a shame that you can't decouple the sound output from the system emulation entirely in a MegaDrive emulator, as you can with a SNES emulator. DreamSNES, for example, simply uses a single looping buffer, and starts it playing. At the end of a frame, it reads off how many samples have been played, generates that many samples, and uploads it. Simple, effective, and doesn't need any kind of synchronisation to work. It also deals with the emulation slowing down without any audio glitches (aside from slowdown), and can deal with frameskipping quite easily.