Multiplayer link cable

بواسطة aoineko

Paragon (1132)

19-05-2023, 14:40

Hello,

I'm looking for information about link cables to transfer data between MSX (especially for game purposes). This could be a next addition for my MSXgl library.

I found information on the hardware part for the Konami cable for F1 Spirit 3D and for the JoyNet standard, but nothing on the software part.

Here are some questions:
- Are there any other types of link cables? I think I read something about a MIDI cable and also a game using the joystick port but incompatible with the Konami/JoyNet cable.
- Are there emulators compatible with some of these cables?
- Is there any information about the programming part of these cables? I'm a noob at electronics so hardware information doesn't help me much. I just need the basic information: how to send or receive a byte (I know it has to be done in chunks of 1 or 2 bits but that's all).
- How is the synchronization of sending and receiving done? I imagine that if you write on the joystick port when a data has just been received, you risk losing this data, no? A timeline of events would help a lot.
- Is there an exhaustive list of MSX games that can be played on multiple machines?

EDIT: I found a piece of example code for JoyNet but can anyone explain the theory behind the read: and write: functions?

بواسطة Hydragon

Paladin (751)

19-05-2023, 18:13

Not sure if it's relevant, but I remember a game called Triplex, multiple people could play together and if i recall correctly it had to do with the MSx computers being linked through the MIDI interface of the Philips Music Module.

بواسطة Danjovic

Champion (344)

19-05-2023, 18:36

Quote:

I found a piece of example code for JoyNet but can anyone explain the theory behind the read: and write: functions?

This example does not tell much about the protocol implemented, it is simply a hardware test and should require a loopback on the joystick port connecting the pins 1-6, 2-7, 3-8.

The Questions and Answers of the JoyNet Standard tells that the user is free to implement it's own protocol.

بواسطة aoineko

Paragon (1132)

20-05-2023, 00:25

I can handle the communication protocol, but I need the basics: how to send and receive data at low level.
I understand that we have to read/write to the joystick port (a bit like we did for the communication with the NinjaTap) but I don't understand how we are supposed to synchronize the reading/writing knowing that another computer is also reading/writing to the same port.

بواسطة Danjovic

Champion (344)

20-05-2023, 14:37

As the joystick ports can not generate interrupts you need to implement a handshake between the computers on the network, and that will require at least one of the (three) data lines.
You can start with:
8-ATT Out, 7-Send1, 6-Send0, 3-ATT in, 2-Receive1, 1-Receive0

Bus in Idle , line 8 in low, lines 6,7 floating high (default MSX state)

Who wants to send :
Rise line 8 (ATT) and put a command of 2 bits of data on the lines 6,7. this allow you to signal up to 4 commands. lets say:
00-send data
01-send block size
10-to be defined
11- break (sync)

the other side after polling the joystick port and recognize the command will respond with data on the lines
00-bus conflict
01-acknowledge
10-ready
11-no response, or busy

the sender will poll the receiver until get the 'ready' response.
after that, the sender will transmit 8 bits of data, in groups of 2 bits flipping the ATT line every 2 bits.
At the end of the 4th cycle the receiver should put an acknowledge on its send data lines, to tell the sender that he received the bytes.
The then the sender can return to idle, and in the sequence thre receiver can return too.

You can use the block size command to optimize the time lost in the handshake.

that's just a the sketch of a protocol, you can think of similar scheme, according to what you have in mind. You can also optimize the protocol to reduce the switching on register 14/15 made to psg on each side.

بواسطة cjs

Master (143)

20-05-2023, 18:32

Note that Danjovic's method will work only if your network "ring" is just two computers; he's using the upstream ACK signal as ATT to downstream, so upstream and downstream must be the same computer.

If you need reliable communications along a ring, I would use D0 as a clock for a synchronous protocol:

The upstream computer simultaneously toggles D0 output and sets the D1 output to the data value, and then waits for its ACK input to toggle.
The downstream computer polls the D0 input and when it chnages state, reads the bit from D1 input and then toggles its ACK output.

You'd then need a higher-level protocol for framing and synchronisation; perhaps a 1 start bit, 8 data bits, and a 0 stop bit. Send at least ten 0s to synchronise (as ten 0s is not a valid byte) and the next 1 you send after that will start the next byte.

This is unidirectional along the ring, of course; any computer that's read a message that's for another computer on the ring has to pass it on downring.

بواسطة Danjovic

Champion (344)

21-05-2023, 15:58

Indeed, I was considering the Konami link cable.
I can think of some methods with the Y cable defined by the Joynet document, like the propagation of the ATT signal along the ring to put all participants in listen state, and then define a routing mechanism, but I haven't figured out a simple mechanism to prevent collision detection in such ring.

A different approach would be share the bidirectional lines among all participants, and use a diode or a transistor to make a bidirectional line out of pins 8 (Pulse) and 1(UP).

With three bidirectional lines it is possible for instance to define an arbitration and a routing mechanism 'inspired' on CAN bus (maybe LIN). The main difference is that one line should be used to get all parts listening, then a second line would be used for sending the protocol data.

بواسطة cjs

Master (143)

21-05-2023, 19:23

Danjovic wrote:

I can think of some methods with the Y cable defined by the JoyNet document, like the propagation of the ATT signal along the ring to put all participants in listen state, and then define a routing mechanism, but I haven't figured out a simple mechanism to prevent collision detection in such ring.

There cannot be collisions in a ring network; each line has only one sender and one receiver. As soon as you add another sender to a line (introducing the possibility of collisions) it's no longer a ring network.

To make sure the terminology's clear here, JoyNet has three lines between each node, two going downring and one going upring. (This technically makes it a bidirectional ring, but from the sounds of it it's more often used as a unidirectional ring with the upring line being used only to ack data from the computer directly connected upring.)

