The Sega Saturn NetLink League

Hello everyone. This is my first post to this board although I've been lurking around for a while. I was a SNES XBAND player (mostly KI, some MK3 and SMK) back in 96. Those were some great times.

I'm wondering about how much progress has been made (if any) in figuring out the communication protocols for XBAND. Searching on Google has proven mostly fruitless. The only information I could find was some vague reference to it using the ADSP protocol of AppleTalk. I also managed to get my hands on what appears to be the source code for the Genesis XBAND server. Unfortunately, there appears to be quite a bit of code missing for it including all of the transport layer stuff. So for now the server code isn't much help at all.

So anyway I tried having the XBAND modem connect to the modem in my computer. Once the connection is established, the modem does nothing but sit and wait. I transmit a carriage return (although it seems that any byte will do) and the XBAND responds with a sequence of 26 bytes (and the text on the TV changes from Dialing... to Connecting...). The XBAND repeats the sequence about once per second a few times before giving up and disconnecting.

Here's what it sends (in hexadecimal):
00 81 40 00 00 00 00 00 00 00 00 04 00
81 01 00 00 00 00 00 00 00 7C 39 10 03

The bytes I highlighted in bold seem to change whenever I repeat this experiment. I could not find a pattern to these changes nor could I get the XBAND to repeat the same bold byte values in subsequent trials.

I have a copy of Inside AppleTalk which explains the DDP (network) and ADSP (transport) protocols. Each of these use a 13 byte header followed by 0 or more bytes of data belonging to their respective upper layers. So the fact that the XBAND transmits 26 bytes seems appropriate.

Now one would expect that the XBAND is either trying to log in or acquire a network address of some kind, or establish an ADSP connection if neither of those things are required (i.e. if the XBAND assumes that it always gets the same known network address).

Unfortunately, the bytes that the XBAND is sending don't make sense with respect to the way Inside AppleTalk describes these protocols. If these bytes represent a DDP datagram, then the second byte and the last 2 bits of the first byte represent the length (including the 13 bytes of the DDP header itself), which is 26 bytes, but in the example above, the value is 129. Furthermore, if the datagram contains a ADSP connection attempt, then the last byte should be $81 or possibly $83, but the value is $03.

So this is what I've been able to do so far. Not much learned yet, but I'm hoping that some collaboration here will lead to some progress. I hope there is someone who has tried to analyze the XBAND rom code and might have some insight to offer.

Thanks for reading.

how did you manage to get that source code???

More importantly, where did you get it? If it's what Krazy (or whatever his username is on that other site) posted, he got that from certain members of this site.

What we had involved very little server code as well, because the member of the team that gave it to us couldn't give us most of it... that technology (or a derivative of it... or at least the patent for it) is still owned by other companies and some of it might still be in use today. The information we had also talked about its similarities to AppleTalk. This is why I suspect that you downloaded the files that Krazy shared. Which I'm still somewhat upset about - he didn't have permission to redistribute that code due to an agreement with that original team member.

I don't remember exactly where I got it, but I found it through a Google search. It's probably the same code you're talking about.

Like I said, it isn't much help right now since it's incomplete and has nothing for the transport layer. It also has nothing about the SNES version either, and for all I know, the SNES version may work nothing like the Genesis version.

It looks like the only way we will figure out how to get these things working again is through reverse engineering unless we can get our hands on some more source code. That's why I've started experimenting with it. I know I don't have anything useful so far, but if we're going to make any progress, we have to start trying stuff and document our findings.

I remember back in the 90s when SNES emulators didn't have sound because nobody knew how the sound chip worked. It took a lot of hard work, but eventually people figured it out. I believe that it can be done for XBAND as well.

That sounds pretty much a match for what we had - there were a few Genesis finished and unfinished patches in there along with other assorted code and compiling software. You probably did get it from the Krazy leak. Most of our progress and research was on the SNES version, however, despite the lack of code.

For the most part, nothing you've said so far is stuff we didn't know about - we knew it would take heavy reverse-engineering to figure out both the server protocols (along with what services the server would have to provide and how it provided them) as well as the game communication protocols. None of us had a telsim to actually get the modem to connect to the computer, but we realized we'd run into that same issue - we'd eventually hit a point where the XBAND required data from the server before it would continue. After all, the XBAND is only part of the whole XBAND network. It's a matter of finding that line where the XBAND ended and the server began.

