nesdev.org

We might be able to adapt my database editor for storing metadata like overclocking limits and such.

I guess if this moves into serious interest, let me know please ^^;

Yeah, interrupts only need to be polled once every four 21.47MHz clock cycles.

Something else I wanted to do that would reduce some bloat: currently we have to do the NMI/IRQ tests before we execute the last work cycle of each instruction. If we instead did this test on every cycle, and kept a latch of the previous value, eg:
foreach_cycle { last = current; current = testInterrupts(); } then we could trigger interrupts based on last instead of curent.
But I haven't been able to make this work because my testInterrupts() has side effects.
Maybe you'd have better luck, though you might not do it as it might be a touch slower ^-^;

In general though, while I do try to keep my code as clean as I can, I've found that often times abstractions that make the code cleaner unfortunately end up also making it slower, esp. since everything in a console tends to be interconnected, heh. Most of the time I tend to favor speed over perfectly isolating the code for each piece of hardware (esp. since I end up with fairly slow code even if I do that :p)

Yep, yep. This is why I've been bugging other emudevs for quite a while now (to no avail :P) to make an accurate SNES emulator.

I've always said you could get about twice the speed of higan without losing any accuracy if you optimized it to its limits. I think you have more headroom in Mesen-S to get more than 200%, but then there's also a few corner cases you're skipping because they're quite frankly ridiculously costly. But on the whole, my original estimate seems to be mostly holding up.

I don't want higan to be the fastest accurate emulator, I want it to be the reference implementation people use to validate the hardware. With higan, I want to preserve the machine more than play games. I am not in any way saying one is more important than the other (if anything, a gaming emulator is way more useful), it's just the kind of emulator I wanted to make is all.

I revived bsnes to try and fill the large gap between higan and Snes9X, because I'd pretty much given up on another serious SNES emulator attempt. I was planning to speed up the accuracy portion inside bsnes, but I think that effort might be a bit redundant now ^-^

RE: overclocking DB, I'll let you know - will probably be a while before AxlRocks plays enough games to get a better idea of what works and whatnot, too.

byuu wrote:If we instead did this test on every cycle, and kept a latch of the previous value, eg:
foreach_cycle { last = current; current = testInterrupts(); } then we could trigger interrupts based on last instead of curent.

This is actually what I'm doing at the moment - the IRQ test runs every 4 cycles and sets the IRQ signal when needed. Then before each CPU cycle, I check the IRQ signal's value, store it, and then check if we need to jump to the IRQ handler when the instruction ends. It's this way mostly because that's also how I implemented it on the NES, too. I had actually been considering the opposite (e.g having code that runs before the last cycle in each instruction), but didn't really get any further than just thinking about it :p

I revived bsnes to try and fill the large gap between higan and Snes9X, because I'd pretty much given up on another serious SNES emulator attempt.

I guess I decided to write this just a bit too late huh? Haha.

But yea, I'm hoping to be able to squeeze more performance out of it all eventually, though for now I'm mostly focusing on implementing the missing stuff (that being said, I do profile every time I change/add anytime major to try and optimize a bit - my efforts are usually rewarded with the exact same FPS no matter how many different ways I write the code)

It's this way mostly because that's also how I implemented it on the NES, too.

Yeah, it pretty much is how the hardware works (well, the four-clock test thing is just the effective result anyway, but the two-stage pipeline is definitely a real thing.) Disappointing thing is the NES/PC Engine (HuC6280) CPUs could definitely do that last work cycle test on every cycle, since their tests don't have obvious side effects like the SNES version does.

I guess I decided to write this just a bit too late huh? Haha.

Yeah, I wouldn't have made bsnes if Mesen-S were already a thing. It was already ~10 months into development with two releases out before I found out about your project (when you announced it here.) I was worried people would accuse bsnes of being a response to it anyway.

That said, I've been very pleasantly surprised by how well bsnes has gone, and the cool features that have popped up like HD mode 7 and widescreen from DerKoun. Long overdue or not, I definitely think getting the SNES emulation rock solid before making a fork like that was the right move.

So I guess at this point, bsnes will be the gap closer between Mesen-S and Snes9X ^-^;
It's not like any of us are getting paid for this, so more choices are always a good thing.

