The #SNES (and SFC) #XBAND modem is one of the few cases where you can somewhat accurately say every copy is personalized. They have DS2401 serial number chips, guaranteeing each one has a unique hardware ID on XBAND.
But there is a problem with that.
(thread)
The problem is that the original Genesis version of XBAND doesn't have this hardware ID. XBAND needs a persistent, unique identity to work properly, so how do you do that on a Genesis modem?
That requires a bit of background. All versions of XBAND have persistent storage in the form of battery-backed SRAM. Upon first connect, the server will program the modem with a unique ID that it generates, and it uses that to identify the modem. But that's not perfect...
In some cases, the data in SRAM could be lost, due to corruption or a dead battery. The server can restore this data, but how do you know whose data to restore? On SNES/SFC you have the hardware ID, but if Genesis loses its SRAM, the ID would be lost too.
And this brings us to the topic of phones. And 800 numbers. And long distance. And CompuServe. And Caller ID.
XBAND has an 800 number in ROM that it uses for the initial server connection. 800 numbers are free for the caller, but expensive for the people running the number. So the first time you connect, the server tells your modem to use a different, non-toll-free number in the future.
It's not just any number though. If the devs picked a number in *their* local area, it would be cheap for them to run, but most people connecting would have to pay long distance fees. And that was not cheap in the 90s.
Enter CompuServe.
CompuServe used to run a nationwide dial-up network. It was like a giant modem pool, with local access numbers in most parts of the country, but it all accesses the same network. So the developers made a compromise.
Their compromise was to pay CompuServe to use their network. The devs have to pay more than just running their own local numbers, but the benefit is that in most cases, CompuServe numbers were cheap for the caller. That means lower phone bills for customers. Happy customers.
And now we get back to the Genesis unique ID situation. The key is that an 800 number has a special ability that local lines don't - reliable caller ID. You can hide your caller ID by prefixing the number you dial with *67, but not on an 800 call...
It's not impossible to spoof caller ID (more properly called ANI) on an 800 number call, but it's much harder. It's not simply a feature built into your phone line. And *that* is how XBAND uniquely identified modems that don't have an internal hardware ID.
When you first set up your XBAND account, it dials the 800 number. The server gets your ANI, programs your modem with all the data it needs, and uses your phone number to find a local access number for you. You redial that and it's used in the future.
But it remembers what number you called in from. So if your modem ever forgets its memory, it defaults back to that 800 number in ROM. The server then, using 800 ANI, knows who you are, and can set your modem back up the way it's supposed to be.
It's still not perfect and there is actually a lot more complexity to this. What if someone's battery dies, but they move to a different phone number? What if that phone number has another existing XBAND account on it? You don't want two clones of the same modem.
The devs put a lot of effort into solving these problems as best as they could. The server code has a ton of references to a condition they called "modem inc*st" (seriously), referring to getting in a situation where it can't tell which modem is which.
In some cases, customer service would even need to get involved to straighten things out. But these safeguards kept calls to customer service as low as they could be.
And I think all of that, that whole complicated process, led to including the hardware serial number chip in the later SNES and SFC versions. Except for a weird case where that serial number chip fails, it could always keep track of modems, and know who is who.
And BTW - if you have an XBAND modem, I have a server online. It works for the basic features like mail, news, and the player list, and if you're on SNES or SFC, you might be able to play some laggy games of SMK or (JP) SSF2. Connect at xband.retrocomputing.network
• • •
Missing some Tweet in this thread? You can try to
force a refresh
something arrived today, definitely a holy grail for me...
a Weather Star 4000! this is the box that at one point, among other things, generated the Local on the 8s graphics for the Weather Channel
(small thread)
the 4000 was introduced in the 90s. several new Star units came out in later years, but a few areas held on to their 4000s until 2014, when the required satellite feed became unavailable.
(the Weather Star XL, a later model, is notable for being based on an SGI O2...)
on the back are connections for A/V and baseband from a satellite receiver, and weather sensors directly connected to the unit.
inside, a few cards on a backplane on the left. power supply and backup batteries on the right.
i've been working on a proper reimplementation of the XBAND server, and i just had a conversation with someone over X-Mail!
i guess i'll make this a development log thread
(i'm going to say right off the bat that gameplay isn't going to work due to voip latency issues, and you should check out retro.link if you're interested in online gameplay on snes/md. also, i'll post xband connection info when the server is more finished)
the next milestone can speak for itself :)
snes supports compression on a lot of the network traffic, and is mandatory for outbound mail. you can send the box mail without compressing it, but everything it sends up is compressed. had to implement RLE + digram. works now!