- For making cartridges of your Super NES games, see Reproduction.
-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.
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.
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>
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
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.
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.
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
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.
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.
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
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.
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.
Thanks! This should be fixed now - hurray for 10+ year old release notes from snes9x:
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.- The final HDMA Indirect Address load is only weird
on the last channel of the scanline.
Touge Densetsu Saisoku Battle problem solved. (anomie, byuu)
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)
byuu captured the state of the RAM chips:
There might be a post about it in the old forums ( )
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
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.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 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 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'm not sure if bsnes/higan randomizes the RAM for the SPC like it does for other things?
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.
Thanks for the info & links!
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