Re: (Joynet protocol)
On Tue, 26 Sep 2000, Adriano Camargo Rodrigues da Cunha wrote:
UZIX processes have priority. You can use a daemon process as a
JUMP driver (as TCP/IP do). The only problem that can arise is that it
will slow down the link (assuming JUMP is a sincronous protocol - an
asincronous protocol will not work, because UZIX JUMP driver will lose
bits).
I understand. It is actually a good thing to give the driver a priority,
because then the user can decide if she wants to slow down the network to
get better performance or not.
So Grauw (you were writing a paper on an asynchronous protocol, right?),
please hurry up and post it, so we can soon realise it.
The best thing (even for TCP/IP) would be putting the driver
inside the kernel (but it can't be done now, due to low memory).
It is good to be compatible with e.g. 64kB, but you could use the system
as in linux, where the user can compile her own kernel with or without
support for all kind of things, so she can choose to have a powerfull
kernel or a small one.
I personally like the idea of a microkernel very much though, because it
can be bugfree eventually. The idea is to have the kernel doing the
resource managing (memory, cpu time) and leave the device managing (vdp,
psg, etc) to the drivers. The drivers should then not have all
permissions, as they do in the linux kernel, but also be limited, so the
kernel doesn't hang if a driver does.
Drivers should be run-time includable and removable (like insmod and
rmmod, but in a more transparent way). I don't know if you feel like
including those ideas into UZIX. I just think it is a good idea, because
it gives the possibility to put drivers like tcp/ip in the kernel, without
wasting the space/opening possible security holes for the users that don't
use them.
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;16i;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/
Re: (Joynet protocol)
In linux, interrupt handlers and their children are not processes and thus don't have a priority. If they claim the processor, they'll get it. So just ajusting the polling frequency should do. I don't know how uzix does this. UZIX processes have priority. You can use a daemon process as a JUMP driver (as TCP/IP do). The only problem that can arise is that it will slow down the link (assuming JUMP is a sincronous protocol - an asincronous protocol will not work, because UZIX JUMP driver will lose bits). The best thing (even for TCP/IP) would be putting the driver inside the kernel (but it can't be done now, due to low memory). Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Te ky o my kybord ha litl dfect. * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
I don't know much about IP either, but Adriano Camargo Rodrigues da Cunha knows (and implemented it in UZIX) and Laurens Holst is now learning (and implementing) it. Guys, please enlighten us. Pfff... It's really very simple. An IP packet consists of a header IP packets are a header plus data. Header is, at least, 20 bytes. Data is 0 or more bytes. TCP packets are a header plus data. TCP header is, at least, 20 bytes. Data is 0 or more bytes. So, a TCP/IP packet is, at least, 40 bytes (no data, only the IP and TCP headers). UZIX TCP/IP Stack doesn't use any TCP/IP options, because they are quite useless for TCP/IP clients (except the Maximum Transmission Unit option, that is 4 bytes). A datalink protocol should be able to handle packets with a minimum of 40 bytes for TCP/IP. The maximum size is important too (since sending packets of 50 bytes, for example, just allow transmission of, in the best case, 10 bytes of data). 256 bytes is a good choice, and is not a so big value. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * The faith remove montains, substituting them by abisms. - CDA * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
UZIX is multi-threaded. JoyNet send could be a thread and JoyNet receive another thread. It's not a good way to do it, Maarten. On "heavy systems", like a PC, it's a good solution. But on MSX, that has limited memory and clockspeed, it's not. You're wasting twice the memory and charging twice the CPU. Use the same process (I wouldn't call it a 'thread', since the concept is different) to send and receive data. That's how the TCP/IP is implemented. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * -8- Don't cut here or you'll destroy your monitor! -8- * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Fri, 8 Sep 2000, Laurens Holst wrote:
Yes, a timeout is needed for such situations. But as long as the other
side is connected (and running an os with JUMP drivers), everything should
be ok and no locks are possible.
You should _never_ assume that... One flawd bit on the ack line and... The
receiver thinks he sent an ack and waits for the next data, the sender
didn't receive an ack so he doesn't send the next packet... wham. Lock.
If I set the joystick port to 1, it cannot go to 0 and stay there, or can
it? even if it can, you should just refresh the signal every now and then
and you can still design a protocol with no dead-lock posibility.
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;16i;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/
Re: (Joynet protocol)
On Tue, 5 Sep 2000, Maarten ter Huurne wrote:
Small numbers of cycles are not possible. But usually, the number of
cycles needed is about 50 or 100.
JoyNet singal propagation doesn't need waits that long. On 3.5MHz I got
speeds of about 3.5 kilobyte per second, that is 3500*8=28000 bits per
second, which is 125 clocks for a total 1-bit cycle (data + ack). Given the
fact that there are quite a few instructions executed for every bit, there is
hardly any waiting at all.
In that case I am truely convinced that the unidirectional solution is
also the quickest (given the joynet hardware).
Adriano wrote that he would like someone to write some code to use joynet
in uzix. I would like to do it, when the protocol is finished. If anyone
else wants to do it (or doesn't want me to do it :P ), let me know, since
I could use my time on other things as well.
I could do it, but I have too many projects already, so if you are willing
to, I prefer that you do it.
It looks like I am the best person to do it anyway. I have experience in
writing drivers for linux and designing operating systems and computers.
It should be pretty easy (with my knowledge, that is).
I would also like to write a network driver for linux, so you can connect
it to a router as well and connect the internet and all that.
For Linux, the best solution would be to write a serial driver for JoyNet.
Then pppd can be used to connect to UZIX and you can use the existing PPP
network device.
Not at all. Linux knows the `network driver' as a special object. I should
just write a network driver, so the parallel port is treated as a network
device. Then you can just use the connection as if it is an ethernet card
, which means there is no need for a point to point link. It also means
that UZIX will need to use 4 byte host addresses (actually interface
addresses), at least in the JUMP driver.
You can also make a user-mode solution, that sends stdin over JoyNet and
sends JoyNet input to stdout. That program can then be connected to pppd
using pipes. It's less flexible than a kernel driver, but it's also easier to
write
Not at all. Just hacking the plip driver is done in a few minutes.
and won't crash your system if it's buggy.
That is true. Well, let's just hope I'm a good programmer :P
It can be a good intermediate step towards a kernel driver.
It can be, but I prefer to write a kernel driver directly.
Hmm, ok. So the parent must be named in every document. By the way I
don't keep my old versions of it and I don't expect others to. There is
no archive of them, which makes it a bit useless, since you cannot see
the tree anyway.
There is the mailinglist archive on msxnet.org...
But I don't post the document to the mailinglist every time I change it.
It's doesn't matter what kind of version system you use personally. The
proposed versioning system is only intended for published documents. So it
should refer to the last *published* parent document.
All documents I make are directly published on my homepage
(www.cpedu.rug.nl/shevek/JUMP.txt). I do not keep an archive of that. But
the evolution tree doesn't really matter anyway, IMO. The reason to give
version numbers to the documents is to make them distinguishable, so you
know you are talking about the same thing.
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;16i;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/
Re: (Joynet protocol)
I only replied to what I didn't agree with or what I had something to say
about. Other things I cut out.
On Wed, 6 Sep 2000, Maarten ter Huurne wrote:
The protocol can be fixed: adding CRC and a timeout is sufficient. But I
think a more elegant solution is possible, where you wouldn't need a CRC.
What do you mean with that? Some error-correction algoritm in the protocol
(equivalent to a CRC)? Or UDP-like transfer, which leaves the
error-checking to the receiving party?
A timeout is always needed, because when the cable is disconnected the
protocol should be able to handle that.
True, but the protocol should not be able to enter a dead lock, as long as
both computers system memory is not corrupt.
Anyway, it could be a gradual system: if you haven't had a transfer in
a long time, lower the poll frequency.
That is a very good idea, but care must be taken not to make the
calculating of the time before the next poll is done make the system too
inefficient. Also, a minimum frequency should of course be kept, so you
don't have to wait an hour for a reaction after a week not using the
network.
and your system is completely 'locked' while receiving...
If you use a non-timed protocol, you can leave interrupts enabled. To improve
performance of the JoyNet transfer, you can lift the thread priority a bit
above average.
In linux, interrupt handlers and their children are not processes and thus
don't have a priority. If they claim the processor, they'll get it. So
just ajusting the polling frequency should do. I don't know how uzix does
this.
Do you mean a scheduler? UZIX has one, PC operating systems have one.
Not all PC operating systems do. *-DOS doesn't.
Note that a running thread is not necessarily active, because there can be
many running threads and CPU time will be shared between them. However, if
the user is waiting for a JoyNet transfer, there will probably be no
foreground process (the user is waiting) and background processes should be
set at a lower priority than the JoyNet transfer, so in result the JoyNet
transfer will get the majority of the CPU time.
No, they should not. If one process wants the joynet data, and another
wants data from memory, there is no reason to priviledge the networking
process. On normal linux systems, most of the processes (all except the
ones that don't require any input for a while, like compilers) sleep most
of the time waiting for data to be ready (from disk, from network, from
the user via a keyboard, etc.). I think it will be a little different in
uzix, because most hardware needs to be polled, but I think that still it
is good to give joynet normal priority. If the system is slow, the network
is slow...
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;16i;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/
Re: (Joynet protocol)
On Fri, 08 Sep 2000, you wrote: The protocol can be fixed: adding CRC and a timeout is sufficient. But I think a more elegant solution is possible, where you wouldn't need a CRC. What do you mean with that? Some error-correction algoritm in the protocol (equivalent to a CRC)? Or UDP-like transfer, which leaves the error-checking to the receiving party? Error detection other than CRC. Under the assumption that there are only 1-bit errors, the protocol itself can detect errors. I'm not sure this assumption is correct, but gathering statistical evidence (hours of testing) should tell us more about that. A timeout is always needed, because when the cable is disconnected the protocol should be able to handle that. True, but the protocol should not be able to enter a dead lock, as long as both computers system memory is not corrupt. The protocol will deadlock if the cable is disconnected. There is no way to avoid that. But a timeout will handle those situations and abort the hanging transfer. A timeout must be viewed as a kind of exception (in Java/C++ terminology), it is not part of the regular protocol. and your system is completely 'locked' while receiving... If you use a non-timed protocol, you can leave interrupts enabled. To improve performance of the JoyNet transfer, you can lift the thread priority a bit above average. In linux, interrupt handlers and their children are not processes and thus don't have a priority. If they claim the processor, they'll get it. So just ajusting the polling frequency should do. I don't know how uzix does this. Hmmm... Maybe JUMP in Linux should be implemented in user mode after all? Claiming the processor for what could be a long time is not a good idea. Or maybe Linux is fast enough to use one interrupt for every single bit transfer? Anyway, I still want to be able to play MP3s while a JoyNet transfer is in progress. Do you mean a scheduler? UZIX has one, PC operating systems have one. Not all PC operating systems do. *-DOS doesn't. OK; all multitasking OSes have one. Note that a running thread is not necessarily active, because there can be many running threads and CPU time will be shared between them. However, if the user is waiting for a JoyNet transfer, there will probably be no foreground process (the user is waiting) and background processes should be set at a lower priority than the JoyNet transfer, so in result the JoyNet transfer will get the majority of the CPU time. No, they should not. If one process wants the joynet data, and another wants data from memory, there is no reason to priviledge the networking process. On normal linux systems, most of the processes (all except the ones that don't require any input for a while, like compilers) sleep most of the time waiting for data to be ready (from disk, from network, from the user via a keyboard, etc.). I think it will be a little different in uzix, because most hardware needs to be polled, but I think that still it is good to give joynet normal priority. If the system is slow, the network is slow... JUMP also acts as a router, forwarding packets that are intended for another node. Should other computers in the network suffer if one of them is under heavy load? Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Fri, 08 Sep 2000, you wrote: JoyNet singal propagation doesn't need waits that long. On 3.5MHz I got speeds of about 3.5 kilobyte per second, that is 3500*8=28000 bits per second, which is 125 clocks for a total 1-bit cycle (data + ack). Given the fact that there are quite a few instructions executed for every bit, there is hardly any waiting at all. In that case I am truely convinced that the unidirectional solution is also the quickest (given the joynet hardware). There is one thing that takes a lot of time in the non-timed protocol: because the ack should be read for every bit written (reverse read and write if you're receiving instead of sending), you constantly have to switch between PSG register 14 and 15. In a timed protocol you only have to read ack once in a while. I think a timed protocol can be quicker, but it's just too complex to get it working correctly on all possible configurations. For Linux, the best solution would be to write a serial driver for JoyNet. Then pppd can be used to connect to UZIX and you can use the existing PPP network device. Not at all. Linux knows the `network driver' as a special object. I should just write a network driver, so the parallel port is treated as a network device. Then you can just use the connection as if it is an ethernet card , which means there is no need for a point to point link. It also means that UZIX will need to use 4 byte host addresses (actually interface addresses), at least in the JUMP driver. One advantage of PPP is that there are very little modifications necessary in UZIX. Another advantage is that host configuration can be done using PAP. If JUMP is treated as ethernet, UZIX has to be configured manually or we would have to write a DHCP client for it. You can also make a user-mode solution, that sends stdin over JoyNet and sends JoyNet input to stdout. That program can then be connected to pppd using pipes. It's less flexible than a kernel driver, but it's also easier to write Not at all. Just hacking the plip driver is done in a few minutes. Are you experienced or optimistic? ;) Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Fri, 8 Sep 2000, Maarten ter Huurne wrote:
Error detection other than CRC. Under the assumption that there are only
1-bit errors, the protocol itself can detect errors. I'm not sure this
assumption is correct, but gathering statistical evidence (hours of testing)
should tell us more about that.
That is a good idea. Anyway, I don't think the error detection mechanism
is really important for the protocol. It can, e.g. be implemented at a
high level like TCP/IP. Then fast and unreliable packets can also be sent
(some people seem to want that... maybe they don't want it over joynet,
because `fast' is slow anyway?)
A timeout is always needed, because when the cable is disconnected the
protocol should be able to handle that.
True, but the protocol should not be able to enter a dead lock, as long as
both computers system memory is not corrupt.
The protocol will deadlock if the cable is disconnected. There is no way to
avoid that. But a timeout will handle those situations and abort the hanging
transfer. A timeout must be viewed as a kind of exception (in Java/C++
terminology), it is not part of the regular protocol.
Yes, a timeout is needed for such situations. But as long as the other
side is connected (and running an os with JUMP drivers), everything should
be ok and no locks are possible.
In linux, interrupt handlers and their children are not processes and thus
don't have a priority. If they claim the processor, they'll get it. So
just ajusting the polling frequency should do. I don't know how uzix does
this.
Hmmm...
Maybe JUMP in Linux should be implemented in user mode after all? Claiming
the processor for what could be a long time is not a good idea. Or maybe
Linux is fast enough to use one interrupt for every single bit transfer?
Anyway, I still want to be able to play MP3s while a JoyNet transfer is in
progress.
No problem. The implementation should consist of polling every once in a
while and flipping bits if the receiver says it's ready. It doesn't keep
the processor occupied very much.
JUMP also acts as a router, forwarding packets that are intended for another
node. Should other computers in the network suffer if one of them is under
heavy load?
I think this is up to the owner of the computer. This means it should be
ajustable in the driver. This shouldn't be a problem to implement.
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;16i;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/
Re: (Joynet protocol)
On Fri, 8 Sep 2000, Maarten ter Huurne wrote:
For Linux, the best solution would be to write a serial driver for
JoyNet. Then pppd can be used to connect to UZIX and you can use the
existing PPP network device.
Not at all. Linux knows the `network driver' as a special object. I should
just write a network driver, so the parallel port is treated as a network
device. Then you can just use the connection as if it is an ethernet card
, which means there is no need for a point to point link. It also means
that UZIX will need to use 4 byte host addresses (actually interface
addresses), at least in the JUMP driver.
One advantage of PPP is that there are very little modifications necessary in
UZIX. Another advantage is that host configuration can be done using PAP. If
JUMP is treated as ethernet, UZIX has to be configured manually or we would
have to write a DHCP client for it.
I do not have experience with that. But I don't think doing it manually is
much work. On my linux box it is just one ifconfig statement. Do you think
it would be more difficult on a MSX?
You can also make a user-mode solution, that sends stdin over JoyNet and
sends JoyNet input to stdout. That program can then be connected to pppd
using pipes. It's less flexible than a kernel driver, but it's also
easier to write
Not at all. Just hacking the plip driver is done in a few minutes.
Are you experienced or optimistic? ;)
Both :P
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;16i;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/
Re: (Joynet protocol)
Not at all. Linux knows the `network driver' as a special object. I should just write a network driver, so the parallel port is treated as a network device. Then you can just use the connection as if it is an ethernet card , which means there is no need for a point to point link. It also means that UZIX will need to use 4 byte host addresses (actually interface addresses), at least in the JUMP driver. One advantage of PPP is that there are very little modifications necessary in UZIX. Another advantage is that host configuration can be done using PAP. If JUMP is treated as ethernet, UZIX has to be configured manually or we would have to write a DHCP client for it. PAP does not configure anything. It handles the login procedure. I think you mean PPP's LCP and IPCP. Not at all. Just hacking the plip driver is done in a few minutes. Are you experienced or optimistic? ;) :) ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
Yes, a timeout is needed for such situations. But as long as the other side is connected (and running an os with JUMP drivers), everything should be ok and no locks are possible. You should _never_ assume that... One flawd bit on the ack line and... The receiver thinks he sent an ack and waits for the next data, the sender didn't receive an ack so he doesn't send the next packet... wham. Lock. ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
And if the 2-computer case is very important, you can always make a single cable connecting 2 nodes. But it won't work for larger networks and it isn't really JoyNet, just partly compatible. I think Laurens even has the schematic for the 2-computer cable on his JoyNet page. Yes, it's there. Another problem is the granularity of the waiting loops. If you want to avoid self-modifying code, the fastest waiting loop is DJNZ, which takes 9 cycles for the last loop and 14 cycles for the other loops. So if you want to wait 10 cycles, you'll have to round to 23. Timing must indeed be thought of. There is no need to round. Loops that are the same every time can easily be coded. Using JP instead of DJNZ, the number of cycles per loop can be made constant. But it's not possible to get every number of cycles (try 6). Nor is it possible to have any fine-grained control without using self-modifying code. And apart from being complex, self-modifying code doesn't work in read-only memory. I made a SiMPL sample-player once, which (before playing the sample) 'calibrated' itself (see how many samples can be played within an interrupt). If it was too fast, a unit-long wait was inserted. Repeat until too slow. Then lower unit by, say, a factor ten, and start decreasing the wait until it's too fast again, and so on until unit has reached the minimal quantity. I used NOPs to wait, since it's the most precise unit. They were inserted into the code (so the part after the NOP waits was relocatable). It's a bit complex, but accurate. You wouldn't have to design the IP layer, because it already exists. We only have to find out what the minimum packet size is and whether using IP in a JoyNet network will work in practice. I don't know much about IP either, but Adriano Camargo Rodrigues da Cunha knows (and implemented it in UZIX) and Laurens Holst is now learning (and implementing) it. Guys, please enlighten us. Pfff... It's really very simple. An IP packet consists of a header (with a good and fast-calculated checksum) and some data. However I suggest to use a simpler protocol. The IP-address for example is 32-bits. You only need 8 bits in this case. And it contains some other parameters which are absolutely not nessecary, and if they are they can be passed as options, not as a part of the default header. Look at ftp://ftp.funet.fi/rfc/rfc791.txt That's the IP documentation. ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
I do have ideas on how to implement a bidirectional peer-to-peer link using JoyNet (=2 computers only). Let's hear it! Supporting more than 2 nodes is a matter of routing, and it can be solved in a higher layer. Not with JoyNet. With more than 2 computers, the databits arrive at a different computer than Ack does. But it's not very difficult to come up with something for a ring... About my protocol: I'll work out an example on my MSX. The basic idea is like this (I have no implementation experience yet though, so it can still be changed): The joystickports are checked regularly. A transfer request is indicated to the peer by flipping ack and setting dat1 and dat2 to 01 or 10, also flipping each time. Why those values? Well, by default the datapins are set to 11, and if the peer MSX is disconnected or off, the datapins are 00. The other then responds, initiating the transfer. The data is transmitted in 4 transmissions on both sides, so 8 in total. If the transfer is bidirectional, the data of the peer is sent together with the ACKs. The first two bytes indicate the packet length (excluding the lenght bytes and the checksum), then the packet is sent, and after the packet a 16-bit TCP-like checksum (excluding the lenght and checksum bytes) is sent: "The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros." Mind you: one's complement. Not two's complement, neither no complement. Check your docs on that (Rodnay Zaks' book on the Z80 features a short description). Short description: when adding data in one's complement, also add the carry. (so ADD A,r:ADC A,0 is a one's complement addition). In one's complement, a negative value is indicated by complementing the value. So -1 is FFFE. And -0 is . But at the same time FFFE is also FFFE (one's complement doesn't limit to -32768 and +32767 if I'm correct... that's a tiny bit confusing)... Then complement the final checksum result. When you receive the data, one's complement add all received words, including the checksum, and if the result is # then all's well. Why a one's complement checksum? Check out rfc1071 (ftp://ftp.funet.fi/rfc1071.txt) and be amazed how cool this checksum is!!! Well that's about it. Simple, eh? However if you have every host connected to two others using a peer-to-peer link (2 computers, so not really a 'network') in both joystickports (which make it a network again), then bidirectional transfer is indeed be possible. The idea of JoyNet was to keep one joystick port free. For example, to play a game using a joystick or game pad. Yes. ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Tue, 05 Sep 2000, you wrote: Small numbers of cycles are not possible. But usually, the number of cycles needed is about 50 or 100. JoyNet singal propagation doesn't need waits that long. On 3.5MHz I got speeds of about 3.5 kilobyte per second, that is 3500*8=28000 bits per second, which is 125 clocks for a total 1-bit cycle (data + ack). Given the fact that there are quite a few instructions executed for every bit, there is hardly any waiting at all. Around those numbers any number of cycles is possible. Fine grained control would be large, but not impossible (without self-modifying code). OK, it would be possible. But not elegant. Adriano wrote that he would like someone to write some code to use joynet in uzix. I would like to do it, when the protocol is finished. If anyone else wants to do it (or doesn't want me to do it :P ), let me know, since I could use my time on other things as well. I could do it, but I have too many projects already, so if you are willing to, I prefer that you do it. I would also like to write a network driver for linux, so you can connect it to a router as well and connect the internet and all that. For Linux, the best solution would be to write a serial driver for JoyNet. Then pppd can be used to connect to UZIX and you can use the existing PPP network device. You can also make a user-mode solution, that sends stdin over JoyNet and sends JoyNet input to stdout. That program can then be connected to pppd using pipes. It's less flexible than a kernel driver, but it's also easier to write and won't crash your system if it's buggy. It can be a good intermediate step towards a kernel driver. Hmm, ok. So the parent must be named in every document. By the way I don't keep my old versions of it and I don't expect others to. There is no archive of them, which makes it a bit useless, since you cannot see the tree anyway. There is the mailinglist archive on msxnet.org... But I don't post the document to the mailinglist every time I change it. It's doesn't matter what kind of version system you use personally. The proposed versioning system is only intended for published documents. So it should refer to the last *published* parent document. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
For Linux, the best solution would be to write a serial driver for JoyNet. Then pppd can be used to connect to UZIX and you can use the existing PPP network device. You can also make a user-mode solution, that sends stdin over JoyNet and sends JoyNet input to stdout. That program can then be connected to pppd using pipes. It's less flexible than a kernel driver, but it's also easier to write and won't crash your system if it's buggy. It can be a good intermediate step towards a kernel driver. I hope you realize that implementing JoyNet in any system which also executes other tasks is a highly delicate matter??? It requires a lot of fine-tuning, and within a single application that's easy, but with multiple apps running... You see, JoyNet doesn't generate an interrupt to indicate the peer is sending/listening, so you'll need to poll continuously, and your system is completely 'locked' while receiving... And the sender can't execute other tasks until the receiver has acknowledged the send_request and has received all data... It can be done, I think (execute all other processes every int, the transmission will hold then but the rest will at least work). However, execute-on-int (to give it a name) is quite hard to program I think. And you must also watch out that the sender doesn't call the other processes while the receiver just finished calling the other processes (that would result in no bytes being received). That can be solved by letting the sender determine when the int starts and transmit some kind of "Execute Other Processes wait" escape-code when the event occurs, so the receiver can then also execute the processes at the same time. In that case, an (partly optional, implementation-dependant) escape-code-mechanism has to be constructed. However, I don't know how that fits into the architecture of Uzix (I think badly). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Tue, 05 Sep 2000, you wrote: I hope you realize that implementing JoyNet in any system which also executes other tasks is a highly delicate matter??? It requires a lot of fine-tuning, and within a single application that's easy, but with multiple apps running... It's not hard at all if you use a non-timed protocol. I have had this running for over a year now, except for the fact that it hangs on transmission errors. Transmission errors are rare in a non-timed protocol, but they can occur (I got one after sending about 50MB). The protocol can be fixed: adding CRC and a timeout is sufficient. But I think a more elegant solution is possible, where you wouldn't need a CRC. A timeout is always needed, because when the cable is disconnected the protocol should be able to handle that. You see, JoyNet doesn't generate an interrupt to indicate the peer is sending/listening, so you'll need to poll continuously, You have to poll once in a while. For systems like PCs polling 100 times per second is no problem. And much higher frequencies are possible as well, although they will start influencing system performance. Anyway, it could be a gradual system: if you haven't had a transfer in a long time, lower the poll frequency. and your system is completely 'locked' while receiving... If you use a non-timed protocol, you can leave interrupts enabled. To improve performance of the JoyNet transfer, you can lift the thread priority a bit above average. And the sender can't execute other tasks until the receiver has acknowledged the send_request and has received all data... That depends on the protocol. It can be done, I think (execute all other processes every int, the transmission will hold then but the rest will at least work). However, execute-on-int (to give it a name) is quite hard to program I think. Do you mean a scheduler? UZIX has one, PC operating systems have one. However, I don't know how that fits into the architecture of Uzix (I think badly). UZIX is multi-threaded. JoyNet send could be a thread and JoyNet receive another thread. When there is no transfer, these threads sleep for a while. When they wake up, they check if a transfer should be started, this is how you get the polling behaviour. If a transfer was started, the thread will remain running until the transfer stops. Note that a running thread is not necessarily active, because there can be many running threads and CPU time will be shared between them. However, if the user is waiting for a JoyNet transfer, there will probably be no foreground process (the user is waiting) and background processes should be set at a lower priority than the JoyNet transfer, so in result the JoyNet transfer will get the majority of the CPU time. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Sat, 2 Sep 2000, Maarten ter Huurne wrote: How can a node (single computer in the network) determine whether its neighbours use JUMP or not? Especially, how can it do so without causing problems with other protocols? It can't. It is impossible to determine. I don't think it's possible to use JUMP and an incompatible protocol on the same network. So why not demand that every node in the network uses JUMP? I put a note about it in the file. Because JUMP does not need a closed ring, all that is needed to demand the whole network to be JUMP. But the endpoints must be recognisable as non-JUMP. Of course if too many bogus packets are received, the driver may conclude that the connection is not JUMP. A special header could be designed for non-JUMP protocols for when they receive a JUMP packet, but they may choose not to use it. Even that is impossible. If the other protocol uses a different algorithm for sending packets, a node using JUMP wouldn't even be able to receive it's packets. In which case the JUMP side will reject that side of the connection. The other side will probably need a ring network, in which case it will hang, or something. Also, it should be made explicit whether the link with the previous or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs, next.dat0, next.dat1 and prev.ack are outputs. True, this should be explicit. But not next and prev, because the network is bidirectional. sender.A, sender.B and receiver.C should do, I think. The prefixes "prev" and "next" can be used on a bidirectional network. If the nodes are numbered, node N knows neighbour N-1 as "prev" and neighbour N+1 as "next". Especially when using a bidirectional network, "sender" and "receiver" is less clear, because either neighbour can fulfill both roles. True. I shall soon change it. With packets I mean packets that are sent in one go, without executing other code while waiting for acknowledge signals or something. If you do that, you can make use of a timed protocol. So you mean that sending or receiving a packet is an atomic action? Yes. Actually it is the being timed that makes it possible to be bidirectional. A non-timed protocol must have at least two lines (data and acknowledge) on the sender side. For joynet, that means it must be one-directional. That's true. But does it really matter? A unidirectional network seems a lot simpler to me. It is simpler to code, but slower and harder to get (you really NEED 2 cables for two computers). The being timed also means you have to wait for the receiver to be ready. Synchronous transfer. Indeed. In modem terminology, isn't SR called RTS (Request To Send)? Yes, I think so. I'm not really familiar with those things. If they are the same, it's better to use the existing term: RTS. I already changed it in the file. Why are packets split up into 32 byte chunks? Usually, packets are the "atoms" of network communication. Packets can be really big (16kB e.g.). Why? See below. I agree with you to chop them , by the way. It is common practice that a higher level protocol chops large data into small chunks. There is no need to send packets as large as 16K. And there is a reason not to do it: a 16K packet needs a buffer space of 16K and memory isn't abundant on MSX. That is why I took 16kB as absolute maximum. A handshake should be able to make it less. But it will be changed anyway. I want to have a check every now and then, to prevent the whole packet having to be resent and to have more secure transmission. This protocol is (without the CRC's) much less reliable than the unidirectional one. It would be much easier to stick to small packets. If packet sizes vary a lot (from a couple of bytes to 16K or larger), you have to pick a CRC that is good enough for the largest packets. If packets are small, you can use a smaller CRC, if you want to send a lot of data, you simply send a lot of packets. True, but I thought it would be much slower. I guess you thought the packets were smaller. We have to watch out for too much packets. every packet, the sender has to wait for the receiver to be ready. This means that the time wasted waiting is proportional to the number of packets transmitted, no matter how large they are. You could make a flag in the header indicating that another packet will immediately follow the current one. The receiver will then return to "ready mode" as soon as it can. That is a good idea :) Timing has some serious disadvantages: - it depends on how strong the joystick port drives the signals (probably not equal for all MSX types) - it depends on cable length (actually capacity, but length is probably the most important factor) This is true. There is a way to get around this however. It should be used. I did not talk about it yet, since I forgot about it. It
Re: (Joynet protocol)
There is another problem in the time before a transfer is started. The sender must wait for the receiver to be ready. If it waits while interrupts are disabled, interrupts can be disabled for quite a while (maximum: timeout value). If it waits while interrupts are enabled, the waiting can be interrupted and the receiver must wait for the sender, resulting in a more complex protocol. Interrupts must be disabled during waiting and the timeout value must be smaller than 1/60th of a second. Music (games/apps) and Modem (apps) won't be happy with that. "Know the time used for the operation" is not as simple as it sounds. It's different for Z80 at 3.5MHz/6MHz/7Mhz/8MhZ, R800, Z380 and non-MSX machines. And on machines with a cache it's impossible to calculate exactly, you can give only minimum and maximum times, but that's not good enough. Even the simple fact that the R800 doesn't send CAS (or was it RAS?) when it isn't needed adds a lot of complexity to the calculation (it matters how many 512-byte boundaries are crossed by the code). Hm, that makes things awfully complicated, indeed. I don't understand how you can use asynchronous communication with JoyNet. It requires a timer on both sides running both at the same speed. Which you haven't, unless both have a MusicModule or OPL4 plugged in (timings of MM and OPL4 are slightly different, so they have to be equal on both machines), and then the transfer rate will still be very slow compared to synchronous communication and the entire concept of JoyNet (cheap, easy) will be lost. Synchronous communication doesn't require the interrupts to be disabled, and it's faster. However I haven't got ideas on how to implement it (think about it yourself). I do have ideas on how to implement a bidirectional peer-to-peer link using JoyNet (=2 computers only). As far as I can see, it's also not possible to communicate bidirectional using a JoyNet network (2 computers), since it has only 1 dataline (ack) going back to the previous host (for acknowledgement), and the other two datalines (dat1 and dat2) go to the next host. However if you have every host connected to two others using a peer-to-peer link (2 computers, so not really a 'network') in both joystickports (which make it a network again), then bidirectional transfer is indeed be possible. However you haven't got any spare joystickports then, the amount of cables is twice as much, and the setup has to be changed depending on the implementation (some might require 'real' JoyNet ring network, which is actually quite logical, and some might require a semi JoyNet ring with simple peer-to-peer links like described above). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Mon, 04 Sep 2000, you wrote: That's true. But does it really matter? A unidirectional network seems a lot simpler to me. It is simpler to code, but slower and harder to get (you really NEED 2 cables for two computers). A ring scales just as well as a line: #nodes#cables:ring#cables:line 2 2 1 3 3 2 4 4 3 etc. And if the 2-computer case is very important, you can always make a single cable connecting 2 nodes. But it won't work for larger networks and it isn't really JoyNet, just partly compatible. I think Laurens even has the schematic for the 2-computer cable on his JoyNet page. That is the negative point of it, indeed. But I still think performance decreases much more by using a unidirectional network, especially when the network is large. Since there usually is a two-way communication, in a unidirectional network the whole ring always needs to be folowed. In a bidirectional network, the shortest path can be taken. In the best case, the bidirectional network will be a factor two faster. However, since the bandwidth in the "backwards" direction is only half that of the forward direction, that lowers the gain somewhat. Another problem is the granularity of the waiting loops. If you want to avoid self-modifying code, the fastest waiting loop is DJNZ, which takes 9 cycles for the last loop and 14 cycles for the other loops. So if you want to wait 10 cycles, you'll have to round to 23. Timing must indeed be thought of. There is no need to round. Loops that are the same every time can easily be coded. Using JP instead of DJNZ, the number of cycles per loop can be made constant. But it's not possible to get every number of cycles (try 6). Nor is it possible to have any fine-grained control without using self-modifying code. And apart from being complex, self-modifying code doesn't work in read-only memory. And after solving all the complex issues, there will be compromises on performance, so the main advantage of a timed protocol may diminish. You may be right. Are you suggesting to rewrite the document to a unidirectional format? Yes, please. And not just unidirectional, but also a protocol without timing. I want to know what other users think of this before I do it. (so please react if you care about what it will be) I'm interested too. A collision means that there are two signals on the same wire at the same time. As far as I know, that will never happen with JoyNet. What can happen, is that two neighbours want to send to each other at the same time, but that's no collision. Hmm, ok. It's a question of definition. I defined a collision as two packets going over the same wire while it can handle only one. The cable is an abstract line that can carry a stream of data, in this case 3 wires of copper. I think the term "collision" is reserved for overlapping signals on the hardware level. For example BNC (coax) networks have collisions, when two network cards send a packet at the same time. When that happens, both packets are destroyed. What you are describing has a lot of similarities, but it happens on a higher level. It is a case where mutual exclusion of two processes (sending and receiving) using a single resource (the wires) must be guaranteed. A difference with collisions is that collisions are undetectable until after they have happened. The mutex (mutual exclusion) can be detected in advance, although they're not easy to deal with: deadlock is possible if you do it the wrong way. Maybe we should make JUMP packets large enough to contain IP packets? That would make IP-over-JUMP a lot easier. Actually, maybe JUMP should only describe the network layer and we can send plain IP packets over that. That is a good idea. But I don't know enough about IP packets to design it. You wouldn't have to design the IP layer, because it already exists. We only have to find out what the minimum packet size is and whether using IP in a JoyNet network will work in practice. I don't know much about IP either, but Adriano Camargo Rodrigues da Cunha knows (and implemented it in UZIX) and Laurens Holst is now learning (and implementing) it. Guys, please enlighten us. I agree with Manuel here. It's not about a "best" version, it is simply useful to know the "evolution tree" of a document. Hmm, ok. So the parent must be named in every document. By the way I don't keep my old versions of it and I don't expect others to. There is no archive of them, which makes it a bit useless, since you cannot see the tree anyway. There is the mailinglist archive on msxnet.org... Sometime soon, I'll post a design for a non-timed protocol that can handle errors. I'm not 100% sure yet it is correct, which is why I didn't release it before. However, I am not making much progress on my own, so I'll publish it hoping for some discussion. UZIX can be useful to test
Re: (Joynet protocol)
On Mon, 04 Sep 2000, you wrote: Interrupts must be disabled during waiting and the timeout value must be smaller than 1/60th of a second. Music (games/apps) and Modem (apps) won't be happy with that. The good news is, that using a non-timed protocol interrupts can be allowed. It must be done carefully, because too many or badly timed interrupts will kill performance, but at least interrupts no longer influence correctness. It requires a timer on both sides running both at the same speed. Which you haven't, unless both have a MusicModule or OPL4 plugged in (timings of MM and OPL4 are slightly different, so they have to be equal on both machines), and then the transfer rate will still be very slow compared to synchronous communication and the entire concept of JoyNet (cheap, easy) will be lost. Shevek wanted to use instruction length for timing at first, but now he agrees that this is too problematic. Note that you cannot even trust two timers of the same kind to run equally fast. For example, start a music replayer in two MSXes with the same song at the same moment. After about a minute you'll hear that they're out of sync. So even 60Hz isn't exactly the same for every MSX. We should indeed remember that the whole point of JoyNet is to be simple and cheap. If we want high speeds, we'll need different hardware. I'm interested in that, but it's a different project. I do have ideas on how to implement a bidirectional peer-to-peer link using JoyNet (=2 computers only). Let's hear it! Supporting more than 2 nodes is a matter of routing, and it can be solved in a higher layer. As far as I can see, it's also not possible to communicate bidirectional using a JoyNet network (2 computers), since it has only 1 dataline (ack) going back to the previous host (for acknowledgement), and the other two datalines (dat1 and dat2) go to the next host. Without fixed timing, bidirectional transfers are indeed impossible over JoyNet. However if you have every host connected to two others using a peer-to-peer link (2 computers, so not really a 'network') in both joystickports (which make it a network again), then bidirectional transfer is indeed be possible. The idea of JoyNet was to keep one joystick port free. For example, to play a game using a joystick or game pad. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
UZIX can be useful to test JUMP, because it has every layer of the network already implemented. JoyNet + JUMP can replace RS232 and we'll have a running system. Maarten is right. Implementing JUMP so it's able to send and receive a byte through the network is enough for UZIX. By the way, if someone wants to write a driver for JUMP and wanna put it in UZIX, contact me please. Due to the actual stage of UZIX development, it's not an easy thing to write low level drivers for it without my help (I hope this problem will finish soon). Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Number of Vulcans needed to replace a bulb? Precisely 1.000 * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Fri, 18 Aug 2000, Maarten ter Huurne wrote:
On Fri, 18 Aug 2000, you wrote:
3. When JUMP should be used
The term "JUMP" is not introduced...
JUMP = Joynet Univeral Message Protocol?
Hmm did I forget that? sorry. It should be Joynet Unified Machine
Protocol. I used this term to emphasize the fact that it is not a MSX
protocol, but a protocol for the cable. Any computer that can set the
signals on the cable can make use of the protocol.
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.
How can a node (single computer in the network) determine whether its
neighbours use JUMP or not? Especially, how can it do so without causing
problems with other protocols?
It can't. It is impossible to determine. Of course if too many bogus
packets are received, the driver may conclude that the connection is not
JUMP. A special header could be designed for non-JUMP protocols for when
they receive a JUMP packet, but they may choose not to use it.
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.
In the case where there is only 1 application running on the network, JUMP is
not necessary. However, if you want to create a Joynet ring that really acts
like a network, a protocol like JUMP is necessary. So JUMP is good for TCP/IP
over Joynet, file serving and such.
Exactly. Thank you for expaining.
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.
What about naming them "dat0", "dat1" and "ack"? Those names are easier to
remember.
I don't think so. A and B are very logical, because on the msx they are
connected to joystick button A and B. I chose C as `the other line',
because I didn't feel the need for a different name. `ack' suggests that
it is only used for the `acknowledge' pulse, which is not true in this
protocol.
Also, it should be made explicit whether the link with the previous
or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs,
next.dat0, next.dat1 and prev.ack are outputs.
True, this should be explicit. But not next and prev, because the network
is bidirectional. sender.A, sender.B and receiver.C should do, I think.
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.
I don't understand: why are these properties consequences of using packets?
With packets I mean packets that are sent in one go, without executing
other code while waiting for acknowledge signals or something. If you do
that, you can make use of a timed protocol. Actually it is the being timed
that makes it possible to be bidirectional. A non-timed protocol must have
at least two lines (data and acknowledge) on the sender side. For joynet,
that means it must be one-directional.
The being timed also means you have to wait for the receiver to be ready.
So I was actually talking about the results of a timed protocol (which
must nessecarily work in packets).
By the way, are there low-level network protocols that do not send data in
packets? I can't remember seeing one.
I used one in Boulderdash III. You can check out the source on my homepage
if you like: www.fmf.nl/~shevek -msx
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:
In modem terminology, isn't SR called RTS (Request To Send)?
Yes, I think so. I'm not really familiar with those things.
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
Re: (Joynet protocol)
On Fri, 01 Sep 2000, you wrote: 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. How can a node (single computer in the network) determine whether its neighbours use JUMP or not? Especially, how can it do so without causing problems with other protocols? It can't. It is impossible to determine. I don't think it's possible to use JUMP and an incompatible protocol on the same network. So why not demand that every node in the network uses JUMP? Of course if too many bogus packets are received, the driver may conclude that the connection is not JUMP. A special header could be designed for non-JUMP protocols for when they receive a JUMP packet, but they may choose not to use it. Even that is impossible. If the other protocol uses a different algorithm for sending packets, a node using JUMP wouldn't even be able to receive it's packets. What about naming them "dat0", "dat1" and "ack"? Those names are easier to remember. I don't think so. A and B are very logical, because on the msx they are connected to joystick button A and B. I chose C as `the other line', because I didn't feel the need for a different name. `ack' suggests that it is only used for the `acknowledge' pulse, which is not true in this protocol. OK. Also, it should be made explicit whether the link with the previous or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs, next.dat0, next.dat1 and prev.ack are outputs. True, this should be explicit. But not next and prev, because the network is bidirectional. sender.A, sender.B and receiver.C should do, I think. The prefixes "prev" and "next" can be used on a bidirectional network. If the nodes are numbered, node N knows neighbour N-1 as "prev" and neighbour N+1 as "next". Especially when using a bidirectional network, "sender" and "receiver" is less clear, because either neighbour can fulfill both roles. 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. I don't understand: why are these properties consequences of using packets? With packets I mean packets that are sent in one go, without executing other code while waiting for acknowledge signals or something. If you do that, you can make use of a timed protocol. So you mean that sending or receiving a packet is an atomic action? Actually it is the being timed that makes it possible to be bidirectional. A non-timed protocol must have at least two lines (data and acknowledge) on the sender side. For joynet, that means it must be one-directional. That's true. But does it really matter? A unidirectional network seems a lot simpler to me. The being timed also means you have to wait for the receiver to be ready. Synchronous transfer. 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: In modem terminology, isn't SR called RTS (Request To Send)? Yes, I think so. I'm not really familiar with those things. If they are the same, it's better to use the existing term: RTS. Why are packets split up into 32 byte chunks? Usually, packets are the "atoms" of network communication. Packets can be really big (16kB e.g.). Why? It is common practice that a higher level protocol chops large data into small chunks. There is no need to send packets as large as 16K. And there is a reason not to do it: a 16K packet needs a buffer space of 16K and memory isn't abundant on MSX. I want to have a check every now and then, to prevent the whole packet having to be resent and to have more secure transmission. This protocol is (without the CRC's) much less reliable than the unidirectional one. It would be much easier to stick to small packets. If packet sizes vary a lot (from a couple of bytes to 16K or larger), you have to pick a CRC that is good enough for the largest packets. If packets are small, you can use a smaller CRC, if you want to send a lot of data, you simply send a lot of packets. 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
Re: (Joynet protocol)
Timing has some serious disadvantages: - it depends on how strong the joystick port drives the signals (probably not equal for all MSX types) - it depends on cable length (actually capacity, but length is probably the most important factor) - it means the interrupt must be disabled when doing JUMP transfers - it is hard to program on PCs (file serving, internet connection, MSX emulators) You need a clock-independant timer for timing. Most basic setup MSX-es haven't (and that's the idea of JoyNet, simplicity). I think synchonous communication (by the means of sending ACKs) is the most reliable, easiest and fastest way to do it (although you spend 1/3rd of your bandwidth with ACKs, the protocol can operate on the slowest computer's maximum speed instead of on a fixed timer). ~Grauw -- email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: (Joynet protocol)
On Fri, 18 Aug 2000, you wrote:
3. When JUMP should be used
The term "JUMP" is not introduced...
JUMP = Joynet Univeral Message Protocol?
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.
How can a node (single computer in the network) determine whether its
neighbours use JUMP or not? Especially, how can it do so without causing
problems with other protocols?
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.
In the case where there is only 1 application running on the network, JUMP is
not necessary. However, if you want to create a Joynet ring that really acts
like a network, a protocol like JUMP is necessary. So JUMP is good for TCP/IP
over Joynet, file serving and such.
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.
What about naming them "dat0", "dat1" and "ack"? Those names are easier to
remember. Also, it should be made explicit whether the link with the previous
or next node is mentioned: prev.dat0, prev.dat1 and next.ack are inputs,
next.dat0, next.dat1 and prev.ack are outputs.
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.
I don't understand: why are these properties consequences of using packets?
By the way, are there low-level network protocols that do not send data in
packets? I can't remember seeing one.
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:
In modem terminology, isn't SR called RTS (Request To Send)?
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
Why are packets split up into 32 byte chunks? Usually, packets are the
"atoms" of network communication.
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.
I think we had this discussion before, but 32 bit CRC is overkill for small
chunks of data. For example, MSX floppy uses 16 bit CRC for sectors (512
bytes long).
Sending of
bytes is done by sending the bits on a timed basis, as is shown.
Timing has some serious disadvantages:
- it depends on how strong the joystick port drives the signals
(probably not equal for all MSX types)
- it depends on cable length
(actually capacity, but length is probably the most important factor)
- it means the interrupt must be disabled when doing JUMP transfers
- it is hard to program on PCs
(file serving, internet connection, MSX emulators)
Both wait a time t1
Receiver reads bit [i;i+1|i] from [AB|C]
Both wait a time t2
While the receiver reads the bits, the sender is doing nothing. But they
should remain in sync, so either the receive time must be substracted from t2
or the sender must wait an amount of time equal to the receive time.
6.4 Control signals and collision detection
Are collisions possible? If there can be no collisions, collision detection
is not necessary.
Please let me know what you think of it. If anything is not clear or you
want it different, let me know.
What is most unclear to me, is why the design decisions are made. The timing
values, why are they chosen as they are? Why is the packet sent in 32-byte
chunks instead of 16-byte or 256-byte?
One thing you haven't addressed, is how the protocol handles broken network
links, like a
Re: (Joynet protocol)
I think we had this discussion before, but 32 bit CRC is overkill for small chunks of data. For example, MSX floppy uses 16 bit CRC for sectors (512 bytes long). A quick and interesting checksum algorithm is the one used for TCP/IP (one's complement of the sum of the one's complement of each word in the packet). Another interesting one is that used in PPP frames. There is an implementation (FCS - Fast Checksum S-i-dont-remember-what-this- letter-means) that uses a 512 bytes lookup table; the cost of the checksum is two XOR operations per byte and the resulting checksum is a constant for any packet (I don't remember the value by heart). If someone is interested, I can give a source code example. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Engenharia de Computacao - UNICAMP http://www.adrpage.cjb.net http://if.you.dont.like.msx.usuck.com * Press any key except... no, No, NO, NOT THAT ONE! * Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
