Bsnes Super Game Boy Issues

Libretro Cores
#1

A little while back, I made a post where I had some help figuring out how to get Super Game Boy running through CLI. Now that I’ve got the gist of it figured out, I thought I might provide a list of the issues I’ve run into while using the Super Game Boy in RetroArch, most of them being relatively minor, along with examples of games where I’ve noticed these issues; I’m not sure if these issues are exclusive to these games (as I’m only documenting them based on my own experiences) or if they’re widespread across the Game Boy and Game Boy Color library (discounting GBC-exclusive titles, which cannot run on original GB hardware like the kind found in the SGB cartridge).

  • Save States: Certain games crash RetroArch when I try to create or load a save state, while others seem to implement them perfectly fine. Games I’ve seen suffer from this problem include Wario Land: Super Mario Land 3 and Super Mario Land 2: 6 Golden Coins.
  • Border and Color Glitches: Select Game Boy titles have special SGB palettes and borders built into them that can be switched on and off via the SGB menu. Some of these games either have corrupted borders (i.e. Pokémon Red & Blue and Gold & Silver), or in some cases don’t load the borders or palettes at all, being mistaken for an un-optimized Game Boy game (as is the case with Pokémon Yellow). The default borders are not affected, so I can still switch to them and play the game no problem, but with Yellow I’m stuck using what the SGB alone can provide.
  • Video Playback Errors: When Donkey Kong '94 boots up, the video feed freezes when the Super Game Boy ROM tries to load the game’s special border. However, the audio feed runs as it should on an actual cartridge, indicating that the game is still properly running aside from the frozen screen.
  • I can’t really put a name on this next one, but Super Mario Land 2 resets when I try to enter certain worlds such as Tree Zone or Turtle Zone
  • This one also doesn’t have a name since it’s exclusive to one ROM, but Super Game Boy 2 doesn’t boot up at all; attempting to load the SGB2 ROM simply causes a black screen to pop up; this was the main issue I was trying to bypass when figuring out how to run SGB mode through BSNES, and while I managed to fix it in the case of the original SGB, SGB2 still hasn’t been resolved. I know this is not an issue with the command lines I’m using because the black screen issue still occurs when I boot up the SGB2 ROM through RGUI, which in the case of SGB1 simply brings up the “no game inserted” screen as it should. Both ROMs are run through bsnes, the only core that supports SGB mode as of right now.

While Super Game Boy mode is a pretty cool thing to use in RetroArch, these issues mar the experience for the games affected. Maybe this can be fixed in an update for bsnes, maybe other cores can implement a more accurate SGB mode in the future. But for now, it seems that these are just the issues that have to be contended with. Are there any other issues you guys have noticed with SGB mode, and is there any way to fix any of the above-listed ones?

1 Like
#2

As far as I knew, SGB support was entirely command-line based, Windows-only, and generally unmaintained for ages due to the lack of interest in the subsystem API. (Totally understandable - I think Super Game Boy support was the only thing that ever used it, and it’s pretty obscure…although more annoying, because none of the libretro GB cores offer ‘fake SGB’ support.) My experience mostly matches this. I think the issue isn’t just the API, but the cores involved and the way bsnes/Higan implements this in the first place, and the changes in code over time.

I’ve been making heavy use of RetroArch for various video/image recording projects simply because the shader support is unparalleled. It makes all kinds of effects much easier to achieve, and lets you do it at any resolution without a fuss. No standalone emulator can match that, and that’s why I stick with libretro even though it does lack in some areas compared to standalone programs. (Albeit, mostly by design - you aren’t going to be debugging in RetroArch, are you?)

I’m willing to pitch into a bounty for it (around $20), assuming the devs approve of the idea. You should post in the bounty forum about the issue and see if we can’t get this fixed at some point…though it might take more work than a bounty is really appropriate for. At a minimum, it’d be nice if we could get ‘fake sgb’ for the fancy borders or something.

#3

I’ve always been more interested in authentic emulation of the Super Game Boy because of the enhancements it provides that “fake” SGB lacks, such as enhanced sound effects (and in some cases, enhanced music), the ability to change the borders and palettes, and the ability to access certain features only present in SGB mode (such as Arcade Mode in Space Invaders), which is why I wish SGB mode through bsnes was more stable or that a better version of it was implemented for other emulators like bsnes-mercury. So yeah, if anyone out there was willing to take up the concept of improving SGB mode as you suggested, that’d be pretty nice; I myself am not a skilled programmer, so at the moment I wouldn’t be able to find a way to fix SGB mode’s issues on my own.

#4

Oh, no, I totally agree. I want authentic SGB emulation to be a part of the RetroArch experience, since the capabilities of the hardware are so intriguing. I just think that, should the team decide refurbishing the subsystem API is too much, exposing ‘fake SGB’ support is better than nothing at all.

Putting up a bounty is something you can do even as an end user, at least, assuming you have the cash. I’ll see about poking at the bounty forum later.

#5

Another option would be to make a completely separate core that handles SGB without the subsystem and instead looks for an SGB ROM in the system/BIOS directory that it loads that way and then the GB ROM is passed as the standard ROM argument.

That is, a hardcoded SGB core.

3 Likes
#6

THAT would be a godsend. SGB is certainly niche, but I think having something like this would bring attention to it.

As someone who highly values emulation as preservation, I can’t get behind this concept enough.

#7

I second that idea; if it’s built right, a hard-coded SGB core would certainly be a much better option than the subsystem in bsnes, particularly when you consider all the problems I listed in my first post.

My only question is whether or not it’d use the original Super Game Boy, the Super Game Boy 2, or both (either interchangeably or as separate cores). My personal preference would be that it use the third option, or maybe some combination of the two SGBs-- that is, having the 1:1 clock speed and game linking compatibility of the SGB2 and all 16 borders from both versions.

Of course, concept and execution are two different things, so I’m not sure if this could be feasibly implemented, particularly when considering the fact that some games have different built-in borders for SGB and SGB2 (i.e. Tetris DX), but I still look forward to see what could be accomplished.

#8

There are a number of ways to handle loading one or the other. I don’t think any mixture is likely.

#9

Would the speed of the emulated SGB be dependent on the speed the ROM is expecting it to be played at? If not, it doesn’t matter too much. Either way, maybe someone could hack the SGB2 ROM to include SGB1 borders and show itself as an SGB1 to the games.

All of this is pretty academic at the moment, though. hunterk, should we go ahead with a bounty of some kind, or is this easy enough to do that we can expect it as part of a regular release schedule?

#10

My guess is that the devs can either create two cores, one for SGB and one for SGB2, or just make one core where the two different versions of the SGB BIOS are interchangeable in the options menu (similarly to how Gambatte can switch between the Game Boy, GBC, and GBA BIOSes). My only real concern with that is the fact that the original Super Game Boy is roughly 3% faster than an actual Game Boy, though this can probably be modified without much issues considering how SGB1 in bsnes has SGB2’s 1:1 clock speed ratio.

#11

Thought it may be helpful to direct to this https://github.com/mgba-emu/mgba/issues/1104

A user on the Mgba github seems to have isolated what he believes to be the cause for Pokemon Yellow not having it’s SGB enhancements detected. I may decide to open a bounty in the future provided I get a good enough itching to play Pokemon Yellow