Super Game Boy system extensions

Discussion of programming and development for the original Game Boy and Game Boy Color.
User avatar
Marscaleb
Posts: 222
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Super Game Boy system extensions

Post by Marscaleb » Sun Nov 10, 2019 3:57 pm

What technical abilities does the Super Game Boy extend to a game boy game?

The Super Game Boy was a great accessory that seems all but forgotten. When the Game Boy Color came out I was disappointed to discover that it didn't respond to the extra palette information that games had for the SGB. Likewise was I disappointed that the Game Boy Advance didn't try to use the custom borders for the SGB. It was like Nintendo forgot that it was ever there.

Though I did discover that many of the dual GB/GBC games did include SGB data. I recall discovering that Dragon Warrior I & II had custom backgrounds (that you actually couldn't disable, for some reason,) that would change according to what the game was doing. They would change if you were on the overworld, in a cave, in a town, etc, which I thought was pretty cool.

But yeah, does the SGB offer any additional technical abilities to a GB game, beyond just offer a pre-decided color palette and (usually optional) special border?
I'm almost certain that it did, because I distinctly recall discovering some differences in Donkey Kong depending on what I played it on. When the princess called for help at the start of a stage, on the actual GB it played a simple square wave, but on the SGB it played a low-quality sample that actually sounded like someone saying "help."
Although when I try to check this on an emulator today (All my Game Boy games got stolen, save one,) the sound doesn't play at all, because the emulator doesn't seem to properly be set up to play SGB content.

I also suspect that the stages in the SGB are using some extended palette information, but I can't quite confirm it, and if it is, I am really curious what kind of capabilities the SGB adds.

The extended abilities would logically not be ones that a game would strictly rely on, since the game had to play properly on a regular Game Boy. But I still want to know what it was capable of.

lidnariq
Posts: 9891
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Super Game Boy system extensions

Post by lidnariq » Sun Nov 10, 2019 4:09 pm

Ultimately, the SGB supports sending arbitrary code to be executed by the SNES, so the sky's the limit.

tepples
Posts: 22173
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Game Boy system extensions

Post by tepples » Sun Nov 10, 2019 4:20 pm

Marscaleb wrote:What technical abilities does the Super Game Boy extend to a game boy game?
The most common are
  1. A border with up to 255 unique H or V flippable tiles and with one of four 15-color palettes for each tile
  2. Coloring individual 8x8-pixel regions of the rendered screen with one of four 3-color palettes (and a shared color 0). This grid cannot be scrolled, and updating portions is slow (a few rectangles every 4 frames). This is why most games just assigned one of the four subpalettes to the map and another to the status bar, except in still scenes like the maps in Donkey Kong (1994).
  3. BRR sample playback through the S-DSP
  4. Multiple controllers
Far less common was what Space Invaders did: send an entire game program to the Super NES's RAM and run it from there.
Marscaleb wrote:The Super Game Boy was a great accessory that seems all but forgotten. When the Game Boy Color came out I was disappointed to discover that it didn't respond to the extra palette information that games had for the SGB.
That's because GBC colors individual background tilemap cells and sprites, while SGB colors areas of the rendered screen.
Marscaleb wrote:Though I did discover that many of the dual GB/GBC games did include SGB data.
For example, 144p Test Suite has GB, SGB enhanced, and GBC enhanced modes.
Last edited by tepples on Sun Nov 10, 2019 10:54 pm, edited 1 time in total.
Reason: Add "Multiple controllers"

User avatar
Marscaleb
Posts: 222
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Re: Super Game Boy system extensions

Post by Marscaleb » Sun Nov 10, 2019 5:12 pm

tepples wrote: Far less common was what Space Invaders did: send an entire game program to the Super NES's RAM and run it from there.
Image

Shonumi
Posts: 321
Joined: Sun Jan 26, 2014 9:31 am

Re: Super Game Boy system extensions

Post by Shonumi » Sun Nov 10, 2019 9:12 pm

Something about the SGB that fascinated me as a kid was support for 4-player modes. Bomberman GB is the one I know best, followed by Wario Blast. You'd need the Super Multitap in addition to the controllers, SGB, and Game Boy game. Unfortunately, not a lot of games used it. In fact, it might be just the two games I listed. More GB games actually used the DMG-07 (Game Boy 4-player adapter) than the Super Multitap.

Additionally, if you also considered the SGB2, it added a Link Cable port to the cart, enabling the use of regular Game Boy multiplayer and all of the accessories compatible with a DMG (Barcode Boy, Barcode Taisen Bardigun Scanner, and even a sewing machine).

About uploading code directly to the SNES, as far as I know, there's a documented way of jumping from Game Boy to SNES, but I've yet to hear of a method of jumping back to Game Boy code. If there were a way, that would open up the possibility of a vaguely Nintendo Switch-like experience, since gameplay progress could be saved to any cart-based SRAM. You could technically do this sort of thing anyway without jumping back to Game Boy code if passwords are used for game progress.

User avatar
Marscaleb
Posts: 222
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Re: Super Game Boy system extensions

Post by Marscaleb » Sun Nov 10, 2019 11:43 pm

Shonumi wrote:Something about the SGB that fascinated me as a kid was support for 4-player modes. Bomberman GB is the one I know best, followed by Wario Blast. You'd need the Super Multitap in addition to the controllers, SGB, and Game Boy game. Unfortunately, not a lot of games used it. In fact, it might be just the two games I listed. More GB games actually used the DMG-07 (Game Boy 4-player adapter) than the Super Multitap.
That sounds like it should be an episode of Punching Weight. Actually, I already have the multitap, so I could do this if I got one of those games. Finally get some use out of the mutltap since I beat Secret of Mana. Hmm, good times.
Shonumi wrote: About uploading code directly to the SNES, as far as I know, there's a documented way of jumping from Game Boy to SNES, but I've yet to hear of a method of jumping back to Game Boy code. If there were a way, that would open up the possibility of a vaguely Nintendo Switch-like experience, since gameplay progress could be saved to any cart-based SRAM. You could technically do this sort of thing anyway without jumping back to Game Boy code if passwords are used for game progress.
Well that's slightly disappointing, but the thought of a gameboy game running SNES code still sounds really cool. Completely unnecessary, but so cool.
tepples wrote: Coloring individual 8x8-pixel regions of the rendered screen with one of four 3-color palettes (and a shared color 0). This grid cannot be scrolled, and updating portions is slow (a few rectangles every 4 frames). This is why most games just assigned one of the four subpalettes to the map and another to the status bar, except in still scenes like the maps in Donkey Kong (1994).
Let me rephrase that to make sure that I have it right.
So when the SGB renders a game, it just outputs the image as one whole image to the SNES (since it is not emulating the hardware but actually running GB hardware that it has to then interface with the SNES) and the coloring effect that the SNES applies is basically like the colored cellophane they put on the screen for old arcade games; it is applying the color to the image AFTER the GB hardware in the SGB has fully rendered the image.
So when you say "This grid cannot be scrolled" it is just referring to that "cellophane cover," and a gameboy game isn't actually unable to scroll an image when utilizing more than one palette; it could use it for more than just still screens. It's just that if the image scrolls to where it isn't lined up with that palette-grid, then it isn't going to look proper.
And of course, this palette effect applies to the entire final render, so it can't separate backgrounds from sprites.

Still, there are a lot of neat color effects someone could pull off within those limitations. If a game is only scrolling in one direction they could apply a different palette to certain parts of the level, maybe have blue sky that isn't shown in the rest of the scene or some such thing.

Changing the palette map slowly is unfortunate, but I assume this just refers to changing what blocks are rendering what palette. If one desired to change the colors within a palette, I would assume this could be done completely within a single frame? Possibly even during a V-blank? Also, could changing the palette map be done quicker if the screen were blank? Like if you wanted to change to a "full" color cutscene or menu or whatnot, what is the fastest that the whole map could be re-written? I mean, I never noticed any lag in Donkey Kong when it displayed the map screen. Maybe it can't update fast enough to keep up with changes in the middle of the game, but still it seemed capable of updating a still screen fast enough.

Also... I just had a crazy thought. Since the SGB could execute arbitrary code on the SNES, couldn't it use that to get around some of these limitations? For example, it can't color sprites differently than the background. What if it just drew SNES sprites on the screen? It could send over the graphics and then each frame dictate how each sprite needs to be drawn. I mean, technically the game has to do that anyway, but it would basically be sending the data through some different channels. It would bring some limitations, like it couldn't draw a sprite behind a background layer. Depending on how much data the GB needs to send to the SNES each frame, it could either use this to draw more sprites on the screen or be constrained to fewer.
This effect *could* be used to simply assign a different palette to sprite objects, or possibly it could be used to render SNES-quality sprites in the game.

Or if those NES-like palette restrictions are too limiting for a still image, why not have the SNES draw a SNES quality still image?
Of course, the next inevitable step is "why not do both and have the whole game look like a SNES game?" But then you reach the question of "why not just make a SNES game, period?" so perhaps let's just scale this back to the sprites. What if I wanted to draw the sprites through the SNES to add extra color palette? If you wanted to still technically be running code off of the Game Boy hardware, how much SNES hardware could you have running in tandem? Could I replace all the GB sprites with SNES sprites And still operate at full speed? Could I have some extra sprites left over to reduce flickering or add extra detail?

lidnariq
Posts: 9891
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Super Game Boy system extensions

Post by lidnariq » Mon Nov 11, 2019 12:43 am

Marscaleb wrote:Also... I just had a crazy thought. Since the SGB could execute arbitrary code on the SNES, couldn't it use that to get around some of these limitations?
Of course. But they already provided an abstraction for many of these in the SGB BIOS.
What if it just drew SNES sprites on the screen?
See nocash's documentation here:
http://problemkaputt.de/pandocs.htm#sgb ... bjcommands

nocash
Posts: 1263
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Super Game Boy system extensions

Post by nocash » Mon Nov 11, 2019 1:10 am

Shonumi wrote:there's a documented way of jumping from Game Boy to SNES, but I've yet to hear of a method of jumping back to Game Boy code
The jump changes the program counter on SNES-side, ie. it jumps from SNES-ROM to SNES-RAM.
There is no jump taking place on gameboy-side, and you can keep doing whatever you want on gameboy-side.
Ie. with the jump you have control of both CPUs, you do lose any control by that.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

calima
Posts: 1249
Joined: Tue Oct 06, 2015 10:16 am

Re: Super Game Boy system extensions

Post by calima » Mon Nov 11, 2019 2:11 am

Something is different in the SGB2's link cable port. A few months back when I was playing Pokemon on it, it failed to link up with my GBC and GBA SP. It would detect the cable is there (led would light up), but when I went to the center to trade, after a short detection pause it would say the cable is not connected, and the led shut down.

The link cable was a third-party one, with both GB and GBC-style ends at both ends, but it worked fine between the two gameboys.

tepples
Posts: 22173
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Game Boy system extensions

Post by tepples » Mon Nov 11, 2019 6:35 am

Shonumi wrote:I've yet to hear of a method of jumping back to Game Boy code.
Reportedly, if the Super NES program hasn't overwritten any variables or buffers on which the SGB depends, the program can return to the SGB firmware by executing JML to an RTS instruction in bank 0. (This address differs per firmware version but can be found by scanning $8000-$FFFF for a $60 byte or by jumping to a stubbed command's entry point.) However, finding which address ranges are available would require disassembling the SGB firmware.

