Atari 2600 games head to head over the internet

[That80sGuy]

Thats my idea. Port the games so the emulators can hook up over the internet. Now I'll leave it up the software gurus to mull it over.

 

[Nukey Shay]

Due to how long everybody has been waiting for this, I'd guess it isn't so easy to pull off

 

Mage (or whatever it was called) - doesn't work, you can't even get the DLL anymore

PCAE with Kaillera - I'd like to hear from ANYONE who's got it to work

Z26 and Stella - gone walkies, I guess

[Ze_ro]

Due to how long everybody has been waiting for this, I'd guess it isn't so easy to pull off

Perhaps the delicate timing issues necessary for proper 2600 emulation in the first place are getting in the way here?

 

In any case, I'd love to see some online-capable emulators so I could hold Super Football tournaments or whatever.

 

--Zero

[Curt Vendel]

This should be possible...

 

if you use some of the virtual serial port adapters, create a serial port tunnel between two PC's, then add to the emulators a change to the joysticks input and create a serial cmd set to joystick 2 movement interface then this would be very possible,

 

have 65 (lowercase a) interpret as up, b would be down, c left, d right and e fire.

 

 

You could then potentially play Combat over the net.

 

 

 

Curt

[Ze_ro]

I think you're simplifying things a bit too much there... you'd still need some way to synchronize the emulators, otherwise the lag between the two computers would eventually lead to each player playing a completely different game.

 

--Zero

[+stephena]

I think you're simplifying things a bit too much there... you'd still need some way to synchronize the emulators, otherwise the lag between the two computers would eventually lead to each player playing a completely different game.

 

--Zero

 

Understatement of the year

 

Steve

[Nukey Shay]

How so? Just how fast would the connection need to be? With streaming media, real time video conference, and such you'd think it would be able to handle little 6507 emulators that have been running since the 486 days...especially since two of them have supposedly already done it (tho the jury is still out over here).

 

The timing is sensitive, but gimme a break

[+stephena]

How so?  Just how fast would the connection need to be?  With streaming media, real time video conference, and such you'd think it would be able to handle little 6507 emulators that have been running since the 486 days...especially since two of them have supposedly already done it (tho the jury is still out over here).

 

The timing is sensitive, but gimme a break

 

I don't think it's a matter of speed, but of latency. We've only recently gotten Stella sufficiently sync'ed wrt audio and video in Windows, and this is on a local system (same address space, but in different threads). Z26 is only now getting their timing working correctly in Linux, and (like Stella) it could still be improved. I don't know what the effects would be over a long distance, high latency link.

 

We're currently working on adding a debugger to Stella, and ironically enough this will actually be beneficial for eventually adding network gaming support as well.

 

Our plan was to add a networking component for the debugger whereby the core code communicates with the debugger. It shouldn't be too hard to extend that networking support to actually play games online.

 

The real hard part would be adding networking code in a platform-independent way. Once we have Stella communicating through a network, it won't really care if it's talking to a debugger or to another instance of Stella.

 

But again, I don't think the performance would be there for using over the Internet. Maybe over a local LAN ...

 

Steve

[+batari]

I don't think it's about bandwidth, it's about latency. You'd only need to send/receive a a little bit at a time but I think you'd need to do it with very little delay, probably in the same vertical frame, that is, 1/60 of a second, and my calcs say that this is 16 ms, still hard to achieve over the internet.

 

Modern multiplayer games are designed to handle internet latency and have synchronization mechanisms programmed into the code. 2600 games were not designed this way and I don't think it's trivial to redesign them. The other thing people are forgetting is if there is any sort of random number generator then there's a good chance that they would be playing two different games even if timing is perfect.

 

I think that the only real solution to this problem involves something other than two emulators running on two different machines, but rather, one emulator running on a server which sends video data to and receives controller data from some client programs. This method could tolerate slower ping times but you'd still want them to be pretty good to avoid noticeable lag.

[+batari]

Dammit, you answered before I could! Talk about latency.

[Ze_ro]

Yeah, the problem with just connecting the serial ports between two computers (let alone the internet) is that when you press a button on one computer, it has to send that information over the wire, and the other computer has to process it... this happens pretty fast (on the order of milliseconds, if not faster), but I don't think it happens fast enough... once in a while, a joystick motion would arrive too late, and would get processed one frame too late on the other computer... depending on how fast a game you're playing, this one frame could be the difference between life and death, so on one computer the player is still alive, but on the other, they didn't move in time and died... now everything screws up and the games aren't synchronized. Paddle games would be especially troublesome. Frankly, I'm amazed any emulator can properly network games across the internet.

 

