Joystick ports as output on VCS

[vdub_bobby]

Since you can configure the joystick ports on the 2600 to output or input, it should be possible to connect two VCSs together and play against the other machine...like a NULL modem connection.

 

Are there any games that tried that? Has anybody tried anything with that?

[MayDay]

I'm not sure about the possibility itself (why not though?) but I can't see any reasoning for this. If you hooked two machines together, you would still only have two players (only advantage would be avoiding splitscreen, if you had a game designed for this). To add more players, you could use four machines, one player per machine. However, there are already 4 player game(s?) out there (Warlords being the only one I can think of off the top of my head) that don't need all the extra machines and titles of the same name.

 

If you had 8-16 machines, I think you're getting beyond the capability of each individual machine to display what is happening. I may be totally off on this though, with my lack of hardware/programming knowledge.

 

Just curious what you had in mind. The reason I've dug this up is because of a discussion about the possibility of Spy vs. Spy for the VCS. Something I had thought of was having a specialized controller (here we go again, right?) that had two plugin cables. One would go to each machine, player 1 in the first, and player 2 in the second. The computer could display the screen for the correct player, but also track the other user with the second controller line. Then each player could have his own screen, could be in whatever room, and avoid screenlooking to find each other (if TVs were back to back). Thoughts?

[MayDay]

Sorry, didn't specify better. It makes more sense to have one cable connect the two consoles than having controllers with two cables. I'm just curious if this is the kind of game/reasoning you had in mind.

 

Thanks,

Jason

[vdub_bobby]

Well, mostly what I had in mind was this: if you can connect two 2600s together directly via the joystick port, the obvious next step is connecting them via a modem.

 

Then we could be talking about some cool applications...online Combat, anyone? And if somebody was really ambitious, with a lot of time on his hands, he could set up a game server with a PC, like BattleNet or something similar, and you could have some wicked cool online 2600 gaming.

 

'Course, you'd need some software to support that.

 

So I dunno. Seems cool to me. Whether it is feasible...?

[+batari]

This sort of thing has been discussed before. The issue is internet latency - typically 100ms on a highspeed connection, 50 ms is you're lucky. (As a reference, I just measured 77ms to atariage.com with my 3 Mbps connection.)

 

And on a modem, it's even worse - 400 ms is typical.

 

Anyway, it's all much too high to support existing 2600 games that expect I/O every 16.7ms (NTSC) or even 20ms (PAL).

 

I don't think that the 2600 is powerful enough to handle long internet streams, analyze them and keep them synchronized at a high frame rate as would be required for action games like Combat, much less something like Warlords, but I could easily see the ability to do slower games. Two-player strategy games are completely plausible.

[MayDay]

vdub_bobby:

Well, mostly what I had in mind was this: if you can connect two 2600s together directly via the joystick port, the obvious next step is connecting them via a modem.

 

Only obvious to people with a functioning brain. Unfortunetely, I think this eliminates me! (especially when you eluded to this in your first post) It all makes sense to me now...

 

batari:

I don't think that the 2600 is powerful enough to handle long internet streams, analyze them and keep them synchronized at a high frame rate as would be required for action games like Combat, much less something like Warlords...

 

I agree... but an emulator/computer would be. Why not just provide a network for (legally permissable) games people could play on? We did this in college, allowing us to play Tecmo Super Bowl (among other non-legal NES stuff) across campus. It should be just as easy to do with the 2600 games. I figured they already had this somewhere, and I'm sure they probably do. While it's not the nostalgic console, it does allow you to link up.

 

And if no such network does exist, I may have to recruit some people to help me get one running! Of course high-speed internet would be desirable/mandatory to avoid lag, but something is better than nothing, no?! Would also make a good marketing tool for homebrew games, maybe bringing outside people back into the world of Atari. With all the rankings and cool stuff they do now on these sites, wouldn't it be awesome to say "I've got the best Combat ranking out of 35,000 on the internet!" Would bring new life and interest to the console, as online games have done for Xbox and PS2. Of course we would need to license the classics somehow to get the broadest appeal, something which may be difficult/impossible to do. Anyone have further ideas/feedback on this?

 

-JD

[vdub_bobby]

This sort of thing has been discussed before.  The issue is internet latency - typically 100ms on a highspeed connection, 50 ms is you're lucky.  (As a reference, I just measured 77ms to atariage.com with my 3 Mbps connection.)

 