But yea, I'm hoping to be able to squeeze more performance out of it all eventually

If Mesen-S didn't come about, I would have tried to do the same for the accuracy mode of bsnes.

As it stands, I'd like to invest as much resources as possible into speeding up the faster side of bsnes, but it's proving to be a really difficult struggle here. The pain comes from the IRQ edge cases. I have a third SNES emulator (really >_>), and with range-tested IRQs and priority queues, and an opcode-based CPU core, I can match Snes9X's performance (for non-SA1/SFX games at least), but it absolutely does not pass my test_nmi/irq ROMs. The question is, is it possible to make what we do faster without losing accuracy?

Frame rates right now for me are:
higan -> 120fps
Mesen-S -> 240fps [less accurate coprocessors]
bsnes -> 390fps (500fps with frameskip fast forward) [less accurate PPU+coprocessors]
Snes9X -> 800fps (1200fps with frameskip fast forward) [less accurate CPU+PPU+coprocessors]

People keep finding new, innovative ways to make SNES emulation more demanding:
* using rock-bottom hardware like $5 Raspberry Pi Zeroes
* implementing run-ahead to multiply the system requirements by the run-ahead amount (+3 frames = 300% more demanding)
* overclocking all the CPUs by 1000% to reduce slowdown
* wanting to run really demanding software filters like snes_ntsc (shaders are at least mostly free)
* wanting to upscale mode 7 to 3840x2160 widescreen
* wanting GL fencing / flushing per-frame
* and of course, us wanting things emulated more accurately
I hear there's one guy who's even considering hires texture replacement packs for SNES tiles! :p

Sorry for derailing your thread again, exciting times though! I'm happy you're here ^-^

byuu wrote:I hear there's one guy who's even considering hires texture replacement packs for SNES tiles! :p

To be honest, I'm still not convinced there's much point to it - the SNES has much less restrictions than the NES to start off, giving it more colors isn't that useful, and increasing the resolution tends to make the animations look choppy. HD Packs on the NES are not really that bad though, 95% of the processing is done in another thread, so it doesn't have too much impact on performance in general.

In other news, I just finished adding CX4 support (and I added S-DD1 support a few days ago, too). CX4 took me a while longer than I had hoped, didn't help that none of the emulators appear to be able to produce trace logs for it (this was also the case with the DSP), but it's finally done. Still seems to have a bit of a timing issue because the MMX2 demo sequence desyncs in the middle of the fight (slowing down by the CX4 by about 5-10% fixes it) - not quite sure if the issue is the CX4 or something else, though. The stuff in ikari_01's thread should mostly be implemented properly, but I must be missing something somewhere.

With this, there's basically only 3 chips left (OBC-1, SPC7110 and ST018). There's also about 3 SA-1 games that don't work right yet because I still have some features to implement. And then another 2 regular games freeze at boot. So roughly 10 games left that still aren't playable. (excluding stuff like BSX and the like)

OBC1 will take you like five minutes. It's the dumbest chip in the world. Metal Combat however is a pretty fun game.

Wow, you weren't kidding, that chip is simpler than most of Nintendo's NES mappers :p
I was going to wait a bit until I added the OBC1 and SPC7110, but now that there's only the SPC7110 left, I might try and get the SPC7110 done so that I can be (mostly) done with enhancement chips for a while and focus on other things.

Also fixed a CX4 bug that caused issues that I hadn't noticed in MMX2/3.

ansarya wrote:I have found an issue where the "CPU Debugger" window is showing the incorrect state due to some stack fiddling by Dragon Quest 3.

This should be fixed now, thanks!

Shogi can wait until after Meabg, and Meabg can in turn wait until after Meecp.

Sour wrote:

byuu wrote:I hear there's one guy who's even considering hires texture replacement packs for SNES tiles! :p

To be honest, I'm still not convinced there's much point to it - the SNES has much less restrictions than the NES to start off, giving it more colors isn't that useful, and increasing the resolution tends to make the animations look choppy. HD Packs on the NES are not really that bad though, 95% of the processing is done in another thread, so it doesn't have too much impact on performance in general.

I too think making SNES HD pack by hand requires too much effort for too little improvement. What I want to see is AI upscale (eg ESRGAN, Waifu2x) but those can't be done in real time yet.

