> On Apr 20, 2016, at 3:58 PM, Kevin Handy <khandy2...@gmail.com> wrote:
>
> I think you are trying to over-engineer this file transfer stuff.
>
> Instead of creating new devices for the transfer to operate over, why not use
> something that already exists on most of the simulators, like a serial port.
> Instead of building all this code into simh to convert from one disk file
> format to another. inside the simulator, use a progrm attached to the serial
> port which handles the hosts file access. You will still need a program on
> the simulated system to handle it's side of the transfers. W can give the
> whole setup a common name, like "kermit".
>
> Most of this stream just seems to me to re-inenting Kermit in one way or
> another. It might be fun/interesting but doesn't seem to gain anything beyond
> what Kermit already does.
Sort of. But Kermit does a whole lot more, things that are not needed here.
Kermit assumes a lossy interconnect with errors, while here that assumption is
not needed. And even E-kermit is fairly large -- 1600 lines of C code. Simply
to say "send me file "foo" now, with the reply being simply a stream of bytes
would be at least an order of magnitude simpler. The obvious data format would
be the SimH tape record format -- a block of bytes preceded by a byte count.
Attaching all this machinery to serial ports makes a lot of sense, assuming you
have them. Most machines do, though some (again, the IBM 1620 is a good
example) all you have is a console, and paper tapes). Some (like the EL-X1)
don't even have a bidirectional console port.
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
