[Simh] Way out idea for simh

Wed Apr 20 17:28:52 EDT 2016

If Kermit does not work on SIMH emulated RTE-6/VM, but works on the real hardware, then I’d say there’s a BUG in the emulator that needs fixing. Derp.

Ø  Kermit cannot be made to work reliably on RTE-6/VM under simh.

Ø  At least I was never able to make it work.

Ø  Not to mention that trying to use an emulator other than QCTerm (which doesn't do Kermit) with RTE is a major PITA.

Ø  I used Kermit extensively on real RTE systems to transfer files to a variety of systems.

Another option is to start a file creation in the emulation from the serial port and use a terminal emulator to cut and paste (slowly) the ascii or hexified file in for you (hopefully with a windows cut/paste), or type(cat) the file to the terminal emulator and select/copy the text out to a host file. Attachmate has worked well for me as a slow cut/paste terminal emulator. Hexifying binaries is a tried-and-true serial copy method when flow control is non-existent or suicidal, and there are quite a few tools to hexify/unhexify data streams.

There’s also lot of tools available for file conversion (mangling), and Kermit is supported on many platforms. Look at the older Kermit-16 and Kermit-32 if you want a simpler Kermit.

If you want to write a universal file transfer tool for ALL of the hosts and emulators SIMH supports, AND write in the OS support drivers for it on ALL of the emulated OS’s, then go for it. But it’s a lot more work than you might think, for very minimal gain.

If it was <me>, and I was having problems with file transfers to a <specific> emulator/OS combination, I’d look to find a solution for that specific platform problem, and not try to solve all of the SIMH host file transfer problems with a universal solution. You’re looking for a universal solution to 50+ years of device and filesystem incompatibility. Most people agree that Kermit is the most universal file transfer solution available.  :-S

Dave

From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Ken Cornetet
Sent: Wednesday, April 20, 2016 4:15 PM
To: simh at trailing-edge.com
Subject: EXT :Re: [Simh] Way out idea for simh

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<mailto:paulkoning at comcast.net>>
Cc: simh at trailing-edge.com<mailto: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/c62ea53d/attachment-0001.html>