Super Game Boy system extensions

Discussion of programming and development for the original Game Boy and Game Boy Color.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Super Game Boy system extensions

Post by calima »

Gekkio's site has pcb pics: https://gbhwdb.gekkio.fi/consoles/sgb2

I've since found I had a genuine Nintendo link cable too, testing that is low on the ever-longer TODO list though. It's just curious that a 3rd party cable would fail, the advertisement for SGB is that it's a GB Pocket inside the cart. I wouldn't put it past Nintendo to try to break 3rd party peripherals on purpose, but it's just as likely something is slightly out of spec.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Super Game Boy system extensions

Post by nocash »

Shonumi wrote: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.
I don't know how to describe that... the gameboy cpu won't vaporize after sending the jump-command packet?
But yes, the pandocs are a it outdated, and lack info on the snes-side, the fullsnes doc has more info on that.

I don't think that anyone would return to the snes rom for further communications after the jump, it would be more straightforward to write your own transfer functions, ie. something similar to what is in the snes rom. I guess ISSOtm was doing (or planning) something like that, too.
https://forums.nesdev.com/viewtopic.php?f=12&t=18431
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Game Boy system extensions

Post by tepples »

nocash wrote:the gameboy cpu won't vaporize after sending the jump-command packet?
I guess the fear was that JUMP would halt the clock to the Game Boy CPU.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Super Game Boy system extensions

Post by Pokun »

I think Shonumi is just overthinking it. This whole console-running-a-ROM-cartridge-in-a-ROM-cartridge-on-another-console-thing is boggling my mind enough to get confused all the time. That's why I suggest to see it as just a cart with expansion audio and expansion video which is processed by the ROM (SGB BIOS) running on the SNES. *phew*
calima wrote:Gekkio's site has pcb pics: https://gbhwdb.gekkio.fi/consoles/sgb2

I've since found I had a genuine Nintendo link cable too, testing that is low on the ever-longer TODO list though. It's just curious that a 3rd party cable would fail, the advertisement for SGB is that it's a GB Pocket inside the cart. I wouldn't put it past Nintendo to try to break 3rd party peripherals on purpose, but it's just as likely something is slightly out of spec.
Now I remember that when I tested this I also used a third-party link cable (which admittedly looks very cheaply made) since the old DMG-04 cable won't fit in SGB2. I did get Tetris working by resetting both systems, but that won't work with Pokemon.

I recently got a CGB-003 though. It looks like it's in good condition and it appears it has ferrite bead lumps. The old DMG-04 did not.
I guess I'll also test it out one more time with this new GBC cable later.
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Super Game Boy system extensions

Post by Shonumi »

tepples wrote: I guess the fear was that JUMP would halt the clock to the Game Boy CPU.
Exactly what I thought until recently. My line of thinking was that if you're going to be doing something like this, you're potentially handing total control over to SNES code at that point. SGB commands are no longer processed by the SGB ROM (until RAM code finds a way to return to ROM at least). The Game Boy hardware is still passing along data to the SNES' VRAM, but the uploaded code in SNES RAM could alter that however it sees fit. It appears audio is piped from the DMG hardware to the TV, so the SNES can't mess with that directly, but it appears the SNES can mute everything, or play its own sounds via the DSP. You could actually totally do without any Game Boy hardware, depending on the scope.

To me, it just seems like if you're going to issue a $12 SGB command, you're asking for the Game Boy to relinquish most, if not all control to whatever SNES code was uploaded, thus the role of the Game Boy CPU after the $12 SGB command was previously unclear. I'd just figured the Game Boy CPU was halted. Naive, perhaps, but not a totally farfetched idea, considering the SGB has the ability to at least reset the DMG CPU. I suppose one response to that might be "Of course the DMG CPU keeps running. What else would it do? Why assume anything else?" Unfortunately we don't all make the same assumptions. Hence, I prefer stuff like this to be explicit, especially since I do plan on doing some SGB-DMG-SNES hybrid homebrew eventually :wink:
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Super Game Boy system extensions

Post by lidnariq »

