- For making cartridges of your Super NES games, see Reproduction.
That being said, this is still in its infancy (I started writing this last month) and far from finished. Notably, it does not support any of the enhancement chips and a number of planned features are still missing (movies, cheats, netplay, etc.)
It currently uses a "pixel-based" renderer (it catches up the rendering mid-scanline as needed) and the timings should be fairly accurate (but there are definitely a large number of scenarios where they may be off by a few master cycles).
Just to be clear though, this is not bsnes-level accuracy, but in some regards it is probably more accurate than snes9x 
A small number of games still have issues (freeze at boot, etc.), and some PPU effects are not perfectly accurate (e.g the mosaic effect in particular has issues).
With all the caveats out of the way, here's what it does offer at the moment:
-Relatively high compatibility (I would guesstimate that over 90% of games that don't use extra chips appear to boot and run properly)
-Windows/Linux support (Linux support is something I put together this morning and haven't had the chance to test much yet, but it compiles and runs)
-Loading from zip/7z files
-Softpatching of IPS/BPS files
-SNES mouse support (Superscope is not supported yet)
-Recording to AVI/WAV
-Breakpoints (w/ conditional breakpoints)
-Memory viewer/editor (including highlighting for recent reads/writes/exec, and data/code highlighting)
-PPU viewer (tilemaps, tiles, palette)
-Event viewer (the same as Mesen's)
If you've ever used Mesen, you already know your way around Mesen-S. It reuses a lot of Mesen's code (and so looks very similar in terms of both code and UI), which has allowed me to put all of this together very quickly. This also means that some features haven't been tested thoroughly - so bugs are to be expected (I am aware of a number of issues, but if you find any, please report them here!)
Also, performance isn't great at the moment (somewhat slower than Mesen in general), it's something that I hope to improve over time.
Website/Documentation: None for now.
Here's what it looks like at the moment (in terms of debugging tools): Note: The emulator currently requires the 64-byte SPC bios to be put in Mesen's data folder (i.e the one you picked on startup) and named "spc700.rom". If the file cannot be found, the UI should print an error message about it when trying to load a game.
As usual, feedback, ideas and bug reports are very much welcome!
P.S: This is not an April Fools' joke, but I did release this now on purpose. :p
Someone of your talent will no doubt catch up quickly, and likely exceed what I've been able to.Just to be clear though, this is not bsnes-level accuracy
Nonetheless, if you have any questions on things, feel free to DM me any time and I'll try to help if I can.
https://github.com/PeterLemon/SNES/tree ... PUTest/CPU
It is already shaping up to be a great SNES emu, thanks so much for this =D
Thanks! And thank you for bsnes/higan, too! A lot of this was only possible because I had bsnes-plus to compare against, which wouldn't have existed without bsnes in the first place. I'll most definitely have questions eventually when I get to the more obscure stuff (and probably some of the not-so-obscure stuff, too.).byuu wrote:Wow, that's really exciting and cool! Congratulations on your first release! :D
Nonetheless, if you have any questions on things, feel free to DM me any time and I'll try to help if I can.
Thanks for those tests, by the way! They were extremely useful when I started this and helped me fix a pretty large amount of CPU bugs (though I did find a few bugs that they don't seem to catch - if you're interested in adding some more test cases to them, let me know and I'll try to come up with a list of things I found so far)krom wrote:Great job, it passes all of my SNES CPU tests
It's been a bit of a marathon trying to get this into a releasable state by April Fools'! I'll probably slow down my pace a little bit, but I should be able to add a lot of the missing stuff (compared to Mesen) over the next few months.koitsu wrote:Absolutely wonderful. I don't really have any other words right now, my mouth is still kinda agape.
I did, however, hit a few bugs:
I brought up the memory viewer and tried typing in it at 7E:EDA1 I think it was. The whole emulator crashed.
(Not sure if this will repro, but I used Go To from the menu to jump to 7E:EDA0, scrolled up one line so I could see from 7E:ED90, then clicked at 7E:EDA1 and tried to type "5F". It crashed when I hit 5.)
When I brought the program back up, it wouldn't load the savestate I'd created prior to the crash.
I rebound a few keys - swapped the as and zx keys in the default arrow-key configuration, and when I restarted the emulator I noted that while the change appeared to have saved, I was getting strange behavior from the controller inputs. Hard to exactly describe, but it was either that some of the re-bound keys were ignored, or it was trying to use both my new settings and the defaults at the same time.
Those issues aside, this is already *massive* improvement on all the other debugging-enabled SNES emulators that I've tried. I can easily see this replacing several pieces of my toolkit. Looking forward to seeing where you take it!
One thing I noticed was a breakpoint on register $2133 was triggering at cycle 340 but the event viewer only goes to 339 so it didn't show up there.
1.) Mega Man X's copy protection is getting triggered. This is applicable to both 1.0 (CRC32 1033EBA4) and 1.1/Rev 1 (CRC32 DED53C64). It's somewhat random in how it works, but https://tcrf.net/Mega_Man_X#Copy_Protection has a nice write up on it. I actually didn't know Rev 1 HAD copy protection at all, but with both ROMs I ended up being thrown back to the intro stage after the first boss was defeated. I guess this is a cartridge database issue?, but thought I'd mention it anyway in case.
2. Changing the video scale doesn't automatically change the window size like it does in Mesen.
3. I also get a lot of audio clipping if I increase the Master Volume, in fact, 10 seems to be better than default of... 25 I think it was? No such issue in Mesen, which I have at 100% and everything is crystal clear. If I decrease the Master Volume in Mesen-S and just turn up Windows audio, it's also crystal clear. I'm on Windows 10, 1809. I'll see if there's an update to the audio drivers in a little bit too, might be something dumb like that.
To be fair, it's been 7 weeks :pgeod wrote:Less than one month and this. Crazy.
Happy to hear it's already useful! There is actually a ton of features still missing when you compare it to Mesen's debugger, I do plan on adding most of them over time.Gideon Zhi wrote:I've only used this a little bit but I have to say, the debugger is super nice
Thanks for the bug reports - I'll try and see if I can reproduce the crash you got.
For the key bindings, it's possible you doubled up the bindings - when you press "Setup" for the controller, the window has 4 tabs allowing you to bind the same controller button to multiple keys, you might have some leftover bindings in the 2nd tab that are conflicting with the ones you've changed in the first tab?
Damn, you've already discovered my terrible secret. At the moment the code emulates 341 regular cycles per line, rather than 338 regular cycles + 2 longer cycles, it comes out as the same number of master cycles but does have some implications (both with debug tools & emulation itself). I do want to fix the PPU to properly run the longer cycles, though, it's mostly a matter of figuring out the best way to do it with as little overhead as possible.paulb_nl wrote:$2133 was triggering at cycle 340 but the event viewer only goes to 339 so it didn't show up there.
That's good to know, I actually played MMX a bit, but did not get far enough to trigger it (didn't know that protection existed). It's most likely a case of incorrect memory mappings, like you said - the core currently just assumes there are only 2 board types ("lorom" and "hirom") and nothing else. Is there a proper database of cartridges available somewhere? There only thing I found when I looked for one before was a website with relatively vague/incomplete information.AxlRocks wrote:I guess this is a cartridge database issue?, but thought I'd mention it anyway in case.
The video scale thing has always been a bit of a pain in Mesen, too - I'll get it working... eventually.. :p
I'll have to see about the volume, I didn't really put much thought into the slider, I think it's pretty much the same as Mesen (25% is 1x, 100% is 4x). It's very possible it clips rather early, I'll have to test and readjust the default/formula a bit.
For a ROM whose size is not a power of two, you'll want to split it at the largest power of 2 no larger than the ROM and then double up the remainder as big as the first. For example, you'd split a 10 Mbit ROM into 8 and 2 Mbit pieces and then quadruple the 2 Mbit part.
The only one I know of is this (and related), which isn't "exceedingly" helpful from an emulation POV, but it might be better than nothing. Possibly Cowering has something?Sour wrote:Is there a proper database of cartridges available somewhere?
If you need documentation on what the majority of official PCBs do, address-space-mapping-wise, that information is available, but you might already have it; ask in PM.
Count every scanline as 1364 clocks, except for:I do want to fix the PPU to properly run the longer cycles, though, it's mostly a matter of figuring out the best way to do it with as little overhead as possible.
* NTSC scanline 240 field 1 in non-interlace mode (1360 clocks)
* PAL scanline 311 field 1 in interlace mode (1368 clocks).
When the counters are latched via $2137 reads or clearing $4201.d7 on writes, compute the dot position from the clock position. But don't forget that long dots don't exist in the 1360-clock NTSC scanline. A simple approximation:
Code: Select all
return (hcounter - ((hcounter > 1292) << 1) - ((hcounter > 1310) << 1)) >> 2;
It's also worth noting that the long dot start positions are fussy. 323 and 327 are the most likely, but I often see 322 and 326 become the long dots, and sometimes even 321 and 325. It can even change at run-time on the same system, so it's not like the NES startup phase states (the SNES has those too, but you can only get them if you reset the system via the cartridge port, ala the sd2snes.)
The CPU NMI and IRQ timing is based off of the Vblank and Hblank pin outputs from the PPU, and it keeps its own internal counters, which means that IRQ timings are not affected by long dots.
Right into the deep end, I see ^-^;Is there a proper database of cartridges available somewhere?
It's incomplete (I have around 1200 unique games in there so far), but this has been my little niche for the past several years. I personally dumped all of these games, their full 16MiB address range, and recorded how their mirroring worked. Yes, this has been *very* expensive and time consuming ^^;
The raw database is here: https://gitlab.com/higan/higan/tree/mas ... s/Database
The first link shows you how each PCB is mapped out on the bus, and the other links give you the PCB IDs of game cartridges to map them to. There are two cases so far where the PCB ID wasn't enough for an exact memory map, so I had to put #A in the PCB IDs.
Board PCB mappings are a huge undertaking. If you would rather use heuristics (which you'd have to for all the games not in my database yet anyway), I have heuristics that work on the entire licensed, released SNES game library here:
https://gitlab.com/higan/higan/blob/mas ... amicom.cpp
If you like, you may use my database or heuristics code linked above under the public domain, no credit necessary. You would have to adapt the heuristics code of course. Think of SNES PCB IDs as being similar to NES mappers. There's hundreds of them, they're just less important to get right and there's lots of overlap (multiple PCB IDs share the same memory mapping.) But there are lots of exceptions: games with coprocessors, games with flash memory, games with Game Boy, Sufami Turbo, and BS-X slots, games with both a BS-X slot and an SA1, etc. Realistically, you'll need at least 30 memory maps to run the entire library.
Or, if you'd rather the short of it, here's a crash course on heuristics:
* LoROM games under 2MB should map SRAM to 70-7d,f0-ff:0000-ffff (Wanderers from Ys requires SRAM in 0000-7fff)
* LoROM games >= 2MB should map SRAM to 70-7d,f0-ff:8000-ffff (Fire Emblem: Thracia 776 requires ROM in 0000-7fff)
* Distinguish the ST010 and ST011 based on the size of the ROM or on the internal game title
* Distinguish the SGB and SGB2 based on size of the ROM or on the internal game title
* For everything else, be as permissive as possible
Many prototype games documented by Evan at snescentral will not work with heuristics, because the SNES header bytes are all blank. You will either need a database for them (I did not make one for prototypes), a way to externally specify board mappings, or tell users to patch their ROMs to fix the bad headers (preferably with a BPS patch.)
Correct. There is a game out there which clips if your volume goes above even 100%. SNES audio volume is just very quiet.I'll have to see about the volume, I didn't really put much thought into the slider, I think it's pretty much the same as Mesen (25% is 1x, 100% is 4x). It's very possible it clips rather early, I'll have to test and readjust the default/formula a bit.
A fancy solution would be to detect clips and dynamically lower the audio volume. But end users may find that annoying.