Programming protocols

The protocol you use can be any protocol you want, provided ofcourse that it is programmed correctly. In the case of JoyNet, the hardware is standarized, not the software. If the hardware is the same, the compatibility between programs using the same protocol is guaranteed. If you want to make a standard protocol, then you are free to do that. There are many ways to establish communication between computers, and the algorythm and the protocol may vary a lot from case to case. So each programmer can use and call the pins just like he wants (D0, ACK, CLK, CTS, IN0, etc...).

However, there are still some STANDARIZED guidelines which every protocol has to use:

Detecting the connection and other computers (and how many of them are available) is a task of the software.
The protocol MUST be able to use Joystick-port 1 as well as port 2, for else some computers with problems on one of the joystick-ports won't be able to use the software and JoyNet.
The protocol should not hang the computer when the cable is disconnected. There are two possible solutions:
1. The protocol gives a timeout when it has to wait too long for response,
2. The user can quit the protocol/network game by pressing ESC.

Also, I have designed a fast bidirectional 2-bits protocol for use with 2 MSX-computers, which includes a CRC check. However, I have not programmed it yet. But if you are interested, email me and I will send it to you. Also, you could ask some people on the MSX Mailinglist if they have designed a protocol. Some people working on a JoyNet-project at the moment are Maarten ter Huurne and Shevek.

Back to the top

Some suggestions

If you don't understand something, you can ask me. And if even I don't understand it (imagine!), then I'll post in on the mailinglist. Also a good idea, by the way, if you want multiple opinions. Go to JoyNet - Main for more info.

If you really want to know EVERYTHING, you should read the messages at Sean Young's International MSX mailinglist archive.

Alwin Henseler gave some tips... Although some parts are not correct, for example the difference between synchronous/asynchronous. But it's a inspiring alternative idea, although this way of transmission is not recommended (read the message below)... Click here to read them.

The speed of JoyNet

- Some test-results of Maarten ter Huurne using his own protocol:
"I just made some routines for sending data between my PC and my turbo R. The routines are as optimized as I could get them."

Results:	`PC -> turbo R (R800 mode): 14 kilobyte per second turbo R (R800 mode) -> PC: 12 kilobyte per second PC -> turbo R (Z80 mode): 3.6 kilobyte per second turbo R (Z80 mode) -> PC: 3.2 kilobyte per second`

"To estimate the number of errors, I transferred the same 16K data back and forth a lot of times. After 2500 transfers, an error occurred. So I was able to send 16K * 2 * 2500 = 80,000K before the first error. I think it's safe to say that a 32 bit CRC is overkill... However, to backup a harddisk, some simple error detection is necessary."

Note of Grauw: because Maarten used a PC for testing, this are ofcourse results at top speed, for the PC checks X times faster than the MSX so if the turboR sends a bit it IMMEDIATELY gets its answer and doesn't have to wait a loop to let the other computer process the data. Also, this is done with the JoyNet->PC-cable, so the conditions are different. But I still think this is a reasonable estimate.
By the way, MtH's protocol uses 1 bit per transfer... If you are only communicating between 2 computers you can use a 2-bit protocol. Useless to say this is a lot faster.

Some ideas for protocols

Here I will suggest 4 protocols, one handshake-protocol and three transfer-protocols.

This will be added ASAP.

The interrupt-problem

When programming a protocol, you definitely cross the interrupt-problem. The problem is, that on the standard MSX-interrupt the pins of the joystickport are being reset by the interrupt. I know two ways to prevent this, one simple one, which use is however quite limited, and one more difficult, but as soon it's ready it is easier to implement into the rest of your program. Also, this second way can be used in Basic-programs.

This will be added ASAP too.

Back to the top

Questions and answers

Alwin wrote:
"If JoyNet only standardises the cable, than that leaves the programmer free to choose for a synchronous or an asynchronous communication method."

Response of Maarten ter Huurne:
It does.
I just strongly recommend an delay-insensitive asynchronous communication protocol, because that will give far less trouble. For example, it is insensitive to cable lengths and it will run at any clock speed.

Alwin wrote:
I think you are both mistaken here. In synchronous communications, the exact point in time at which the data signal(s) is sampled, is determined by an 'extra' signal, an other signal, and with that, the data stream is SYNCHRONISED with that other signal.

Response of Maarten ter Huurne:
What you call an 'extra' signal, is just as much part of the signal as the data signals are. Dependant on the encoding, it may not even be possible to say "these bits are data and these bits are timing". Take for example the encoding I proposed on this list a while ago: There are 2 signal bits: D0 and D1.
Flipping of D0 means "a 0 is transmitted".
Flipping of D1 means "a 1 is transmitted".

Note from Grauw: after that you can use the ACK-signal to notify the sender that the data is recieved.

MSX on the network!
~Grauw