Just recently decided to finally try Mesen and Mesen-S and to my surprise those 2 emulators are pretty advanced, packed with plenty of features and compatibility and has a pretty nice GUI to boot, awesome.

Mesen is probably the best or 2nd best NES emulator at the moment and I've tried dozens (puNES is Mesen's competition IMHO when it comes to features and compatibility) and Mesen-S is shaping up to be the best SNES emulator around. Currently I consider Snes9X to be the best SNES emulator and Bsnes is in 2nd place but goddamn, Mesen-S is pretty new and is already in 3rd place IMHO. At this rate Mesen-S will become my default SNES emulator because it has (or will have) all the good features the other emulators have but it also has a pretty good GUI that I'm loving so far and the rewind functionality of Mesen and Mesen-S are pretty good as well.

I only have 2 minor issues with Mesen-S:

1 - It doesn't have the option to clear the recent games (Mesen has the option though).
2 - it doesn't have the option to disable the "Game Selection Screen" (Mesen also has this option).

Hopefully you can implement those options, they should be pretty easy to implement for people of your caliber.

Also, I wonder why emulator authors doesn't implement the save state/load state feature that Snes9X for Mac/OSX has? in my opinion no emulator has EVER come close to it. Just look at how pretty it looks:

xZabuzax wrote:Mesen-S is pretty new and is already in 3rd place IMHO

Sweet, 3rd place out of 4! :p Joking aside, thank you!

RE: the missing functionalities vs Mesen - I've been trying to cut down on the number of options a bit (especially those that do not really "add" anything beyond allowing more customization). This was mostly to both save time while coding Mesen-S and also keep code complexity down when I can (all those little options pile up!)

That said, I am keeping track of missing features from Mesen that people request, since that is a good indicator that they are actually used (if only I had usage statistics for this kind of stuff...) So the simple stuff that has low impact (e.g like these) I will probably add once I get a chance (there are a lot of features missing all around, still)

RE: The Snes9x save state screen, I've actually never seen that before. Though it looks somewhat similar to PPSSPP's save state system (or at least, what I remember from using it like 2+ years ago.) It's also essentially the same as Mesen's game selection screen, except for save states (and it shows multiple states instead of just one).

As for why that kind of thing is rare, I would guess that the answer is simply because while it's pretty and possibly useful to some users, it can take a lot of time to code something like this (and increases code complexity, maintenance, etc.). This is especially true when the feature doesn't really add anything beyond potentially a cleaner interface. In cases like these, users will still expect keyboard shortcuts and menus for save states, on top of this additional feature, so it increases the amount of code required for save states, without really allowing anything that wasn't already possible, either.

Sour wrote:Sweet, 3rd place out of 4! :p Joking aside, thank you!

More like 7 or 8, there's more Snes emulators like SnesGT, no$sns, Zsnes, sneese, and other's that I can't remember so for Mesen-S coming out of nowhere and already surpassing most of them that had years of development is already a big achievement. This will definitely become the best SNES emulator once the missing features and compatibility is added and I can't wait to have this one as my default SNES emulator.

Sour wrote: RE: the missing functionalities vs Mesen - I've been trying to cut down on the number of options a bit (especially those that do not really "add" anything beyond allowing more customization). This was mostly to both save time while coding Mesen-S and also keep code complexity down when I can (all those little options pile up!)

That said, I am keeping track of missing features from Mesen that people request, since that is a good indicator that they are actually used (if only I had usage statistics for this kind of stuff...) So the simple stuff that has low impact (e.g like these) I will probably add once I get a chance (there are a lot of features missing all around, still)

I totally understand mate, those little features makes an emulator more "complete" but I'm not in a hurry, keep coding at your own pace, hopefully you can add those later.

Sour wrote: RE: The Snes9x save state screen, I've actually never seen that before. Though it looks somewhat similar to PPSSPP's save state system (or at least, what I remember from using it like 2+ years ago.) It's also essentially the same as Mesen's game selection screen, except for save states (and it shows multiple states instead of just one).

I was a Mac user in the 90s and early 2000, I used Snes9X a lot and the save sate/load state feature of that emulator was so damn good, I still miss it in this day. The only emulator that had something similar is indeed PPSSPP but IMHO the one from Snes9X is better and it allows for more slots to save the game. The one from Mesen and Mesen-S is a bit similar but it only works when you quit the emulator, I rather use that feature with a simple hotkey like the Mac/Os X version of Snes9X had.

