Plans and ideas, who cares to participate?

[LX.NET]

Hello everyone at the Lynx programming forum,

 

Here are a couple of things that have kept me busy with the Atari Lynx and related stuff. I want to share them with you and hear your reactions. Let me keep this first post fairly short and I can elaborate later.

 

Emulator in C#

At lynxemulator.codeplex.com I share the source code of the C# version of a Lynx emulator. I have written the code from scratch and annotated it with the comments from the Lynx development documentation. It is now working (without sound) for a lot of games, some with little quirks (e.g. Robotron 2084 where you cannot save humans, because there is a bug in the collision detection functionality of the emulator), other with larger quirks. Plans are to get the last video rendering bug sorted out and start on music. Then I will add development tooling for the Lynx, like a sprite debugging system.

Credits where credits are due: Keith Wilkins is a genious. How he figured out how everything works is beyond imagination. I understand ALL of his C++ code now, but how he managed to reverse engineer this from the Lynx developer docs is a mayor accomplishment. I learned so much from his code and some parts (such as the actual sprite rendering) fairly close resemble his implementation.

 

ComLynx over the internet

Shouldn't it be possible to connect the Lynxes over the Internet using a ComLynx to USB cable and a clever bit of PC software? I talked to a friend of mine who know some electronics stuff and he gave me FTDI with the 5V details, plus capacitor things, without him knowing this forum and its discussions. So it seems that a connection from Lynx to PC is possible. The software I can write. Latency might be an issue. And I know not too much about the ComLynx programming part.

 

Lynx on the XBox 360 and Windows Phone 7

This should be in reach when the C# emulator is completed. Cross-compiling for the XBox360 and Phone 7 is not a big deal, especially since I use the XNA framework for the rendering and ideally sound.

 

Visual Studio as development environment

I'm a Microsoft guy as you may have noticed. That's why I am comfortable with their development environment and platform. I guess not everyone's preferred choice and certainly not cross-platform. But I hope it will appeal to a broader public. I have already created/configured a makefile project in Visual Studio C++ 2010 so you can compile and build cc65 code (done for HelloWorld and nearly completed for Sollitaire, a more complex setup). This gives you syntax highlighting, partial IntelliSense, direct navigation to error locations, integration with source code repositories like SVN and codeplex. You can also imagine combining the Lynx emulator (be it Handy or my C# implementation) as a debugger for the Lynx game project (in the same environment). This way you could debug at multiple levels: tooling support from the emulator and Visual Studio debugging while in the emulator (kind of meta-debugging)

 

More content for my blog

I have a blog with some content on the Lynx. http://www.alexthissen.nl/blogs/atarilynx . I think about documenting what I have learned about the Atari Lynx's internals, tutorials on programming for the Lynx (as I am learning myself), and more.

 

Input wanted:

• Who is interested in any of these ideas, plans and projects?
  
• Who is interested in contributing (building, testing, discussing, providing feedback)?
  
• What are requirements for debugging/development tooling for the Atari Lynx?
  
• Interesting content on my blog? Does anyone read this? What would you like to read about?
  
• Documenting the internals of the Atari Lynx?
  

 

Looking forward to your reactions and feedback. Like I said, I can provide more details if required.

 

Alex

Edited June 24, 2011 by LX.NET

[Wookie]

My USB comlynx adapter: http://www.classicgamedev.com/Blog:Hacking_Classics/USB_Serial_to_ComLynx_Adapter

 

Comlynx over the Internet is certainly possible but it really depends on how each game is programmed to handle the serial I/O. It it is expecting a response over the comlynx before it continues running the game (synchronous) then it may not be possible with a potentially laggy Internet connection in between.

 

I have one complete USB to comlynx device made but I haven't fully tested it. I do know that the stereo connector part is wrong. It is too big and it hadro order an adapter.

 

--wookie

[sage]

I like the idea that someone takes over the handy development and fixes the bugs, crappy sound etc which are still in.

Even in the nevest version there was a bug in collision of scaled sprites and the out of screen bits.

And, a improved debugging version would be very welcome.

But... I think it would be much much better to continue work on the sdl port, as this is the one which is used on all other emulators (mednafen), machines and handhelds. Actually, with handhelds it really makes sence to improve the comlynx over udp of handy. Anyway, as long as the development will be only for one or two systems, I will not invest my time, sorry.

 

I will put together a list of suggestions.

[LX.NET]

My USB comlynx adapter: http://www.classicgamedev.com/Blog:Hacking_Classics/USB_Serial_to_ComLynx_Adapter

 

Comlynx over the Internet is certainly possible but it really depends on how each game is programmed to handle the serial I/O. It it is expecting a response over the comlynx before it continues running the game (synchronous) then it may not be possible with a potentially laggy Internet connection in between.

 

I have one complete USB to comlynx device made but I haven't fully tested it. I do know that the stereo connector part is wrong. It is too big and it hadro order an adapter.

 

--wookie

 

Hi Wookie,

 

Agree with you on the latency. Any idea what the max time is that a game will wait for a reply? Also, I do not know too much on the ComLynx implementation in the original games (yet). I'll have a look at the way that cc65 has support for it.

 

