[TUHS] Upgrading from 11/40 to 11/45 in Unix v6
jnc at mercury.lcs.mit.edu
Mon Dec 31 16:51:25 AEST 2018
> From: Will Senn
> We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a
> PDP 11/45 (preferably another SIMH)
Heh! When I saw the subject line, I thought you wanted to upgrade a
_physical_ -11/40 to an -11/45. ('Step 1. Sell the -11/40. Step 2. Buy
an -11/45.' :-)
> for our Unix v6 installation.
Why on earth would an organization have such a thing? :-)
> Our CEO was traveling and met a techie in first class (seriously,
> first class?) who told him that we needed one.
Heh. If said techie knows about the two, he's probably pretty senior (i.e.
eligible for Social Security :-), and thus elegible for first class... :-)
> It has fairly low utilization - a developer logs in and writes code
> every few days
Who the *&%^&*(%& is still writing code under V6?!
And how do you all get the bits in and out? (I run mine under Ersatz-11,
which has this nice device which allows it to read files off the host file
system; transfering stuff back and forth is a snap, I do all my editing with
Epsilon on my Windoze box, 'cause I'm too lazy to bring up the V6 Emacs I
> 1. Are there any v6 specific concerns about upgrading?
Not that I know of.
> 2. Why should we consider taking the leap to the 11/45? Everything
> seems to work fine now.
You're asking _us_?
Some larger applications will only run on an split-I-D machine, is about the
only reason I can think of.
Oh, also, the floating point instructions on the /45 are the only kind
understood by V6; the C compiler doesn't emit the ones the /40 provides. Any
floating point code run on the /40, the instructions are simulated by a
trap handler (by way of the OS, which has to handle it and reflect it to
the user process). I.e. very slow.
> 3. If we jump in and do the upgrade, how can we immediately recognize
> what has changed in the environment? I.e what are some things that we
> can now do that we couldn't do before?
> 4. If we just insert our current diskpacks into the new system, will it
> just boot and work? Or what do we need to before/after booting to
> prepare/respond to the new system?
Any V6 disk pack can be read/mounted on any V6 machine. Any binaries (the OS,
or user commands) for the -11/40 will run on the -/45. (Which is why the V6
dist includes binaries for /40 versions of the OS only.)
To make use of the /45, you need a different copy of the OS binary, built from
a slightly different set of modules. (Replace m40.s with m45.s; and you will
need to re-asssemble l.s, prepending it with data.s.) Both variants can live
on the same pack, under different filenames; select the right one at boot
> 5. Is 256K enough memory or what configuration do y'all recommend?
256KB is all you can have. Neither SIMH nor Ersatz-11 support the Able
which is what you need to have more than 256KB on a UNIBUS -11.
> From: Clem Cole
> You'll probably want to configure a kernel for the 45 class machine.
> Look at the differences in the *.s files in the kernel.
More importantly, look at the 'run' file in /usr/sys, which has commented
out lines to build the OS image for /45-/70 class machines.
> But either way you should configure the system to use the largest drive
> v6 has.
This is actually of limited utility, since a V6 file system is restricted to
65K blocks _max_. So a disk with 350K blocks (like an RP06), you'll have to
split it into like 5 partitions to use it all.
> From: Will Senn
> Do you know of some commonly used at the time v6 programs that needed
> that much space?
Heh. Spun up my v6, and did "file * | grep separate" in /bin and /usr/bin,
and then recalled that V6 was distributed in a form suitable for a /40. So,
Did the same thing on /bin from the MIT V6+ system, and got:
a68: separate I&D executable not stripped
a86: separate I&D executable not stripped
bteco: separate I&D executable not stripped
c86: separate I&D executable not stripped
e: separate I&D executable not stripped
emacs: separate I&D executable not stripped
lisp: separate I&D executable not stripped
mail: separate I&D executable not stripped
ndd: separate I&D executable not stripped
s: separate I&D executable not stripped
send: separate I&D executable not stripped
teco: separate I&D executable not stripped
No idea what the difference is between 'teco' and 'bteco', what 's/send' do,
> Is there any material difference between doing it at install time vs
> having run on 11/40 for a while and moving the disk over to the 11/45
No; like I said, you can have two different OS binaries on the disk, and
select which one you boot.
> On a related note, how difficult is it to copy the system from rk to
> hp? I know I can rebuild, but I'm sure there's a quicker/easier method...
Build a system with both, and then copy the files? I'd use 'tar' (I have a V6
tar, but it uses a modified OS with the smdate() call added back in) to do the
moving (which would retain the last-write dates); 'tp' or 'stp' would also
The hack _I_ used on simulated systems was to expand the file that held the
'disk pack', mount it as a different kind of pack (RL or RP), and then go in
and hand-patch the disk size in the root block with 'db', then 'icheck -s' to
re-build the free list. Note: this won't give you more inodes, so you may run
out, but the usual inode allocation is pretty generous.
PS: Speaking of the last write dates, I have versions of mv/mvall, cp/cpall,
ln, chmod etc which retain them (using smdate()). If there's an actual
community of people using V6, I should upload all the stuff I have. Although
it might be good to establish some central location for exchange of V6 code.
However, I don't and won't (don't even ask) use GitHub or any similar modern
More information about the TUHS