Quote:

A different approach would be share the bidirectional lines among all participants, and use a diode or a transistor to make a bidirectional line out of pins 8 (Pulse) and 1(UP).

I guess the word "the" in the above is a typo? JoyNet has no bidirectional lines (though some of the lines use bidirectional pins on the joystick ports in one direction only).

But yeah, if you're talking about creating a new (non-JoyNet) connection between all the computers with pins 6, 7 and 8+1 wired in common amongst all of them (making it a broadcast network), that would work, and probably be a better solution for some applications.

This is how Commodore did their serial bus used with VIC-20 and C64 peripherals. And, with three lines for A̅T̅N̅, C̅L̅K̅ and D̅A̅T̅A̅ you could probably even re-implement their protocols, though I'm not saying that would necessarily be a good idea. :-)

BTW, looking at the schematic I noticed that pin 8 is wired with a pull-up straight to IOB4 and IOB5 on the PSG, so in theory it could be used bidirectionally without any extra hardware. This would, however, entail setting port IOB to input mode (for all pins; they can't be set independently) which would disable input on pins 1-4, 6 and 7 because the 74LS157 select line would be left floating. (And it would also leave the Kana light in a random state, or maybe always off.) Still, there might be some clever way to make this work.

بواسطة cjs

Master (143)

21-05-2023, 19:56

Danjovic wrote:

A different approach would be share the bidirectional lines among all participants, and use a diode or a transistor to make a bidirectional line out of pins 8 (Pulse) and 1(UP).

Thinking about this further, you don't need even a diode to make a bidirecitonal line out of pins 8 and 1: looking at the schematic I linked above, these can be safely wired together on a joystick port. This will leave you with two typ. 10k external pull-ups on the line, plus whatever the internal pull-up on pin 8 of the chip is (another 10k?) giving you say a 3k3 pull-up, which I am guessing should stilll be ok (the PSG pin then needs to sink 1.5 mA instead of 1 mA).

The potential problem comes in when you wire that pair to the same pair on other machines; every machine you connect adds another pair of 10k external pull-ups plus the internal pull-up in parallel, so the current the PSG pin needs to sink rises to 3 mA for two machines, 6 mA for four machines, and 12 mA for eight machines, which may be getting a bit high.

Unfortunately the datasheet doesn't seem give a specification for how much current an I/O port pin can sink.

بواسطة sdsnatcher73

Enlighted (4278)

21-05-2023, 21:28

Why not use RS232 protocol with RTS/CTS (Ready or Request to Send/Clear to Send). A ring can be made easily by implementing a target ID in every message. If you receive a message for your target ID you handle it, if it is not your target ID you forward it to upstream. IDs could be managed by end user or even handed out by a master (then all slaves can be assigned an ID by sending a initialization message handing out IDs upstream from the master, if an init is received and the slave has no ID it takes on that ID. If the slave has an ID it will forward upstream, if the unit message is received back by the master it knows the number of slaves)

بواسطة Danjovic

Champion (344)

22-05-2023, 00:08

Quote:

There cannot be collisions in a ring network

With the method I have proposed to put all the machines in "wait" to workaround the lack of interrupts you can not differentiate a machine propagating the ATT signal from a machine generating it to start a message. So there is a probability of two machines start a transmission at the same time.

Quote:

...share the bidirectional...

I mean the Joystick Port bidirectional lines, pins 6 and 7

Quote:

...if you're talking about creating a new (non-JoyNet) connection between all the computers...

Precisely!

Quote:

looking at the schematic I linked above, these can be safely wired together on a joystick port

Nope. Pin 8 is directly connected to a push pull output of the PSG. Wire them together may damage the pins during a bus contention.

Quote:

Unfortunately the datasheet doesn't seem give a specification for how much current an I/O port pin can sink.

No need to worry. The current on bidirectional pins (6,7) is sink by (the internal) LS06s which are rated to 40mA. Nevertheless every 10k pullup will sink only 500uA (even assuming Voh=0Volts). Eight machines will sink 4mA, and so on .
But this is a good point to consider to make a bidirectional line out of pin 8! A transistor will suit much better than a diode.