Hello,
This is a pretty long mail, so I shall start by describing it and thus letting
you know if you want to read on or not.
This mail handles about joynet. I want there to be a standard protocol for
communicating over joynet. In the introduction I shall talk about why and
when this protocol should be used.
The reason I am posting this mail to the mailinglist and the newsgroup is that
of course this protocol must be used by everyone. It should be part of the
standard that in certain situation a standard protocol is used. I have designed
such a protocol, but now I want you, the MSX community, to propose
changes/propose a totally new protocol/agree with this protocol, so that in the
end, we'll have a protocol that everyone likes and therefore everyone will use.
So you shoul read this if you want to help developing the new standard joynet
protocol and if you just want to see the prototype. If not, the rest of this
mail will not interest you.
Please read it while typing a reply, because that way you will not have
forgotten most of your comments when you're finished reading :)
0. Version and copyright.
This is version shevek-2000081700a of this document.
This document may be freely copied, provided the version number is correctly
updated. The version number consists of the name of the last person who made a
change, followed by a dash, a serial number and optionally a letter. The serial
number should (until the year 10000) contain exactly 10 digits, the first 8 of
which encode a date. The first 4 are the year. The 5th and 6th are the month,
ranging 01-12. The last two digits are the day of the month. Example: the 17th
of august 2000 is 20000817. This date should be the day of writing. The last
two digits of the serial number are the serial number for that day. This should
only be different from `00' if more than 1 version of the document is written
that day. Additionally, a `a' or `b' may be added if the document is considered
alpha or beta (no characters other than ascii in the range 32-127 are allowed
in the document, so don't try to make alpha's and beta's. If constructed this
way, higher serial numbers will always be later versions of the document. This
does not mean it is more up to date. An author can change an old document and
add a new serial number. Anyway, let's get to the point.
1. Terminology
In this document, every time I said she/her/... it could equally well have been
he/his/... I just didn't feel like typing she/he all the time.
2. Introduction
Some time ago, joynet was developed for the MSX computer. It is a describtion
of a standard cable, which is to be used to connect computers when a network is
desired. A protocol was not added to the standard, because it was left to the
freedom of the coder to use whatever protocol she wants. This is nice in the
case of a program, run on two computers, like a game. But when a program just
wants to connect to `the network', without knowing what program is on the other
side of the connection, a standard protocol needs to be used. This document
intends to describe such a protocol. It is still very alpha.
3. When JUMP should be used
If a coder wants to make a program (probably a game) that should run on
multiple computers, she may use any protocol she desires. If she has a way of
knowing what the other side of the connection does, for example because it also
runs her software, she does not need to follow JUMP. It is advisable however,
to check if the computer is at that time in a JUMP network, because the network
would be suffering from the (for JUMP) bogus packets that seem to keep coming
in.
JUMP should be used to connect to a network in general. If the coder doesn't
know what the network is, for applications like NFS, telnet and ftp. In such
a case using JUMP is mandatory.
4. Why JUMP should be used
The reason to have a standard protocol is simple. many coders can make many
network programs and they all want to communicate with each other. If there is
no standard protocol, every computer would need drivers for all protocols.
Drivers? Most programs would probably not even offer the possibility for custom
network drivers. So a program written by X can only communicate with other
software written by X. This is a highly undesirable situation and therefore
JUMP was designed. So all the coder has to do is use it.
5. What joynet is
Joynet is a standard for a network cable. It can connect MSX's in a ring via
their joystick ports. between each two computers, there are 3 lines:
The lines connected to button A and B are on the other side connected to steer
up and down respectively. The line connected to steer left is connected to the
strobe on the other side. For an exact description of the cable, see the
joynet homepage by Grauw, `www.fixme.nl'. The information here is all the coder
needs.
In the rest of this document, I shall address the lines by the letters A, B and
C. A and B are the lines comping from the buttons. C is the line going to steer
left. A and B are outgoing lines and C is an incoming line on one side. With
the computer on the other side, A and B are incoming and C is outgoing.
6. How JUMP works
6.1. General overview
Jump is a protocol that works in packets. There are positive and negative sides
to that. The most important negative point is that the sending computer has to
wait for the receiving computer to be ready. The most important positive point
is that the data flow can be bidirectional.
6.2. Sending a packet
Before sending, a send request (SR) should be given. After that, the sending
computer has to wait for a reaction (and check for collisions, see below). When
the client has seen a send request, it sends a clear to send (CTS). After that,
the transmission begins. It works as follows:
Sender sends header
Receiver sends CRC1 and packet size back for confirmation
Sender sends confirmation
While (packetlength >= 32) {
Sender sends 32 bytes of the packet
Receiver sends CRC0
Sender sends confirmation
first 32 bytes are cut off packet
}
Sender sends remaining bytes of packet
Receiver sends CRC0
Sender sends confirmation
Receiver sends CRC1
Sender sends confirmation
This is the complete transmission of a packet. CRC0 is a 8 bit CRC on the data
that has just been received. CRC1 is a 32 bit CRC of all received bytes*3.
So when a byte X arrives, the driver has to do
- CRC0 = CRC0 + X
- CRC1 = CRC1 + ( 3 * X )
- handle the incoming byte
where CRC0 is a byte, CRC1 is a double word and overflow is not checked.
Of course the CRC's should not be added when transferring a CRC. After a CRC
has arrived, it should be set to 0. If a CRC is not confirmed (that is, it is
incorrect), the packet should be resent from the last correct CRC.
6.3. Sending a byte
In section 6.2 I described how a packet should be send. It contains many times
the sending of data. Here I shall describe how this is done.
When bytes are to be sent, the protocol describes exactly how many bytes should
be transferred. Therefore, there is no need to send this information over the
network (except in the packet header, of course). When a byte is to be
transferred, the sender should be ready for it. When the receiver sends a CTS,
the sending of the byte starts. After every byte, a CTS should be sent again,
thus making sure the computers stay synchronized. Sending of bytes is done by
sending the bits on a timed basis, as is shown. Numbers are for the sender
having [AB|C].
Sender checks RS from receiver. If it is set, the packet must first be received
Sender sends RS
While there are bytes to send {
Both wait. Sender times out after a time t4
Receiver sends CTS
Both wait a time t0
for i=0 to [6|7] step [2|1] {
Sender puts bits [i;i+1|i] on [AB|C]
Both wait a time t1
Receiver reads bit [i;i+1|i] from [AB|C]
Both wait a time t2
}
Both wait a time t3
}
Exact timings are as follows:
time min max
t0 100 101
t1 100 101
t2 100 101
t3 100 101
t4 120 121
t5 0 50 (see 6.4:collision detection)
All timings are given without units, because the unit can be changed by the
protocol. On first connection and every time a timeout occurs, the unit
defaults to microseconds. Changing the unit is done via a special packet, which
consists of only a header. See below for details.
6.4 Control signals and collision detection
There are 4 contol signals which can be sent and they are chosen so, that
collision detection is possible. The signals are RS and CTS and both can be
sent via AB or C.
The first important thing is that when no packet is being sent, all lines must
be in the state the MSX BIOS interrupt routine sets them. This means A=B=1 and
C=0.
All signals are:
RS on AB: A=0
RS on C: C=1
CTS on AB: flip B
CTS on C: flip C
CTS must be `flip', because it must be given multiple times, without any change
in between. No line is allowed to flip on the receivers side until the sender
is waiting for it. After a byte has been sent, the senders lines must return in
the `rest' state. This is essential when the receiver needs to send a CRC,
because `flipping' is defined by the original state.
When writing to the network, first the RS from the other side should be
checked. If it is set, the packet must be accepted before starting to send.
This way, collisions are mostly avoided. However it is still possible that a
RS enters the network from two sides. This means for the computer sending on
AB:
Look at RS: no RS from other computer.
Set RS.
Look at CTS: other computer gives CTS.
Start sending packet.
The computer sending on C has the following situation:
Look at RS: no RS from other computer.
Set RS.
Look at CTS: receiving RS instead.
Start receiving packet.
Timings are more critical here. The time between the first check for RS and the
check for CTS is t5 and may not be longer than 50 units. Normally, waiting for
timer t0 should be done from the first time CTS is seen. However, when CTS is
seen immediately after the RS is set, the driver should wait as if CTS was set
half of the time between the two checks. In formulas:
T0: check for RS (result: not set)
T1: set RS
T2: first check for CTS: set
T3: set first data bits
Now T2-T0<t5 and T3-T2=t0-(T2-T0)/2
Actually, this also goes for normal transmission. The driver should wait
the time t0 from the best estimation of the flip of the line signalling
CTS. The best estimation is half the time between two checks before the
last check.
END OF DOCUMENT
Please let me know what you think of it. If anything is not clear or you
want it different, let me know. If we all agree on a protocol, we can all
use it (I would write standard drivers, which can be used by everyone).
I guess if you made it to here you will be willing to send a reply on it
as well, huh? well, please do so! I hope this protocol will be really good
(Actually I think it already it :) )
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44> x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16 >i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