If you can start reverse-engineering the server, good for you. As I said in another thread, I'm working on a different, semi-related project right now - one that I feel is more important in the long run - so I'm not planning to devote a lot of my attention to this right now.

If you don't have time to help work on it, that's ok. However, any existing knowledge you can share would be helpful.

A couple of things I can share.

First, you don't really need an expensive commercially made telephone line simulator. All you really need is about $10 worth of parts to make the loop current circuit and a modem with voice command capability.

The voice commands I use for the modem are:
at+fclass=8 (puts modem into voice mode)
at+vls=1 (takes the modem off hook and listen for dtmf tones)
at+vts=[350,440,250] (plays 350 and 440 Hz tones for 250 centiseconds, i.e. a 2.5 second dial tone)

Then once the XBAND has dialed and waiting for an answer just do:
atz (reset the modem back into data mode)
ata (answer the call)

The XBAND will connect at 2400 bps, v.22bis modulation, no error correction or data compression. Any modem made in the last 20 years should support v.22bis. The only real limitation is that there's no way to send a ring signal to the XBAND.

Heck, you don't even necessarily need voice capability in the modem as you can just use a splitter to hook up a telephone and play a dial tone into the microphone.

Second, I've been scrounging around the internet looking for more information. It seems that a guy who goes by the handle neviksti had made a lot of progress, but he seems to have abandoned his efforts some time ago. He didn't post all the details of everything he discovered either, but there is plenty to work with.

One problem neviksti seemed to have was not knowing how ADSP worked or where to find documentation on it. I can help there. The following pdf explains it all. The chapter on ADSP starts on page 286.

http://web.archive.org/web/200812031241 ... leTalk.pdf

neviksti did find that the XBAND does not use a packet-switched network layer at all but instead encapsulates ADSP segments in a bisync protocol. With that, I now know what the bytes I posted above mean.

00 (start of message byte. the XBAND doesn't care what this value is so long as it's there which probably explains why I can get a response when I send one byte)
-----
81 40 00 00 00 00 00 00 00 00 04 00 81 (13-byte ADSP header, source ConnID $8140, 1kB receive window, open connection request)
-----
01 00 00 00 00 00 00 00 (this is also part of the ADSP open connection dialog. See page 314 for details)
-----
7C 39 (checksum for bit error detection)
10 03 (DLE + ETX ASCII characters indicating end of message)

The major issue I have right now is that I don't know what the algorithm is for the checksum. In the example above, CRC-16 produces the right value, but that's only a coincidence. Further experimentation proved that it's not CRC-16. It's also not the checksum algorithm that Apple uses for DDP. neviksti claimed to have figured out the algorithm, but he didn't share any details.

So that's where things stand right now. I need to know that checksum algorithm so that I can send data that the XBAND will accept. If anyone already knows the algorithm, please share.

Unfortunately, I can't offer much help, but I have had some experience buying Telephone Line simulators for fairly cheap off eBay (incidentally, for connecting the Dreamcast Dial-Up Modem to Broadband internet to play online w/o having to cough up $150+ for the BBA...). Anyways, if you just do a search for Telephone Line Sims there's a few different brands, so I'd guess you'd have to make sure you're getting what you want, but it looks like you can get one for $50 or so. I prefer the Teltone tls line, they seem to me anyways to be one of the best (although since you're not trying to use them to connect to the internet, you wouldn't really need the best), but if you keep an eye on this eBay search, I usually see a decently priced one go up ever couple weeks. All the Buy It Nows are always way too expensive (although there is one for just under $100 now), its the auctions you'd want, and you'd want to look for the tls2 or tls3 (the tls4 and tls5 have two talk channels and are thus much more expensive). I've gotten a 2 and 3, both for $50 - $75 - the tls3 works great and the tls2 I got seems to kick in and out, but that'd be find if you're just using it for testing.

I did some short testing on this a long while back prior to the leak with krazystyle

Esentially if its got a dead battery (modem) and the sram is wiped its sending the user profile (1 of the 4 spots, username, if its a new user, pw, ect ect) use a line sim or dial into a terminal and watch the plain-text spit out. i was able to actually get some english out of the thing and compare with what was in some of the source code i had. seems its sending basic details to register with the server and then the number of the "box" as catapult called it or serial number of the xband modem for english speak.

As for the algorithm on the checksum i cant really help. i wish more was listed in the source code about this but doesnt seem to be... you could try getting ahold of the orirginal catapult developers possibly. Mainly konstantin othmer, however he is a very busy man and hard to get ahold of.