Re: TI-H: Talk 85

[Prev][Next][Index][Thread]

Re: TI-H: Talk 85

On Sat,  9 Nov 1996 23:43:29, -0500, you wrote:


>TI DOES NOT USE A CLOCK SIGNAL!!!  It would not be accurate.  See? =20
>Look:  As we know, the speed of the calc's varies with the battery=20
>strength.  Let's say the the batteries in the sending calculator are=20
>BETTER than the ones in the recieveing calc.  This would mean that=20
>the sending calc is running FASTER than the recieving calc.  Now the=20
>recieving calc CANNOT keep up with the clock pulses coming from the=20
>sending calc, causing the recieving calc to "miss" a few bits of data=20
>here and there.  THAT IS WHY THIS METHOD IS INSANELY ERROR-PRONE. =20
>Even if it WAS used, the transmission would have to be slowed down=20
>greatly, to ensure that the calc's could keep up with each other. =20




You're right that there's no clock signal, but your logic is pretty
much all wrong.


Even if one calculator was at "full" speed (i.e. fresh batteries) and
the other calculator was running on near-dead batteries, the
transmission would be fine.  You see, 9600 bps translates to a bit
clock period of about 400 microseconds.  To a human, this is an
extremely small time period.  However, to a 6MHz Z80, this is an
eternity!  In 400 microseconds the processor can execute over 4000
instructions!!!  It's literally twiddling its thumbs waiting for the
next bit to come in.  That's why transfers never get screwed up.  This
is why the transfer rate with the RAM Expander will be on the order of
30000 to 100000+ bps.


Second, there IS actually a clock signal, but not in the normal sense.
A standard RS232 serial port is setup for synchronous transfers.  This
means that all transmissions are sent based on a clock signal, so in a
sense the data stream itself IS the clock signal.  There's no clock
reference signal being sent along side the data because the data does
that for you.


The serial protocol is actually even more complex.  You've got all
sorts of extraneous timing things to keep track of (like when
transmission starts, break signals, latency and timeout periods,
etc.).  Once you understand that stuff, then you move into other
subprotocols such as xmodem, zmodem, and tcp/ppp packet transfer
methods.  A few days ago people were talking about using zmodem and
xmodem and the like, and I can say now that forget about 'em.  The
zmodem specifications like 100 pages!!!  Those things are far too
complex to be implemented on the TI.


-Mel


<pre>
--
The TI Memory Expansion Homepage
http://pilot.msu.edu/user/tsaimelv/expander.htm
</pre>
References: