11/730 question

11/730 question

[Michael Sokolov]

Dear PUPS/TUHS members,

I wonder if any of you has some input on this issue. As I'm preparing for
making my planned disk labeling improvements (making it possible to install the
system on a fresh unlabeled disk in a more or less straightforward way), I
first want to clean up some mess in the standalone system. One thing that
annoys me in there is that for every standalone program that's supposed to go
on the console media there are two versions built, a normal one and a "730"
one. The comments say that 11/730 has a microcode botch that prevents it from
loading programs larger than 12.5 KB, so supposedly all "730" standalone
programs must be smaller than that. However, right now all standalone programs
are around 30 KB, and the difference between the normal and "730" versions is
only about 3 KB, even though the "730" versions do have the MASSBUS and BI code
compiled out. Wondering if there is a way to make them smaller, I looked at
older versions, and guess what, even in 4.2 the "730" versions are a little bit
over the alleged 12.5 KB limit! That's right, 4.2BSD is the first release with
11/730 support, and its standalone programs are already over the alleged 11/730
microcode limit!

This raises quite a few questions. First of all, does the 11/730 microcode
really have this limitation, or is it just a hoax? If this limit does exist,
when exactly does it apply? The BSD distribution TU58 cassette always used the
full versions of the programs, not the "730" ones (the distribution cassette is
also used for 750s), and yet apparently 730s could be bootstrapped from it.
Maybe this limitation applies only to automatic bootstrap and not to manual
loading? And if this is indeed a microcode botch, are there any patches
available for it?

I would appreciate it if someone here can provide some answers to these
questions. I would really like to get rid of those "730" standalone programs,
but I can't do it if this would break 11/730 support. (It's my responsibility
as the 4.3BSD-* maintainer to only add features, but never break anything that
works in plain 4.3 or 4.2.)

Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46 at k2.scl.cwru.edu

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA13144
	for pups-liszt; Wed, 13 Jan 1999 11:00:18 +1100 (EST)
Received: from flamingo.McKusick.COM (root at flamingo.mckusick.com [209.31.233.178])
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id LAA13139
	for <pups at minnie.cs.adfa.edu.au>; Wed, 13 Jan 1999 11:00:10 +1100 (EST)
Received: from flamingo.McKusick.COM (mckusick at localhost [127.0.0.1])
	by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id MAA10534;
	Tue, 12 Jan 1999 12:18:13 -0800 (PST)
Message-Id: <199901122018.MAA10534 at flamingo.McKusick.COM>
To: mxs46 at k2.scl.cwru.edu (Michael Sokolov)
Subject: Re: 11/730 question 
cc: pups at minnie.cs.adfa.edu.au
In-reply-to: Your message of "Tue, 12 Jan 1999 18:18:35 EST."
             <199901122318.SAA04873 at skybridge.scl.cwru.edu> 
Date: Tue, 12 Jan 1999 12:18:13 -0800
From: Kirk McKusick <mckusick@mckusick.com>
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

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. It was a very feeble
processor (0.3 of a 780) and very few of them were ever sold.
We had only one at Berkeley (for porting purposes), and it was
so slow that we were not even able to pawn it off on the
undergrad CS organization when we were done with it.

	Kirk

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA13915
	for pups-liszt; Wed, 13 Jan 1999 15:15:54 +1100 (EST)
Received: from eclipse.scl.cwru.edu (eclipse.SCL.CWRU.Edu [129.22.32.56])
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id PAA13910
	for <pups at minnie.cs.adfa.edu.au>; Wed, 13 Jan 1999 15:15:44 +1100 (EST)
Received: (from smap at localhost)
	by eclipse.scl.cwru.edu (8.8.8/adam2.2) id XAA24338
	for <pups at minnie.cs.adfa.edu.au>; Tue, 12 Jan 1999 23:15:38 -0500 (EST)
Received: from <mxs46 at k2.scl.cwru.edu> (k2.scl.cwru.edu [129.22.32.50]) by eclipse via smap (V2.0)
	id xma024336; Tue, 12 Jan 99 23:15:33 -0500
Received: by k2.cwru.edu (8.6.12/SMI-SVR4)
	id XAA12527; Tue, 12 Jan 1999 23:19:36 -0500
Received: from <mxs46 at k2.scl.cwru.edu> (skybridge.scl.cwru.edu [129.22.32.1]) by k2.scl.cwru.edu via smap (V2.0)
	id xma012525; Wed, 13 Jan 99 04:19:33 GMT
Received: by skybridge.scl.cwru.edu (SMI-8.6/SMI-SVR4)
	id XAA04949; Tue, 12 Jan 1999 23:29:12 -0500
Date: Tue, 12 Jan 1999 23:29:12 -0500
From: mxs46@k2.scl.cwru.edu (Michael Sokolov)
Message-Id: <199901130429.XAA04949 at skybridge.scl.cwru.edu>
To: pups at minnie.cs.adfa.edu.au
Subject: Re: 11/730 question
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

Kirk McKusick <mckusick at 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 at k2.scl.cwru.edu