<div dir="ltr"><div><div><div><div>I think you are trying to over-engineer this file transfer stuff.<br><br></div>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. <br></div> Instead of building all this code into simh to convert from one disk file<br></div> 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".<br><br></div><div>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.<br><br></div><div>All this stuff has been hashed over many times when the hardware was actually in use, and solutions were devised then to handle the <br>numerous problems. Creating new interfaces, new instructions, etc. and modifying OS's just to re-implement kermit in another way seems to be a lot of overkill to me., but most of these messages seem to have no advantages to just using existing kermit capabilities.<br><br></div><div>If you want shares access the host filesystem, look to 'nfs'. If the emulated system doesn't already have shared filesystem already, you are probably going to be fighting such things as the disk caching code. File system corruption is very likely to occur.<br><br></div><div>A lot of the simulated OS's have more basic problems that just making the raw data available to the host OS. VMS doesn't store anything, including text files, in a "stream of byte" form. Others have 6 or 9-bit bytes. Then there is ASCII (multiple variants) EBCDIC (multiple variants), BAUDOUT, etc.<br><br>I think it would be more advantageous to write disk image manipulation routines to insert/extract files to the simulated disk images (while simulator is not running).<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 1:14 PM, Paul Koning <span dir="ltr"><<a href="mailto:paulkoning@comcast.net" target="_blank">paulkoning@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Apr 20, 2016, at 3:08 PM, <a href="mailto:skyvis@sky-visions.com">skyvis@sky-visions.com</a> wrote:<br>
><br>
> OS's don't support foreign file systems. What they do is provide the ability to access a drive that does not have what they believe to be a valid file system.<br>
<br>
</span>Not necessarily.  RSTS does in the latest versions, but not in early versions.  For example, RSTS V4A has no raw disk API, and gives you no access to any disk except via the RSTS file system.  The same goes for some other operating systems; I don't know of raw disk access on CDC NOS either, for example.  (Well, not unless you write a PPU program; if you don't mind doing that, the job is easy.)<br>
<span class="HOEnZb"><font color="#888888"><br>
        paul<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Simh mailing list<br>
<a href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" rel="noreferrer" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></div></div></blockquote></div><br></div>