I think one interesting factor is that the SGB CPU can't do much to affect the outside world without the SNES's cooperation. It's basically limited to a sound synthesizer and a data server, and on the SGB2, the link port. There's little reason to use the SGB's video output after switching to code running on the S-CPU, because the S-CPU has to start a new DMA every 8 gameboy scanlines to get the current contents.

That said, a GBA-like soundtrack played using the DMG's channels and the SPC700 could be fun. I don't remember that many GBA soundtracks that used both softsynth and PSG sounds at the same time.
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Super Game Boy system extensions

Post by Shonumi »

lidnariq wrote: There's little reason to use the SGB's video output after switching to code running on the S-CPU, because the S-CPU has to start a new DMA every 8 gameboy scanlines to get the current contents.
This is controlled by code from the SGB ROM though, correct? Would it be possible for the uploaded and executed RAM code to simply disable all DMA channels (or even repurpose them) and potentially disable interrupts (to avoid jumping back to ROM code)? I now know of the restrictions on the $12 SGB command, but it seems like RAM code itself should be able to do stuff like that. Of course, I don't know the first thing about programming on the SNES, so I'm curious about it now.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Super Game Boy system extensions

Post by lidnariq »

Yeah, usually the SGB BIOS is waiting to be able to DMA another block of data from the ICD2 chip to the SNES's RAM, and then copies the whole framebuffer to the PPU during vblank. Obviously code in the SNES side could continue doing this ... but it's a lot of overhead, and I can't figure out why it'd be worth doing so.

(8 SGB scanlines should work out to ≈13.4 SNES scanlines; 8 SGB2 scanlines should be ≈13.7 SNES scanlines)
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Super Game Boy system extensions

Post by Shonumi »

lidnariq wrote: Obviously code in the SNES side could continue doing this ... but it's a lot of overhead, and I can't figure out why it'd be worth doing so.
Rather than doing it manually from RAM, I was thinking more along the lines of completely ignoring video from the Game Boy hardware. I was just entertaining the idea that the SNES could be almost entirely independent from the SGB once code and some graphics have been uploaded. With such limitations though, it might be hard to make anything really useful, but the exercise itself would be very interesting.

I'm also messing around with some ideas for homebrew that would really be enhanced by the SGB over a normal DMG. Perhaps, for example, displaying something like a 16-bit color, full-screen still image (and maybe some auto-appearing text) for a brief "cutscene" or two in a game.
Last edited by Shonumi on Tue Nov 12, 2019 9:10 pm, edited 1 time in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Game Boy system extensions

Post by tepples »

lidnariq wrote:[After JUMP, the Game Boy CPU is] basically limited to a sound synthesizer and a data server
So like a slow, bleepy counterpart to MSU-1. Purrrr-fect. That way it doesn't matter whether the player has the Game Boy or Super NES version of the EverDrive if a specially designed ROM is built as an SGB/SNES polyglot: always running from RAM and requesting data either directly from ROM or from the GB data server as appropriate.
lidnariq wrote:and on the SGB2, the link port.
And this... is how I plan to bring an NES into the network. (Once I learn to solder, that is.)
User avatar
Marscaleb
Posts: 240
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Re: Super Game Boy system extensions

Post by Marscaleb »

lidnariq wrote:
What if it just drew SNES sprites on the screen?
See nocash's documentation here:
http://problemkaputt.de/pandocs.htm#sgb ... bjcommands
I'm not technically fluent enough to understand that.
I should clarify that I'm not really looking to program something to do this, I'm just curious about what the system could do.
Could you translate some of that to just tell me: if a game boy game DID try to have the SNES draw sprites over the screen (as if they were sprites within the game) about how would that performance compare to running them as per normal on the GB hardware?
Like, would it actually be more taxing and it could not update as many on the screen each frame, or could it slightly increase performance to do things like avoid some sprite flickering or slowdown, or completely blow the GB's performance out of the water by nearly matching a SNES game, or what?
At the very least, I would assume a game could at least free up some of its CHR memory by having the SNES store its tiles, so it could draw some more detailed backgrounds.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Super Game Boy system extensions