And on a modem, it's even worse - 400 ms is typical.

 

Anyway, it's all much too high to support existing 2600 games that expect I/O every 16.7ms (NTSC) or even 20ms (PAL).

 

I don't think that the 2600 is powerful enough to handle long internet streams, analyze them and keep them synchronized at a high frame rate as would be required for action games like Combat, much less something like Warlords, but I could easily see the ability to do slower games.  Two-player strategy games are completely plausible.

I'm not real hip to the lingo; could you explain to me what 'latency' is? I am getting the general idea, but I'm not all the way there yet.

 

And what do you mean by a long internet stream? For a two-player game of Combat you would only have to send and receive maybe a byte. 5 bits for the joystick and trigger plus 1 bit denoting an early end to the game (i.e., one guy hits reset before the game is over). Plus some overhead, sure. But I don't really know much about this stuff.

 

Where has this been discussed before? I looked around before I created this topic and couldn't find much of anything.

[Tom]

http://en.wikipedia.org/wiki/Latency

 

Basically in this case it's the amount of time a packet needs to get from one machine to the other. If I ping atariage I get a time of 142 ms, and if you assume the message from my machine needs roughly as much time as the message from aa back to me, the latency would be 71ms.

[djmips]

Since the tanks in combat move slowly and you are shooting and not directly interacting, this game play would make it fairly tolerant of network latency.

 

The important thing to do is to run both games would run at full speed on either end with no waits for control packets from the other end. This prevents the sluggish behavior if you locked your frame update to the latency. Normally a NTSC game can get input and update graphics about every ~17ms (60 fps) waiting for latency would drop the frame rate unacceptably low and jerky.

 

The way I envision a system to handle a combat game would be to write actual game sim on a server and gather frame stamped input from both combatants and distribute frame stamped tank and missile state. Collision detection and death would always be client side and determined by the combatant (2600 CPU) who's life is the balance.

 

Latency hiding can be accommodated during the flight of the shot. When fired the shot is 100% in local frame but over the course of the shot it could be smoothly migrated to the other time frame.

 

To reiterate, the local view is always correct for your own tank and shots. When new frame stamped input arrives to the server, it is inserted into the correct place in time (even if it is in a past frame) and the simulation is rerun from the frame of the new input forward to present and updated state is pushed to the clients. This may cause some disconcerting effects with regard to your view of your opponent, depending on the magnitude of the latency. Since the tanks move slowly, it would be minimized.

 

It might be possible to some or all of this work on the 2600 in a peer to peer arrangement. To do this, you would need a great deal more RAM, so some special cartridge would be required. It would also be slower as the re-sim portion would take a lot of cycles, how many would depend on how many cycles the sim portion of Combat currently takes.

 

- David

[supercat]

Well, mostly what I had in mind was this:  if you can connect two 2600s together directly via the joystick port, the obvious next step is connecting them via a modem. 

 

I think the idea of connecting Ataris via the joystick ports would be cool. Using anything other than a direct connection might be tricky, though, since the Atari lacks any sort of UART functionality and blanking the entire screen during communication would be most uncool. Thus, it would be necessary for both Ataris to be operating in lockstep with each other so that each would be communicating precisely when the other one was expecting to hear it. Over a short direct cable, this shouldn't be a problem. If one of the Atari units is called the 'master' and the other the 'slave', the units could be set up roughly as follows:

 

(Master)

At scan line #220, start blanking

At scan line #228 start outputting a pulse and waiting for the reply

Once you get the reply, communicate some data (you have about 16 lines to do it)

If you've gotten to scan line #236 without a pulse, give up for that frame

At scan line #259 turn on VSYNC

At scan line #262 turn off VSYNC and restart frame

 

(Slave)

At scan line #220 start blanking

Start looking for a pulse. If you find one before line #236 make note of where you found it and do the necessary communication.

If pulse was found before scan line #224, trigger VSYNC/frame end at line #258 and 261; if after line #232, VSYNC/frame end at #260/263; if never seen at all, VSYNC/frame end at 269/272. Otherwise at #259/#262

 

The result will be that the slave's frame timing will be synced to the master within a few scan lines. The slave may sometimes outout a long or short frame if necessary to keep things in synchronization, but frame length should always be reasonable.

