below...
On Sun, Jan 29, 2017 at 6:13 PM, Jason Self <ja...@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?
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh