Hi!
>o When a computer wants to send, it starts it's CLOCK and waits for the
> receiving side to set the READY signal
>o Sending starts with 1 start bit (high signal)
>o Followed by data and odd parity
>o Sender waits for a drop of the READY signal for 1 clock cycle as an ACK
>o If it doesn't drop withing X cycles after sending the last bit a resend
> is in order (step 2)
>o If there is more data to send, return to step 2
>o All data sent, stop CLOCK signal
>o Receiver drops READY signal
Why do you want a CLOCK signal? I'm a big fan of asynchronous
communication, because it's easy and robust.
One way of doing asynchronous communication is a handshake. I think a
2-phase handshake is appropriate for the joystick port communication protocol.
In a 2-phase handshake you have 2 control signals:
- request (REQ), written by the sender
- acknowledge (ACK), written by the receiver
Apart from the control signals you also have a number of data signals. We
have only 1 bit left, so we'll use 1 data signal.
This could be a handshake cycle between computer S (sender) and R (receiver):
S: write DATA
S: signal REQ
R: read DATA
R: signal ACK
A signal in a 2-phase handshake is the flipping of a bit, so the transition
from '0' to '1' is a signal and the transition from '1' to '0' is another
signal.
To make the system more safe, we can combine DATA and REQ. It still takes 2
bits, now called DR0 and DR1 (data & request).
Sending a signal over DR0 means "REQ & DATA=0".
Sending a signal over DR1 means "REQ & DATA=1".
In technical terms, this is a "one-hot" code.
Here is the reason that the DR0/DR1 encoding is safer than the REQ/DATA
encoding:
It takes some time for a signal to go through a wire. This delay depends on
many factors, for example: length of the wire, temperature, material of the
wire, strength of the signal. The result is that you never know how much
the delay is exactly.
There are two ways to combat this:
- calculate a maximum for the delay
- make the encoding delay-insensitive
The first way is more difficult, and in this case the second way is as
efficient as the first one. So I say we should go for the delay-insensitive
way.
Using the REQ/DATA encoding, you first send the DATA and then the REQ. But
because of the delays in the wires, it's quite possible that sometimes the
REQ will arrive first. If that happens, the old (invalid) data will be read
and you have a transmission error.
Using the DR0/DR1 encoding, you send a signal on either DR0 or DR1. Because
you send only 1 signal, the wire delay doesn't matter. So this encoding is
delay insensitive.
Note that the protocol I described can use the same hardware that Patrick
Lina proposed. The protocol only tells you how to send bits over the
network. The next step would be to describe the format of a transmission.
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
