Atari 2600 games head to head over the internet

[Dones]

Like Nukey said, PCAE is the only one that tried it. I was never able to make it work with Internet (it might work on LAN though).

[Nukey Shay]

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.

 

According to PCAE's doc, it is possible (though it appears that I'm not the only one who couldn't get the damn thing to work). Tho the manual does not state who was responsible for adding Kaillera support, so I dunno how you'd go about asking how it was done

 

* Kaillera net-play support. Using this will open up emulation in a separate pop-up window. Players can chat among one another by hitting the slash key and typing chat text.

 

Clicking on the network play button on the main toolbar will open up the Kaillera connection screen. From here you must enter a unique name that represents your client (e.g. jdpcae). Those with whom you wish to play must also do the same on their computers. Then, as a group, you all have to join the SAME Kaillera server from the server list. If you are running your own server (e.g. on a LAN), you can click the “Enter IP” button to enter the LAN IP of the local Kaillera server. Once that is done, you all must agree on who will start the game. Kaillera games work by having one person “create” a net-play game and having all others join that game. One of you creates the game and chooses the game that is to be played. The others will see that game show up on their active games list and merely have to choose to join it. ALL PLAYERS IN QUESTION MUST ALREADY HAVE THE GAME THEY WISH TO PLAY. Neither the emulator nor the Kaillera client distribute a game to players who don’t have it, so they must all be legal owners of their respective games. (Actually Kaillera handles all of the game setup mechanics; the emulator itself does no more than supply a textual list of games the “creator” has available). Once all players have joined the game, they can start the net-play game. This instructs all players’ emulators to begin running their respective copies of the game, and Kaillera keeps them all synchronized. Play takes place as normal, with a player able to quit by pressing Esc to stop emulation. Players can completely exit the Kaillera net-play interface by closing the Kaillera pop-up windows after stopping emulation and “leaving” the net-play game. For more information you should visit the official Kaillera homepage, which as of this writing ishttp://www.kaillera.com.

[+batari]

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.

I remain skeptical that this will work in the manner you describe. Emulators and real hardware on both ends demand that the communication engine be synchronous, and the 2600 requires I/O every 16.7 ms and there's not really a way to slow this down without slowing down the whole game.

 

Back in the "old days" of network gaming, we had Doom, which was indeed synchronous, but even this wasn't as demanding as the 2600 even at the fastest speed: It only needed data every 28.5 ms at the fastest speed. There was a way to slow this down, too. We could skip frames without slowing the game down - it would make for a choppier game but it would still be playable game with packets being sent once every 114 ms.

 

Back in 1994, 114 ms was probably too slow for the internet, but then again, Doom only supported gaming over a LAN or direct-connection via modem/null-modem.

 

It wasn't until Quake, or therabouts, that someone devised an asynchronous communication engine that could tolerate the slowness of the internet. I don't know how this works exactly, but I don't see it as adapting to existing 2600 games unless the game code is being run on a central server and only sending video data out and taking controller data in.

 

Note that I could be totally wrong on this, since maybe someone can think of an ingenious way to anticipate the game actions and make corrections on the fly if the predictions would send the game out of sync.

[danwinslow]

No, I generally agree that if the target is real hardware on the client side, it becomes very difficult to do. But, given emulators on both ends there are lots of things that could be done. I think its pretty possible to do a decent job given careful programming, there are lots of tricks. You may well end up with some choppiness and slowdown, but you cant escape that on net games.

[danwinslow]

but I don't see it as adapting to existing 2600 games unless the game code is being run on a central server and only sending video data out and taking controller data in.

 

I agree. That was my point.

[+batari]

but I don't see it as adapting to existing 2600 games unless the game code is being run on a central server and only sending video data out and taking controller data in.

 

I agree. That was my point.

I misunderstood you, then. So we're on the same page with emus, but I still can't see a practical way that a central server could adapt to a real 2600. It's not possible to write client software that can render an arbitrary screen on the 2600. It has no screen memory, it's done by a custom kernel where timing is critical. At the very least, you'd have to write a custom client for every game.

 

You might be able to run the game itself if the server can account for mid-course corrections in the game code, but you'd need a way to directly modify the 2600's ROM and RAM contents, but you can't change RAM from the cart slot. You'd need to crack open the 2600 itself and do some soldering, at the very least.

 

Of course I could be missing something.

[danwinslow]

Uh...no screen ram? I take it its all done on the fly as the raster is drawn? Ouch, I didn't realize that. No wonder the timing issues are scary. But as far as emulators go, part of their job is to realize a 2600 screen, right? Somewhere in there, a screen gets drawn, and mapped ( I expect ) to video RAM or something on the host machine. If the internal state of the emulator gets copied to another one sufficiently fast...or maybe just the host machine screen RAM...I dunno.

 

I still think that if you wrapped hooks around every internal function of a server 2600 emulator such that any time a machine state item got changed ( ie., a register got written, ram changed, etc. ) it would replicate the change to a slave machine...Yknow, you should be able to make like a recording of all the operations, like a macro...and play it back to reproduce exactly a given session. So you wouldn't really need a client 2600 so much as a slaved emulator session. If the emulator could optionally be in slave or master mode, then the same software would serve as either side. You would have to have a syncronization key...probably an internal virtual jiffy count that got sent along with each update or at intervals or something. The clients would block waiting for updates packets to arrive, and the server would block waiting for acks for each jiffy update cycle...so the server could not advance the jiffy until the previous jiffies' update had been ack'ed by the clients..that would lock them in sync. Controller reads would be by request., ie, the server machine would access the appropriate port, which would be hooked to send a read port request to the client, The client would then do a controller read and send the packet.

 

The whole shebang would all slow down or speed up together, servers and clients, based on the highest latency for the jiffy acks. But I bet a smart routine for packing the updates and acks together in larger time chunks, and maybe also controlling internal server run speed based on current latency info, I bet you could get a decent session going.

[vdub_bobby]

Uh...no screen ram? I take it its all done on the fly as the raster is drawn? Ouch, I didn't realize that. No wonder the timing issues are scary.

Oh, there's screen RAM

 

20 bits of playfield

16 bits for two sprites

2 bits for two missiles

1 bit for 1 ball

+

7 bits for background color

7 bits for PF color and the ball

14 bits for sprite color (1 each) and their matching missiles

 

67 bits total.

 

And that's not even counting the bits in REFPx, VDELPx, NUSIZx, and CTRLPF. Add those in (2, 3, 10, and 5 bits) and we are up to: 87 total bits of screen RAM. Almost 11 bytes