Sour wrote: As for why that kind of thing is rare, I would guess that the answer is simply because while it's pretty and possibly useful to some users, it can take a lot of time to code something like this (and increases code complexity, maintenance, etc.). This is especially true when the feature doesn't really add anything beyond potentially a cleaner interface. In cases like these, users will still expect keyboard shortcuts and menus for save states, on top of this additional feature, so it increases the amount of code required for save states, without really allowing anything that wasn't already possible, either.

I totally understand that but then again, the Mac/Os X version of Snes9X had no trouble maintaining that feature, I haven't used a Mac in decades but I remember that Snes9X had that awesome save state/load state feature in the 90s and it still has it today, so if the Mac version of Snes9X can maintain this awesome feature for decades then I see no reason why this can't be maintained in Windows as well.

Edit:

Now that I think about it, since you have something similar with Mesen or Mesen-S game selection on startup you can take the extra mile and allow 2 hotkeys to open that same window, the hotkeys will be the "Save Window" and "Load Window" and you just need to allow more "slots" in it and it will be pretty similar to Snes9X, the only difference is that your approach only has 1 slot at the moment but you can easily reduce the picture to add more slots in it. So basically, the implementation of this feature is basically done in your emulators as well, you just need to take that extra mile to make that approach prettier and drop a couple of lines of codes here and there for the hotkeys and the extra slots but the feature is basically there.

Hopefully you can take your time to think about this.

Honestly, Mesen's game selection feature would be more useful if you could display more games/screenshots simultanously like in that example.

Not that I'd use it myself, I exclusively use emulators for testing/development, and tend to just double-click the rom file, rather than going through the program's UI first. But if you were to use it, easily spotting and recognizing a screenshot is way more effecient than flipping through a bunch of them until you find what you need.

The idea with a screenshot overview for save slots is super nice, but barely useful unless you're for some reason keeping multiple threads of a game going, and want to be able to quickly tell them apart. I don't think a lot of people have any use for that, outside of maybe speedrunners who keep a ton of states ready for immediately practicing any individual segment of a game.
Personally I didn't add savestates to my own emulator at all, because my immediate goal was replicating an actual NES, and I don't personally think savestates add any value.

Small Debugger display error:

When showing "unknown" areas of code as code (see the background is red) I noticed that "ADC #xxxx" is correctly using up 3 bytes, but it doesn't display the high byte.

In this example it is displaying "ADC #75"



bytes at $C06905 ---- 18 69 75 38 85 14

See that the 38 is missing, should be ADC #3875.

This displays fine when the debugger has run that code before and has marked that area as "code" instead of "unknown".

I am using the Mesen-S 2.0 release.

Yeah there's sadly no guaranteed way to detect what the M/X flags will be before executing the instruction.

You can keep building up heuristics to increase the chances of good disassembly, eg tracking rep/sep instructions, treating code immediately after PLP and RTI/RTS/RTL as suspect, and during unknown M/X states, try to apply heuristics (eg BRK and SBC $aaaaaa,x are quite unlikely instructions to appear, so it's more likely adc #$0000) ...

But a particularly evil coder could make one routine that executes differently based on the M/X flags, and make the program dependent on all of the variants. So there's no such thing as perfection.

Yeah, I understand that you can't tell until it's run (and as you said, not necessarily even then) although I'm super glad it's trying as it's super useful. DQ3 loves to fiddle with the stack all the time, especially to store data for a routine directly after the JSL that calls it and then change the return address, for instance (which is why my wish-list text file includes "Declare a range of 'unknown' to be data or code").

But in this instance it is using up 3 bytes of the code (pc goes from c06906 to c06909) but only displaying the 2 byte version and the $38 is thrown away. It is interpreting the instruction one way and displaying it another. Not a big issue, but then I've got to go look up the bytes in the hex editor.

One another note, should I be using the Development Build version instead of the 2.0 release? I use the Mesen-S debugging tools every day so I think I should be testing the latest and I don't care about the slowdown in the dev builds since I spend most of my time paused anyways.