Genesis Plus/DC Emulation Discussion

[Stef.D]

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).

Just to clarify some point out :
Bench68K was originally wrote by Fox68k, not by me.
I just sent you a copy
Something you need to know about this bench, it heavily uses the DIV instruction. I know Fox68k recently made change to the DIV instruction to have accurate cycles calculation, something than C68K doesn't have :
if you take a look on C68K source, you can read : "todo : fix DIV instruction timing".
C68K assumes an "average" number of cycles for division instruction, that's totally wrong but it's a fast solution. Having correct cycles calculation for DIV instruction take many extra CPU time. I guess if we try to use another bench code (no DIV instruction) FAME is ahead C68K without difficulties.

[Stef.D]

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.

Does anyone have a link to the SMS Plus source code? Considering that SMS Plus and Genesis Plus are both written by Charles MacDonald and are very similar to each other, there might be something useful hidden in there.

You have a perfect understading about how sound emulation works
About the 59.94 Hz, that's the real NTSC refresh rate, we assume 60 Hz, but in reality, it's 59.94 Hz... i didn't worried about it in Gens, at least in the old version, but i modified it in my WIP because it's more correct and i know it's the only way to have smooth video and smooth sound without using heavy sound interpolation processing.
Unfortunatly the magic 23976Hz number works only for NTSC, so i guess we have to choose different sound rate for PAL and NTSC.

[Syd]

Thanks a lot BA, they were two very interesting posts. Now I have a better understanding of how sound emulation actually works.

I was always wondering why SNES sound was so much easier to emulate than the Genesis sound. Now I understand how much crap you have to deal with in Genesis Plus.

[DARKGATE]

excuse me boys, a fast question if possible answer please =).
The version wich you blackaura working of your emu MEGADRIVE, the games of cars "OUT RUN, TURBO OUT RUN, THUNDER BLADE, SUP. HANG ON) work now?
For christmas a version ufficial can get out? =|
Now support the six button?
Bye.

[BlackAura]

You have a perfect understading about how sound emulation works

Thanks.

The version wich you blackaura working of your emu MEGADRIVE, the games of cars "OUT RUN, TURBO OUT RUN, THUNDER BLADE, SUP. HANG ON) work now?

No. Assuming that we're staying with the hardware renderer, they never will work properly. However, the emulator is fast enough that you could use the software renderer, turn down the sound quality a bit, use a bit of frameskipping, and still have the game running at (relatively) full speed. Probably quick enough for Road Rash anyway.

It's probably worth putting the software renderer back in anyway. It'll never be as fast as the hardware renderer (although it could be sped up a little), but the hardware renderer will never be as accurate, no matter how much work gets done to it.

For christmas a version ufficial can get out? =|

That's how long? (Looks at calendar) Just under two months, and there's still a lot of work to be done.

It might happen, if I get enough free time. That's kind of contingent on me finding a job and getting settled down a bit first. Paradoxically, not having anything to do seems to leave me with less free time. Certainly less free time that I actually want to spend doing anything.

Now support the six button?

Considering that I've not done any work on GP/DC since last time I answered that question, the answer is still "I have it working in the emulator, but I haven't rigged the Dreamcast code up to it yet". Don't worry, it'll be there.

[Quzar]

Just to clarify some point out :
Bench68K was originally wrote by Fox68k, not by me.
I just sent you a copy
Something you need to know about this bench, it heavily uses the DIV instruction. I know Fox68k recently made change to the DIV instruction to have accurate cycles calculation, something than C68K doesn't have :
if you take a look on C68K source, you can read : "todo : fix DIV instruction timing".
C68K assumes an "average" number of cycles for division instruction, that's totally wrong but it's a fast solution. Having correct cycles calculation for DIV instruction take many extra CPU time. I guess if we try to use another bench code (no DIV instruction) FAME is ahead C68K without difficulties.

Well, I don't think it could be that far off since in my emulator itself, when I set it to fame and use the previously newest release I get much faster average fps than with the newest release.Also, I tried with both of the asm tests bubble sort and prime number, and got similar results. The bubble sort does not use div at all.

