From mboxrd@z Thu Jan 1 00:00:00 1970 From: mxs46@k2.scl.cwru.edu (Michael Sokolov) Date: Tue, 12 Jan 1999 18:18:35 -0500 Subject: 11/730 question Message-ID: <199901122318.SAA04873@skybridge.scl.cwru.edu> 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 ; 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 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 ; 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 ; Tue, 12 Jan 1999 23:15:38 -0500 (EST) Received: from (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 (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 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