RedEye internet gateway

[+karri]

Daydreaming again...

 

I was thinking about this Redeye code that seems to be in many Lynx programs.

 

It should be possible to create an ComLynx - udp gateway that mirrors all traffic between a game server and a real Lynx or Handy/Mednafen.

 

Sending a character at a time is too slow. Sending a packet containing one or more Lynx messages is a different story.

 

The server could be a small EC2 instance in Virginia/US. Best price to performance ratio I could find.

 

The FTDI USB-serial cable works in Windows and Ubuntu using the non-standard serial rates.

 

You could ComLynx any mixture of real Lynxes and Handy. The round robin system might be slower over internet. But it should work. With just a few lines of code to write.

 

Crazy idea?

 

-

Karri

[LX.NET]

Well, I think it is a great idea.

Obschan and myself have been working on ComLynx emulation. We might have made some mistakes there, but it is functioning in a single emulator. I posted some videos on that, with support for up to 7 players (with 8 players there is an instable connection for the 8th player). Obschan did some extra work to get emulators working across multiple programs using various transports and even in one emulator using multithreading. We discovered that the ComLynx only works with perfect synchronization. It's might be something in the ComLynx emulation code. Since I am responsible for that you can blame me Any help is appreciated. Let us know if you are willing to take a look at the code. http://lynxemulator.codeplex.com/SourceControl/latest#Source/AtariLynxEmulator/Atari/AtariLynx/Uart/

It might help in your investigations for Uart over Udp. I think the biggest technical challenge will be the buffering of bytes and the two-way chatty connection with confliect detection.

[+karri]

After a very brief look at the code it is a bit different of what I usually write.

 

Whenever I am in a hurry I try to triple buffer everything.

 

Input buffer

Process buffer

Output buffer

 

All these three should work simultaneously. Usually the Input/Output is taken care of by DMA or some other magic.

 

At input I would probably read in the byte and the status register only.

The process stage would do decisions about the byte and set the appropriate flags.

At output we feed the data to the emulator.

 

Timewise the input and output should run in parallell. Reading and feeding data at wirespeed. This may get you the missing milliseconds to make it work.

 

I don't know yet if I can find out how to accomplish this in an emulator.

 

If we add a redeye level to the emulator then we will probably get rid of the sync problems for the games that are using redeye. This may be a good-enough solution. But I know it is not an optimum solution.

 

The first thing is to get redeye libs into cc65 and write some tests.

 

A C# version of redeye is also needed as you seem to code in that. The C# redeye would use UDP packets for transferring the messages and simulate byte communication towards the emulator. I wonder if we could use UDP multicasts for this? L2 layer switches turn these into standard broadcasts so emulation should work well if you are on the same network. Over the internet you need IGMP group control which is a little tricky getting to work through L3 routers. The time to register a stream using IGMP can take up to a minute. Multicasts are also having just one sender and many receivers so we need every Lynx to transmit on its own port number or using its own multicast address. Something like 239.192.0.1-239.192.0.16:1989 (the port is the birth year of the Lynx) might work.

 

Actually I am impressed by the readability of your project. Looks much better than the C# projects I occasionally have to work with.

[LX.NET]

It sounds very plausible. We might have to team/meet up to get this to fly.

One big question that I have is this one: the redeye code relies on the fact that bytes that have been sent are echoed in the receive register, and checks that they are properly received (right after sending them). The transmission collision detection relies on this. Wouldn't buffering get in the way of that?

 

Actually I am impressed by the readability of your project. Looks much better than the C# projects I occasionally have to work with.

Thanks for the compliments. I took care of documenting the purpose of the emulation code as much as possible, as it relates to the hardware and should have a well-defined meaning.

I did notice that the Uart section has some residue files left. I hope you looked at Uart4 and SerialControlRegister2, or opened up the sources from Visual Studio.

[+karri]

There may only be collisions at the login phase of redeye. After that it is round-robin. Collisions are not required for the protocol to work. Besides in emulators there is never collisions anyway so that path is never taken.