[Alex H]

Since you can configure the joystick ports on the 2600 to output or input, it should be possible to connect two VCSs together and play against the other machine...like a NULL modem connection.

 

Are there any games that tried that?  Has anybody tried anything with that?

772375[/snapback]

 

I've done this on the Vectrex. Check out VecLink Maze Demo on my site: www.herbs64.com. Not much info there, but a photo of it running. The problem with doing it on the VCS is that the 2 machines will not run at the exact same speed and will drift, so as one machine gets ahead you have to add an extra scanline every once in a while to bring them back in line. That might cause some display twitching. The Vectrex doesn't have this problem because the display is entirely under CPU control so it's easy to sync the two.

[Hornpipe2]

Here's a design for a "joystick router" that sends joystick presses over the Internet. You'd need some kind of hardware interface from PC to console, but this system and software could be generalized to any console game system. It works with existing games and does not require any changes to the console. In fact, since the joystick goes through the PC first, you could use any PC-connectable joystick as a control method for the console game.

 

software init: Synchronize timestamps with remote machine

loop: record a local buttonpress to the buffer with "received timestamp"

log incoming buttonpress packets to buffer with "remote received timestamp"

if the time is right send both buttonpresses at the same time.

goto loop

 

I can already think of a number of situations where this design won't work - console switches aren't emulated, you can't start both machines at the same time, there is no way to ensure the machines are synchronized, latency will always delay buttonpresses so players have to learn to lead their actions, random number generation differs per-console, tradeoff between TCP (slower) and UDP (have to handle dropped packets) etc. But it may be useful for strategy games or slow-paced gaming.

 

I may build it if I get some free time. You could then set up that matchmaking service (I already have a working server browser design) to find available gamers.

[mos6507]

Simply having a "remote" joystick with existing games is not going to work. You have to write games specifically for multiplayer. One side has to be a master and the other just a display engine, or both sides would be display engines getting state packets from a central server.

 

Also, the 2600 is too slow reading serial input on the sticks to make this work. You need a special cartridge with a buffered UART in it to do a lot of the heavy lifting. That's what the Chimera design plans to do. Otherwise you're really only going to be able to play turn-based stuff.

[Hornpipe2]

Simply having a "remote" joystick with existing games is not going to work. You have to write games specifically for multiplayer. One side has to be a master and the other just a display engine, or both sides would be display engines getting state packets from a central server.

Why not? PC-based emulators do it all the time. There are careful synchronization issues to be worked out to ensure the same presses hit each machine at the same time, and clearly it's not a perfect solution (think about random number generation, where each console starts with a different seed - this is impossible to sync). But that doesn't mean it's not workable.

 

Also, the 2600 is too slow reading serial input on the sticks to make this work. You need a special cartridge with a buffered UART in it to do a lot of the heavy lifting. That's what the Chimera design plans to do. Otherwise you're really only going to be able to play turn-based stuff.

So just put a set of flip-flops driving the inputs on your PC-to-Atari board, and let the PC parallel port program them with new button press info when updates need to happen. That way the correct data is waiting when the Atari comes to read.

 

Or are you referring to the original "joystick ports as null-modem" post? I probably should've started a new thread.

[mos6507]

Why not?

 

The random number generator issue by itself is a showstopper.

 

You can't just hook up two VCSs to eachother and expect the same game experience through a remote joystick connection. The gamestate between both VCSs will diverge. It will LOOK like it's working but what one person experiences will be different from what the other person experiences. Eventually these differences will compound and confuse the two players.

[Curt Vendel]

You guys are going for a full sprint, lets crawl first...

 

 

Why not allow for a group of local 2600's - say along a table at a convention - to all be connected to play something like an 8 player tank game or playing Warlords across 4 separate consoles.

 

 

Curt

 

Why not?

 

The random number generator issue by itself is a showstopper.

 

You can't just hook up two VCSs to eachother and expect the same game experience through a remote joystick connection. The gamestate between both VCSs will diverge. It will LOOK like it's working but what one person experiences will be different from what the other person experiences. Eventually these differences will compound and confuse the two players.

[djmips]

Why not?

 

The random number generator issue by itself is a showstopper.

 

