I'm more than satisfied with the emulator. Quick ROM changing should be one of the first few feature additions.
> Basically, this succeeds up until a point - it errors out at a specific point (at the SDSP part - it complains about sDSP being undeclared.
There are typos in your sDSP rule, and you don't want to build aDSP. That's a separate, faster, less accurate DSP core.
v060 was before libsnes, so it's not entirely possible to build a GUIless core. You are going to need to implement an SNES interface class to handle callbacks (to render frames, output audio samples, etc.)
> Do you suppose we'll be running into the same (input generation) problems with bSNES?
Yes, all emulators have this problem. You either drop the occasional video frame or you have to balance the input frequency against the video refresh rate.
> This never seemed to be much of a problem with zSNES and SNES9x in the late '90s and on - I take it that was because of accuracy not being much of an issue.
As mentioned, they used a really evil trick. They ran two DSP cores at the same time. When the sound buffer was low, they ran the virtual DSP to fill the buffer. This really, really distorted sound and desynced the chips. Very inaccurate, caused all kinds of problems. ZSNES still does it, listen to how it plays Earthworm Jim 2 sound effects. That's what that approach gets you.
> Just to add to this - I also tried to exclude ruby from PPU_SRC since that is also platform-dependent - didn't change anything.
You wouldn't use ruby at all. That is Windows/OS X/Linux video/audio/input drivers. You will have to make your own drivers that tie into the PS3 SDK for that. Which you already did with Snes9X
> That said, is anything happening with the bsnes port? Last I heard Byuu was making some stuff easier to port for v069.
I am working on adding save states to my new v068.10 PPU renderer, which is a bit faster. After that, I'll release v069, hopefully this weekend or so. Someone on my forum offered to try porting it back to C++98, so we'll see how that goes.
Snes9x provides a pretty extensive Porting document that goes into most of these callbacks that the porter needs to implement. Is there something similar available for bSNES?
In case we want to be able to run these translated games - at which specific point did they go from 2 DSP cores to 1? If SNES9x 1.51 still has it, perhaps it might be an idea to backport that as well and have all these emulators basically as selectable engines that you can select.
On that same topic, how do you feel about bSNES and SNES9x perhaps ending up in one single binary? Are there differences in licenses (SNES9x, bSNES), do you strongly object to this?
I will look at bSNES v0.60 again later today/tomorrow.
That said, it would be great if that person on your board could make the v069 source C++98-compatible - I would really like to see the latest version of bSNES too personally.
Last edited by squarepusher2; 09-24-2010 at 02:42 AM Reason: Automerged Doublepost
> Snes9x provides a pretty extensive Porting document that goes into most of these callbacks that the porter needs to implement. Is there something similar available for bSNES?
For libsnes, yes. http://gitorious.org/python-snes/python-snes/blobs/master/snes/core.py
That is basically the documentation AND a Python wrapper at the same time, so just read the comments on each function and ignore the Python-specific stuff.
But it's really super simple, again only 10-12 functions or so total.
snes_init(); to start things off
snes_set_video_refresh/audio_sample/input_poll(); for your C callbacks like 9X
snes_load_cartridge_normal(); to give it the raw binary data (read in a file, pass it on)
snes_power() or snes_reset(); to simulate those events
snes_run(); to emulate one full frame and return, will invoke callbacks as data is ready
snes_get_memory_data(); lets you grab RAM handles to load and save SRAM to disk
snes_serialize() to save a state, unserialize() to load a state
snes_set_controller_port_device() if you add Mouse/Justifier/Scope support
And that's every function in a nutshell
> Yeah, I was aware of that and had figured that out on my own.
Ah, sorry about that then.
> That said, it would be great if that person on your board could make the v069 source C++98-compatible - I would really like to see the latest version of bSNES too personally.
Yeah, it's about 70% faster and much easier to code for.
> On that same topic, how do you feel about bSNES and SNES9x perhaps ending up in one single binary? Are there differences in licenses (SNES9x, bSNES), do you strongly object to this?
I don't mind at all if you bundle 9X with bsnes. I come off a bit negative, I apologize, Snes9X really is a nice emulator for how few resources it uses, and I help out with it as well.
The licenses aren't compatible as Snes9X is non-commercial only, but as they are separate programs, it should not be an issue. I'm certain nobody will mind, and the only people who COULD complain would be me and the 9X team. So don't worry about it.
> at which specific point did they go from 2 DSP cores to 1?
v1.51 is the last old core version. If you're going to make one for broken software to run (I jokingly call that a ZSNES emulator), look for the blockinvalidvramaccess flag and set that to false, but ONLY for the v1.51 hack core, because it will break commercial games like Hook if it's not emulated properly.
Pretty excited for this to grow! One of the main reason's I did the jailbreak on my ps3!
I was using an older build of SNES9x on my ps3 and was annoyed by the fast forward type sound and all the cracks and pops in the sound.
I upgraded today to the latest release and now my sound is perfect but the game now runs slow. As in lower fps than before.
Thanks for everyone's hard work on this project.
BTW, all of the PAL problems are due to the way the libgcm graphics routines have been implemented by eisz (you will also notice that in Seiken Densetsu 2/3, whenever it needs to switch between 256x224 mode (normal in-game resolution) and 512x448 (the SNES' hi-res mode - used in menus and whenever text is displayed), that the new screen (512x448) will be overlaid on top of the older screen, but will be about half of the height.
Eisz might want to revisit that entirely or else go with PSGL.
Can't edit my post more than three times - but in any case, to the guy who said he gets lower fps than before - with NTSC ROMs you get 60fps on everything - if you want to test this for yourself, edit cell.cpp and look for the line that says 'Settings.SoundInputRate ='
add the following line:
Settings.DisplayFrameRate = TRUE
and then recompile and repackage. You should see that nearly every game stays locked at 60fps - this is SNES9x's internal fps display function.
As a followup to this: the resolution handling/switching should be handled in our implementation of S9xDeinitupdate (it's inside cell.cpp).
S9xDeinitupdate is a callback that is called 'once a complete SNES screen has been rendered into the GFX.Screen memory buffer.
SNES has the following resolutions:
256 x 224 (NTSC)
256 x 239 (PAL)
512 x 224 (NTSC)
512 x 239 (PAL)
512 x 448 (NTSC)
512 x 478 (PAL)
Followup no. #2 - looking at Porting.html again, looks like SNES9x calls S9xContinueUpdate when it renders a 512x448/512x478 screen (such as is the case with Secret of Mana/Seiken Densetsu 3 at specific locations). So, going by that assumption, S9xDeinitUpdate is intended for low-res resolutions (256x224/256x239) and S9xContinueUpdate is meant for the high-res resolutions (512x224/512x239/512x448/512x478).
Last edited by squarepusher2; 09-24-2010 at 03:47 PM Reason: Automerged Doublepost