0 users browsing Emulation. | 1 guest | 1 bot  
Main » Emulation » Sneeze9x
Pages: 1
Posted on 19-01-05, 22:07

Post: #16 of 32
Since: 10-29-18

Last post: 19 hours
Last view: 19 hours
So it finally happened:
https://www.smwcentral.net/?p=viewthread&t=96128

For the looks of it, it's even better than bzsnes, now we just need some SD2SNES firmware update for this stuff and then screw you ZSNES!
Posted on 19-01-06, 08:13

Post: #13 of 18
Since: 10-30-18

Last post: 220 days
Last view: 12 days
Posted by NTI
now we just need some SD2SNES firmware update for this stuff
I would prefer ikari not implement any features to "fix" broken hacks.

Why don't people focus their efforts on fixing the hacks themselves instead of continuing to release broken emulators?
Posted on 19-01-06, 08:21

Post: #28 of 100
Since: 10-30-18

Last post: 91 days
Last view: 12 days
Some hacks are too obscure to find and fix. Like, personally distributed to three or four people obscure.
Posted on 19-01-06, 08:55 (revision 2)

Post: #43 of 160
Since: 10-29-18

Last post: 12 days
Last view: 12 days
I mean yeah, ideally, every hacks should have been tested to work on hardware but back in the old (ZSNES) days it was not uncommon stuff would only be tested on ZSNES and the chance of some of the older hacks (some of which were actually pretty decent) being fixed are slim to none. So as long as everything is optional and it's made clear this is not how the hardware worked, I think it's fine.

From what I remember "addmusic" (for SMW hacks) was one of the biggest culprit of hacks not working on hardware.
Posted on 19-01-06, 09:14
Custom title here

Post: #184 of 866
Since: 10-30-18

Last post: 1 day
Last view: 6 hours
Posted by Broseph


From what I remember "addmusic" (for SMW hacks) was one of the biggest culprit of hacks not working on hardware.

That and illegal writes to VRAM.

--- In UTF-16, where available. ---
Posted on 19-01-08, 21:50 (revision 1)

Post: #26 of 158
Since: 10-30-18

Last post: 1 day
Last view: 11 hours
So basically it’s a patch for addmusic hacks. Honestly, the world would be better off if most of those hacks went the wayside.

I can fix the SA-1 speed at a slight speed penalty, but Vitor already released an updated SA-1 patch that fixes the problem. We’ve still got the invalid vram and sprite limit flags in the core, but they have to be enabled in the config file.
*edit*
There, the SA1 speed is fixed, so half this patch is unneeded.
Posted on 19-01-09, 00:06
Burned-out Genius Developer
Post: #5 of 48
Since: 10-30-18

Last post: 221 days
Last view: 8 days
> it's even better than bzsnes

Irony is dead.

> I can fix the SA-1 speed at a slight speed penalty
> There, the SA1 speed is fixed, so half this patch is unneeded.

True SA-1 timing is *insane*. Cycle-accurate isn't enough, you have to synchronize every clock tick. And even then I only got things about 90% correct (much better than the 10% we were at before.) Granted, the test cases are extremely unlikely to ever occur in real games.

Still, if you want some fun, try out https://github.com/VitorVilela7/SnesSpeedTest ^-^
Posted on 19-01-09, 02:12 (revision 1)

Post: #27 of 158
Since: 10-30-18

Last post: 1 day
Last view: 11 hours
Posted by byuu
> it's even better than bzsnes

Irony is dead.

> I can fix the SA-1 speed at a slight speed penalty
> There, the SA1 speed is fixed, so half this patch is unneeded.

True SA-1 timing is *insane*. Cycle-accurate isn't enough, you have to synchronize every clock tick. And even then I only got things about 90% correct (much better than the 10% we were at before.) Granted, the test cases are extremely unlikely to ever occur in real games.

Still, if you want some fun, try out https://github.com/VitorVilela7/SnesSpeedTest ^-^

I'm aware of your discussions a couple months back and was already using that :-). By "fixed", I meant it's significantly more accurate than before, which simply ran 5 SA1 opcodes for every S-CPU one, and fixes the Super Mario World SA1 hack that they're talking about. Not going to bother with bus conflict for now, which is the major speed hit.

Also, most of this is just proper cycle counting with several fixes from Vitor's Snes9x branch.
Posted on 19-01-09, 04:32
Post: #7 of 75
Since: 10-31-18

Last post: 47 days
Last view: 9 hours
So is sneeze9x less accurate than snes9x, except the SA-1 timing is more accurate?
Posted on 19-01-09, 11:36

Post: #68 of 210
Since: 10-29-18

Last post: 186 days
Last view: 158 days
Well, not anymore.
Posted on 19-01-09, 16:08 (revision 2)

Post: #28 of 158
Since: 10-30-18

Last post: 1 day
Last view: 11 hours
Posted by jimbo1qaz
So is sneeze9x less accurate than snes9x, except the SA-1 timing is more accurate?

No no no. The timing was more accurate on Snes9x because I adjusted it faster to fix Kirby and SMRPG, but it broke the Super Mario World SA1 hack, so they added an option to regress to the previous speed. The code I just added to git makes it the most accurate it's been.
Posted on 19-01-16, 05:01 (revision 1)
Burned-out Genius Developer
Post: #7 of 48
Since: 10-30-18

Last post: 221 days
Last view: 8 days
> By "fixed", I meant it's significantly more accurate than before, which simply ran 5 SA1 opcodes for every S-CPU one, and fixes the Super Mario World SA1 hack that they're talking about. Not going to bother with bus conflict for now, which is the major speed hit.

That sounds like a major improvement, indeed. Thanks so much for your continued hard work! :D
Pages: 1
Main » Emulation » Sneeze9x
Yes, it's an ad.