Howdy,  I need a sanity check on a project here and hopefully someone can oblidge (or offer advice).  All this should take is a pair of good eyes, but advice from a hardware person would be appreciated as well.

I'm trying to hack the XBand rom to let me directly connect to another to play games (basically, skip the now defunct call center / server).  However, I'm having trouble figuring out how this thing even works solely looking at code.  I decided to sit down and trace out what all the main control chip connects to so I get a feel for what is possible / impossible (and also help me make educated guesses of what is going on).

I eventually figured out what every pin does except one ... it seems to control a transistor which controls ... well, nothing.

Some pictures are available here:
http://www.snescentral.com/article.php?id=0067

The chip I'm interested in at the moment is the FredIIH.  The pin in question is pin 37 (pins are labelled counter-clockwise from bottom-left corner).  If you don't feel like counting, pin 37 is connected to the middle trace of the three trace 'group' coming out of right side of the chip.

What I see is this:
I checked and there is no trace that goes under the chip from pin 37.
Following trace away from pin I see it go through board (right below R18),
then it goes and connects to base of transistor U9,
it continues on and goes through board again,
this goes through resistor R206 to Vcc (top of C15) ... since this is Vcc it goes elsewhere of course

emitter of U9 -> GND
collector of U9 -> NoWhere!?!?


Please can someone sanity check this?  Am I missing something obvious?  Any ideas?
I really don't know what is going on with this pin.

That would be great! 

I am not a romhacker by any means, and so therefore often get side tracked trying to understand some code that turns out not to even be useful.  Years back when I looked into this, my goal was to understand the protocals and write an XBand server for the fun of it.  That didn't get finished, and I definitely don't have time to try that again.  Sure I'd love to understand how everything works, but goals now are more along the line of:

    1) figure out how to bypass connecting to the server and jump straight to being setup to play and "waiting for opponent"  (supposedly, if the server couldn't find you anyone to play with immediately it would just hang up and tell you to wait and then have another player's modem call you directly ... so figuring out how to force this "wait for opponent" mode would be great)

    2) figure out where the patches are, and how they work

(Actually, according to this http://saturnleague.com/board/viewtopic.php?p=1032#1032 , if you get step 1, you can already play games with people for reliving the fun and awe of this amazing engineering feat.)
In case it would be useful, I made some small rom hacks to allow Sleuth to consider "Super Mario Cart" or "Weaponlord" or "nothing" is attached in the external cartridge slot.


As for looking at the code:
This is one of the rare SNES programs that was written in C.  All the stack frames and local variables take a bit getting used to.  Also, they wanted to be able to update the system as the service grew.  So there is a "dispatch system" which sends many requests through tables in the SRAM... this allows the operating system to be easily updated. (It also let us easily enumerate what they felt were common/important routines.)

The XBand also has a built in "debugger" (really just a kind of memory viewer) that I can show anyone how to activate if they'd like to play with the memory map on the real system and don't have a copier. (Actually, anyone with an XBand and working SNES can probably help out here, I can explain what to do if you have no technical experience ... it's just reading, recording, and comparing many things on the screen.) This device is like an ultra-game genie with a modem attached.  The direct modem access is obvious given the datasheet and memory map, but I haven't figured out even the base features of the "patcher" part yet, but hopefully that will come later.

Here's my current understanding of the memory map to help out a bit:

For those wanting to follow the code even tighter, the modem is a  RC2424DPL, and datasheets are available online.  Be wary that, due to how everything is wired up, there probably is a FIFO for transferring data once the connection gets going... I don't know which regs these are. (Setup stuff all uses direct modem access though.)

One important thing I learned while pin mapping is that the controller chip does not use the A0 address line, and controls all other address lines to the ROM and SRAM.  So it can't "trigger" patching on an opcode (sort of like game doctor sf7), but instead probably maps in whole sections of SRAM after certain address triggers.  I was told by an employee of Catapult that they remember the device being able to handle 16 such trigger points or regions or however this thing works.  They used the word vector so I'm guessing specific addresses trigger it, but who knows for sure.

The code usually only uses banks $00, $Dx,$E0 and stuff in $FB:C000-C1FF.

I've recently ran across across it writing to stuff at $004fxx, $FFC000, and $FB:FExx ... no idea at the moment.

For the hardware curious, here's an example of controlling mapping the cartridge in, copying some data to identify the cartridge later, and then returning to the normal mapping (this is all ran from WRAM):


Notice:
24bit pointer $fbc070 = #$007800 = #$00F000 / 2 (because no A0 line)
Of course that may just be a conincidence.


If it somehow becomes important to understand the communication protocal, I can explain what I've learned so far.  (There can be an initial identification transaction, and then everything after that uses a kind of packet system which has a couple layers... I understand the base layers okay, but it gets fuzzy after that.)  There is also a way, with a button sequence, to go to a "service mode" which waits for incoming calls for diagnostics.  That may be another means to figure out the protocal if necessary.

Yep, that's it.

Oh, I had no idea there was a standard.  I'm basically self taught, and thought it was just a loose convention (I've seen Q, T, and U all refer to transistors before).  Due to the package and E,B,C labels I really thought this was a transistor.

But yes, you are correct!
I was hoping I was blindly overlooking something simple! Thank you very much.
The ink appears to have worn off (or was black!?).  But if I tilt it just right, I can read some stuff on it due to a difference in reflectivity.

DS2401
This is a really neat little piece.  I never new such a thing existed (but in retrospect the demand for such a device makes sense).

"The DS2401 enhanced Silicon Serial Number is a low-cost, electronic registration number that provides an absolutely unique identity which can be determined with a minimal electronic interface (typically, a single port pin of a microcontroller). The DS2401 consists of a factory-lasered, 64-bit ROM that includes a unique 48-bit serial number, an 8-bit CRC, and an 8-bit Family Code (01h). Data is transferred serially via the 1-Wire® protocol that requires only a single data lead and a ground return. Power for reading and writing the device is derived from the data line itself with no need for an external power source."

Neat!

It really appears that way.  And makes sense now that I see the datasheet of the actual part.  I wonder why they labelled it that way?  None of the transistors on the cartridge even have E,B,C labelled.