Porting ComLynx Epyx Redeye code to CC65

[LX.NET]

Continuing the discussion that started in the Karate World Tour thread.

 

For convenience sake some quotes and fragments:

 

Karri:

"I believe all the source code is available. Carl just posted it in this thread.

It appears to be spread out into two layers: comlink and msgmgr.

Perhaps the driver could go into a single file redeye.s with a companion redeye.h file for using it from cc65."

 

Shawn Jefferson:

"I'd probably think about splitting it up a bit... the logon code should be separate, as it runs somewhat autonomously and you could put it into a different segment so it can be loaded when required only."

 

Resources so far:

Background document from Epyx documentation on Redeye (a must-read!): https://atarilynxdev...ntation/redeye/ or scanned http://atarilynxdeve.../redeye-doc.pdf

ComLynx_BW.zip

testredeye.zip

[LX.NET]

I've put together an archive containing all the unaltered original sources of the Epyx development kit related to the redeye code. I think (barring any mistakes) that it contains all code you would need to compile the testredeye program. I've added my own version of testredeye.hsf and title1.bin for those that have the Epyx assembler and linker.

 

Okay, Karri, you are good to go

 

If you need anything (resources or help), please let me know.

RedeyeSources.zip

[Songbird]

Here are some additional extracted routines from the BW source, including parts of the main game engine where it checks the transmission and sends data for all players. It does appear to heavily utilize the Atari libraries for comlink and msgmgr. Enjoy!

 

BW_comlynx.zip

[Songbird]

Also, throughout the rest of the BattleWheels code, it looks like it does one of two sequences after some local variables are updated:

 

jsr launch_redeye_joytest
jsr load_comlink_data

 

or

 

jsr launch_redeye
jsr load_comlink_data

I haven't studied it enough to understand why it does one vs. the other. The 'joytest' routine apparently checks for pause before invoking the 'non-joytest' routine.

[+karri]

Thanks. The code looks well made. The logon stuff needs to be in its own segment so that it can be discarded after use. The runtime could go into the main area as it is needed all the time.

 

One thing that bothers me a little is that there is some self-modifying code there as well. It really does not matter as the Lynx CODE segment lies in RAM and not in ROM. I assume I just leave it. Bad programming habits. But imho it is better to copy it bit for bit as the original authors wanted to have it and just fine tune it to fit the cc65 environment.

 

From the architectural view this is a strictly real-time ComLynx. All the units will talk constantly sharing all info for every display frame. My assumption was that ComLynx should only talk when it has something to say. But the Redeye architects had different ideas.

 

The next thing is then to have a globally allocated GAME_ID list. The Redeye will check that the versions are compatible during logon.

 

GAME_ID - The unique game ID number.
Range: 1 to 65534
The following numbers are in use:
0 – test programs
1 – Gauntlet the Third Encounter
2 – Zarlor Mercenary
3 – California Games
4 – Xenophobe
5 – Slime World
6 – RoboSquash
7 – Warbirds (Space Wars?)
83 – Shanghai
4949 – Rampage
65535 – test programs

 

One way to avoid clashes would be to use the launch year+month for future games.

 

1408 = game launched in year 2014 August.

 

With the current launch rate there should not be too many clashes.

[+karri]

The interrupts used by cc65 in case someone wants to know will be:

 

HBL_INTERRUPT = TIMER0_INTERRUPT

COMLINK_INTERRUPT = TIMER1_INTERRUPT

VBL_INTERRUPT = TIMER2_INTERRUPT

 

SERIAL_INTERRUPT = TIMER4_INTERRUPT

LOGON_INTERRUPT = TIMER5_INTERRUPT

 

SND_INTERRUPT = TIMER7_INTERRUPT

 

The HBL interrupt is also used to create a real-time clock. So you can use some time functions to get the local time since startup.

The SERIAL baud rate is generated by timer 4.

This leaves only timers 3 and 6 as general purpose timers for your own code.

The timer 5 can also be used after the logon is complete.

 

The new timer COMLINK is used for monitoring when packets are supposed to arrive from different Redeye connected Lynxes.

The timer LOGON is used during logon to generate a 500ms wait that is needed in the process.

[+karri]

Status update:

The code compiles with a few errors. The plan is to put it into bitbucket once it compiles without errors.

The obvious second step is to compile the testcode against it to see if it could logon against the precompiled binary.

 

If this works it would be nice to create a small ComLynxed game to test it. Not pong.

[Songbird]