Ah, sorry, i thought you had written it since you sent it to me. I also didn't notice 'fox68k' or 'oscar (can't remember his last name)' anywhere in the source.

Is there any chance you will ever go back to C68k and work on it some more? If it is ever to be compiled using gcc 4.0.0 some modification at least needs to be made there (due to lval casts).

[UndeadDC]

I'm sorry if this is a stupid question, but I have a modest understanding of programming at best. Anyway, since the the DC uses an arm processor for it's sound chip couldn't you use it to emulate the genesis FM synth circuits serperately, or is it implemented into to much of a specialized way to be this flexible? Or maybe it's just not powerful enough?

[BlackAura]

No, the ARM7 is nowhere near powerful enough. It's intended for running (very) small bits of code to control the sound hardware.

[Stef.D]

Just to clarify some point out :
Bench68K was originally wrote by Fox68k, not by me.
I just sent you a copy
Something you need to know about this bench, it heavily uses the DIV instruction. I know Fox68k recently made change to the DIV instruction to have accurate cycles calculation, something than C68K doesn't have :
if you take a look on C68K source, you can read : "todo : fix DIV instruction timing".
C68K assumes an "average" number of cycles for division instruction, that's totally wrong but it's a fast solution. Having correct cycles calculation for DIV instruction take many extra CPU time. I guess if we try to use another bench code (no DIV instruction) FAME is ahead C68K without difficulties.

Well, I don't think it could be that far off since in my emulator itself, when I set it to fame and use the previously newest release I get much faster average fps than with the newest release.Also, I tried with both of the asm tests bubble sort and prime number, and got similar results. The bubble sort does not use div at all.

Ah, sorry, i thought you had written it since you sent it to me. I also didn't notice 'fox68k' or 'oscar (can't remember his last name)' anywhere in the source.

Is there any chance you will ever go back to C68k and work on it some more? If it is ever to be compiled using gcc 4.0.0 some modification at least needs to be made there (due to lval casts).

FAME is also slower with the bubble sort test ? i'm really surprised
maybe some very bad cache alignement issues.

no problem about the bench, it's just for Fox68K

You said that C68K need to be modified for GCC 4, but i believe the last version of C68K is already modified to avoid lval casting.
I though you already had it ^^
C68K is a bit slower since these modifications (not too much hopefully).
problem is : i don't remember the link where i uploaded it, and i don't have my FTP account infos here :p

[Quzar]

Maybe I do already have it. I tend to forget about that kind of thing. I'm not using GCC 4 yet, so I don't care, just looking to see if you're ever going to update it =P.

I'll always be using c68k as opposed to fame because of the size issue, when I get to supporting arcade games, I will want every bit of ram free and c68k is much smaller than fame.

[DcSteve]

wouldnt it be possible and less time consuming to implement a version w/ sound done in the same method as Sega did (midi quality) but with less bugs and no looping or skipping (which smashpack doesnt really do for the games that come with it anyway). Im sure refined smashpack quality sound would still satisfy lots of people.

[Quzar]

The smashpack didn't have 'midi quality' genesis sound, what it had was midi'd versions of genesis sound. What they did was they just generated sound effects and such used by those games and had their sound emulatore play them back, instead of doing any calculations and real emulation.

At least that has been how I've interpreted every prior discussion about the way it worked.

[Stef.D]

Hmmm... from what i heard when i tested the smash pack, it looks more like partial emulation of FM chip.
Normally you have 6 channels with 4 slots for each.
Slots can be linked together and depending the "link shem" they can modulate an slot input or give output.
I believe Sega just ignored "shem link" and assume each slot do output (simpler than modulate). They also ignored all envelop calculations (attack, decay, release...).
It's why it sounds so horrible... sound generation is close to what PSG can do (just a bit better) and really far from what YM2612 can do
But at least, that requires far less CPU time to generate YM2612 sound.

[DcSteve]

what about emulating it with the shem link and all the envelop calculations, would it still take less cpu time than YM2612.

[Quzar]

what about emulating it with the shem link and all the envelop calculations, would it still take less cpu time than YM2612.

That would mean emulating everything, considering he said those were the two things taken out, we would have the same emulation we currently do.

[DcSteve]

ok, then how bout ignoring some of the calculations instead of all of them and doing variations with what works best.

[Quzar]

Because if that's what BA wanted to do he would have done it already.

[DcSteve]

i know that and he has already said he wont do that in the past. Im just curious to know if its easier to implement that instead of whats currently being attempted.

[Stef.D]

I know old version of KGen used a tips for having fast YM2612 emulation.
envelop calculation were only updated once by frame.
Of course that's not correct, but it's a good solution to have acceptable sound emulation and speed.
IMO, i don't like use that type of trick, i know the dreamcast has enough horse power to handle complete genesis emulation at full speed, we just have to do it
There is many CPU power waste in sound interface (transfert between "emulation buffer" and "dreamcast buffer") and also probably in video interface we can do better. Software VDP can be improved also...
Even using complete software emulation, i'm pretty sure it's possible to achieve full speed (60 FPS emulation).

[dr apocalipsis]

God may hears you...

Are you God?