> 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