2 Aug
2006
2 Aug
'06
12:24 p.m.
Chuck Guzis wrote:
Yes. Anything that provides a reasonably unambiguos "signature"
On 8/2/2006 at 11:32 AM Don Y wrote:
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.
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 bidirectional
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. 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 C
compiler), it wouldn't be an onerous job. You could probably do that
while the transfer was running. 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.