The other way is for the Game Boy program to act as a storage server. Even after the firmware has jumped the S-CPU to native code, the Game Boy CPU still runs. This CPU could read requests from the controller and upload 4K blocks of data from the Game Pak through the ICD2 chip in the same way that a game uploads border data, and the program running on the S-CPU could receive them from the ICD2 chip. It'd be like the S-CPU using the Game Boy as a block storage device.

Shonumi
Posts: 321
Joined: Sun Jan 26, 2014 9:31 am

Re: Super Game Boy system extensions

Post by Shonumi » Mon Nov 11, 2019 7:27 am

nocash wrote: You can keep doing whatever you want on gameboy-side.
Ie. with the jump you have control of both CPUs, you do lose any control by that.
This information (along with what tepples posted) is missing from Pan Docs and other resources I've looked at. Might be obvious to people who have worked with SNES emulation or homebrew and have poked around the SGB (e.g. for yourself nocash, and byuu maybe), but as someone who exclusively deals with just Game Boy stuff, it isn't clear. All this time it was never evident to me that both CPUs run in tandem. I mean, a lot of material is absent from Pan Docs, but these are details that need to be documented somewhere.

Anyway, TIL. Thanks to both of you! :D

tepples
Posts: 22173
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Game Boy system extensions

Post by tepples » Mon Nov 11, 2019 7:56 am