Thanks, Karri. Looking forward to hearing more about this.

 

From your previous post, do we really need to monitor GAME_ID? I am honestly not sure if all the existing games (Atari and hobby) use mutually exclusive GAME_IDs, and if they don't, what's the worst that could happen? You can't link Xybots to Champ Rally?

[LX.NET]

Great going, Karri. Can't wait to see how we will integrate this into the CC65 stack and tool chain.

I would love to do a Lynx version of Combat (from the Atari VCS), or at least the tank battle part of it. Should be doable and simple enough as a test program.

 

From your previous post, do we really need to monitor GAME_ID? I am honestly not sure if all the existing games (Atari and hobby) use mutually exclusive GAME_IDs, and if they don't, what's the worst that could happen? You can't link Xybots to Champ Rally?

 

The GAME_IDs are what the Redeye code uses internally to detect wrong games trying to connect. If it is in there, why remove it?

[Songbird]

I think it's fine to keep the GAME_ID concept, I just think it is low priority to ensure uniqueness, not to mention difficult to enforce. It would however be interesting to have a complete map of all GAME_IDs. I actually don't know which IDs are used by Champ Rally and Loopz, and I published those games...

[LX.NET]

I think it's fine to keep the GAME_ID concept, I just think it is low priority to ensure uniqueness, not to mention difficult to enforce. It would however be interesting to have a complete map of all GAME_IDs. I actually don't know which IDs are used by Champ Rally and Loopz, and I published those games...

 

Good point. With our small community we could make an effort to assign the IDs before a ComLynx game is finalized.

I tried to look into the multiplayer games and found it hard to locate the Redeye code in the binaries. I did a simple binary search, but from what I saw the compiled version of the Redeye code seem to be using slightly different code-bases. I could verify that SlimeWorld, Xenophobe Gauntlet and Zarlor Mercenary have the mentioned (Epyx documentation and testredeye source code) IDs, but not for California Games. I had real trouble finding the particular piece of code. The ID for Tournament Cyberball seems to be 0x05D0. The other IDs are all also 0x05 prefixed. If anyone is interested I can put up the positions in the ROM binary.

[Shawn Jefferson]

Thanks. The code looks well made. The logon stuff needs to be in its own segment so that it can be discarded after use. The runtime could go into the main area as it is needed all the time.

Agree.

 

From the architectural view this is a strictly real-time ComLynx. All the units will talk constantly sharing all info for every display frame. My assumption was that ComLynx should only talk when it has something to say. But the Redeye architects had different ideas.

Really it's meant to be run once per game frame, not display frame, but I don't think anything in the RedEye code that forces you into that method, you could send data whenever you had data to send. Most games will probably just want to send joystick movements anyway, and each Lynx keep track of all the game state separately. I suppose you could envision other types of communication and game state synchronization methods though...

 

The next thing is then to have a globally allocated GAME_ID list. The Redeye will check that the versions are compatible during logon.

 

GAME_ID - The unique game ID number.

Range: 1 to 65534

The following numbers are in use:

0 – test programs

1 – Gauntlet the Third Encounter

2 – Zarlor Mercenary

3 – California Games

4 – Xenophobe

5 – Slime World

6 – RoboSquash

7 – Warbirds (Space Wars?)

83 – Shanghai

4949 – Rampage

65535 – test programs

 

One way to avoid clashes would be to use the launch year+month for future games.

 

1408 = game launched in year 2014 August.

 

With the current launch rate there should not be too many clashes.

Makes sense!

[+karri]

Game frame != display frame. Of course. Silly me.

 

Now the code compiles without errors but there is still some small things with how to deal with logon interrupts when the code is gone. I did not see a "reverse" interruptor. So I probably just add a test somewhere.

 

Another thing that needs re-coding is zeroing the variables. In the original code the author had the logon segment and the comlink segment variables after each other so you could erase the area in one go. Now we need to do two erases as the linker may place logon anywhere.

 

The idea of sending over joystick presses instead of game data is a bit "alien" to me. If I was to code "pong" as a multiplayer I would probably send the position of my own paddle, hit + new direction of ball or info that I missed the ball. That would be a lot more robust imho. The gamplay would then move to my lynx when I have to catch the ball and to the opponents lynx after I hit the ball.

[LX.NET]

Iirc the redeye code doesn't dictate what you send. I agree with Karri that sending current state is more robust against interruptions than actions. Then again, state might be too large to send, so recalculating it on other consoles based on sent actions could be better. Luckily redeye lets you make that decision.

