Efforts to come

[Xranger60]

Hey Neviksti! It's great to have you around here, I was afraid you'd completely dissapeared from the scene altogether, and Cherryrom has been down. I thought I'd let you know that whatever work you've done on the project has been appreciated very much, but I understand there are lots of other things that demand your attention first so don't feel any pressure or anything.

Aside from that, if there's anything we can do to help, let us know. I'm sure we can make something happen if we all pitch together on this. I've got a landline phone at home that could be used for testing. Also if you'd like to upload anything I've created a section specifically for this under downloads that you can upload to. Welcome aboard!

[neviksti]

Aside from that, if there's anything we can do to help, let us know.

The two biggest things I listed in my previous post. Basically:
1) follow up on rush6432's comments/contacts (for specifics refer to my previous post)
2) help find programming info on that AppleTalk protocal (for specifics see below)

#1 is by far the most important.

=============================================
The communication protocals they used were apparently several layers of standard protocals. As mentioned, I'm having trouble finding detailed "implementation level" information on some of the protocals. Since they are standard protocals, we should be able to find something. Help here is much appreciated.

The protocal I'm stuck at now is called: AppleTalk ADSP (Appletalk Data Stream Protocal)

[neviksti]

For those that want more details (and to better explain the current status), here is a copy of an old post about the communication protocals. Not much progress has been made since then.

Here's what a packet looks like:

--------------
"IBM's BiSync" like framing
special characters:
STX = start of text / data = $02
ETX = end of text / data = $03
DLE = data link escape = $10

packet looks like:
STX ...data... DLE ETX

Any DLE characters in the data itself are "padded" with an extra DLE.

