I wrote earlier:

> >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.

Maarten ter Huurne  <[EMAIL PROTECTED]>  replied:

> That's synchronous communication. In asynchronous communication,
> there is no baudrate.

[EMAIL PROTECTED]    replied:

Van:              [EMAIL PROTECTED]
Ehrm... I don't wanna spoil the fun, but for JoyNet, we're talking
about asynchronous communication. What you describe here ("...based
upon a fixed time...baudrate") is synchronous comm.

        [Which trashes the whole supersampling idea]

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.

If such an other signal is not used, or not present, the data stream 
can NOT be SYNCHRONISED with that other signal, and thus becomes an 
ASYNCHRONE communication method. In this case, it is usallly a fixed 
timing scheme that determines when bits are to be sampled. Such a 
fixed timing scheme is usually referred to/derived from/related to as 
"baudrate". This is the common way used for RS-232 communications, 
and the same goes for MIDI-connections (also Asynchronous).

Note that for both ways of communicating there IS a baudrate, only 
for asynchronous it is determined externally (and needs to be the 
same for transmitter and receiver to have it working), for 
synchronous this is determined by these 'extra' signals (call it 
'bit-clock' or such). Bit-rate and baud-rate are not the same thing 
technically, I wouldn't know the exact difference between these 

I do not know exactly what method is used with JoyNet, if it uses a 
fixed bit-timing, that would make it asynchronous. If it uses an 
extra signal, besides the data-carrying signal, that would make it a 
synchronous communication (you figure that out).

Besides: if JoyNet only standardises the cable, than that leaves the 
programmer free to choose for a synchronous or an asynchronous 
communication method. If the number of connection lines in the cable 
is such, that no extra lines besides the data lines are available, 
then that would automaticly force asynchronous communication to be 
used. If not, both methods could be used.

Anyway, my suggestions were just that. Whether you think it's needed 
to implement these in your applications, is up to you. Generally, I 
-For networkgames, SPEED is crucial, and error-checking not that 
important, or not at all
-For data-transfer, speed is not THAT important, and error-checking 
might greatly improve reliability. If not needed (with good, short 
cables, and/or low speeds) it won't matter, IF needed (under worse 
conditions), a proper error-detection mechanism can well be the 
difference between something working lousy, and something working 
normal, but just a bit (!) slower. That's all. And you should know 
that less-than-optimum conditions are more common than optimimum 


Alwin Henseler    ([EMAIL PROTECTED])

http://huizen.dds.nl/~alwinh/msx     (MSX Tech Doc page)
http://www.twente.nl/~cce/index.htm    (Computerclub Enschede)

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/)

Reply via email to