Other thing: can you explain why you have built a new cable, USB board with chip? What I am looking for is what makes this interesting/required and if the cable from FTDI would do the same thing?

 

That friend of mine mentioned one might be able to configure the transfer to "9 bit, no parity" to bypass the parity bit bug. From there on in you should be able to use standard frameworks for UART communication. Would that be possible?

 

It is too big and it hadro order an adapter.

I do not understand the last bit. Did you mean capacitor that should be at the stereo jack's end?

 

Alex

[LX.NET]

I like the idea that someone takes over the handy development and fixes the bugs, crappy sound etc which are still in.

Even in the nevest version there was a bug in collision of scaled sprites and the out of screen bits.

And, a improved debugging version would be very welcome.

But... I think it would be much much better to continue work on the sdl port, as this is the one which is used on all other emulators (mednafen), machines and handhelds. Actually, with handhelds it really makes sence to improve the comlynx over udp of handy. Anyway, as long as the development will be only for one or two systems, I will not invest my time, sorry.

 

I will put together a list of suggestions.

 

Hi Sage,

 

I understand your point. I will also take a look at the SDL port of the code. Most of the Handy C++ code is still in there, so no big changes there. Most of the emulator code I have seen for other systems seem to include the C++ source files and compile them as part of the entire emulator, instead of a library (.dll) file. Some improvements in that regard could be made.

 

It's great that you know about bugs in the Handy emulator. Maybe we can get them collected so I can start figuring out what might be wrong. I did notice the following things:

• some irregularities in Joust (red area under bottom platform runs too far to the right)
  
• crash of Xybots (did anyone else experience these?)
  

Could you elaborate a bit on the bugs you noticed? Keeping my eyes open for those will be pretty easy for me to do.

 

Also, what debugging improvements are you looking for. I have no idea what you Lynx devs are looking for. I found it easy to be able to render/move around and scale sprites that were currently being drawn. I did so from the Visual Studio debugger, but it wouldn't be too difficult to extend these kinds of things to the emulator level, like in Handy.

 

I think I will try to get in touch with Keith Wilkins to ask for permission to carry forward his codebase. I did have short contact with him back in 1998 (or thereabouts) on helping him with the development of Handy. A couple of months ago I contacted him again, but had no reply. Does anyone have a current email address of Keith? PM me if you do.

 

Looking forward to your list of suggestions.

Alex

[+karri]

From the cc65 docs I wrote this:

 

The ComLynx port has Tx and Rx wired together. Every byte is sent to all connected Lynxes. Only one Lynx can send at a time. There is no protocol created for communication. You are on your own.

 

If the Lynx returns framing error then it is likely that another Lynx is sending data at the same time.

 

The Lynx can also send a break and receive a break. The Lynx break is recognized if the bit is down for 24 bit cycles or more.

 

To send a break you just set the break bit.

 

The length of the break depends on how long this bit is down.

 

The driver supports the baudrates:

 

   62500
   31250
   9600
   7200
   4800
   3600
   2400
   1800
   1200
   600
   300
   150
   134.5
   110
   75

 

The parity bit supports MARK and SPACE. It also supports EVEN and ODD parity but the parity bit is included in the calculation. Most of us don't want it this way. But there is nothing we can do about it.

 

The Lynx hardware will always check parity on incoming traffic. Currently the driver cannot receive data from standard PC's due to this parity bug. For working with Lynx to Lynx communication use EVEN parity.

 

To send data to standard PC's use MARK or SPACE as parity setting.

 

There is always only one stop bit. And the data length is always 8 bits.

 

We have no handshaking available. Even software handshake is impossible as ComLynx has only one wire for the data.

 

Both transmit and receive are interrupt driven.

 

--

Regards,

 

Karri

[sage]

 

The driver supports the baudrates:

 

 

you dont have to care about speed if you anyway send the packets by "software" lets say udp.

[LX.NET]

Thanks Karri and Sage for your information,

 

 

The driver supports the baudrates:

 

 

you dont have to care about speed if you anyway send the packets by "software" lets say udp.

 

To clarify a bit on what I mean with ComLynx over the Internet. I envision the client-PCs to which the individual Lynxes are connected to be tied together in a larger network. Details on what this larger network should be are not clear to me now. Given the broadcast nature of the ComLynx communication the network might be UDP based (client/server) and/or P2P (peer to peer). Each of the client-PCs will act as a mere pass-through connector, doing nothing more than sending the data coming from the ComLynx cable to the network and vice versa. No intelligence and no need to understand the data. That's why I mentioned the 9 bit, no parity data sending ... on the client-PC. That way, the parity bit with bug will not matter as it is seen by the PC as additional data and just passes it on.

 

Am I making at least some sense here?

 

Does anyone know what the maximum latency is that the ComLynx related logic is willing to accept? Or the baud-rates that is used for the commercial games? From the latter you could derive some indicative numbers for the latency maybe.

 

Alex

[+karri]

 

