Mesen-S - SNES Emulator

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Tue May 26, 2020 4:58 pm

I've taken a look at all the issues (except Kishin and Battle Grand Prix - those are timing issues I know about):

-Lemmings is caused by an out-of-bounds vram access. The PPU options in lemmings make it load an address > $7FFF, which ended up loading outside the vram buffer. This used to work properly, but I switched from an array of bytes to an array of shorts at one point to simplify the code a bit (and give a small speed increase), which made it so the mirroring did not work properly anymore. This is fixed now.

-Brutal - Paws of Fury had issues with the shadows because it turns on the "interlace" flag for sprites for them, and the logic I was using to process those was apparently broken - this is fixed too.

-Elfaria II, Big Sky Trooper and Ashita no Joe all appears to be the same problem: RAM initialization. I think you've probably set Mesen-S to initialize RAM to 0s instead of the default random values? This causes the saved games that should not exist in elfaria & big sky trooper (which is what causes the graphical corruption, too), and it's what causes the intro in ashita no joe to be bugged, too. I'll have to check if these games work properly with ram initialized to e.g $FF and force that as the setting for those games if it works properly.

User avatar
FitzRoy
Posts: 138
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Tue May 26, 2020 10:12 pm

Yeah, woops. I must've changed that setting when I was testing the Death Brade/Power Drive stuff months ago and forgot to change it back. Kind of a dangerous setting I guess.

Seems odd that Ashita no Joe glitches with either 00 or FF and requires randomization to avoid glitches. I don't remember us discovering that with bsnes. The game doesn't have SRAM, either.

User avatar
FitzRoy
Posts: 138
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Wed Jun 03, 2020 1:22 pm

3/4ths of the way done now. I added:

Code: Select all

Mega Man X2 (EUR)....................................................... minor CX4 timing issues cause attract mode to noticeably desync
Mega Man X2 (USA)....................................................... minor CX4 timing issues cause attract mode to noticeably desync
Pachi-Slot Monogatari - PAL Kougyou Special (JPN)....................... crashes emulator.
Rockman X2 (USA)........................................................ minor CX4 timing issues cause attract mode to noticeably desync
Virtual Bart (EUR)...................................................... hangs when bart drops onto Acclaim logo. RAM power on state values change behavior, but all options hang at some point.<br>
There was a thread 4 years ago where ikari_01 figured out the CX4 timings, which were eventually applied to bsnes
http://forums.nesdev.com/viewtopic.php?f=12&t=14647

The Pachi-Slot game has a thread here about how the board is weird and the game doesn't appear to use the SA1 in an expected way. The game works in bsnes115, but fails in higan/byuu
http://forums.nesdev.com/viewtopic.php?f=12&t=17610

I don't have any info on the PAL version of Virtual Bart, and don't remember that game ever hanging in bsnes. Changing the RAM option does affect when the game hangs, but it seems like every option hangs at some point. Also, Bart is supposed to say "ay caramba" when he drops onto the logo, but audio fails to play until the title screen with 0s or 1s. Random just hangs attempting to play that sound.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Wed Jun 03, 2020 5:52 pm

Good to hear there hasn't been too many other issues so far.

For MMX2, I'm aware of the thread, and in theory the timings should match (but clearly don't) - I've tried debugging this in the past with no success. It's still on my list of things to figure out eventually.

Pachi-slot was crashing because it's a SA-1 game with no SRAM - the crash is fixed, and I also implemented IRAM being battery-backed in this case, which makes the load/save feature in the game work properly.

Virtual Bart is definitely weird - could be a SPC timing issue, I'll have to try overclocking/downclocking the SPC to see if it changes anything. The fact the RAM power on state has an impact on this is a bit weird, though. Initializing with $FF at least appears to let the first level load and it seems to work properly. I'll take another look when I get done with the GB/SGB stuff.

creaothceann
Posts: 224
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Mesen-S - SNES Emulator

Post by creaothceann » Thu Jun 04, 2020 7:51 am

A debugging feature that shows when & where an uninitialized memory location is accessed would help here, though probably not trivial to implement...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Thu Jun 04, 2020 1:38 pm