Post by lidnariq »

Marscaleb wrote:I'm not technically fluent enough to understand that.
I should clarify that I'm not really looking to program something to do this, I'm just curious about what the system could do.
So, if the SGB can receive arbitrary code from the cart, anything the SNES can do is in scope.

The only difference is that the SGB provides some convenience functions to do things that people probably already want to do, such as:
* Specify which of four 3-color palettes should be used for each 8x8 region on the TV; the 4th color in each palette is global
* Specify a 13 color master palette (just like NES backgrounds) to colorize the 2bpp data from the GB
* Specify the border contents
* Upload a replacement (or augmenting) soundtrack to the SPC700
* Relay data from SNES multitap
* Draw sprites using SNES's sprite hardware

I'm probably missing a few...
Could you translate some of that to just tell me: if a game boy game DID try to have the SNES draw sprites over the screen (as if they were sprites within the game) about how would that performance compare to running them as per normal on the GB hardware?
There's hardly any DMA bandwidth available if you're still relaying picture data from the SGB to the S-PPU. Uploading a new SGB screen every vblank takes 160*144/4=5760 bytes, and vblanking in NTSC in 224 scanline mode only leaves 350ish for whatever else is being done - not even enough to upload a complete set of new OBJ data.

This bandwidth limit is probably why we've never seen much in this way of a hybrid system.

I wouldn't be surprised if Space Invaders had started out intending to just being a minor cosmetic improvement, and they discovered that the only supported way to do that required porting the game to the SNES. If the SGB BIOS had included an "extended vertical blanking" mode to increase DMA bandwidth, these more-sophisticated modes might have been practical, but I'm not aware of such a feature.
User avatar
Marscaleb
Posts: 240
Joined: Fri Sep 11, 2015 10:39 am
Contact:

Re: Super Game Boy system extensions

Post by Marscaleb »

lidnariq wrote: There's hardly any DMA bandwidth available if you're still relaying picture data from the SGB to the S-PPU. Uploading a new SGB screen every vblank takes 160*144/4=5760 bytes, and vblanking in NTSC in 224 scanline mode only leaves 350ish for whatever else is being done - not even enough to upload a complete set of new OBJ data.

This bandwidth limit is probably why we've never seen much in this way of a hybrid system.
So by "upload a complete set of new OBJ data" you mean it couldn't even update the sprites position on the screen, correct?
Hmm, dang.
I suppose one could try to run a game at a lower framerate (as many game boy games already did) but it sounds like it would be a really tricky process that could crumble if things weren't done right.

The next best idea I could think of is maybe if the game uploaded more game code to the SNES so that the SNES could update its sprites on its own, effectively acting independently of the game running on the GB hardware. And apart from having more noticeable loading times, I can forsee this causing problems if the game the SNES is running ever goes out of sync with the game the GB is running.
Still, I suppose that it would be "technically possible."
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Super Game Boy system extensions

Post by Pokun »

That's exactly what Space Invaders supposedly does, and what Tepples and Lidnariq both described. You upload a SNES program (written in 65816 and SPC700 code) to the SNES RAM and let the SNES Program Counter jump to it and run it from there. The SGB only serves to upload more data to the SNES program from the GB cartridge and can also be used as an expansion audio device (with the whole 4-channel Game Boy APU available!) to mix with the audio from the SNES APU. Since you are running on the SNES you have full control of the SNES hardware like any SNES game do (multitap, mouse, super scope etc included). The only limitation is that the program needs to fit in RAM, since the ROM is the SGB BIOS. Since the SGB BIOS isn't running, I guess things like the SGB menu isn't accessible unless you somehow implement that in the SNES program running from RAM.

To pull this off with both SNES and GB sound you have three programs in 3 different machine code languages: 65816 (SNES program), SPC700 (SNES audio engine) and SM83 (Game Boy audio engine and initial program).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Game Boy system extensions

Post by tepples »

Fortunately, thanks to the effort of blargg and myself, ca65 can assemble all three using macro packs: blargg's SPC700 pack and my ca83 pack targeting Game Boy.
Post Reply