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
though.
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
think:
-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
conditions.
Greetings,
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/)
****