The code seems to ignore the STX character (doesn't even check it), but it does expect a character there.
---------------
The data in that last packet structure is actually a crude AppleTalk like packet.
(I've been told they used a form of ADSP, and have also seen interviews where people have re-iterated this as well.)

this "inner" packet looks like:
ADSP header ...data... crc

The crc is a checksum of all the packet data before it, INCLUDING the STX character, and the ADSP header, and BEFORE padding the data with any DLE characters.

ADSP header, $0D bytes long
how the code treats the data -
(word), (two dword entries - treated as a pair?), (word), ?flags? (byte)

header data is in network byte order (most significant byte first)
--------------------------------

As for the actual data itself, I've only looked at the server mode (not game mode) stuff so far. It looks like the server controls everything. It basically sends a command and parameters which the X-Band then executes and responds.

I found the crc algorithm in the ROM, and it is easy to follow.
As for the ADSP header stuff, and actual data handling ... I know where the "main controlling routine" is for this. But it calls many routines and I'm getting lost trying to understand everything.

Googling for a bit-level explanation of the ADSP header has not turned up anything useful. I obviously haven't hit upon the correct keywords to search for.

Anyone that can help me understand this header by looking for info ... it would really be appreciated. We're getting closer!
================
EDIT:

Okay, this seems to explain what is in the ADSP header:
http://www.lex-con.com/protocols/apple.htm

Source Connection ID, (Send Sequence Number, Receive Sequence Number), Receive Window, Descriptor

Here's some other pages:
http://www.networksorcery.com/enp/protocol/adsp.htm (has the RFC)
http://www.protocols.com/pbook/appletalk.htm#ADSP (not much better info, but explains what the receive window means)

Still nothing that explains the bits (not even the RFC? Am I missing something obvious?).

EDIT(2):
Okay, found more:
http://darcs.brianweb.net/vendor/powerp ... tat/adsp.h

I don't really understand it right now. I think I'll get some sleep and read it again tomorrow.

I don't currently understand the sequence of events necessary to "establish a connection" (nor how much of this the BIOS code actually implements, but since this was meant to be cross platform, they probably implemented all the essentials to conform with the protocal).

EDIT:
I found source code for the appletalk library Apple uses.
http://darwinsource.opendarwin.org/10.0 ... bsd/netat/

If someone could fish through this and summarize the important ADSP structures, flags, and connection sequences ... it would be a great way to help out.

In the mean time I'll dig through the BIOS disassembly and see where I left off.

[rush6432]

From what i understood, it was basically during each VBLANK (Screen refresh), there was a routine that would grab all the data from the joypad (if anything was pressed) and then send it to the modem hardware out through the lines. as far as the header and how it was coded i know nothing more. the xband was used like you would use a game genie. basically slap your game on, it gets the patch either when you update for the daily news for the day or to send an email, then that patch is applied to the game when you play against someone, it inserts itselft into the vblank of each game and grabs the controller input and sends it to the opponents xband and updates info and does the same back and fourth the entire game. now ive tried contacting the guy about the source for the snes, no luck, he says he thought he had it but doesn't anymore. so i think source code at this point is lost. the only game i know of thats hard coded to work with xband is weapon lord for snes and sega. thats about it............we do know if we got the code sequence to work right and the xband modems to connect that weaponlord would work..

[neviksti]

now ive tried contacting the guy about the source for the snes, no luck, he says he thought he had it but doesn't anymore. so i think source code at this point is lost.

Which one were you talking to? I think kon is the one that knows where most of the stuff is at this point. If you could get ahold of him, that is probably our best bet. Those header files would be so very very useful.

Also, have you ran across the guy who worked on the hardware (the chip was nicknamed FRED if that means anything)? Because, of the employees I talked to several years ago, none seemed to know (or at least remember) how the patcher worked. They load into some hardware registers the addresses (basically it sounds like "breakpoints") at which the patching mechanism triggers. Then what? Does it create a BRK/IRQ and switch memory modes to map in the XBand interrupt code instead of the cartridge code and handle it from there? I'm completely guessing, as this would allow the most flexibility for least amount of hardware. No one I talked to could remember how it was designed ... I figure the hardware guy, who poured his hardwork and sweat into it, will probably remember.

---------------------
In the worse case (the XBand employees can't remember enough or find anything) the only other option is to continue on our own.

As mentioned above, if someone could wade through the ADSP source code (linked in previous post) and summarize the important ADSP structures, flags, and connection sequences ... it would be a great way to help out. Is anyone willing to help with that task?

[Overwatch]

If you could put progress into percentage form what would that number be?

[Xband411]

Ok, check out this Xband Employee Roster and tell me who I should hunt down and what exactly I should say to them:

http://web.archive.org/web/200108151424 ... oster.html

[neviksti]

Ok, check out this Xband Employee Roster and tell me who I should hunt down and what exactly I should say to them:

http://web.archive.org/web/200108151424 ... oster.html

Just write them a note saying you heard that they worked on the XBand and is this true? And then mention some fans are trying to figure out how the system worked (and maybe even gets parts of it to run purely for nostalgia purposes). Then say you're curious and ask if it would be alright to ask some questions about the XBand. Whether you want to shove some questions at the end there or see if they respond first... I don't know. Whatever you think is best.


Matt Hersenson (Hardware Engineering)
- Ask him what he remembers about the XBand.
- Ask him if he worked on the SNES FRED chip, or does he know who did?
- What all did the FRED do?
- How did the patching system work?
- Ask if he happens to have any files explaining the locations and names of the hardware registers on the XBand cartridge (SNES or otherwise).


Konstantin Othmer (EVP Product Development)
- Ask him what he remembers about the XBand.
- Ask him if any of the original source code still exists (or can point us to who might know).
- Ask if the fans could buy the source off of them, or if it can't be sold, can we have the header files to help us understand the structures (it wouldn't give us the actual code, so it might be a good compromise).
- Ask if he happens to have any files explaining the locations and names of the hardware registers on the XBand cartridge.

The questions about the source code are of course the big touchy questions. I'm not sure the best way to approach such questions. But definitely be a fan asking a favor (and of course don't outright demand anything).


ANY of the "game crackers"
- Ask him what he remembers about the XBand.
- Ask if they worked on the SNES games (since that is the hardware we've started work on, of course their input is still helpful otherwise, but we won't be able to use it immediately).
- Ask if they remember how the hardware worked
- Even more specifically, how did the patching system work.
- Ask if he happens to have any files explaining the locations and names of the hardware registers on the XBand cartridge.


It looks like that contact list is quite old, so that will probably be a lot of work. But whatever you have time to do would be greatly appreciated. Nothing can help get this working like real info from real employees.

I wish you great luck, and thank you.

[Xband411]

Ok, I just fired off emails to Konstantin Othmer and Matt Hershensen's companies asking for a way to get in touch with them (neither had their email address listed for obvious reasons).

On Saturday, I'll work on firing off emails to every game cracker that I can. I'll post any results that I find here.

[neviksti]

Thank you very much!
Any luck so far?

[Xranger60]

Neviksti, I may undertake the task of wading through that source code for you, if i can do it without much code experience. But look at this:

For the record, I don't consider a month and a half wait a double post.

(Oz, if you want to clean this up, and/or put this somewhere, maybe sicky it, that'd be awesome, especially since I don't remember the menu structure on the Xband)

As for "Spoofing" the modem into calling someone directly...

1> Check your Phone Options (?), and select "Do not wait for dialtone".

2> Leave the dial in number as is.

3> Plug your phone line (people still HAVE these things?) into the Xband, if you haven't already.

4> Pick up phone, ON THE SAME LINE (pick up a phone line splitter if you have to, they are about $3, or make one yourself, it's only CAT-3), dial your friend.

5> Dial your friend's HOME phone number.

6> Your friend should select "Wait for Incoming calls" (?) while you are performing step 5. IM or cell phones are great for setting this up.

7> After you finish pushing the last digit, tell your Xband to connect and look for players.

8> Enjoy (hopefully, I'm doing this from 10 year faded memory).

If anyone wants to test this, let me know what I did wrong.

Screen caps are great for this.

That was taken from Xband.com. Any thoughts on the feasibility of this?

[neviksti]

Neviksti, I may undertake the task of wading through that source code for you, if i can do it without much code experience.

That sounds great!
It would be good to know the sequence of setting up a connection, and how any acknowledgements (or requests to resend) work during normal connection state. Basically, I don't know how this protocal works at all.

Also, pointing out some of the important datastructures for the packets, and any special values/flags in the packet headers would be nice.

But whatever you have time to do is of course appreciated

That was taken from Xband.com. Any thoughts on the feasibility of this?

From what I know of the higher level protocal, that sequence doesn't sound very plausible to me. However, we haven't figured out the details of the command structure, so maybe it could work. (It would be a shame to declare it incorrect without at least giving it the benefit of the doubt and trying it.)

If there are two people with XBands, they should definitely check it out. Any takers?

[PorkNBeans]

Man I wish you guys the best of luck, I would love to be able to pop my Genesis Xband in and play again.

[mjshopgames]

it would be nice to be able to play SNES and Genesis games with other people!!!! I would be on it every day!!! I hope you guys get it to work and i wish you the best of luck!!! Keep at it!!!! You will make some people very happy!!! I never got to play online with my sega genesis and super nintendo and i didn't even know there was such a thing until i looked at this website and now i am looking forward to hopefully playing my super nintendo and sega genesis online!!!

Good Luck

[Overwatch]

Has anything new happened on this topic?