I think this is missing the actual problem. If a simh supported machine
has some kind of (paper/magnetic) tape oder disk device, they are almost
always physical files on the host system which can be attached/detached
by simh console commands. What is in the files, a file system or bit
stream or block structure, and what data encoding is used, is entirely
depending on the emulated operating system. Since some simh emulators
support different operating systems, like RT11/RSX11/Unix7 on a PDP-11,
a built-in FTP API (or any other transfer utility, Zmodem, Kermit, etc.)
must effectively know what OS is currently running.
Some structures, like Files-11, are well documented, other might not, or
not fully. If the data structures used are sufficently known, whether
simple or not, one can write host software that converts a user file and
extracts or injects it into the expected data structure. There are
numerous programs for all kinds of guest operating systems; and I have
myself written some as well whenever I need them, but neither are such
tools complete or portable, nor are they based on a widely accepted
source format.
This leaves the burden to the target operating system to write a
conversion tool that takes some input - from whatever source - and
converts it into its own native file format. This is probably even more
challenging, because unless it is an already supported input source,
like a paper-tape reader or an emulated serial line, one needs to write
some kind of device driver, or as suggested for RTE/6VM, some custom
microcode instruction, to be surrounded by some native assembler or
FORTRAN file (which leaves the open question whether this then can be
reused in RTE/IVB, RTE-A, MPE etc. without major rewrites).
The Kermit approach appears to be most feasible for the moment, as it
actually works through a supported input source, does the necessary
conversion, and is anchored in the target operating system where fo
which it exists. It should rather be analyzed why it doesn't seem to
work on RTE - operating system issue, or simh emulation flaw? I remember
having transferred numerous files between the HP1000 and the big VAX in
a former life. Surely, certain file types won't work, but text is
commonly possible. And for some special cases with IBM iron, there were
native EBCDIC converters.
Surely it won't work for very old systems for which no Kermit exists,
but then also some other means like an FTP API wont' help either.
The terminal emulation issue that only QCterm might be usable with
HP1000 is a different topic, but it is a related general problem: not
every system can deal with the lingua franca VT-100/ANSI, and not all
terminal emulators work correctly.
Holger
Am 20.04.2016 um 20:48 schrieb Ken Cornetet:
Again, you don't need OS support for foreign file systems, you just need to be
able to read the disk blocks in a raw mode.
-----Original Message-----
From: Simh [mailto:[email protected]] On Behalf Of Rich Alderson
Sent: Wednesday, April 20, 2016 2:31 PM
To: [email protected]
Subject: Re: [Simh] Way out idea for simh
Date: Wed, 20 Apr 2016 17:04:18 +0000
From: [email protected]
For example the B5500 does not have the concept of a mountable pack.
Drives could be attached, but they were a permanent attachment. For
the Ibm 7000 line, most did not support disk. The disk drive that was
supported by many of the machines was a large box that you could not
put drives into (IBM 1301/2301). Also these machines all worked in BCD
(6 bit), not Ascii.
I am also not sure when TOPS10 got support for mounting foreign file
systems. I don't believe that 6.03 or 5.03 support this idea.
As of 7.05 (the very last maintenance release, from 1990) it still hadn't.
I work with it daily.
Rich
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
