[TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Noel Chiappa]

    > 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
have.)

    > 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?

See above.

    > 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
time.

    > 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
ENABLE:

  http://gunkies.org/wiki/Able_ENABLE

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,
null set.

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,
etc.

    > 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
    > later?

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
work.

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.

	Noel

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
thing.