- For making cartridges of your Super NES games, see Reproduction.
I did some prelim testing of GB, most of the games broken in higan work correctly. Let me know when you want me to library test that one.
As far as GB/GBC goes, I know of these issues atm:
GB: Pinball Deluxe - freezes
GB: Urusei Yatsura - flashing in maze
GB: Renju Club - freezes
GBC: Lego racer - freezes
GBC: 3d pocket pool - graphic issues
GBC: Perfect dark - Missing background music
GBC: Oddworld Adventures II - missing speech
GBC: Ready 2 Rumble Boxing - static during speech
GBC: Cannon Fodder - buzzing sound
I've gone through a couple of lists of "hard to emulate games" (e.g: https://www.reddit.com/r/EmuDev/comment ... o_emulate/) and most of the games mentioned in this issue: https://github.com/TASVideos/BizHawk/issues/1227, but beyond that, I really haven't tested many games.
It's not stable enough to properly test yet, though. Almost done implementing super gameboy, and I'll probably get back to trying to figure out the remaining issues after that (and trying to fix some of the test roms that still fail)
You can do this either by binding a key to the "Run single frame" shortcut (in Options->Preferences->Shortcuts), or via the debugger window by using the "Run one frame" option.
"Run single frame" will pause in vblank, on scanline ~240, "Run one frame" will pause 1 full frame later, on the same scanline/dot.
Also, a recent commit caused "power off" on gameboy games to retain the last frame instead of going black as expected.
Thanks! This was caused by the LCD blending option I added, which was causing it to blend the last GB frame into the black background - should be fixed now.
@SourFitzRoy wrote: ↑Wed Jun 03, 2020 1:22 pm3/4ths of the way done now. I added:
There was a thread 4 years ago where ikari_01 figured out the CX4 timings, which were eventually applied to bsnes
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.
i'm not sure that this is helpful, but it never hangs when you reset the game.
It works on a real SNES but I got reports that it doesn't work on Mesen-S no matter what game is loaded. I haven't tried Mesen-S myself.
It may be due to some unusual code not supported. Here are some examples:
- At start up, I use the stack pointer and PEA to set my clear-memory DMAs.
- Some leftover WDM for debugging, they aren't removed for the released version as they don't cause any significant time loss.
- I use some of the unused DMA bytes for highly used variables, including $43xB.
- IRQ is set where NMI is supposed to be so I can use SEI for locking thread faster.
- 16-bit STZ to $2180. I use this for queuing VRAM updates. During vblank, I write a 0 at the end before resetting the address (page aligned).
I can't think of anything else at the moment.
Let me know if you need more information.
EDIT: $43xB is open bus on Mesen-S but should be fully read/write-able.
You have to use the development build: https://ci.appveyor.com/project/Sour/me ... /artifacts
As far as I can tell he stopped because SameBoy's author started accusing him of plagiarism, and Sour didn't want to deal with that sort of thing. The Mesen Patreon is also paused.
I respect Sour and his emulation work. He makes this emulation research accessible in the form of easy to use software with powerful debuggers. He is to be commended for his effort.
But what LIJI said was true. Sour claimed he "reverse engineered the timings from (SameBoy)", but looking at the code in question it was a deliberate copy, with slight formatting changes and variable renaming. Without accreditation, this is plagiarism. The smoking gun was a case statement in Mesen-S that only existed for backward-compatibility with older SameBoy save states, which had no other reason to exist at all. But there were several more examples. Furthermore, his SNES code is in many cases rewritten bsnes code. And while there's too many NES emulators to be worth narrowing it down, I suspect the same is true for his NES code.
Sour using open-source emulation code wasn't a problem, in fact it's the ideal case. Sour himself has said he doesn't do hardware testing, so without this code, the Mesen emulators wouldn't exist, and that would be a detriment to us all.
But LIJI's software license was MIT, it could not be more permissive. All Sour had to do was put a single line in his license to give credit to LIJI. That's it. That he chose to quit emulation instead is on Sour, not LIJI. Don't put the blame on LIJI for being the person to call out this behavior. Sour can still make this right with a simple apology and a tiny license update, if he so chooses.
Sour's good deeds do not give him a free pass to take credit for someone else's work.