Beta Snes9X4D4P - Another New Build, Now With Hi Res And New Rom Picker


chaosmage said:
EvilDragon said:
Until HF4 is released, do NOT clock exactly to 650 Mhz. Due to some small error in the algorithm, setting CPU Speed to 650 sets it to -1 MHz (whatever the OMAP does then... but it's slow).

So use 651 or 649 or something completely different - but not 650 :D

Yeek. I assume that the slider doesn't change the actual speed until you click on OK, right? Otherwise this is bad mojo...

Only when you press OK. Before that, no speed change happens.

Are there any other speeds we should avoid because of a similar issue?

Not that I know of - but if you overclock and your Pandora becomes really slow, you found one ;)

Don't worry though, a reboot changes your speed back to normal and Hotfix 4 Beta should be available until next week :)
 
Last edited:
skeezix said:
MDave said:
PLEASE get sound interpolation in! Some games sound absolutely dreadful without it :(

Any examples? I'm not not emu level coding per se, just doing the port of SiENcE's port of snes9x, so post and hopefulyl he'll be about and take a look.

My hands are full enough that getting into snes9x actual emu coding is too much I'm afraid.

jeff

Axelay sounds pretty dire on the Konami intro sound. I think the rest of the music sounded quite rough from what I remember.
 
Last edited by a moderator:
How long ago did you try? The very first builds I posted were using some really low khz rate; I think now it uses 32khz or 48khz, so shoudl sound pretty good (ie: assuming the emulated sound quality is good in the first place.)

jeff

Hmm, xelay does sound like hell; is it supposed to be like that? ;)
 
jb0yx said:
also zsnes has filters that can be applied such as 2xsai and super 2xsai, super eagle etc.... is there any possible way these can find their way into this emu? it makes games look a little smoother when stretched all to hell like that.
2xsai and Eagle are actually really bad algorithms. They anti-alias by blending the colour of all the pixels around it, which results in a very blurred image, especially noticeable across sharp lines. That's why I recommended hq2x: it only tries to blend across low contrast colours, resulting in a smooth image without sacrificing sharp edges and outlines.
Of course, if Jeff has time, there's no reason not to add 2xSai and Eagle. The more the merrier. But if he's under constraints and only enough time to get one in, I think you'll find hq2x is better. :)
Or maybe you won't, no accounting for taste :p
 
Last edited by a moderator:
skeezix said:
MDave said:
PLEASE get sound interpolation in! Some games sound absolutely dreadful without it :(

Any examples? I'm not not emu level coding per se, just doing the port of SiENcE's port of snes9x, so post and hopefulyl he'll be about and take a look.

My hands are full enough that getting into snes9x actual emu coding is too much I'm afraid.

jeff

Ahh code examples, or examples from games where you hear the sound being off? :p I'll answer both as much as I can!

Code example wise, the original snes9x source code is worth a look. I was just browsing in soundux.cpp and in the "void MixStereo (int sample_count)" function you'll come across something related to sound interpolation in there. I suspect SiENcE's port of snes9x might have it too, but its not turned on by default maybe? Need to check the source to find out ;)

Games to check out, would be the buzzing sound you hear in the Donkey Kong Country 2 logo intro and the Bee levels. Start a new save file, press down about 5~7 times on the 1/2 player select screen to get the music test ;)

Also, Legend of Zelda: A Link to the Past. When you wait at the title screen then get the prologue of the story, you can hear the music in the background is a bit rough sounding too.
 
Last edited by a moderator:
Just a little comment on the sound interpolation thing: The SNES had 32KHz audio, as we know, and gaussian interpolation should be in there as well (if memory serves, this is what the SNES itself did, or close enough to it). :p
 
skeezix said:
How long ago did you try? The very first builds I posted were using some really low khz rate; I think now it uses 32khz or 48khz, so shoudl sound pretty good (ie: assuming the emulated sound quality is good in the first place.)

jeff

Hmm, xelay does sound like hell; is it supposed to be like that? ;)

Just downloaded the version you posted on the first page. That seems better - something definately sounded out of phase or wrong somehow before (not sure it's perfect, but it is better). You can take a quick listen on youtube to make a comparison. Axely had some really nice music (expecially the underwater cavern level). The intro with the invasion does sound kinda intentionally nasty anyway.
Oh, and thanks for your work BTW! :)
 
Last edited by a moderator:
WizardStan said:
2xsai and Eagle are actually really bad algorithms. They anti-alias by blending the colour of all the pixels around it, which results in a very blurred image, especially noticeable across sharp lines. That's why I recommended hq2x: it only tries to blend across low contrast colours, resulting in a smooth image without sacrificing sharp edges and outlines.
Of course, if Jeff has time, there's no reason not to add 2xSai and Eagle. The more the merrier. But if he's under constraints and only enough time to get one in, I think you'll find hq2x is better. :)
Or maybe you won't, no accounting for taste :p
opps didn't realize that's what you guys were talking about, I admit my comment was the result of just wanting something and skimming this thread. Glad it's a point of interest to others as well.