You can't just hook up two VCSs to eachother and expect the same game experience through a remote joystick connection. The gamestate between both VCSs will diverge. It will LOOK like it's working but what one person experiences will be different from what the other person experiences. Eventually these differences will compound and confuse the two players.

 

I forgot to reply on this earlier. I was just going to say that showstopper is too strong. Keeping the randoms synched is just another of the many challenges that can be overcome. Fortunately games on the VCS will be much easier to keep deterministic as there are not multiple threads running for instance. Certainly there will be challenges but they can be overcome. In the past a colleague of mine worked for a company that modded Sega Genesis games for online play over their network. They had to take existing games and reverse engineer them, sychronize the gameplay and take care of the random problem and the worst part is the latency issue. But they managed to succeed even though they were dealing with modem connections at that time.

 

I think that connecting VCS games over a network is achievable but it will be a lot of work.

[Curt Vendel]

Well there are some hooks you could put into place, essentially - state codes that would be checked for a hi lo bit to make sure both consoles are maintaining a sync with one another for the player position, direction, etc. Essentially a cheat sheet between the two systems.

 

Doing a two-console game like Combat would be the best initial game design to work on, then maybe something along the lines of Maze Craze. The key is the keep the game elements very simple and not over tax the cycles.

 

 

 

Curt

 

Why not?

 

The random number generator issue by itself is a showstopper.

 

You can't just hook up two VCSs to eachother and expect the same game experience through a remote joystick connection. The gamestate between both VCSs will diverge. It will LOOK like it's working but what one person experiences will be different from what the other person experiences. Eventually these differences will compound and confuse the two players.

[+batari]

In the past a colleague of mine worked for a company that modded Sega Genesis games for online play over their network. They had to take existing games and reverse engineer them, sychronize the gameplay and take care of the random problem and the worst part is the latency issue. But they managed to succeed even though they were dealing with modem connections at that time.

Modem to modem, or modem to internet to modem?

 

The former has very little latency, while the latter has tons.

[djmips]

In the past a colleague of mine worked for a company that modded Sega Genesis games for online play over their network. They had to take existing games and reverse engineer them, sychronize the gameplay and take care of the random problem and the worst part is the latency issue. But they managed to succeed even though they were dealing with modem connections at that time.

Modem to modem, or modem to internet to modem?

 

The former has very little latency, while the latter has tons.

 

It was modem to modem so it didn't suffer from the inherent latency of the Internet. In my experience some modems, particularly the software modems had an inherent latency on the order of 100ms, and this could be on both ends. But you're right, direct connect on average wouldn't have as much latency to deal with as the internet.

[Gorf]

I think the PC server using the parallel to cart port idea it the

one that sounds most viable and promising. Online combat would

be too sweet though!

[supercat]

Since you can configure the joystick ports on the 2600 to output or input, it should be possible to connect two VCSs together and play against the other machine...like a NULL modem connection.

 

It would be theoretically possible, but it would be a sufficient pain in the tusch to implement that so far as I know nobody as done it. Given that finding people interested in playing VCS games is often a challenge in and of itself, compounding the issue by requiring two VCS consoles would make things even worse.

[djmips]

Since you can configure the joystick ports on the 2600 to output or input, it should be possible to connect two VCSs together and play against the other machine...like a NULL modem connection.

 

It would be theoretically possible, but it would be a sufficient pain in the tusch to implement that so far as I know nobody as done it. Given that finding people interested in playing VCS games is often a challenge in and of itself, compounding the issue by requiring two VCS consoles would make things even worse.

 

It would be a nice thing for your local Atari club or to bring to a show though!

[supercat]

It would be a nice thing for your local Atari club or to bring to a show though!

 

It would, but I don't feel like spending weeks writing something that would get played a few hours a year.

[BigO]

Such a scheme would make possible games where information needs to be visible to only one player. A version of Battleship would be an example. Latency wouldn't mean much. Low bandwidth should work well enough to transmit players' moves between consoles and support a little chit-chat to make sure the other console is still alive.

 

I think some card games would lend themselves to this format fairly well.

 

Chess or checkers (new games, not the existing ones) don't require hiding information from either player, but could likely be played over a network. There being 64 squares on a checker board, one could transmit a couple of bytes to say where a piece moved from and where it moved to. The rules and logic enforcement would take place on the console before the move was transmitted to the opponent's console.