creaothceann wrote:
Thu Jun 04, 2020 7:51 am
A debugging feature that shows when & where an uninitialized memory location is accessed would help here, though probably not trivial to implement...
This actually exists already: in the debugger window -> Options -> Break options -> Break on uninit memory reads
It's currently only available for the S-CPU's (and SA-1) debuggers, though. I wanted to add it for the SPC, too, but the DSP reads a bunch of uninit ram at power on, which made the feature rather annoying to use. I'd have to add some way of making a distinction between SPC reads and DSP reads and have options for both of them.

User avatar
FitzRoy
Posts: 138
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Sat Jun 06, 2020 9:51 am

Sour wrote:
Wed Jun 03, 2020 5:52 pm
For MMX2, I'm aware of the thread, and in theory the timings should match (but clearly don't) - I've tried debugging this in the past with no success. It's still on my list of things to figure out eventually.
Well, maybe it's due to general timings then and not cx4. Super Bonk is another game with an attract mode that serves as an extreme timings test, and that game doesn't have a coprocessor. Bonk is either supposed to go through the pipe or stop right next to it. (note that the EUR and JPN versions of Super Bonk are fine. Somehow just the USA version has this problem)

Btw, do you need me to play through Speedy Gonzales and see if its unique lategame bug exists? I'm not sure what knowledge you have of this.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Sat Jun 06, 2020 8:53 pm

FitzRoy wrote:
Sat Jun 06, 2020 9:51 am
Bonk is either supposed to go through the pipe or stop right next to it.
Ah, did not know that one was causing issues. Supposedly it also sometimes desyncs on hardware, but mesen-s seems to desync every time.

creaothceann tested Speedy Gonzales a while back here: http://forums.nesdev.com/viewtopic.php?p=237147#p237147
That was back in 0.1.0, though, so it's not impossible something broke since, but feel free to skip it if it's annoying to test :p

Near
Founder of higan project
Posts: 1550
Joined: Mon Mar 27, 2006 5:23 pm

Re: Mesen-S - SNES Emulator

Post by Near » Sat Jun 06, 2020 10:37 pm

It's quite easy to make Bonk go through the pipe every time by tweaking the CPU<>SMP ratio, but it's just as hardware-inaccurate to make that happen as it is for him to always get stuck. Making it randomized by choosing a different CPU<>SMP ratio on each game play would break determinism (TAS, movie playbacks, bug reports, etc would become messier.) We could make it an extreme accuracy option to add some randomness to the clock frequencies, but even that doesn't really model what's going on: oscillator frequencies fluctuate with both age and temperature on a live system. And the APU ceramic oscillator has weaker tolerances than the CPU quartz oscillator. At some point you have to give up, and personally, I think Super Bonk is that point.

But I'm still hoping one day that there will be an SNES mod to use a single oscillator to drive both the CPU and APU at close to the nominal frequencies, and then we can base our deterministic emulation off of that.

Magical Drop's tokoton mode is a more interesting edge case. Instead of an inconsequential attract sequence, the game will deadlock or not based on the randomness of DSP registers. In that case, it feels much worth it to offer the option to force it to always work. Whereas cases like Super Bonk would probably never end, and you'd keep getting pushed to "fix" more and more esoteric glitches that can occur on real hardware. Although even in Magical Drop's case, I think BPS patches to fix the game bugs is a better strategy than baking in a bunch of game-specific hacks into our emulators.

User avatar
FitzRoy
Posts: 138
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Sun Jun 07, 2020 3:38 am

I did say that getting near the pipe counts as a pass, but Mesen-S isn't even getting on the platform where the pipes are. I agree that it borders on being a non-issue. I do remember testing this on hardware though, and at least on my particular system he went through the pipes. I certainly wouldn't commit any kind of uncertain fix towards it for fear of breaking other things. The biggest problem with this system is that it's basically impossible to backtest a 3200 game library after every commit. So any changes at this point have to be with confidence.

User avatar
FitzRoy
Posts: 138
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Wed Jun 10, 2020 5:37 am

Done testing. Just found one other bug. bsnes used to have this one, was fixed in 0.18.

Touge Densetsu (JPN): color corruption after selecting a bike.

There were a couple of other things that looked suspicious because they don't happen in bsnes. Theme Park clicks pretty loud at boot, kinda of the same sound Virtual Bart makes before it hangs. Winning Post has 1 frame of corrupted tiles at default ram values before the KOEI logo, which do not appear with 0s or 1s. I also noted some very minor scanline differences that I'll revisit when the PPU timing research is done.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Wed Jun 10, 2020 3:24 pm

