New SMS Plus Beta

Should I put a PAR version with cdunlock function in each release ? Also can I keep the cdunlock function on CD version ? I've never tried with the swap trick if the emu will start anyway.
 
I've already downloaded it, but can't test it on a real Saturn yet, I'm sort of "on vacation". Instead, I'm working hard on Police Officer Smith, my C4-2007 entry. In the new year, there is time to play smsplus.

vbt said:
Should I put a PAR version with cdunlock function in each release ? Also can I keep the cdunlock function on CD version ? I've never tried with the swap trick if the emu will start anyway.

No, don't make a cdunlock in general. Swap-trickers would wonder, why it's not working and get annoyed. I once had such a binary and it was hard to perform a second swap trick. You could surely do it on button press or somehow detect, that the game is running from cart.
 
Try reading from 0x2600c00 to 0x26002000. From what I know, you can probably parse it and check if the Saturn has an AR connected.

I guess another way is to check if 0x5a or 0x5c is present when reading from 0x24ffffff.

These are just guesses, though.
 
SMS Plus Saturn is coming back soon.

I've applied a little change to call the slave cpu on sound update, it saves around 2 fps when vsynch is disabled. I'm trying to find some way to improve sound rendering.
 
vbt said:
SMS Plus Saturn is coming back soon.

I've applied a little change to call the slave cpu on sound update, it saves around 2 fps when vsynch is disabled. I'm trying to find some way to improve sound rendering.

How do you handle the sound now?

My suggestion would be the following:

Save all PSG port writes on the SH2 side, and send them to the SCSP (through SCU) once per frame, or maybe a couple of times per frame. Games aren't likely to run their music engine more often than that. Run your PSG emulation code on the M68k, which renders data at some suitable rate (maybe 22.5 kHz). Since the SCSP has plenty of slots you could use one slot per PSG channel to avoid having to do any software mixing. Or even two slots per channel to get double buffering.
 
mic said:
How do you handle the sound now?

Same as before, still common emulation, just sending PSG_Update & PCM_Task to second CPU.

My suggestion would be the following:

Save all PSG port writes on the SH2 side, and send them to the SCSP (through SCU) once per frame, or maybe a couple of times per frame. Games aren't likely to run their music engine more often than that. Run your PSG emulation code on the M68k, which renders data at some suitable rate (maybe 22.5 kHz). Since the SCSP has plenty of slots you could use one slot per PSG channel to avoid having to do any software mixing. Or even two slots per channel to get double buffering.

I'd like to do that but I'm not able to.
 
vbt said:
I'd like to do that but I'm not able to.

Well, I might be able to help with that. If I find the time maybe I can put together a proof-of-concept of this PSG emulation idea.
 
mic said:
Well, I might be able to help with that. If I find the time maybe I can put together a proof-of-concept of this PSG emulation idea.

That would be great!
rockin.gif
I also use it on Green Beret/Mr Goemon emulation.
 
vbt said:
could it be a good thing if I merged sms plus saturn with final burn alpha ?

That would depend... would it make it easier to maintain? Would it increase the difficulty in debugging? Would it make it harder to add more features?
 
Chilly Willy said:
That would depend... would it make it easier to maintain? Would it increase the difficulty in debugging? Would it make it harder to add more features?

it's just i've updated smsplus and now they share the same(99%) saturn.c so i would have only one project to update.
 
vbt said:
it's just i've updated smsplus and now they share the same(99%) saturn.c so i would have only one project to update.

Well, then it sounds like it WOULD be better to combine them.
smile.gif


Being both emulators, it would seem like they would use most all the same things... same kind of interface to select a game, same options for display, sound, and input, yada, yada, yada. The main differences would be in the actual emulation code, which would be in separate files.
 
Back
Top