General Insanity (Genesis + PVR)

Ian Micheal · Post by **Ian Micheal** » Thu Jun 24, 2004 10:08 am

No saving code working or started in the emulator that i know of. I have no throttle so it's running as fast it can no frameskip or underclocking needed.

Any way back on topic this is not about neogeo cd sorry.

Carry on lads.

Post by **Christuserloeser** » Thu Jun 24, 2004 10:13 am

Storminator16 wrote:Ummm, there has only been one bin release already. The most current versions are all faster than that one

Nope, Meta compiled a 2nd release today

Storminator16 · Post by **Storminator16** » Thu Jun 24, 2004 10:27 am

Cool

Anyhoot, I've done what I could.

http://www.storm-studios.net/gpdc_save.zip

Just 2 files called 'save.c' and 'save.h'. I placed the necessary undefined funtions in save.c and I commented on them as such. Needs 3 VDP functions and about 6 z80 functions to be defined.

DcSteve · Post by **DcSteve** » Thu Jun 24, 2004 11:58 am

has anyone intergrated saving into the latest source yet? Eighter way, can someone release an elf so i can test this mother out (build pvr-3 w c68k).

Warmtoe · Post by **Warmtoe** » Thu Jun 24, 2004 12:00 pm

Ian Micheal wrote:Well with stefs help my own crazy 2 part dev system i have the c68 in neogeo now working OMFG it's fast fullspeed no slow down on metal slug.

Holy cow!

Mooooo... see what a great team we make when we all work together? I don't mean to pretend for a minute that my contribution to GPDC was anything incredible, it's all BA's hard work - but I think the encouragement and code mods we've all chipped in here have helped with both of these...

Looks like real CARE to me!

speud · Post by **speud** » Thu Jun 24, 2004 12:16 pm

will your link is dead, i might be able to help with the saving code if you need me.
[EDIT]nevermind, dont really know why it doesnt work when i use "save target as" with mozilla, but when i click on the link i can save the file.[/EDIT]

so now neocd is using the new c68k too eh? thats excellent news, congrats stef

got to try and compile gpdc with it now, cant wait to see the result.

Storminator16 · Post by **Storminator16** » Thu Jun 24, 2004 2:35 pm

DcSteve wrote:has anyone intergrated saving into the latest source yet? Eighter way, can someone release an elf so i can test this mother out (build pvr-3 w c68k).

It will be awhile still until saving actually works.

Ian Micheal · Post by **Ian Micheal** » Thu Jun 24, 2004 2:53 pm

speud wrote:will your link is dead, i might be able to help with the saving code if you need me.
[EDIT]nevermind, dont really know why it doesnt work when i use "save target as" with mozilla, but when i click on the link i can save the file.[/EDIT]

so now neocd is using the new c68k too eh? thats excellent news, congrats stef
got to try and compile gpdc with it now, cant wait to see the result.

Stef is great core is wonderfull speed is much better. Fantastic job. Also Speud you did a fantastic job on pvr rending.

All adds up as a great team effort. Thou this project will be hard to compile now.

Storminator16 · Post by **Storminator16** » Thu Jun 24, 2004 3:17 pm

Ian Micheal wrote: Thou this project will be hard to compile now.

?

This is starting to look familiar...

speud · Post by **speud** » Thu Jun 24, 2004 7:01 pm

wow the new core is giving it a real boost. the sound is still a bit desync with some games but its a lot less anoying than before, plus its fullspeed or close to it without having to lower the z80 clock's speed !

i tried ians method and called audio_init() in the rendering loop, it made things go really slow and no real sound was output (it was noise more than sound actualy). isnt there a way to modify the sound rate without having to init the sound again?

MetaFox · Post by **MetaFox** » Thu Jun 24, 2004 8:06 pm

I just compiled and tested this and I was floored. I'm at a loss for words - Awesome.

Ian Micheal · Post by **Ian Micheal** » Fri Jun 25, 2004 12:20 am

I was not initing the sound again it was for the first time and inside my frameskip routine .

I could give you a bin fixed but im a bit busy.

Ian Micheal · Post by **Ian Micheal** » Fri Jun 25, 2004 12:24 am

inside my main loop inside the frameskip routine