FitzRoy wrote:
Wed Jun 10, 2020 5:37 am
Touge Densetsu (JPN): color corruption after selecting a bike.
Thanks! This should be fixed now - hurray for 10+ year old release notes from snes9x:
- The final HDMA Indirect Address load is only weird
on the last channel of the scanline.
Touge Densetsu Saisoku Battle problem solved. (anomie, byuu)
Turns out I implemented that bug, and even pasted a comment about how it only happens on the last active channel... and then I never implemented the "last active channel" check at all :) So it was triggering the bug too often.

I know FF2 also behaves similarly to Theme Park - there is some audio distortion right at the start when using random RAM. I'm not sure if bsnes/higan randomizes the RAM for the SPC like it does for other things?

Winning Post appears to turn on sprites before initializing OAM, so the random contents of OAM end up showing on the screen for a frame. It's not impossible that OAM is guaranteed to be $00 (or $FF) on power on on the SNES, but I haven't seen any information on that particular topic.

Thanks for taking the time to test all of these! Overall, there were less issues than I was anticipating (which is great for me!) - sounds like the majority of the remaining issues are mostly caused by slightly incorrect timings (which is arguably the most annoying kind of problem to fix :p)

creaothceann
Posts: 224
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Mesen-S - SNES Emulator

Post by creaothceann » Wed Jun 10, 2020 3:58 pm

Sour wrote:
Wed Jun 10, 2020 3:24 pm
It's not impossible that OAM is guaranteed to be $00 (or $FF) on power on on the SNES, but I haven't seen any information on that particular topic.
byuu captured the state of the RAM chips:

http://www.mediafire.com/file/tfp8qy9zoo89lbs/
http://www.mediafire.com/file/xcelszub8ui0buo/ (PNG)

There might be a post about it in the old forums ([1] [2])
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Near
Founder of higan project
Posts: 1550
Joined: Mon Mar 27, 2006 5:23 pm

Re: Mesen-S - SNES Emulator

Post by Near » Sat Jun 13, 2020 4:44 am

last active channel... and then I never implemented the "last active channel" check at all :) So it was triggering the bug too often.
It's a shame it's all trapped in 10+ year old forum posts and such, yeah. It was a real pain to figure this all out and now it's almost lost to time.

It's wild how timing sensitive the SNES is that we actually have to emulate not loading one extra byte per frame to fix Circuit USA, but if we load one byte too few per frame we break Touge Densetsu.

We need both these effects documented, and the example games to show why they matter and aren't just pedantic perfectionism.
I'm not sure if bsnes/higan randomizes the RAM for the SPC like it does for other things?
I do. There's at least a game or two that has distorted audio samples in the opening if your randomization is high-entropy (PCG, LFSR, etc), because they play back samples from uninitialized RAM, and entropy in audio samples = noise. Sorry but I can't recall what they are right now, bad memory.

I have three entropy settings: none (all 0xFFs), high (PCG, useful for validating homebrew though your logger warning people about it is better for that), and low ... which is the most interesting. I took about a dozen samples of all the RAM chips on cold boots on different SNES consoles, analyzed them for their general patterns, and tried to make an algorithm that approximated roughly the same entropy. What I came up with is not -quite- entropic enough, but pretty close, and mostly avoids the audio glitch issues at startup without having to disable entropy entirely.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Sat Jun 13, 2020 6:10 pm

creaothceann wrote:
Wed Jun 10, 2020 3:58 pm
byuu captured the state of the RAM chips:
Thanks for the info & links!
byuu wrote:
Sat Jun 13, 2020 4:44 am
We need both these effects documented, and the example games to show why they matter and aren't just pedantic perfectionism.
This particular glitch is documented in anomie's docs, I think (at least, that's where the quoted comment in my code comes from, iirc.)
I wrote a quick list of games I've had issues with while writing Mesen-S & the reason for each problem a little while ago - it's not super specific or quite up-to-date, but it should be a pretty decent list of games to use when trying to test for regressions (or testing a new emulation core): https://snesdev.mesen.ca/wiki/index.php ... late_games

Unfortunately, Circuit USA still locks up despite this - so there must be something else that's wrong, still.

I guess the "ram similar to what a snes tends to boot with" is the option I'm missing here. I can probably get by with forcing certain titles to use $00 or $FF for now, but that's certainly not ideal for romhacking and the like

Post Reply