It is currently Wed Aug 21, 2019 4:50 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Feb 08, 2019 11:43 pm 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 39
Location: France, right of a pile of consoles
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.


Attachments:
File comment: Open this ROM in a SGB-capable emulator; a GB emulator won't work. Or run it on a SGB via a GB flashcart.
sgb-testing.gb [32 KiB]
Downloaded 237 times

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
Top
 Profile  
 
PostPosted: Sat Feb 09, 2019 10:30 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 972
I had used a SGB with gameboy flashcart in my first attempts to run code on SNES, too.
ISSOtm wrote:
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.
Okay, then I should change this...
Code:
SGB Port 600Fh - Chip Version (R)
  7-0  ICD2 Chip Version
Seems to indicate the ICD2 Chip Version. Known values/versions are:
  21h = ICD2-R (without company logo on chip package)
  61h = ICD2-R (with company logo on chip package)
  ??  = ICD2-N (this one is used in SGB2)
The versions differ on reading unused/write-only ports (see notes in SGB I/O map).
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?
Code:
On ICD2-R chips with [600Fh]=61h, that garbage is:
  CPU Open Bus values (though, for some reason, usually with bit3=1).
On ICD2-R chips with [600Fh]=21h, that garbage is:
  6001h.R, 6004h-6005h.R --> mirror of 6000h.R
  6003h.R, 6006h-6007h.R --> mirror of 6002h.R
  6008h-600Eh.R          --> mirror of 600Fh.R
On ICD2-N chips, that garbage is:
   Unknown.


Top
 Profile  
 
PostPosted: Sat Feb 09, 2019 11:10 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 39
Location: France, right of a pile of consoles
nocash wrote:
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.

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

nocash wrote:
And did you test the garbage in unused/readonly registers, too?
Code:
On ICD2-R chips with [600Fh]=61h, that garbage is:
  CPU Open Bus values (though, for some reason, usually with bit3=1).
On ICD2-R chips with [600Fh]=21h, that garbage is:
  6001h.R, 6004h-6005h.R --> mirror of 6000h.R
  6003h.R, 6006h-6007h.R --> mirror of 6002h.R
  6008h-600Eh.R          --> mirror of 600Fh.R
On ICD2-N chips, that garbage is:
   Unknown.

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.

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Sat Feb 09, 2019 7:39 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 972
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).
Code:
  CPU2 SGB-R-10  Super Gameboy (1994) (more common)       ;with ICD2-R
  CPU2 SGB-N-10  Super Gameboy (1994) (not so common)     ;with ICD2-N
  SGB1-EVA2      Super Gameboy (1994) (rare prototype)    ;with ICD1
  SHVC SGB2-01   Super Gameboy 2 (1998) (with link port)  ;with ICD2-R


Top
 Profile  
 
PostPosted: Sun Feb 10, 2019 1:55 pm 
Offline

Joined: Fri Oct 24, 2014 1:56 am
Posts: 82
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.


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 1:57 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 39
Location: France, right of a pile of consoles
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

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Sat Feb 16, 2019 1:30 pm 
Offline

Joined: Fri Oct 24, 2014 1:56 am
Posts: 82
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.


Top
 Profile  
 
PostPosted: Sun Feb 17, 2019 5:51 pm 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 39
Location: France, right of a pile of consoles
Hmm, this implies detecting the firmware version isn't trivial. I'll have to look further into it.

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Sun Apr 28, 2019 8:32 am 
Offline

Joined: Thu May 28, 2009 12:17 pm
Posts: 27
any update?


Top
 Profile  
 
PostPosted: Wed May 01, 2019 7:05 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 39
Location: France, right of a pile of consoles
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.

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Wed May 01, 2019 7:09 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21559
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed May 01, 2019 7:24 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 39
Location: France, right of a pile of consoles
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?

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Wed May 01, 2019 7:43 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21559
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed May 01, 2019 11:31 am 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 583
Hrm...

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


Top
 Profile  
 
PostPosted: Wed May 01, 2019 12:48 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21559
Location: NE Indiana, USA (NTSC)
B00daW wrote:
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group