My ComLynx journey

[KanedaFr]

So, it"s time to add multiplayer support on my game (yeaahhhhh at last!)

 

I read every post available on AA about the ComLynx, very interesting.

 

I have already 2 questions :

- if player 1 sends a byte, since TX/RX are on the same line, will it receive it too (let's call it echo) ? or only the other networked Lynxes ?

- is there any update/feedback on @42bs 's usb comlynx described here ? I already had some CP2022 so I'd like to make one to sniff/debug every message sent ...so I only need to order diode and 2.5 jack ?

 

[42bs]

I am using now an FTDI232(AZDelivery) board and do not use the diode anymore.

 

It works great even with TURBO (1MBd) mode.

For flashing or BLL upload I use Python3 with pySerial and it works nicely.

 

And yes, the bytes sent out appear are echoed.

 

Edited May 16 by 42bs

[KanedaFr]

My headaches started again...

 

Let me explain :

if I try to do like LX explained on his RedEye analyse.

at logon, if every Lynx announces its ID, how could I know if another Lynx gave the same ID than me or if it's my echo ?

 

My first idea was to add some kind of random value (taken from a counter when user pressed a button to be sure it's unique) at the end of message for control but it raised another issue:

if several Lynxes (included mine) talks on the same line, my received buffer will be filled by the bytes of which Lynx(es) ?

Nothing can't avoid the possibility that buffer[0] is from Lynx 3, buffer[1] from Lynx8, buffer[2] from Lynx 2 ...no ?

 

From the RedEye analysis, they set a random delay before sending a message...a long (ms not us) delay before answering to avoid 2 Lynx messaging at the same moment

while it somehow fixes my first issue (well, reduces a LOT its probability), and secures the fact that each Lynx has its really unique own ID, it doesn't answer to my second issue but avoid it.

 

For now, to avoid conflict, based on what I understand and RedEye analysis, I plan to handle it this way

- secure the unique ID using delay at logon

- player0 is the master and ask each Lynx, one by one, to answer a question (what is your statut ?)  -> every Lynx knows the statut of the others, but a Lynx can"t rise an event (like "I kill P2" or "I'm dead" or "I did a special move")

 

 

I assume some of you already thought about it so sorry if it's stupid or already seen.

 

Note I read Championship Rally comlynx code and didn't see the part about conflict, but perhaps I missed it .
I only understood (?) its unique ID detection is based on the fact there is already something on the received buffer or not (ie  not the first one)
This assume all the Lynxes should be powered when one launches the lobby.

You can't access the lobby and wait for others to power on and connect to the network using this method, no ?

 

[42bs]

https://github.com/42Bastian/new_bll/blob/master/demos/logon/logon.asm

 

1 random should be related to some real random stuff like button press.

2 wait a random time

3 each Lynx claims an random ID, sends this out on

4 if it sees it's ID (not immediately, as this is the echo) then back to (2)

5 if there are no more conflicts (other Lynx' see them also), declare initial phase ended.

6 the Lynx with the lowest ID becomes master

 

Now it depends on you game how to continue:

- in T-Tris I send only events (line filed, paused)

- in Isolation I send button presses and feed them into the "handle button" routine as if it were locally read

 

A master might "ping" all others to detect a Lynx being disconnected.

 

Note: The random part is essential. If it is seeded w/o human interaction you need a substantial delay on boot.

Edited May 16 by 42bs

[KanedaFr]

1 hour ago, 42bs said:

4 if it sees it's ID (not immediately, as this is the echo) then back to (2)

hmmm... does it mean I can detect echo ?

 

something like : 

1. send byte
2. test received byte, if same, delete it
3. loop

or perhaps

1. clear receive buffer
2. send data (n bytes)
3. clear receive buffer

or even better, just ignore it

1. disable receiving (with RXINTEN)
2. send data
3. reenable receiving

???

 

For the other points, it seems that I wasn't totally wrong for logon, so I'm happy  

 

===

 

So on TTris, any Lynx could send a message at any moment (and all others will receive it) ?

Unable to detect if it was received or if some of the lynx missed it ?

 

Anyway, it means I have to find the way it 'll works the best with my gameplay...

 

Edited May 16 by KanedaFr

[42bs]

I do disable RXINT while sending.

 

T-Tris can send any time, but loosing data is not very likely. Isolations sends every VBL the current buttons. Since it is a round game, no need to synchronize extensivly.

 

BTW: The "8 player limit" comes from the RedEye code which sends status data during the 3 VBL lines.

[KanedaFr]

Thanks, time to code

[KanedaFr]

Now that I get deeper on the serial stuff, I noticed that the CC65 comlynx driver also disable the RX int when you want to send data

so, finally, echo should not be an issue 😀

[sage]

Depending on the type of game (complexity), i suggest to use existing comlynx code and dont try to write your own. getting logon-ID, timeout/resubmit and checksumming done properly is hell. (if you need it)

 

Concerning the USB-comlynx. you have a large choice nowadays which hardware to use. There are several 5V compatible adapter on the market which just need the wire and connector soldered.

You can even use most arduino/MCU boards which support 5V. you just need support for

• unusual baud rates
• different parity settings for send and receive (can also use the RX, TX from two different configured serial ports on MCU)
• 5V on send and receive

Reminder: For stability, it is better to add a diode between RX and TX pins.

 

[KanedaFr]

5 hours ago, sage said:

Depending on the type of game (complexity), i suggest to use existing comlynx code and dont try to write your own. getting logon-ID, timeout/resubmit and checksumming done properly is hell. (if you need it)

unless I missed something, the only code I know is comlynx driver on CC65...

If you have another source, I'll be more than happy to use it and avoid pitfalls!

 

5 hours ago, sage said:

Reminder: For stability, it is better to add a diode between RX and TX pins.

thanks, exactly what I was looking for : confirmation to use this diode or not -> some of the schematics I found use it, some not

[sage]

The Diode is mandatory if you want to use the adapter for snooping the traffic of other machines, otherwise TX will always pull the line.

 

The comlynx redeye code has been spread, but it is for the EPYX development environment (assembler, libraries). there is a private port for lyxass assembler. but no port for cc65