[Simh] 32V on SIMH

[Clem Cole]

below...



On Sun, Jan 29, 2017 at 6:13 PM, Jason Self <jason at bluehome.net> wrote:

My next task is to be able to copy files back and forth between the
emulator and the host system.



​Others have answered this in pieces - let me see if I can pull it all
together so it is a little more crisp and give you better understand the
magnitude of what you have actually asked/observed.



As Mark points out, in those days the way a user interacted with the system
it was via a *Data Terminating Equipment* (*a.k.a.* a “DTE” or simply
computer “terminal”) and you moved data to and from it via a disk, tape or
over that serial link.   So, as he points out, anything you do today is to
emulate that world and somehow make a bridge or logical worm-hole between
the old and the new.  There are basically 3 issues and let me see if we can
explore a little the methods to solve them.



Issues:

1.    How do you get data to/from the old and new world (your original
question).



2.    The old system does not have stuff I need/desire from the new world
[tools, such as editors, newer languages or newer editions of a language,
support for more modern features].  Solution: either work around, do
without, or somehow add them to the old system.



3.    The new system is making an assumption that is not really valid in
the old world [address space size is usually the hardest, but missing
features].





32V is a simple V7 port to VAX.   It is pretty much the same state as the
Research V7 on PDP-11.  Which means, that the Solutions people have created
to these problems running simh for V7/PDP11 will pretty map well to 32V.
There are a number of HOW-TO’s around and other than address space, pretty
much what works for the V7 port will be the same as what is needed for the
32V.



So. let’s first consider you moving data to/from question.   As other
people on the list have pointed out, the quickest and simplest thing to do
is to start is use a virtual disk [ or tape – more in a minute].   To do
either, in the /dev directory make sure you have the proper mknod links
created, that your kernel supports them and simh has been configured to map
the virtual disk to local file in your host’s file system (/dev/rrpU{p} – U
unit and possible partition *e.g.* /dev/rrp3c).   With a “shared” virtual
disk/file in place you can read or write to the file using a tool in a
format the both systems agree (here in lies a different dragon).



The virtual disk file is a just a *sequence of disk data blocks* and
trivial to read and write.  All the Unix tools on both sides will “just”
work opening the raw device and you are done.  On the host file,
Unix/Windows/Linux/whatever, just write/read raw blocks and what-you-see,
if what you get.  Obviously, in 32V, you open the raw device and go at it.



You could (and I have) done the same thing with a virtual tape drive.  But
an issue is that format of the tape drive is *virtual tape blocks*, so it
has *data and meta data* in the same file [described in the simh docs and I
have host program I wrote to convert to/from a couple of these, not raw
disk blocks – other have done the same].



A virtual tape is useful for boot strapping and if you a distribution tape
that you need to access very low level, but if you the contents of the tape
as a stream of blocks, it is usually sufficient to put the blocks in a raw
disk.   [For instance, we used to do raw RK05 backup’s using a DEC DOS-11
tool called “rollin” and created a bootable mag tape.   So, the images I
have(had) of those tapes are both the raw data and meta data so I actually
boot them on simh].   But the extra step of preparing the virtual tape
image can be a hassle, so the raw disk is usually easier.



Anyway – the key to these two techniques is *sharing a file format* on both
the new and old system.   We often use tar(1) because it mostly works on
both sides.   It turns out Ken had a bug when he wrote the original V6
version of tar in how he did the checksum for the header, which we
exploited when we did the POSIX standard.   So, most modern implementations
will write metadata that the older versions will ignore (mostly).   The
USENIX “pax” implementation (which is what Apple is based on) is actually
the best here.  Gnutar in -–pax mode should work also, but I have seen
gnutar screw up and never chased down what they did the #$%^ it up with the
original tar (which is annoying but not enough to fix it because I have a
solution – not use gnutar).



The second scheme you mentioned was a shared a *file system* format.
Using something like FUSE allows you to mount an entire file tree.   This
is the higher BW because of course, it means with care, you can work on
both sides but … be careful because even if you find a copy of FUSE that
understands the exact file system layout that 32V used (and I’m not sure
the AccientFS stuff supported the 32V OS directly), the local OS will have
no logic in allows sharing.   When simh is running, the host side >>must<<
unmount the FS.



The next scheme is using the serial link.  You mentioned cut/paste with the
window manager and certainly we all do that for text.    But you probably
also will want something like Kermit or the like on a virtual serial
port.   As a quick and dirty solution, I recommend setting up
infrastructure to do be able to do this early.   You will find yourself
wanting to move things back and forth, particularly small binaries and this
will be a fast way when the simulator is up and you don’t have networking.



Which brings up networking.  No one to my knowledge at AT&T ported an IP
stack, although it does come with uucp.   So, setting up Taylor uucp on a
UNIX host side and running through the virtual serial port you can network
V7 style to 32V.   All the basic uucp tools are there and should “just
work.”   Although, since this is the original uucp implementation, you want
to hunt around and update the scripts to make it easier to manage and use,
as the original uucp had some rough edges and compared to what you will see
in the Taylor package, the 32V implementation may seem pretty crude.



As other folks have noted the BBN and BSD support for IP/TCP/Ethernet for
VAX UNIX would not be available for a few years. What is interesting is
that the 3Com UNET was written for pure V7 as Paul has recently noted.   If
we can manage to dig up the UNET sources and get it released from 3Com, it
might actually be a reasonable IP/TCP stack for V32 since its needs are
small and much of it is actually is user space.    Technically, besides the
obvious thing of UNET having not been released on the VAX to my knowledge
[Tek had an 11/70 and IIRC Borden and Shaw were using a 11/45], the biggest
issues is getting UNET to work for you will be that you will need an
Ethernet driver for 32V that talks to simh.  Greg Shaw wrote a V7 driver
for the 3Com 3Cx01 series Unibus board which should be in the UNET sources,
but alas I do not believe simh has support for it.  Also, if I find UNET
for Paul in my archives, I should also have Steve Glaser’s HyperChannel
driver in the same sources. So, it should be possible to look at Greg’s and
Steve’s drivers, and the try to write one for one of the DEC supported
Ethernet controllers of the 780 that simh supports.  Anyway, putting that
all together, might give you ftp and telnet – but such a project is going
to take a lot of work and I wonder if it worth it.





Which brings me to point #2.   What’s missing on 32/V.   As I said, a
number of folks have pulled together different tools for V7 from 1BSD,
2BSD, the Harvard Tapes, USENIX tapes *etc. *so you can have an editor
besides *ed* and the like.  Google in your friend here.  But you are likely
to want to build up the toolkit a bit.  And this opens up the first big can
of worms.   The problem is that V7 that C (and UNIX) changed over time.  So
you will have to be careful about which versions you can move.  V7 C is
“white book” K&R – which is good, much of the either code from 1BSD,
Harvard et al, is before that, so the compiler does supports the standard
I/O library and most basic language features accept for function prototypes
that are needed; although the libraries may not be as complete.    So, this
is where, looking what people have done in making V7 more comfortable will
be a huge help – it should tell you the types of things that you will need
and where to grab them to build some of the simpler tools.





The final point is moving code from the new world to the old world.
Function prototypes is just the beginning; whole subsystems will be
missing.   Warren has probably taken this the farthest with xv6-freebsd [
https://github.com/DoctorWkt/xv6-freebsd] work – the key point is that you
are likely to unhappy with the tools as is.  So how much do you need?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170130/e9c43d19/attachment-0001.html>