4 Aug
2006
4 Aug
'06
4:55 a.m.
If all else fails there's always kermit and a null modem cable.
The binary is probably on line at Columbia.edu...
On 8/2/06, Don Y <dgy at dakotacom.net> wrote:
Chuck Guzis wrote:
C
On 8/2/2006 at 11:32 AM Don Y wrote:
bidirectional
Unfortunately, you then need *one* box with
hardware suitable
to capture the incoming bytestream (i.e. *not* an SPP).
I know this is a vintage list, but at a minimum, PS/2-style parallel ports have been around for a very long
time, so this shouldn't
be
a problem. Even if you had an old XT, printer
and monochrome adapter
cards
can usually be modified to operate in
bi-directional mode.
After that, it's just the cable and a bit of software on the receiving
side.
Or, a small bit of hardware to mux the 8 data lines onto the
incoming status lines (SPP). I.e. you only need *one* of
these and *one* machine with this capability to handle
a variety of "source" machines.
Ideally,
the source box would have MD5 or some other hash
available so you could gain some reassurance that the
received image agreed with the sent image.
CRC-32 would probably do if MD5 wasn't available, and it's short enough
that if you had to key the C source in (assuming that the SCO box has a compiler), it wouldn't be an onerous job.
You could probably do that
while the transfer was running.
Yes. Anything that provides a reasonably unambiguos "signature"
Failing that, you could transfer the tarball
twice and compare the two
files. A miscompare wouldn't tell you which was bad, but it would at
least
indicate that something had gone wrong.
I'd shy away from that. In addition to the issue of
"what happens if you get N different results (N>2)",
you are also vulnerable to any problems in the *mechanism*.
E.g., if the I/F was not 8 bit clean, you would *think*
you had a successful transfer and actually lost all the MSB's.
Likewise if a signal is shorted in the cable, it will
consistently yield the same (wrong!) results.