Using SGB as a makeshift SNES flashcart

I have finished developing a small utility ROM that displays the SGB ICD2 version number, SNES PPU1 and PPU2 versions.
It's very rough, intentionally displaying a lot of garbage. I've made it so it uses only the space games use for patching, as I'm not completely certain of the portability of other memory locations. This severely limited size and features.

This is the first step I'm making towards using the SGB to run SNES programs; the next step is uploading larger programs to SNES WRAM, and using the GB as a coprocessor (output can be forwarded from GB CHR RAM to the SNES; maybe a DMA setup could help?)
Also I just realized it should be possible to display the program on-screen, transfer a small loader stub (it looks like there are several places where the framebuffer is located, I'm not sure we can just JUMP), then execute the transferred code, which will probably "download" compressed code/data from the transmitted screen tiles, decompress to SNES WRAM, and go!


In theory this only allows programs up to the size of the SNES WRAM (and assuming no WRAM is used as data), but we have the GB, which can function as a coprocessor / slow data storage.
The most efficient IO from the GB to the SNES is simply its VRAM, and the SNES can send up to 4 bytes of joypad data to the GB at a time, kinda like the SPC; the Game Boy is also able to send command packets, but they have to be sent by slowly bitbanging serial, and nocash's docs imply only one packet can be read at a time, so I only see it as a possible side channel to "respond" to SNES commands, sending a SGB packet to notify data is ready to be read from the GB rendering.

Speaking of fullsnes, LIJI32 tested this ROM on his SGB2, and it reported "2111", so now we know the ICD2-N chip version is 0x21.

I had used a SGB with gameboy flashcart in my first attempts to run code on SNES, too.
Okay, then I should change this...
by replacing "??" by "21h", giving ICD2-N the same ID as the logo-less ICD2-R. Yet a different value would have been more intersting. Hmmm, are you sure that the SGB2 contains a "ICD2-N" chip? I don't know for sure if that's the case in all SGB2's.

And did you test the garbage in unused/readonly registers, too?

Interestingly, none of gekkio's gbhwdb entries have one.
I've asked LIJI if they can confirm.


I did not. The program uploaded is currently limited to a little over 90 bytes (more or less what's allowed by the region used by game hotpatches, afaik), since I wanted something that was guaranteed to run; I will create a memory viewer/test ROM soon to check that.

Looks as if I was wrong about ICD2-N being used on SGB2. However, the chip does exist on some older SGB boards. And there's also ICD1 chip on SGB prototype boards. I have found 4 different boards, and 3 different chips. Or maybe there are even more boards, with different -10 or -01 revision suffix. And maybe more chips (some have some odd symbol after the -R).

I have a bunch of SGB boards. I have at least a couple of each chip type.

An example of the markings for each type:

ICD2-N 21
[Nintendo oriented to bottom of cart]
Nintendo
ICD2-N
9421KP205
D93115

ICD2-R 21
[Nintendo oriented to bottom of cart]
Nintendo
ICD2-R
9429KP214
D93218

ICD2-R 61
[Nintendo oriented to left side]
Nintendo
ICD2-R Symbol
435 161

The orientation of the chip markings seem to correspond with whether the chip returns 21 or 61.

I know of three version of the SGB firmware (SGB1v0, SGB1v1, SGB1v2), I wonder how those map to the ICD2 revisions (I'd assume they do?).

Eventually I'll complete my SGB1v2 disasm, then I'll be able to focus on comparing with other firmware revisions. Given the existence of JUMP and DATA_* packets, I'm expecting at least memory layouts to be similar, but I can't be sure yet

Looking at the SGB boards that I have readily available:

ICD2-N boards have SYS-SGB-NT or SYS-SGB-1.

ICD2-R (21) boards have SYS-SGB-2.

ICD2-R (61) boards have SYS-SGB-NT or SYS-SGB-2.

SYS-SGB-NT = v1.0
SYS-SGB-1 = v1.1
SYS-SGB-2 = v1.2

This isn't a comprehensive list. This is only based on my small sample of boards. BTW, majority of my boards are ICD2-R (61) with SYS-SGB-2.

Hmm, this implies detecting the firmware version isn't trivial. I'll have to look further into it.

any update?

School and other obligations meant I haven't had time so far to progress my SGB firmware disasm or work further on this. It's still a thing I want to do, but there are also a lot of those; that said, I'm not the only one interested, so maybe someone else can pick up my efforts.

I'd like to pick up your efforts if I get time, but I couldn't find anything relevant to fork on your GitHub repository list.

That's because nothing has been published; the disassembly IDB and my (admittedly pretty botched) GB+SNES code are both sitting on my computer. Do you want me to upload those?

Mostly I'd like to see the GB+SNES code, so I can at least have something to look at to get "Hello World" up, plus whatever WRAM regions in $7E0000-$7FFFFF you've identified that appear completely unused so I know where I can safely DATA_TRN before a JUMP.

Hrm...

Could you essentially switch in-between GB and SNES modes? Or could you have a transparent SNES mode overtop the GB display?

The ICD2 chip receives a stream of pixels from the DMG CPU, formats them as tiles in GB/SNES 2bpp format, and sends 160x8-pixel (320-byte) strips to the S-CPU through DMA. As I understand it, one strip is produced once every 5*456*8 = 18240 master clocks, or 18240/1364 = 13.37 S-PPU scanlines, except during vblank. (It's slightly slower on the Japan-only SGB2.) If the program sent to Super NES WRAM keeps receiving these strips to a double buffer in WRAM and blitting them to VRAM, then the strips can be used as any layer of mode 0 or the third layer of mode 2. However, it'd be very tricky for the Super NES program to do anything involving HDMA because S-CPU version 1 behavior is undefined if a DMA finishes too close to HDMA.

My GB code is uttely bad, for a fairly unique but stupid reason: at some point the SD card I was using to feed my flashcart GB ROMs ceased working, so I kept running the same (at the time broken) ROM. SO I ended up fixing problems and things that weren't (to my great confusion). Since I wasn't planning to use a VCS by the time I realized this, I was left with very very botched code.
As for the memory map, I thus fell back to areas I knew were correct, ie. the small regions used by games to hot-patch the SGB firmware.

That said, I have identified other buffers that are most certainly free, though I am unsure whether their location is preserved across firmware revisions.



Things of interest:

Unsurprisingly, the SGB runs in Mode 1. BG1 is used for the menus and custom drawings, BG2 for the border, and BG3 for the GB screen.