Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
  • entries
    41
  • comments
    373
  • views
    64,045

2600 LAN

batari

Entry posted by batari

2,051 views

 Share

I originally wrote a detailed blog entry about this, but lost it due to accidentally closing the browser window, so this one will be brief unless I feel like recreating all that effort again.

 

Anyway, this is a proof-of-concept demo of a multiplayer game on two 2600s connected via the right joystick port. It's Adventure, where one console controls our hero and the other controls an enemy (dragons or the bat, and these are swapped every few seconds.) The cable may be constructed by anyone with readily available parts. You just need a straight-through serial cable with pin 7 of the male end of the cable lopped off with needle-nose pliers, and on that male end you need a female-to-female gender changer. I already had the cable (it is exceedingly common) but I used a gender changer from Radio Shack, though not particularly cheap, it was small and the attachment screws could be removed easily so it will actually fit in the console.

 

Here are links to Radio Shack parts:

Male-to-Female straight-through 9-pin serial cable

Gender changer

 

The game works by establishing a master console when reset is pressed. The master searches for a slave console in a tight loop. If no other console is found, the game doesn't start, so there's no point in trying this in an emulator or single console. The consoles exchange joystick information and a few collision registers, but that alone isn't enough, as it would have required significant modifications to the game to support just that. So for now, the RAM contents are uploaded to the slave, one byte per frame. Therefore it takes about 2 seconds of weirdness for the game to begin. There is also some weirdness during gameplay on the slave console (the one controlling the enemies) but it actually isn't bad, and it corrects itself soon enough. It sort of reminds me of how some online games behave with a high-latency connection.

 

It is not necessary to start the game on the slave console - that will happen automatically. It is a good idea to make sure the difficulty switches match or you will get more weirdness than necessary.

 

At first I made considerable effort to ensure that two consoles would have essentially zero chance of trying to output at the same time. But then I made some mistakes and I found the consoles were actually creating output contention for considerable periods of time (several minutes) and no damage occurred. I'm not sure if it was due to the resistance of the serial cable or that the outputs are open drain, but regardless, this leads me to believe that preventing output contention might not be as critical as I thought.

 

The source code has not been posted, as this was a quick hack for NWCGE 2008 and I barely got it working the night before the show. I know the code is awful and the timing delays are less than ideal, but it works (kind of.)

 

I also wonder if lopping off pin 7 is really necessary after I found a circuit with two 7805s in parallel with their outputs directly connected. This may cause some current to feed back to another console, but I wonder how damaging it could be. I have not tried this, however.

 

If you make a cable and try this out, let me know how it worked for you.

 Share

5 Comments

Recommended Comments

selgus

So what was the protocol you were using for the peer-to-peer connection? Did you design it to be flexible to allow a per console ID, so you could extend it to a ring-like network?

Link to comment
batari
So what was the protocol you were using for the peer-to-peer connection? Did you design it to be flexible to allow a per console ID, so you could extend it to a ring-like network?
Sort of. The ACK signals consist of two bits, so with minor changes, one could allow for four consoles. The master would need to control all slaves, and it could send something like 01, 10, and 11 for a slave console ID, then the slave could reply with its own ID. As it is now, there probably isn't enough time to establish communication with more than one console per frame.

 

It's a simple protocol, and really just a demo, as I am pretty sure there has never been a public demo of 2600 communication (though reportedly it has been done before.) There are 4 pins we can use to send and receive data, so I used two for master->slave and the other two for slave->master communication.

 

The master sends a connection request, then waits for an ACK from the slave, and when received, the slave sends an ACK back. The consoles should be synced to within about a few cycles (I think I estimated it would be less than 10.) After that, the data is exchanged synchronously, two bits at a time, half-duplex. I don't know how fast of a data rate the cable will support, so for now it's running around 20kbps per channel.

 

Probably the main problem with 2600 communication is the limited amount of time we have to do useful work between rendering the screen. Right now, only 3 bytes per frame are exchanged, and at two bits per transaction, it takes about 8 scanlines. If the cables will support it, it may be possible to up the data rate to around 40-50kbps per channel.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...