Super Game Boy system extensions
Re: Super Game Boy system extensions
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.
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.
Re: Super Game Boy system extensions
I don't know how to describe that... the gameboy cpu won't vaporize after sending the jump-command packet?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.
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
Re: Super Game Boy system extensions
I guess the fear was that JUMP would halt the clock to the Game Boy CPU.nocash wrote:the gameboy cpu won't vaporize after sending the jump-command packet?
Re: Super Game Boy system extensions
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*
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.
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.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.
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.
Re: Super Game Boy system extensions
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.tepples wrote: I guess the fear was that JUMP would halt the clock to the Game Boy CPU.
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
Re: Super Game Boy system extensions
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.
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.
Re: Super Game Boy system extensions
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 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.
Re: Super Game Boy system extensions
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)
(8 SGB scanlines should work out to ≈13.4 SNES scanlines; 8 SGB2 scanlines should be ≈13.7 SNES scanlines)
Re: Super Game Boy system extensions
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.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.
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.
Re: Super Game Boy system extensions
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:[After JUMP, the Game Boy CPU is] basically limited to a sound synthesizer and a data server
And this... is how I plan to bring an NES into the network. (Once I learn to solder, that is.)lidnariq wrote:and on the SGB2, the link port.
Re: Super Game Boy system extensions
I'm not technically fluent enough to understand that.lidnariq wrote:See nocash's documentation here:What if it just drew SNES sprites on the screen?
http://problemkaputt.de/pandocs.htm#sgb ... bjcommands
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.
Re: Super Game Boy system extensions
So, if the SGB can receive arbitrary code from the cart, anything the SNES can do is in scope.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.
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...
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.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?
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.
Re: Super Game Boy system extensions
So by "upload a complete set of new OBJ data" you mean it couldn't even update the sprites position on the screen, correct?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.
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."
Re: Super Game Boy system extensions
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).
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).
Re: Super Game Boy system extensions
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.