if (fs_enabled) {
if ((timer_end >= (timer_start1 + (1000.0/(fs_value)))) && (timer_end < (timer_start1 +(4*(1000/fs_value))))){
timer_start1 = SDL_GetTicks();
audio_init(12050);
SDL_BlitSurface(bmp, &src, screen, &viewport);
SDL_UpdateRect(screen, viewport.x, viewport.y, viewport.w, viewport.h);

etc works fine and not slow and keeps in time i can do this on the SDL version im sure i could do it on this one.

speud · Post by **speud** » Fri Jun 25, 2004 1:06 am

yer so youre calling audio_init() inside the main loop, thats what i meant.
heres what i tried and made things go slow:

Code: Select all

if (dc_options.sound_enabled) {
   if (!dc_options.fps_display)
      pvr_get_stats(&pvrstats);
   if (pvrstats.frame_rate > 0)
      audio_init(12000 / 60 * pvrstats.frame_rate);
}

i dont blame you for the slowness, i just stated it was slow and the sound didnt work properly, because it is the case.
i dont know why its not causing any problem for you, maybe audio_init() has changed? or maybe thats something in my code?

Ian Micheal · Post by **Ian Micheal** » Fri Jun 25, 2004 3:18 am

yeah Pvr get stats seems not to work like SDL. Not tested it with this version. C68k in the sdl version it seems fullspeed now. I do have auto frameskip.

qatmix · Post by **qatmix** » Fri Jun 25, 2004 4:22 am

Anyone thought of compiling NeoMame with the new 68K Core? That was already pretty fast!

Thanks
Q

Storminator16 · Post by **Storminator16** » Fri Jun 25, 2004 4:52 am

'Pvrstats.framerate' is a float integer. Try '(int)pvrstats.framerate'.

speud · Post by **speud** » Fri Jun 25, 2004 5:03 am

actually thats what i did, i removed it to see if that was the reason of the slowdown and i didnt think about changing it again when i pasted the example.

btw will, where your save code is coming from? did you take it from another open source genesis emu or did you write it from scratch?
is someone working on implementing sram support (i dont think ive noticed anything about that in your code but please correct me if im wrong)?

BlackAura · Post by **BlackAura** » Fri Jun 25, 2004 5:09 am

Here's how I'm doing sound:

I've completely removed the sound output code, and I'm modifying the sound generation code. The way I'm doing this will break one game (Afterburner 2, because it uses the PSG as a second DAC), but I don't really care at the moment. If the emulator gets fast enough to go back to the original way (which is more accurate), we can do that. Until then, something that works for every other game is acceptable, and it'll still sound better than the Smash Pack did.

Instead of two sound output channels, we will have four: PSG (center), FM (left), FM (right), DAC (center). I'm pretty sure the DAC can't do stereo, but if it can we could just pan the DAC channel.

Only the DAC channel will be generated with sample-level accuracy, because it's required for it to work. So during the frame emulation, the DAC buffer is filled with the appropriate data.

At the end of each emulated frame, we check to see how many real frames have elapsed. If all goes well, this will be one frame, but it might be two or (possibly) three, although I don't think anything runs quite that slowly.

The emulator will then generate that many frames worth of sound data for each FM channel and the PSG channel. These should be generated in 16-sample blocks (so we can use store queues to shove them out to the sound hardware), and written directly to sound memory using store queues. We will be shoving more data out to sound memory, but we'll be able to generate that data more efficiently, because we aren't re-reading and mixing the data at all. This is the same principle behind the accelerated VDP, which actually generates more data than the software renderer, but you can see how much faster it is...

The sound data is then written out to the appropriate part of sound memory, just in front of the currently playing block.

If all goes well, this approach should be faster, and it won't skip even if the thing's not running fast enough to keep up.

We should be able to run this at three sample rates: 48000, 24000, and 14400Hz (because these sample rates will all work at 50Hz and 60Hz perfectly). I don't think we'll be fast enough for 48000Hz, but 14400Hz should be easily managable.

I'm still not sure if we should use the MAME sound emulation code, or the Gens sound emulation code. I've not tried to benchmark them or anything, but as far as I can tell there's very little difference in speed (certainly too small to tell either way).

Phantom · Post by **Phantom** » Fri Jun 25, 2004 5:22 am

BlackAura wrote:I'm still not sure if we should use the MAME sound emulation code, or the Gens sound emulation code. I've not tried to benchmark them or anything, but as far as I can tell there's very little difference in speed (certainly too small to tell either way).

I'm not sure exactly what kind of FM chip is present in the Mega Drive. FreeSCI uses fmopl.c from MAME for YM3812 emulation. I found that fmopl 0.37a is twice as fast as later versions, but sounds inferior.

It should also be noted that:

The original author of the 0.37a version has given permission for release under LGPL and hence GPL license.

The new author that did the later versions has not given that permission. As the MAME license is not GPL compatible, any versions of fmopl.c later than 0.37a should not be used in GPL'd software. (We made that mistake in the FreeSCI project.)