Hi all,

For anyone going to make software/drivers/applications using this 
JoyNet, or any other serial system (I'm not going to, though), I have 
some tips:

In some UART (Universal Asynchronous Receiver/Transmitter) 
datasheets, I read something once, that might make such transfer 
routines a bit more error-proof:

It's about the exact time(s) of sampling the bit values of the main 
(RxD/TxD) signal. In asynchronous communications, this is based upon 
a fixed time for a single bit, determined by the baudrate. Common way 
is, to detect a 1-to-0 or 0-to-1 transition in a 'start bit', then 
wait 1/2 bit time (or 1 and 1/2, I don't know), and sample the 1st 
bit (which would then be halfway). Then 1 bit-time later (1 and 1/2, 
or 2 and a half, bittime after this first detected transition) the 
next bit, and so on. And last, repeat this for a clearly limited 
number of bits (like 10-20), after which the start of a new set of 
bits has to be detected again. This is to avoid having a limited 
precision in the baudrate (1 % for instance) having an impact on the 
exact times that bits are sampled.


I might imagine, that most MSX programmers might do it that way, and 
every bit would be read exactly 1 time. I read about an improvement 
on this: divide the bittime in somewhat smaller slices, say 8 or 16 
parts, and for each bit, take 3 samples, somewhere in the middle of 
that bit (timed on the smaller time-slices). For instance at 3/8, 
4/8, and 5/8 bit-time, or at 7/16, 8/16, and 9/16-th bit-time.

That always gives an odd number of samples. If it's 0, 0, 0: must be 
zero. If it's 0,0,1: probably zero (same as 0,1,0 or 1,0,0). If it's 
1,1,0: probably 1 (same as 1,0,1 or 0,1,1). If it's 1,1,1: must be 
one.

Of course, a bit more trouble for the programmer. But hey, that's why 
they're there for, to stick their noses into these kinds of trouble. 
Advantage here is, that every bit doesn't get sampled only once, but 
3 times, giving you a great commercial slogan as well: "now with 3 
times digital oversampling included!". The result is an improved 
in-sensitivity to noise (don't ask me how much), if the bit-signal 
reads out wrong one time because of such noise, and it reads out 
right the other 2 times, you still get the correct bit value. Hint: 
one might expect that many UARTs might use this trick.


In any application, I would STRONGLY suggest (call it almost 
obligated, if you want to make a 'solid' piece of software) using 
some DECENT type of error-detection mechanism, so that you can 
re-transfer a data block, if it fails the error checking. For 
instance a 32-bit CRC (Cyclic Redundancy Check), not something like 
"adding all bytes, modulo 2^16" for a 16-bit checksum.

When tranferring large amounts of data over cables, there's BOUND to 
be some errors. If you don't have any error-detection mechanism, or a 
too simple one, there might well be hundreds of bits be modified, if 
10s or 100s of MB.'s were transferred. And as computer users, you 
know that would be too much. So some kind of proper error-detection 
is really needed for this.

And if it's for transferring data (for instance MSX -> PC), some 
extra overhead is really a don't care, if you got 50 MB's to 
transfer, who cares whether that takes 20, or 22 hours or so?

If that time DOES matter (for instance on real-time networkgame 
applications) then you MIGHT forget it, as long as it wouldn't have 
too great an impact (for games, this might even introduce a nice 
'random' element!).


And you can include all of these things in a set of standard-routines 
that go with any JoyNet application, and might be updated any time. 
An application programmer could just take this standard set of 
routines, and build his/her application around it, not worrying about 
the internals of these standard routines. Like with drivers for 
equipment, you could have updates of these drivers later on, and 
application software would be easily modified (maybe not even) to 
include these newer versions, whenever these become available.

And hey, you'll have to put together some of these standard-routines 
at some time, how are you gonna call this a standard otherwise?



Alwin Henseler