LIJI32
Better SGB+GBC support (RetroArch/libretro)
Originally posted here: https://github.com/libretro/SameBoy/issues/87 Adding it here since that repo doesn't seem to have much traffic and other core issues are being reported here anyway.
Current version allows you to force display SGB borders while using GBC colors, however this seems to only work for native SGB-supported games. Certain SGB borders added by ROM hacks (e.g. Kirby's Dream Land 2 DX, Pokémon Crystal Clear) are not detected/enabled as they would be on emulators with full support (I believe mGBA on desktop (but not the core) has this functionality).
See this for some more info: https://www.reddit.com/r/PKMNCrystalClear/comments/o4paxs/how_do_i_play_this_with_the_sgb/
There are two major problems with the "SGBC" unofficial extension to the GBC:
- It is heavily reliant on how some emulators very inaccurately emulated the way the Game Boy side of the original SGB large data bulks to the SNES side. For an accuracy-based emulator, supporting this means essentially having two different implementations of the SGB logic, an accurate one for real SGB, and an inaccurate one for SGBC. This will heavily hinder maintainability and potentially performance.
- There is no documentation of how this mode should work to begin with. Originally, it was ROM hacks that tailored themselves to work with a specific emulator, then other emulators implemented this feature specifically to support these ROM hacks. These makes implementations very fragile as ROM hacks will most likely continue a target a specific implementation, breaking the others.
While I'm generally open to supporting unofficial extensions (see: the TPP1 mapper), as it stands right now the SGBC extension is no different than supporting ROM hacks that only run on VBA. When and if the situation changes, I will reconsider supporting this extension. Leaving this issue open for future discussion and reference for when the situation changes.
Thanks for the explanation! I'm not so familiar with the technical side of this so this was very insightful & interesting.
For an accuracy-based emulator, supporting this means essentially having two different implementations of the SGB logic, an accurate one for real SGB, and an inaccurate one for SGBC.
Is this what mGBA does? I know mGBA is regarded as a highly accurate GBA emulator, but I don't know much about how accurate their GB/GBC emulation is.
Maybe it's worth noting here too that there appears to be multiple ways this this implemented. I've found some games with added borders don't even display them at all, even when running under SGB (and depend on the unofficial implementations in emulators to display them), while others behave more traditionally and do show a border (but only in SGB mode of course).
I'm not sure what mGBA is actually doing, nor am I sure how accurate SGB emulation is in mGBA. However I did discuss this with BGB's developer Beware. Turns out the first emulator to introduce this thing is NO$GMB (An emulator that got its last update in 2000), and BGB only added this feature for parity. Turns out it was never intended to be used this way, and could break in a future BGB update.
The most hardware-implementable model of SGBC behavior that I know of:
- allow border, sound, and multiplayer commands and disregard palette and attribute commands
- while a TRN is in progress, output 2bpp with palette controlled by BGP and OBP0/1, for SGB to receive
- otherwise, output 15bpp through the GBC palette path