Does anyone know what the maximum latency is that the ComLynx related logic is willing to accept? Or the baud-rates that is used for the commercial games? From the latter you could derive some indicative numbers for the latency maybe.

 

Alex

 

The maximum latency is problematic. In real-time games you need very low latency. In board games the latency can be seconds without affecting anything.

 

But most games allow for dropped packets by design. So UDP is ok. If you lose one packet it does not matter.

 

I would suggest to use Boost Asio for writing this part on the PC. It has support for both serial and Ethernet. It is also reactor-based and is run in one thread only.

 

So basically you have listening sockets (one for ComLynx and one for your UDP port).

 

The code itself is like

 

start_udp_read:

// binds to udp_read_complete

 

start_ComLynx_read:

// binds to ComLynx_complete

 

start_udp_write:

// binds to udp_write_complete

 

start_ComLynx_write:

// binds to ComLynx_write_complete

 

Then the engine waits for any condition to complete and goes on from there.

 

I can volunteer to write this part

 

The good thing is that this will never hang or break due to fails.

--

Karri

[LX.NET]

 

Does anyone know what the maximum latency is that the ComLynx related logic is willing to accept? Or the baud-rates that is used for the commercial games? From the latter you could derive some indicative numbers for the latency maybe.

 

Alex

 

The maximum latency is problematic. In real-time games you need very low latency. In board games the latency can be seconds without affecting anything.

 

But most games allow for dropped packets by design. So UDP is ok. If you lose one packet it does not matter.

 

I would suggest to use Boost Asio for writing this part on the PC. It has support for both serial and Ethernet. It is also reactor-based and is run in one thread only.

 

So basically you have listening sockets (one for ComLynx and one for your UDP port).

 

The code itself is like

 

start_udp_read:

// binds to udp_read_complete

 

start_ComLynx_read:

// binds to ComLynx_complete

 

start_udp_write:

// binds to udp_write_complete

 

start_ComLynx_write:

// binds to ComLynx_write_complete

 

Then the engine waits for any condition to complete and goes on from there.

 

I can volunteer to write this part

 

The good thing is that this will never hang or break due to fails.

--

Karri

 

Picking up where we left off.

Karri, great idea! It would be really good if you could collaborate on this. I've taken a quick look at the Boost Asio library and it seems like a good candidate.

 

Some quick thoughts:

I saw that it can handle both IPv4 and v6, UDP and TCP. Do you know if it can do peer-to-peer network handling as well (maintain the mesh etc)? The reason I am thinking about a P2P network is that it would not require a hosted server to connect players to each other.

I have no idea which is the faster option: a P2P or client-server network? It could very well be. All of this remains to be investigated.

 

My proposal to continue:

Start a separate thread to keep all of this together. Anyone second that?

[rush6432]

Just thought id chime in here. i did some testing like this with the jaguar (over the internet and ethernet on a lan) which seemed to work but the code does need to expect latency of some sorts. if your communication speed is lower, the better chance you have of the game being smoother as odd as that sounds. If you have for instance 9600 baud or lower and your internet connection is say 5-10mbps then you have a good chance of having a decent connection. distance does depend however. I managed to use the jaglink which has a max323 chip i believe which converts to serial signals and made an adaptor to convert to db9 and took input from serial ports on each computer and tunneled between a UDP connection

[obschan]

You can also imagine combining the Lynx emulator (be it Handy or my C# implementation) as a debugger for the Lynx game project (in the same environment). This way you could debug at multiple levels: tooling support from the emulator and Visual Studio debugging while in the emulator (kind of meta-debugging)

Hi Alex,

 

I would love that, that will definitively boost the development process, now debugging is such a pain.

Have you made any progress there ?

 

Thanks.

[LX.NET]

Hi Alex, I would love that, that will definitively boost the development process, now debugging is such a pain. Have you made any progress there ? Thanks.

Not that much progress actually. I have been thinking about two scenarios for debugging:

1. a specialized version of the emulator, much like Handy has a normal and developer version.
   
2. tight integration into Visual Studio, which is the most powerful, but also the most limiting in terms of reach for developers on other platforms (than Windows).
   

Do you have any specific funtional requirements for debugging support in mind?

 

Alex

[sage]

gdb interfce would be nice :-)

[+karri]

Not that much progress actually. I have been thinking about two scenarios for debugging:

1. a specialized version of the emulator, much like Handy has a normal and developer version.
   
2. tight integration into Visual Studio, which is the most powerful, but also the most limiting in terms of reach for developers on other platforms (than Windows).
   

 

One nice IDE is Code::Blocks. It is very much like Visual Studio, much smaller than Eclipse and easy to configure for cc65 compilers.

 

It also runs on Windows and Linux.

 

I have used it a little but being more of a shell script guy I prefer very simple text based tools.

 

--

Karri

[obschan]

Do you have any specific funtional requirements for debugging support in mind?

Nothing really specific but since you are porting handy, maybe adding the C equivalent to the ASM debugger, and variable watches can be a quick start.

But I agree, support of Code::Blocks or Visual Studio would be better.

I am currently using Code::Blocks, but can switch to Visual Studio as you seem to be a Microsoft guy