[Lynxpro]

Status update:

The code compiles with a few errors. The plan is to put it into bitbucket once it compiles without errors.

The obvious second step is to compile the testcode against it to see if it could logon against the precompiled binary.

 

If this works it would be nice to create a small ComLynxed game to test it. Not pong.

 

MIDI Maze. Ahem.

[+karri]

Sure... What is MIDI Maze?

 

Anyway the repository is set up at https://bitbucket.org/karri/redeye/src

 

The code is still work-in-progress but at least it compiles.

[Songbird]

I think sending player input (joypad + buttons) is probably the most common networking data, particularly for older games. Random numbers needed to be pseudo-random so everything happens predictably across all networked Lynxes, so if you just send the player input presumably the Lynx can handle the rest of the updates -- calculating position, life points, inventory, or whatever. It needs to do so for all the AI players anyway, for a game like BattleWheels, so handling the updates for a networked player should be trivial.

[LX.NET]

Had a short look at the code you wrote Karri. Wow, that is a serious amount of code and work. I noticed you had to bring in a substantial part of the Epyx macros and includes to get it to compile.

 

That makes me wonder if it would be worthwhile to port that part to CC65 as well. It would mean that there is a more complete offering for the CA65 for assembler coders.

 

Any ideas what we might run into if we go that route. There will be some differences such as the way interruptor tables are created and composed. Also, the requirements for startup. Can we opt out of the C runtime?

 

Ideas or opinions anyone?

[+karri]

I see no problem in adding definitions to asminc/lynx.inc to help asm coders.

 

Actually I would also like to put the BLL macro language in there to do structural asm. We did have a discussion at the cc65 developers list for making macros like IF ELSE CASE WHILE... available as standard for coding with asm. But today it has become more difficult to add features to cc65 as the current maintainer is not too supportive to new ideas.

[Shawn Jefferson]

You can always add these as a separate library or include files. No need to include them in the main cc65 distribution. You can also not link any of the cc65 runtime if you don't want to...

[+karri]

True. The problem is just that separate files get lost during the years. It would be nice to have a special fork of cc65, bll, sprpck, lyxass, fonts, handymusic, chipper, redeye, docs, tutorials, games and forums in one place. Somewhere to be easily found.

 

Currently I am using Bitbucket as it is free. One way would be to clone repositories there and update them from the mainstream every now and then. I believe you can grant up to 5 contributors without paying.

 

Could this be hosted here on AtariAge somehow? The forum is here already.

[Albert]

Could this be hosted here on AtariAge somehow? The forum is here already.

I'd be glad to do that, what would you need on my end?

 

..Al

[Shawn Jefferson]

I wouldn't fork cc65 personally. But creating a Lynx add-on pack for cc65 seems like a great idea!

[+karri]

I'd be glad to do that, what would you need on my end?

 

..Al

 

The most important thing would be a git repository that could be accessed like

 

git clone https://git.atariage.com/lynx/redeye.git

cd redeye

# Start working on the project

 

And then we add new tools to the pinned LX.NET Programming tutorial page.

 

Stable set of tools for developers

 

Stable release 2014:

C-compiler (cc65 linux) (cc65 windows) (cc65 source package)

Extra fonts (cc65 sources)

Redeye packet communications for ComLynx (cc65 sources)

LN.NET tutorials for programming the Lynx (eBook) (http://atarilynxdeveloper.wordpress.com/2012/04/05/programming-tutorial-part-1getting-started/)

Links for user created games with free sources that can be studied. Perhaps there coul be a git repository for contrib stuff as well

(https://git.atariage.com/lynx/contrib/Solitaire) (download lnx image)

(https://git.atariage.com/lynx/contrib/Shaken) (download lnx image)

 

At some point in time we may create a new set of stable tools. But I assume that the set stays pretty stable for a loooong time. So to Shawn, ordinary programmers need a stable tool that works for years. It is not "forked" just "frozen".

 

Stable release 2020: would then come next.

Edited September 5, 2014 by karri

[Albert]

The forum has a sophisticated "Downloads" module that I am not currently not using. I could finally enable this and setup a Lynx Tools area, and the tools could sit in there. It supports versions of files as well, so if a new version comes along of any of the tools, we could update the file, and retain the older versions as well. And a discussion topic can be directly linked to a specific download, which is helpful.

 

As for setting up a git repository on AtariAge, I could probably do that as well, but need to investigate. I use git for my full-time development work, so I'm familiar with it.

 

..Al