Kirk McKusick <mckusick(a)McKusick.COM> wrote:
I applaud your desire not to break old 4.2/4.3
machines.
I would be very resistant to losing support for a popular
machine like the 11/750. However, I think that losing support
for the 11/730 would be acceptable.
You are not the first person I hear this from, and I wouldn't completely
disagree. However, it always pains me very much when a system really ought to
run on a machine and has all the necessary ingredients, but fails because of
some tiny nit. This is exactly the case here. The CPU is supported, the console
storage device is supported, all bootstrap scripts are already written, even
the IDC is supported, but the standalone programs refuse to load because of a
ucode botch!
Now, I did look more carefully, and the boot.730 program does fit into 12.5 KB
after all in 4.2 and 4.3 (copy.730 fits in 4.2 but not in 4.3, and format.730
doesn't fit even in 4.2). So I guess it would be possible after all to massage
up the Makefile and the ifdefing in the sources to make the 4.3-Quasijarus
standalone system build a small boot.730.
However, the objections to this approach are:
1. Instead of tidying up the standalone system, this would make it an even
worse mess.
2. In future Quasijarus releases I plan to retire the current standalone
drivers for U/Q and BI MSCP and make the standalone system call DEC's own
VMB for I/O from/to all MSCP devices, making it possible to support MSCP on
more than just U/Q and BI. However, this means that all big VAX users with
MSCP disks will now need a copy of DEC's VMB.EXE in addition to UNIX's
native boot code. It will also have to be a recent enough version, and I'm
sure as hell that the version that came with 11/730 is too old. A newer
version of VMB can be pulled out of almost any VMS or Ultrix distribution,
but the one I have seen was 40 KB long. Thus even if I manage to make a
boot.730 that fits within 12.5 KB, you would still need the 40 KB VMB.EXE if
your disk is RAxx (the most common type), and this obviously makes boot.730
squeezing an exercise in futility.
Resolution: I will pitch the *.730 programs and add a note to the documentation
that installation on a 730 requires a ucode upgrade that fixes this botch. If
someone asks me where to obtain one (or how to write one if it doesn't exist),
I'll redirect them to this list, as I have no idea. :-)
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu