new disk controllers for DEC platforms (was Re: Q-bus to CF)

On Sat, Mar 01, 2008 at 08:35:14PM -0500, Charles H Dickman wrote: And in the case of the PDP-11, several 20-year-old OSes, or in the case of the VAX, a few old OSes, of many versions. I have an sbc6120 w/IDE interface. It's great. It's also a case of writing _a_ device driver for the most common case, OS/8. While there are a few versions of OS/8 out there, there's no compelling reason to want to write an IDE driver for, say, OS/8 v2, since there is little reason to _run_ OS/8 v2, even on real hardware. This is very much _not_ the case for newer DEC hardware. For the PDP-11, RT-11 is very popular for small systems, but does run on pretty much every -11 made, from an LSI-11 (11/03) all the way up to an 11/93. If you happen to have an 11/70, you are probably going to be running some flavor of RSTS/E or BSD UNIX, but it's not a requirement. Same goes for the other large Unibus machines - they will run RT-11, but you are probably going to have some multi-user OS on it. On real machines, I've seen the spread from RT-11 V2, V4.00, V5.X, to RSX-11 and -11/M 2.X, 3.X, 4.X, as well as nearly every version of RSTS/E being the most popular). To increase the fun and complexity, sticking merely with Unibus and Qbus VAXen, the interest is there for running VMS 1.0, VMS 3.X, VMS 4.X and VMS 5.X (I don't imagine someone is likely to run VMS 6.X on hardware with a Qbus or a Unibus, but it's not impossible). There are favorite spots in there, so it's not like you'd even try to support every single point-release of VMS, but at the very least, 3.6, 4.0, 4.5 and or 4.6, plus 5.4 or 5.5 come to mind, and there was a lot of evolution in drivers and priv mode code over that spread, especially between 4.x and 5.0 (adding SMP support with spinlocks, etc). My point is that it makes sense in the near monoculture of the PDP-8 to craft a new interface and a new driver. You can cover 90%+ of your audience with one piece of code. In the PDP-11 and VAX realm, there are so many more choices that even to hit 50% of your target audience, you'd need three drivers, let's say - RT-11 V5.3, some arbitrary version of VMS (V5.4?), and 2.11BSD. Emulating a real DEC or third-party disk controller wipes away a *lot* of software effort, concentrating the effort into one place - the microcode/firmware on the disk controller. If there are bugs, you fix them in one place, not potentially several. the behavior of most disk controllers is (was?) well known, so that any register-exact emulation failures should show up fairly quickly. When I used to run a room full of DEC equipment, we had nearly all DEC disk controllers, since we had to support about a dozen OSes based on what our customers were using. We had one VAX with RK07s that we _didn't_ upgrade, specifically because we could swap out a pair of packs, reboot, and match our customers' specific environment. Later, we did upgrade that same VAX to have a pair of RA81s (plus other disks) so that we could have two primary OSes on a largish system (VMS and Ultrix) for the same reason. Each of our PDP-11s was rigged to handle two or three OSes (some flavor of RSX-11, of RSX-11/M, and sometimes one or two flavors of RSTS/E) on two to four RL02 drives. Out of all of this variety, one machine stood out - our main company shared VAX on which we did all of our C development, word processing (MASS-11), and e-mail... it had a Fuji Eagle attached via an SI9900 - I've written about it here before - The single most difficult part of our entire machine room to deal with when it came time for upgrades. We had to wait until Systems Industries issued patch tapes to twiddle the DRDRIVER.EXE with a new geometry table. It was the real and genuine DEC driver for our OS, but we couldn't use our big disk because the driver didn't know about it. That's nowhere near as hard as a third-party disk with an entirely third-party driver. So... while a cheap and simple IDE interface might be a seductive path, given how many different OSes would have to be supported, I think it's worth a little design time to come up with something that can use the drivers that are already there on the install media for a large collection of platforms and operating systems. Obviously, older OSes might have a problem with a card that only speaks MSCP (newer ones will *love* it), but someone's suggestion for a flexible card that might be able to emulate an RL02 w/four drives (as was really done for small systems w/ST-506-type drives) or an RK611 w/multiple RK07 drives or even a third-party controller like an Emulex w/SMD or ESDI drives (hpdriver under 2BSD, for example) might be a way around both issues (OS MSCP support and the complexity of building an MSCP controller in the first place). My purely personal preferences would be to be able to run such a card under RT-11 v5.3 and newer, 2.9BSD and 2.11BSD, and VAX/VMS from, say, 4.0 through 5.6, with VMS 3.6 being a bonus (since it was my first exposure to VMS). I might want to eventually run a different OS on a PDP-11 (RSX and RSTS), but I would not make a purchase based on those. I'm sure everyone else here has their own unique combinations of OS and platform priorities, but I thought I'd throw mine out there for debate. And, yes, I _would_ buy a card that fit that niche, as long as I could get it for, say $200 (even if I can only get a bare board and stuff it myself for that price). I'd be substantially less inclined at the $350 level. For that kind of money, I'd be more likely to slap an IDE interface on an old COMBOARD and start writing drivers (all COMBOARDs have DMA interfaces and 8MHz-10MHz 680x0 CPUs that could push about 200kb/sec to the bus. I have a pile of Unibus and VAXBI COMBOARDs, but only one or two Qbus). -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 2-Mar-2008 at 07:09 Z South Pole Station PSC 468 Box 400 Temp -53.7 F (-47.6 C) Windchill -87.6 F (-66.4 C) APO AP 96598 Wind 12.5 kts Grid 11 Barometer 688.3 mb (10317 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html