rtsi.com/2014.01.www.rtsi.com.tar/www.rtsi.com/OS9/OSK/TELECOM/rzsz_3_24_3_OSK.lzh/Notes.CoCo

Text File | 1993-11-07 | 5KB | 97 lines

Notes for CoCo users:
---------------------
It is highly recomended that you use one of the Bruce Isted RS-232 drivers
(SAcia or DAcia) from the Eliminator Software package if you are using a
"standard" RS-232. Also, you should install one of the new clock modules that
has the GIME toggle IRQ fix. If you have a "Halting" floppy/HD controller, you
should use a RAMDISK device for Zmodem receives. Finally, note that proper
RTS/CTS hardware handshakeing is required for reliable operation at speeds over
2400 baud (Most versions of "Standard" RS-232 paks have a 6551 ACIA chip in it
that does NOT handle CTS transitions properly)
--
PrJ



Notes for CoCo hackers:
-----------------------
To compile this source on the CoCo, you will need Tim Keintzles make utility,
Carl Krieders clib.l, and C_Prep 1.8 (or newer). The stock c.prep dies due to
the massive amounts of "#define" directives.
--
PrJ


Hand optimization to enhance speed by Maurice E. (Gene) Heskett, who does
NOT claim to be a C guru, and who will not be responsible for its miss-use
or erronious performance in any way.

The code included here is NOT 6309 specific.

When the original rzsz program package available here in the database was
compiled, it was apparently done using the standard distribution clib.l at
link time. It doesn't really make that much difference in the area I've been
re-working however since all the available libraries share one rather
glaring fault when its time to do a shift operation such as is called for by
finding a set of >> to the right of a variables name in a line of code.

Now, one thing that is in common for both 16 and 32 bit versions of a crc
generator for telecom useage is that the most common shift by far is a "by
8" shift. This shift is very easily done in assembly with the nemonic pair
of "tfr a,b" and "clra", (or the reverse direction) for doing a right shift
of 8 bits, 20+ times faster to do than the "test for done, if not do one
bit, branch to test", particularly if the shift is over a 'long' instead of
an integer (or byte) Why the original compilers library didn't test for an 8
bit or multiple thereof shift request and sub the correct tfr's is beyond
me, but so far none of them do. Boisy tells me he might look into that
eventually so all isn't lost.  If that was done, then anybody could expect a
speedup in his C programs without having to do the monkey business of hand
tweeking the .a file the compiler can make if given that option and then
continueing the compile to the target .r file for eventual linking into
runnable object.  This hand tweek will get the faster code though.

Here is a set of rz and sz object files which have had the crc routines hand
optimized to handle both the 16 bit and the 32 bit shifts entirely in the
processor registers or directly in memory without resorting to the slower
library calls.  That did not remove the library code totally as sz in
particular has shifter calls for both 6 and 7 bit shifts.


In testing this code over a 14.4/V42BIS hookup, I did find one item that
could create some #$%&*)($# comments in the case of rz.  The problem, or
potential problem has to do with the size of buffer assigned to Sacia via
the 'xtp' byte in the /t2 descriptor.  I had been running with it set for
3840 bytes here with xtp=$0F.  After we had crashed out in the middle of the
testers returning the sz test file to me on 3 occasions, it came to us at
about the same time that the input buffer shouldn't exceed the block size,
else there would be so much data in the buffer thats unread that it would
never get back in sync once an error repeat command had been sent. And it
apparently exited so quickly that no error message could have been read had
it been issued on this end.  The errors reported were reported on the
sending end however.

So I changed the bootfile's /t2 descriptor so reduce it down to only 3 pages,
or 768 bytes. Then rebooted.  Now the rts lights on the sniffer show a lot
more activity as it controls the data flow, but it never overruns the
present frame of data being moved. And it worked just fine. Now I could see
where some systems that start out at 512 byte frames could still overrun it,
Delphi runs the first 10k at 512 byte frames, but at the same time, we're
not gonna worry about it very much unless Delphi installs some hi speed
lines. Anybody else I've called has *always* sent the first frame at 1024
bytes.

Our rz speeds weren't too bad, until I reduced the buffer. As long as we
could buffer it, the data came in at rates between 1136 and 1280 cps. The
reduced buffer size cut into the speed since it was holding the other end up
in mid frame.  The average rz speed over a 24k file was then about 580 cps.
sz, in this latest incarnation sent at a pretty steady 351 cps.  Neither of
those last 2 real world figures are anywhere near a good 9600 baud circuit
*yet*. Stay tuned!  I've got some untested ideas yet.  Note that both of the
first 2 rz figures are *above* the 960 cps a 9600 baud circuit should be
able to handle, so the Amiga timer/counter might not be dead accurate that
we were using to "meter" this test.  His com prog is set to talk to his
modem at 57,600 I think. He has logged a maximum xfer rate at 5200+ cps a
couple of times.
--
Cheers, Gene Heskett