[Simh] Way out idea for simh

[Ken Cornetet]

I guess I need to shout this:

******* KERMIT DOES NOT WORK ON SIMH EMULATED RTE-6/VM ********

Kermit does not exist (and probably couldn’t feasibly exist) on any earlier versions of RTE.

Also, people keep reminding me that some simh guest OSes  don’t’ have the ability to read raw disks. Well, I’d venture to say that even more simh guest OSes lack a working Kermit.

Even if Kermit does exist for a guest OS, you may not have a binary available, nor the compiler needed to compile it.

Yes, Kermit is wonderful. I used it extensively in the days when I worked on a real RTE system. Unfortunately, it is not a generally useful option for simh users. The fact that much of the traffic on this list is “how do I get files in and out of guests” is pretty well proof of that.

What I’m trying to do is come up with something that would be relatively easy to implement in simh, and be useful in as many of the emulated machines as possible.






From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Kevin Handy
Sent: Wednesday, April 20, 2016 3:58 PM
To: Paul Koning <paulkoning at comcast.net>
Cc: simh at trailing-edge.com
Subject: Re: [Simh] Way out idea for simh

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.
All this stuff has been hashed over many times when the hardware was actually in use, and solutions were devised then to handle the
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.
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.
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.

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).

On Wed, Apr 20, 2016 at 1:14 PM, Paul Koning <paulkoning at comcast.net<mailto:paulkoning at comcast.net>> wrote:

> On Apr 20, 2016, at 3:08 PM, skyvis at sky-visions.com<mailto:skyvis at sky-visions.com> wrote:
>
> 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.

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.)

        paul


_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160420/08e654cf/attachment.html>