I haven't heard any mention of ANSI labeled tapes as a data format. OS
support varies, and interpretation of the standard varies perhaps even more.
I never liked them much (I never had good tools for them on my real
hardware). In theory it should be a reasonable common format.
On 04/21/2016 03:56 AM, Veit, Holger wrote:
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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