Shonumi wrote:This information (along with what tepples posted) is missing from Pan Docs and other resources I've looked at.
Did you look at the Super Game Boy section of Fullsnes?
Shonumi wrote:I mean, a lot of material is absent from Pan Docs, but these are details that need to be documented somewhere.
There's a community-maintained fork of Pan Docs that includes some of the missing information. If you're interested in improving it, join gbdev.

Shonumi
Posts: 321
Joined: Sun Jan 26, 2014 9:31 am

Re: Super Game Boy system extensions

Post by Shonumi » Mon Nov 11, 2019 8:17 am

@tepples: It's early in the morning for me, so perhaps I missed something, but neither sources you posted mentions what exactly happens to the Game Boy side of things after the SGB Jump command is issued. I've used the GBdev wiki page as reference before, but it's still a bit lacking in this specific regard.

As I said, maybe it's just me that this is new information. However, it was non-obvious what behavior occurs from the perspective of the Game Boy code after the jump, so perhaps documentation going forward should err on the side of being explicit.

Pokun
Posts: 1599
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Super Game Boy system extensions

Post by Pokun » Mon Nov 11, 2019 6:09 pm

I'd guess the Game Boy CPU just continues to run like normal in parallel, so you probably want to stop sending commands and stuff after starting a SNES program in SNES RAM, and wait in a loop for the SNES PC to return to ROM.
I don't know the details, but the cartridge is just a Game Boy with some extra hardware and software to communicate with the SNES and the SNES is just running a ROM cartridge with special hardware, both running in parallel at all times I think (or else nothing would work).
calima wrote:Something is different in the SGB2's link cable port. A few months back when I was playing Pokemon on it, it failed to link up with my GBC and GBA SP. It would detect the cable is there (led would light up), but when I went to the center to trade, after a short detection pause it would say the cable is not connected, and the led shut down.

The link cable was a third-party one, with both GB and GBC-style ends at both ends, but it worked fine between the two gameboys.
Yeah I noticed that too. A normal Game Boy doesn't even use a LED for the expansion port in the first place, only SGB2 has this and seems to give up if linking fails.

lidnariq
Posts: 9891
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Super Game Boy system extensions

Post by lidnariq » Mon Nov 11, 2019 6:24 pm

calima wrote:It would detect the cable is there (led would light up)
Do we know what controls the LED? Quickly checking, I couldn't obviously find a schematic for the SGB2 anywhere.

Post Reply