I've had random success with each filter, some more cartoonish games look better blended IMO, and some depending on how stretched they are from the original I'll choose a different filter, but like you said, it's just a matter of taste.
 
Last edited by a moderator:
EvilDragon said:
Until HF4 is released, do NOT clock exactly to 650 Mhz. Due to some small error in the algorithm, setting CPU Speed to 650 sets it to -1 MHz (whatever the OMAP does then... but it's slow).

So use 651 or 649 or something completely different - but not 650 :D
Seriously, how do bugs like these happen? What algorithm results in a -1 at a specific number, but exactly the number given anywhere else?
 
Last edited by a moderator:
its not the exact number everywhere else. there are at least 2 numbers in the 800's that do that slow 1 mhz thing, from my experience.
 
Fantastic work, cheers Jeff :D

So save states (snapshot saves) are not yet implemented? Not at home so cant test yet...
 
skeezix said:
How long ago did you try? The very first builds I posted were using some really low khz rate; I think now it uses 32khz or 48khz, so shoudl sound pretty good (ie: assuming the emulated sound quality is good in the first place.)

jeff

Hmm, xelay does sound like hell; is it supposed to be like that? ;)
It is probably in the dingoo port that way. PocketSNES sounded better and was more optimised (would be good as there would be headroom for scalers without having to burn your CPU out at 800 MHz, the sound quality goes way down if using 3:2 mode) but it looks like you decided to just continue the dingoo port. Not sure what can be done about the dodgy sound in that.

For scale modes one mode that would be good to have is a straight 2X vertical (there is not enough unused space vertical that makes it worth the ugliness) but then do a smoothed scale horizontal to the correct aspect. That looks most TV like as TVs tended to be sharp vertical but smooth horizontal. Me I would probably still use just straight 2X but not sure without seing it.
 
Last edited by a moderator:
DaveC said:
Not sure what can be done about the dodgy sound in that.
Don't worry: What has already been posted in this thread. ;) (Hint: Gaussian interpolation.)
 
Last edited by a moderator:
Prometheus said:
DaveC said:
Not sure what can be done about the dodgy sound in that.
Don't worry: What has already been posted in this thread. ;) (Hint: Gaussian interpolation.)
Not really. The sound emulation itself is an issue. It is probably cutting some corners to get it to run playable speed. If the Pandora needs overclock to run well I can only imagine the steps needed to make it playable on a dingoo. All interpolation does is make the sound more muffled. The SNES had very little memory. So sound samples were sampled at a low rate. This low rate caused aliasing in the sound. They then just stuck a low pass filter (hardware?) over it to filter out the aliasing. Like any filter there is a tradeoff. You get rid of the aliasing but then the sound is muffled as you loose all of the highs. Some refer to this muffling as "warm" as all of the treble is cut.
 
Last edited by a moderator:
Wolenber said:
Seriously, how do bugs like these happen? What algorithm results in a -1 at a specific number, but exactly the number given anywhere else?
ED's explanation is not 100% complete, because this thing is complex. Yeah it was a bug in the DPLL rate rounding algo (it chose something the hardware isnt able to cope with), they also improved our clock setting systems interpretation of the DPLL register value. See http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=summary for the exact stuff.
 
Last edited by a moderator:
It's better that it defaults to a negative (with the hardware interpreting this as instruction to switch it to 1, I assume) then to have it automatically set to 32767 (the extreme end of a stored integer)... *shudder*. I don't care what you say about overclocking being safe, that's just a scary thought.
 
EvilDragon said:
Until HF4 is released, do NOT clock exactly to 650 Mhz. Due to some small error in the algorithm, setting CPU Speed to 650 sets it to -1 MHz (whatever the OMAP does then... but it's slow).

So use 651 or 649 or something completely different - but not 650 :D

Any word on a date for Hotfix 4? Will it include the fix to enable tethering to a mobile phone to work?
 
Last edited by a moderator:
mrdremel said:
Will it include the fix to enable tethering to a mobile phone to work?
The bluetooth fix? It's in git already (why people never just take a look there, dunno...), so I guess it will make it's way into HF4. (I've had it for like ... two weeks (not sure)... (of course partially to test that the fix actually works) nearly forgotten that you all still have that bug.)
 
Last edited by a moderator:
mrdremel said:
EvilDragon said:
Until HF4 is released, do NOT clock exactly to 650 Mhz. Due to some small error in the algorithm, setting CPU Speed to 650 sets it to -1 MHz (whatever the OMAP does then... but it's slow).

So use 651 or 649 or something completely different - but not 650 :D

Any word on a date for Hotfix 4? Will it include the fix to enable tethering to a mobile phone to work?


Hey! stop hijacking the thread!
 
Last edited by a moderator:
Back
Top