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(a)k2.scl.cwru.edu Received: (from major@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(a)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(a)minnie.cs.adfa.edu.au>; Wed, 13 Jan 1999 11:00:10 +1100 (EST) Received: from flamingo.McKusick.COM (mckusick@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(a)flamingo.McKusick.COM> To: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) Subject: Re: 11/730 question cc: pups(a)minnie.cs.adfa.edu.au In-reply-to: Your message of "Tue, 12 Jan 1999 18:18:35 EST." <199901122318.SAA04873(a)skybridge.scl.cwru.edu> Date: Tue, 12 Jan 1999 12:18:13 -0800 From: Kirk McKusick <mckusick(a)mckusick.com> Sender: owner-pups(a)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@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)