The only way I can even think that this could work properly is if both emulators communicated to each other to make sure they were processing the exact same frame at the exact same time... but then you still get timing problems, which might cause some slowdown in the game (but at least the two computers would remain in sync). Hopefully, this slowdown would be almost unnoticable, but we'll never know until someone tries.

 

Our plan was to add a networking component for the debugger whereby the core code communicates with the debugger.

Wow, that's interesting... so you could actually run the game on one computer and be debugging it from another... for some reason, the nerdiness of that appeals to me

 

--Zero

[+stephena]

Our plan was to add a networking component for the debugger whereby the core code communicates with the debugger.

Wow, that's interesting... so you could actually run the game on one computer and be debugging it from another... for some reason, the nerdiness of that appeals to me

 

--Zero

 

It could work that way, but wasn't really the reason I was looking at it. Basically, I need a platform-independent way to have the emulator talk to the debugger. Networking was the only one I could think of; the ability for the applications to be on separate computers was just a side effect.

 

Or, I may go the initial route and just integrate the debugger into Stella itself. The problem with making it internal is that it complicates the (already complicated) event handling, and I'd need to create GUI elements (scroll bars, text boxes, menu items, etc) in SDL.

 

The reason for making it external is to use a toolkit that provides all the GUI functionality, but that comes at the cost of having to have two applications communicate in a platform-independent way (since I don't want to create code for each port).

 

Ironically enough, the &&%#( GUI is what's causing all the problems. I don't forsee the actual debugging code being all that bad. Simply creating a usable GUI seems to be the hard problem.

 

Steve

[Spirantho]

Wow, that's interesting... so you could actually run the game on one computer and be debugging it from another... for some reason, the nerdiness of that appeals to me

 

 

How do you think modern consoles are programmed?

[danwinslow]

Well, you don't so much need to connect the two 2600's across the 'net, you just need to connect a joystick and screen deltas. So set up a client 2600 to just read the joystick and send it to the 'server' 2600 ( the one actually running the game ). That would be easy in comparison to the screen deltas. You'd have to have some kind of external hardware piece that could snap the screen at every vblank or something and compress and send the screen data. Video capture or maybe some kind of conferencing tool. The client 2600 would receive and display the screen updates, and send the joystick data, and thats it. The server machine would be the only one actually running the game, and so that eliminates the sync problems to some extent. Still, the client machine would probably look and feel laggy if there were significant latency.

[danwinslow]

*edit*

The amount of RAM data required to represent a 2600 screen has got to be pretty small....maybe 1k or so? Not really sure. So maybe rather than grabbing the screen off the TV with a digitizer, you could have a hardware device that can snap the screen memory off of a running game every vblank. If its around 1k that would fit into one packet and would be very easy to send to the client and have him update his screen. As long as you kept the screen refresh stream going in one direction and the client joystick data in the other you'd be set. You'd still be laggy sometimes but you can't get away from that in net games.

[danwinslow]

Heck, with the amount of RAM we are talking about here you could just snap ALL of the RAM and send it every vblank I bet.

[jeepnut24]

Voice communication during Halo2 without lag and we can't get 2600 across the net???

[maibock]

OK - I'll throw 100 bucks into the kitty to whomever can get this to work properly..

[+stephena]

Voice communication during Halo2 without lag and we can't get 2600 across the net???

 

And that application was designed and written with networking in mind. I don't know of any 2600 games that were written to do that. Also, aside from the latency issues (lets assume it was running on a local LAN), there are other problems. Like in a two player game, the emulator has to know when player one is playing, it goes to computer 1. And when player 2 is playing, it goes to computer 2.

 

Now, if it only had to be done with one game, it could probably be feasible. Halo2, as complex a game as it is (compared to a 2600) is still just one game. Assumptions were made that were valid for that game.

 

To do something similar in an emulator, it has to work with all possible games you throw at it.

 

Honestly, I don't see how it could be done. Perhaps it's quite easy, and I just don't have the required skills to do it.

 

OK - I'll throw 100 bucks into the kitty to whomever can get this to work properly..

 

And I'd add another $100 myself for someone that can give me a patch. Or even if someone is familiar (at the code level) with how other emulators work over a network, it would be useful information to me. Note that the $100 would be for a working patch, not for advice or info

 

Steve

[danwinslow]

Here's maybe how to do it :

 

1. Drop the concept that your 2600 emulation has to properly draw the screen. I suspect that a lot of the delicate timing issues come from having to syncronize things like NOP loops waiting for raster beam positioning with the ACTUAL raster as drawn by the host computer. If you aren't worried about realizing the screen on a host display, all of a sudden your timing becomes relative, and you can go as fast or as slow as you want as long as it's internally consistent. You would be tracking your own 'virtual' raster beam, so to speak.

 

2. So set up a 2600 emulator 'server' that runs on a host computer, and is only concerned about maintaining the internal state of the machine, namely the ram/rom contents.

 

3. Wrap this emulator in a TCP-enabled shell that interrupts it every X jiffies, snaps the machine state and broadcasts it via TCP. The game running on the emulator never knows anything happened.

 

4. Create emulator 'clients' that can run on a variety of host machines, and are set to connect to the server and only do 2 things : read and send the joystick info, and receive and display the machine state. The game itself would not be running at all on the clients.

 

5. Since the server no longer needs to be slaved to a particular display, you can run ther server as fast or slow as you need to..you could use a positive ack/nak protocol to let the server adjust for latency times. This would lock the clients in sync. The display may get choppy still due to latency, but you would always know that you are in sync.

 

6. If you wanted to play via real hardware, you could take a SBC ( Single Board Computer ), like this one, and fit it into a freakin cartridge if you wanted to, plus some extra chippage to do the interfacing into the 2600. Plug the cartridge in the 2600, stick an ethernet line into it, and off you go. The cartridge would read and send the joystick info, and receive the machine state pulses and write them into the actual 2600.

 

You could even have a BIG server running lots of these 2600 server instances, and host it all under a custom framework, kind of like battle.net or team fortress or what have you.

 

You wouldnt have to reprogram the games themselves at all.

[danwinslow]

Eh, can't edit. Here's the SBC I mentioned :

http://www.jkmicro.com/products/picoflash.html

[+stephena]

If you aren't worried about realizing the screen on a host display, all of a sudden your timing becomes relative, and you can go as fast or as slow as you want as long as it's internally consistent. You would be tracking your own 'virtual' raster beam, so to speak.

 

OK, this already happens in Stella. There's a function that's called 60 times per second. Each time it's called, one more frame is processed and displayed. In fact, that's how I do a 'pause' in Stella; I simply don't call that function anymore.

 

2. So set up a 2600 emulator 'server' that runs on a host computer, and is only concerned about maintaining the internal state of the machine, namely the ram/rom contents.

 

OK, this is part of the work, and it would need some more discussion.

 

3. Wrap this emulator in a TCP-enabled shell that interrupts it every X jiffies, snaps the machine state and broadcasts it via TCP. The game running on the emulator never knows anything happened.

 

There is already code in Stella that can save a statefile. It may not save everything that's needed, though.

 

4. Create emulator 'clients' that can run on a variety of host machines, and are set to connect to the server and only do 2 things : read and send the joystick info, and receive and display the machine state. The game itself would not be running at all on the clients.

 

OK, this is where the idea gets a little fuzzy. First of all, there are more events to send than just joystick. There are also paddles, driving controllers, etc. And also all the keyboard shortcuts that Stella contains.

 

So, at this point all we have is two (or more) clients which 'see' what's happening in Stella, at the same time. Sort of like me playing a game here, and you seeing the progress in a window on another computer (sort of like a movie).

 

There's still the problem of how to get that other computer to tell the emulator that it will be 'player 2', and this computer will be 'player 1'. The emulator (server I guess) must know when to take input from each client, and when the input from a client is to be used.

 

For example, assume we're playing a game of Frostbite locally. Player 1 uses a specific joystick and/or set of keys. At that point, joystick and/or keys for player 2 are ignored. When player 1 dies, the system starts polling for player 2 joystick. But it *knows* where to look, since player 2 joystick and/or keys are different from player 1.

 

I guess what I trying to say is how is it decided who is player 1 and who is player 2 when the emulation is in two separate parts? Player 2, on some remote system, will want to use his *player 1* events to send *player 2* events to the server. And this doesn't even get into when there are more than two players.

 

Another way to look at it is if I start a 2 player game locally, I want the joystick events from the second player to come from the local player sitting next to me. But if I start a 2 player game remotely, I want the joystick events from the second player to come from the remote machine, and any player 2 events that would normally come from the local machine be ignored. This is assuming I'm player 1, and I initiated the game.

 

Now, on the other machine, that player is player 2. They will want to use the joystick they normally use for player 1, but it must send player 2 events. And, the emulation on that end must ignore any player 1 events that are generated locally.

 

Maybe, in the autonegotiation stage, we need something that says "I'm player 1 and you're player 2. Whenever you send me an event, I'll interpret it as from player 2." Of course, the problem is in implementing that :>

 

5. Since the server no longer needs to be slaved to a particular display, you can run ther server as fast or slow as you need to..you could use a positive ack/nak protocol to let the server adjust for latency times. This would lock the clients in sync. The display may get choppy still due to latency, but you would always know that you are in sync.

 

There are several levels of sync. What you mention may take care of one of them. That is, each client has a copy of the machine state. But the dispatching of events still has to be sync'ed as well. And that's the one I'm addressing.

 

Also, there's the issue of who initiates a game, and then how the other player joins. Ideally, while the idea of client/server makes the most sense, I'd prefer it to all be in the same Stella executable. I don't want to have people *needing* to have another program to run. So each copy of Stella would act as client *and* server.

 

Well overall, I still don't know how doable this is. But at least the fog is beginning to clear a little

 

I will research this some more once I get the current modifications finished (in-game GUI and possibly debugger).

 

Steve

 

 

Steve

[danwinslow]

The issues of mapping controller inputs to specific ports on the server side are easily handeled. Thats a standard issue. As you mentioned, there is usually a negotiation at some point ( unbeknownst to the user perhaps ).

 

As far as knowing when to seek input from the clients, its handled in a couple of ways. Often you set up a stream of UDP packets from the client constantly sending data concerning the inputs...this is then cached and staged if necessary and played into the server. Its usually UDP because its largely redundant data so if we drop one or two its usually no big deal. The wrapper around the server just keeps the virtual controllers updated with the most recent data, and the server just reads them whenever it normally would. You can also send just delta packets ( ie., only when the value changes ) and thats usually more efficient but if packets get dropped it can have more impact on the play.

 

Syncronizing machine state back to the client is a different matter...first of all, how much data are we talking about? How big is a stella state file, for instance. If thats larger than we feel comfortable pumping out 60 or 30 times a second, we can generate deltas ( list of addresses and changed values ) instead of the whole thing every time. That (usually) decreases the data size but can add handling overhead.

Also, whats the apply overhead like? How long would it take to flash a new state in?

 

There are also other chip states to worry about...music comes to mind. It seems like it would be hard to get an unbroken stream of music to play on the client if its coming in discrete chunks and you have to slam a new state onto the chips every frame. For specific chip states like that we would probably send an initial state, but then rather than updating with the entire stream of state changes, we would let it 'play' on its own for a while on the client box...then resync it to a known point every so often, or when something changes. It would still probably sound choppy but I bet a smart routine could combine periodic updates with a 'free play' time window and get a good matchup. The screen ram we ought to be able to pack up and send very often in its entirety I would think, and if its fast enough ( around 10 frames per second if I recall my limits of normal human perception ).

 

So that idea all has to do with the game being plaued on the server, and the clients just being 'dumb' displays. That solves a LOT of sync problems, but its high overhead. If you have to get to the point where the game needs to run on the clients too ( with periodic state updates ) then things start to get dicey. Most on line games have very thick clients, that do almost all of the display work in between periodic updates, animating characters and walking things along in the last known direction, etc, with the server side just giving object x,y,z and various state updates periodically. This leads to wierd effects from lag though, and probably wouldn't be good on something like a 2600 game, which has no knowledge at all that it might be being lagged.

[danwinslow]

Ooooh...on the chip state issue....you could put hooks around your internal 'chips' that would automatically generate a corresponding update to the client machine.....yar. So we would get a stream of chip state changes as they should occur anyway to the client. That and the video RAM updates ought to make for a playable situation...hmmm.

[danwinslow]

OK, I think this is very, very doable with both servers and clients as emulators. If you wanted to be able to drive real hardware on the client side, thats going to be much harder...but I think it would still be possible.

 

With the clients as stella emulators as well, all you would have to do is put update hooks around all of your writes into the simulated machine on the server side, so that each write to your internal simulated 2600 would result in a corresponding update packet to the listening client 'emulators'. Really the clients would be an 'emulator emulator' at that point. Or something like that.