So it shouldn't be a surprise that DEC, admittedly like many fellow mini makers, was similarly retrograde when it officially entered the personal computer market in 1982. At least on paper the DEC Rainbow was reasonable enough: CP/M was still a thing and MS-DOS was just newly a thing, so Digital put an 8088 and a Z80 inside so it could run both. On the other hand, the DECmate II, ostensibly part of the venerable PDP-8 family, was mostly treated as a word processor and office machine; its operating system was somewhat crippled and various bugs hampered compatibility with earlier software. You could put a Z80 or an 8086 in it and run CP/M and MS-DOS (more or less), but it wasn't a PC, and its practical utility as a micro-PDP didn't fully match the promise.
All of these systems were originally meant as commodity machines for office work, yet more or less with the exception of the Rainbow, they couldn't run much that office professionals actually wanted to run and little that existing PDP users did. Still, despite questionable technical choices, these machines (the Pros in particular) are some of the most well-built computers of the era. Indeed, they must have sold in some quantity to justify the Pro getting another shot as a high end system. Here's the apex of the line, the 1984 DEC Professional 380.
This particular unit is one of the few artifacts I have left from a massive DEC haul almost twelve years ago. It runs PRO/VENIX, the only official DEC Unix option for the Pros, but in its less common final release (we'll talk about versions of Venix). I don't trust the clanky ST-506 hard drive anymore, so today we'll convert it to solid state and double its base RAM to make it even more professional, and then play around in VENIX some for a taste of old-school classic Unix — after, of course, some history.
As a first salvo in the war, many mini makers chose to simply shrink their existing proprietary architectures further. Hewlett-Packard, for example, made a well-regarded line of "programmable calculators" and technical workstations out of their HP 2100 (later HP 1000) platform by miniaturizing it as the 1975 Binary Processor Chip. This, in turn, yielded reasonably popular systems like the HP 9830 and HP 9845, though HP was careful never to officially bill them as follow-ons to the originals. Texas Instruments also had similar success, at least early on, by turning the TI-990 (an evolution of the TI-960 and TI-980) into the 1976 TMS 9900 and even made inroads with it into the home computer world as the TI 99/4 family (including clones like the Tomy Tutor). It, too, was never sold as a successor to the 990; later 990 hardware even used 9900-series CPUs directly. However, TI got greedy and shortsightedly repulsed third-party development, while the 9900 architecture had what turned out to be a fatal dependence on RAM speed and became a technological dead end.
More problems occurred after the IBM PC scrambled the landscape and mini vendors tried touting their smaller "microminis" as upmarket alternatives, though these systems were deliberately less powerful than and sometimes mostly or totally incompatible with their big systems to avoid cannibalizing high-end sales. Their prices were likewise uncompetitive, so newer cost-sensitive customers continued buying cheaper PC-compatibles while legacy customers were unhappy their existing software might not work. Attempts to entice that low end by adding more typical microcomputer CPUs as compatibility options, usually the 8086 or 8088, simply made them into poor PCs that cost even more. Data General was one notorious instance as they repeatedly failed to parlay their successful Nova into smaller offerings, first with the poorly-received 1977 microNOVA, and later with the microECLIPSE in the bizarre 1983 Desktop Generation modular machines. While Data General claimed it could run everything the bigger MV hardware could, such software had to be converted by vendors "with standard software [in] a few hours" (PC Magazine 11/83), and its PC compatibility side was unable to run major applications like Lotus 1-2-3 without patches. Given how expensive the DG was, most developers didn't bother and most potential customers didn't either. For its part, although early rumours talked about a small System/370, IBM never turned any of their mainframes or minis into commodity microcomputers except for various specialized add-on boards, and the 5150 PC itself was all off-the-shelf.
Surprisingly, DEC was already in this segment, sort of, albeit half-heartedly and in small quantities. As far back as 1974, an internal skunkworks unit had presented management with two small systems prototypes described as a PDP-8 in a VT50 terminal and a portable PDP-11 chassis. Engineers were intrigued but sales staff felt these smaller versions would cut into their traditional product lines, and Olsen duly cancelled the project, famously observing no one would want a computer in their home. Team member David Ahl was particularly incensed and quit DEC in frustration, going on to found Creative Computing. A charitable interpretation says Olsen may have been referring to the size and state of computers at the time, and most people probably wouldn't have wanted one of those in their house, but it wasn't very future-thinking to imply they'd always stay that way. Olsen reiterated to the World Future Society in 1977 that "[t]here is no reason for any individual to have a computer in their home," later arguing in various retrospectives that he meant no one would want a computer at home controlling everything. True to his words, both Ken Olsen and Gordon Bell reportedly had terminals in their residences but no standalone systems.
In September 1981, however, Ahl alleged in Creative Computing that Olsen's attitude was changing, possibly goaded by the IBM PC's wildly successful launch in August or maybe when Ahl said "his [Olsen's] daughter begged for a computer at home," adding DEC's new low-end computer would be "based on the venerable PDP-8." (This became, of course, the DECmate II.) Olsen subsequently told investors in November to expect a "DEC personal computer" (his words), adding "we are not planning to go after the home computer market" but that it would be "equivalent" to the IBM PC. In early 1982 he intimated further that there would indeed be an updated DECmate soon, plus two new lower-cost "16-bit" systems. This project, administered by DEC's new Small Systems Group (SSG), was internally referred to as the "XT" Computer Terminal (not to be confused with the IBM PC/XT, which IBM didn't release until March 1983).
The machines were designed around a new interconnect called the Computer Terminal Internal (inexplicably abbreviated "XTI") bus, using a unique ZIF form factor for its interface cards incompatible with any other PDP-11 system prior or since. Both the XT120 and XT150 came with a full six expansion slots. XTI options developed by the designers included additional memory cards; a telephone management board for receiving, making and recording voice calls; a network interface card; and an Advance Video Option [sic] providing planar colour video. Except for the Winchester disks, DEC SSG explicitly intended to manufacture every single component, and it wouldn't be compatible with existing PDP-11s.
Late in the product cycle SSG management renamed the DEC XT to the DEC Professional (perhaps DEC had heard what IBM was planning to call its next system), changing the XT120 to the DEC Professional 325 and the XT150 to the DEC Professional 350. Critically, the 325 was made cheaper still by removing two of the XT120's slots, and the XT150 hard disk became optional in the 350; on the other hand, both systems also made the FPU standard. With the XT name shelved, the bus thus properly became the CTI bus. Meanwhile, the 128K RAM base was proving inadequate for its consumer menu-based operating system (what would become P/OS), forcing DEC to ship the RAM upgrade option pre-installed to yield 256K. This was an early sign of problems to come.
To industry observers' surprise, DEC uncharacteristically seemed to price the DECmate II and Rainbow to sell. The now 8MHz DECmate II had better hardware yet went for much less than the DECmate ($3745 [$12,600] compared to 1982's later price of $5845 [$19,700]), even considering it needed its own keyboard and monitor. However, what really startled people was the Rainbow. Introduced at $3495 [$11,700], DEC had already slashed it to $2675 [$9000] by the fall. At a time when a reasonably configured IBM PC system might set you back itself around $3500-ish in late 1982, with CPU, monochrome display, base 64K RAM and 180K floppy drive(s), a comparable Rainbow setup with 64K, baseline 400K RX50 5.25" dual drives and serial port, hybrid CP/M-86/80, LK201 keyboard and VR201 monochrome display came in at just over $3700 at the later pricing, with MS-DOS support on the way. Although the barebone 16K IBM PC started at $1565 [$5260], DEC wisely predicted most people would opt for the larger RAM.
Even the higher-end Professionals seemed to be aggressively priced, though admittedly mostly when compared to their mini ancestors, starting with the lowest-spec 325 at $3995 [$13,400]. Their 256K base of RAM came from the original 128K plus the 128K upgrade (both as daughtercards) which was now standard. The Professional 325, sold with four CTI slots and no hard disk option, was proudly cited in DEC's Professional Handbook as "the lowest cost PDP-11 system ever produced." However, the two upper tiers got expensive quickly: the midrange configuration, a 350 without a hard disk, was otherwise the same except for its six CTI slots and sold for $4995 [$16,800], and adding the 5MB hard disk and controller card pushed the total bill to $8495 [$28,500].
The bloom started coming off the rose when manufacturing problems delayed sales; the 325 and 350 didn't hit the market until almost December, and the Rainbow was stalled for months. Even when people could buy them, DEC's unusual design choices started coming home to roost. None of the systems could format their own floppy disks with their shipping operating systems, leading to user revolt when they were expected to buy preformatted media from DEC directly; officially only later versions of CP/M and MS-DOS for the Rainbow could do this, and some Pro users bought a Rainbow specifically for the purpose. While the Rainbow could read and write specially formatted MS-DOS floppies, its native format was the incompatible (but higher capacity) RX50's, and unlike the 5150 PC its text mode acted like a VT220 terminal with initially no graphics support of any kind — or ISA slots to add some. (Graphics options later became available.) More ominously for the future, the first version of the Rainbow 100 couldn't boot from a hard drive. As for the DECmate II, it was less expensive and more expandable but to buyers' displeasure somewhat less functional than its predecessor, affected by irregularities in the new OS/278 and compatibility problems with older programs. It also offered no built-in options for acting as a standalone terminal (only software), which was a common use for the DECmate I in office environments.
Meanwhile, power users found the 325 and 350 slow and ponderous compared to larger PDPs and objected to the Pro family's inability to run traditional PDP-11 environments. Reviewers appreciated the sold build quality and modular design, but complained the machines were heavy and the fans and hard drive were unusually loud. While Pro high-resolution graphics were considered by all to be extremely good, even making an appearance at SIGGRAPH, they were slow to update and scroll, and made using the menu-driven P/OS (based on a modified port of the real-time RSX-11M Plus) feel even more sluggish. Consistent with the XT's office aims DEC had promised early adopters a port of VisiCalc and a word processing package, but by summer 1983 little application software of any sort was available which caused retailers and buyers to start cancelling orders. Dan Bricklin, who himself led the P/OS ports of VisiCalc and TK!Solver, blamed P/OS's large memory footprint in particular and cited poor developer relations with DEC generally.
In the fall DEC leadership concluded their personal computer strategy was failing and SSG VP Andrew Knowles resigned in September 1983, the sixth vice-president to leave Digital in two years. Analysts cited high prices, ineffective marketing, weak distribution channels and missing software applications, as well as the Pro's substantial production delays which allowed the IBM PC to flourish at its expense. For its part, the Rainbow's unique architecture became an increasing liability as current software now assumed a true PC compatible and directly accessed the hardware, hampering it from running all but simple or well-behaved DOS applications. In April 1984 DEC introduced the Rainbow 100B, adding hard disk support, improved PC hardware compatibility and twice the base memory at the same price, along with a RAM expansion for both the original Rainbow 100 (now the 100A) and the new 100B, and additional software telecommunications options. On the very low end DEC also shrunk the DECmate II into the less-expensive DECmate III, reducing its options, size and clock speed.
A glaring omission was a native Unix, which categorical PDP-11 minis had been able to run almost from the beginning in 1970. VenturCom, another Massachusetts tech company, was a current licensee of Version 7 Unix and sold their V7 variant with some BSD enhancements as VENIX (hereafter mostly rendered as Venix to save my eyes), which existed as VENIX-11 for the PDP-11/23 since at least 1982. VenturCom also had a Z80 Venix port at one time and after the introduction of the 5150 PC launched "Project Viking" to port it to the 8086 as well, arriving in January 1983 and beating IBM's PC/IX by a year. Likely as the quickest means to market, DEC contracted VenturCom to port Venix-11 to the Pro 350 as its official Unix option, adding specific support for the Pro video hardware in its graphics library and including Venix's more unusual features like real-time programming, shared data segments, semaphores and code mapping (to dynamically page executable code in and out of main memory on small systems). We'll talk about why these features were important to DEC when we get to using Venix proper. The result was PRO/VENIX, announced in June 1984, and even included a future-facing UNIX System V license from AT&T. (Later on DEC also commissioned Pro ports of XENIX and Whitesmiths Idris, though it's unclear if these were actually completed or sold.)
How I wound up with a 380 is a little more prosaic. In 2013 I got contacted — I don't recall now exactly how — about a storage unit owned by a recently deceased individual "with a lot of old computers" that had to be cleaned out, and would I like to see what was there before the scrappers came? (I'm happy to do this and save or re-home any systems I can, but here's a protip: if you value your collection, don't ever let it get this far.) Whatever I could haul away was mine and what we couldn't haul away went to recycling that afternoon. So I rented a van and talked my friend Jon into coming along as extra muscle and we drove out to Pasadena to have a look.
Besides the clear monster hard disk and the 11/44, the other things we hauled away were an RL02 and whatever hard disk packs we could fit, approximately one metric crap-ton of paper tape, some documentation (including, it turned out, a mostly complete set of Venix manuals for the 350), a couple AUI Ethernet hubs, various random cables, two VAXstation 100s (I told you I didnt know much about DEC hardware at the time), a somewhat thrashed VT100 terminal I thought I could restore, and, relevant to this post, a DECmate II, a VR201 green screen monitor, a VR241 colour monitor, and — ta-daa! — two DEC Pro 380s. Everything was dirty and gritty but other than the whacked VT they were intact, and neither of the monitors had evidence of the "mold spots" or "cataracts" that sometimes afflict these models. That was all we could rescue and there was no time for a second trip or to call anyone else; the scrappers were already pulling up as we tried to get the van door closed.
Over time, I am relieved to say that to the best of my knowledge none of these items ended up in the skip, or at least not on my account. Unlike the other VAXstations (like the VAXstation 3100 M76 I have, currently my only VAX or VMS system), the VAXstation 100 is in fact a graphical terminal that requires a UNIBUS tether, and is of some specific historical interest (which I was unaware of at the time) because it was part of the transition from the W Window System to X. It has its own 68000 CPU, but it is not a standalone machine, and they turned out to be useless to me because I had no idea how to hook them up to the 11/44. Fortunately I found a home for them. In the end we didn't have the space and I was concerned we didn't have the power to actually fire up the 11/44 either, nor did we ever determine what that monster hard disk went with, so the PDP, the monster, the RL02, the disk packs, the beat-up VT100 and the rat's nest of paper tape went to someone else. I kept the monitors, cables, documentation and the remaining computers and tracked down an LK201 keyboard, and if I get around to finding or making boot disks for it, the DECmate II may be the subject of a future article.
At the top is the Caltech asset tag, using its full name as the California Institute of Technology. The location field is blank and the property number is just its DEC serial number, although there's also a notation "Ref 6005" for its "Dept or Contract." I don't know what this means and I couldn't find a department code 6005 (it's possible this was an old grant or sales contract now lost), but we can nevertheless make a good guess about where it was used because a prior user left his name in a file on the hard disk. This person was indeed Caltech faculty, and based on time stamps in the filesystem we can also ascertain that the machine was most likely decommissioned from Caltech around June 1989. More about that later.
Although the DEC Pro (and Rainbow, and DECmate II) use the same monitors and LK201 keyboard, they do not all use the same video cables. Also, a stern warning: since the video cables carry +12V, never connect them with the system turned on or an inadvertent short could fry any attached keyboard. For the monochrome VR201 display, plug a BCC02 cable into the Pro, plug the RJ-type cable from the LK201 into the VR201, and plug the other end of the BCC02 cable into the VR201. A straight-thru female-to-female DA-15 cable, the same port used for earlier PC joysticks or old Mac monitors, substitutes easily and also works for the DECmate II. In this configuration the monitor and keyboard are powered by the computer. The monochrome video signal can also be displayed on just about any composite monitor.
For the larger VR241 colour display, plug a BCC03 cable into the Pro, plug the RJ-type cable from the LK201 into the box at the other end of the cable, and attach the BNC R, G and B cables to the appropriate connectors on the monitor. The VR241 additionally requires its own source of wall power, and the BCC03 should not be used with the Rainbow (it uses the BCC17). We'll be using the VR241 here; I've since allocated the VR201 to the DECmate II.
On the far right in this picture are the status LEDs. The rightmost green LED indicates good power (got a DCOK signal from the power supply) and should stay lit. If this light doesn't come on or the system won't power up generally, check the internal circuit breaker first. The other four red LEDs (numbered 4-1, left to right) start lit and then go out in various order as internal system tests are passed. If any remain lit, there was a fault. In broad strokes, LED 4 indicates which type of error and the other three LEDs are an error code in binary, with LED 1 being the least significant bit. if LED 4 is out, then the system is indicating a problem with a particular slot (e.g., LED 3 and LED 2 on means physical slot 6 is bad). If LED 4 is on, then from 1-7 (0 is unpossible), the keyboard failed or was not detected, no boot device could be found, no monitor cable was connected, both logic board memory banks are bad, the low bank of memory is bad, the high bank of memory is bad, or the system module has failed completely (i.e., all LEDs on and will not extinguish). An on-screen display may give more information and/or additional error codes if enough of the system is working. We'll see an example of that a little later.
Eventually this was judged impractical as other option cards were developed and shipped Pros instead have a removable plate where a secondary port module can be installed. This plate has a visibly different colour on my 380 now due to different manufacture and the ravages of time. The real-time module option, such as those used with the VAX Consoles but also sold separately for general data acquisition, exposed ports here such as IEEE-488; the IVIS machines had an entire interface device connected here dubbed the "backpack" which broke out multiple connectors to and from attached playback hardware.
As for the TMS itself, in its shipped form it provided built-in voice and modem services using a special telephone line interface module with jacks for the phone handset and lines. Since the Pro had no built-in audio, the line module also had a DIN connector that carried power and signals to an external voice unit used for dialing and as a speakerphone. The TMS was capable of digitizing audio data and storing voicemail and audio recordings to the Pro's hard disk, and playing them back via the voice unit or over the phone line. Playback could be controlled directly from the voice unit.
All of these extra hardware options were generally supported only in P/OS. An obvious disadvantage to this final layout is that only one such module can be installed at a time, but there were never very many such modules to begin with.
The RX50 is notable in that it has a single spindle for both drives, and that for the bottom drive the disk is to be inserted upside down. This confused enough people using the Rainbow in particular that DEC eventually put a guide direction arrow inside later units, though this earlier example doesn't have it.
The rechargeable battery pack is for the clock, which is now of course thoroughly dead. We're not going to replace it today and the fact that it is indeed dead was actually useful to this entry. Again, more later when we get to the operating system.
The gate array marked DC363 at the top left is the video chip, and the 64kW of memory is the base framebuffer. This is the same setup that the 325 and 350 require a separate CTI card for, just with twice the memory; here the video hardware is integrated into the logic board as a phantom seventh CTI slot and addressed in the same way. It provides a single plane of a 60Hz 1024x240 or 50Hz 1024x256 bitmap (typical displayed resolution 960x256). The extra 32kW in the 380 can be displayed as another 256 rows for an interlaced 60Hz 1024x480 or 50Hz 1024x512 image, double the vertical resolution.
Next to the 64-pin daughtercard connector is another gate array marked DC362. This is the I/O interface gate array and handles all CTI bus activity, including DMA and IRQs. It also multiplexes the CPU boot ROM (the EPROM) so that the CPU gets full 16-bit words, handles all system interrupts, handles support for the maintenance terminal mode, and contains support logic and the baud rate clocking signal for the communications ports.
The third gate array is marked DC365, the control gate array. It provides direct access to onboard memory not on the CTI bus, handles system bus timing and arbitration, and provides singlestepping for the low-level debugger accessed via the printer/console port.
The success of the LSI-11, and its attendant disadvantages, spurred DEC to develop its own designs. These commenced with the F-11 "Fonz" chipset, used in KDF11 CPUs starting with the 1979 11/23, and was a true 16-bit microarchitecture. In the DEC Pro 325 and 350, it was called the KDF11-CA CPU and consisted of five chips fabricated on a 6-micron process consolidated into three hybrid 40-pin DIPs that implement the standard PDP-11 instruction set, the EIS (extended instruction set), and FP-11 floating point instructions. The data chip (containing all non-float registers and scratchpads, the ALU and conditional branching logic) and the control chip (containing the microcode) are on one DIP together equivalent to the KEV11-B, the MMU is its own DIP equivalent to the KTF11-A, and the floating point adapter is spread over two chips on the third equivalent to the KEF11-A. Interestingly, the actual floating point registers are stored in the MMU. The F-11 as implemented in the 325 and 350 can address up to 4MB (22-bit) with 1MB reserved for option cards and I/O, though it lacks split I+D mode (again, we'll talk about this when we discuss Venix's internals) and has no cache. CPU timings are derived from a 26.666MHz crystal and divided by two to yield the 13.333MHz master CPU clock, which is internally divided again by four to yield its nominal clock rate of 3.333MHz.
The J-11 "Jaws" chip shown here in the Pro 380 is more compact than the F-11 and higher performance, but the processor ended up less powerful than it was intended to be: Supnik describes the design as "idiosyncratic," stating that its complexity and size overwhelmed development partner Harris, and the chips had so many problems with yield and bugs that "Jaws" never reached its internal clock speed goal of 5MHz. The basic package consisted of two 4-micron chips on one carrier, a data chip with the ALU, external interfaces, MMU and registers, and a control chip with the microcode. Pads on the underside of the hybrid were to accommodate two more chips, likely for additional instruction set options, but this idea was never implemented. Internally the J-11 also appears to divide its clock by four. The J-11 was introduced with the PDP-11/73 in 1984, using the 15MHz (i.e., 3.75MHz) KDJ11-B CPU card with an 8K write-through cache and a separate floating point accelerator, and likewise implements the base instruction set, the EIS and FP-11. DEC's fastest J-11s eventually topped out at 4.5MHz (on an 18MHz clock), though the Mentec M100 reportedly pushed it to 4.9152MHz (on a 19.66MHz clock). Unfortunately the 380's J-11 (the KDJ11-C) is somewhat gimped by comparison, having been downlocked to 10.08MHz (divided down from the 20.16MHz system master clock crystal near the DC 363) for an effective internal clock speed of 2.52MHz, and lacking any options to add cache or floating point acceleration. However, it does implement split I+D, and Venix even makes use of the feature. Because the J-11 also requires fewer cycles per instruction and the 380's RAM is faster, the 380 is anywhere from two to three times quicker in practice than the 325/350 despite being clocked slower, and the CPU collectively uses less than a fifth of the power.
A third and even smaller DEC-designed PDP-11 CPU was also available, the 7.5MHz/10MHz T-11 "Tiny" chip. The T-11 was introduced in 1981 and is a single-chip CPU with no MMU or floating point support fabricated on a 5-micron process with 12,000 transistors. DEC intended this processor for embedded systems and used it in some disk controllers and the VT240 terminal, but its most famous use was as the main CPU of the Atari System 2 arcade board (some of my favourite arcade games like Paperboy, 720 and the best one of all time, APB, which I played for the first time as a kid in the Disneyland arcade — who doesn't like donuts, demerits and police brutality?). It was indisputably the most successful of the PDPs-on-some-chips and produced in the hundreds of thousands. These particular CPUs and the PDP-11 architecture generally were all mercilessly ripped off by the Soviets, by the way, and one very small CPU in this family we may visit at another time. For that matter, the Red Menace even made clone Pros!
The hardware supports reducing the horizontal resolution to 512 or 256 to add additional bits to each larger pixel and get more simultaneous colours. In fact, the EBO makes it possible with careful but relatively simple programming to get up to a full 256x256 (on the 380, 256x512) picture in 4096 colours directly supported by the hardware, which was really quite something for a 1982 computer. I'll show you a brief example presently.
If you do need more than 1MB of RAM you can try to find more CTI cards, though as a practical matter even with a six slot 380 you could only get up to 2MB with the available 256K CTI RAM boards and still have a bootable floppy and hard disk (one slot each). Also visible here are the NEC D7201C and Motorola MC2661PC, which service the printer and RS-423 ports.
That suffices as a short tour of the hardware. Let's next get to our first and primary upgrade, converting the hard disk to solid state. I should note that pretty much exactly the same steps will work for the Pro 350 and serve generally for other systems with similar hard drives.
Just like you can buy SCSI emulators nowadays like the O.G. SCSI2SD and the later ZuluSCSI and BlueSCSI units, and I use them a lot, there are MFM emulators that serve an analogous function for even older drives like these. In my opinion the best one you can get is David Gesswein's MFM hard disk reader and emulator, which can read an existing drive to an image and then immediately substitute for it. It's not a dirt-cheap device but you get what you pay for. It has separate connectors for reading and for emulation, and looks to the Pro almost exactly like the hard disk that used to be there.
The BBG's microUSB USB client port is what we'll use for a serial console since it's easy to access and a bog-standard FTDI that just about anything will have drivers for (it worked out of the box with my POWER9 Fedora Linux box and my M1 MacBook Air). You can also use the usual 3V3 serial adapter on the BeagleBoard itself but this is hard to do with the cape on. Even though USB power is not enough to bring up the entire assembly, you can at least access the BBG separately this way. We aren't going to bother with networking it. Dave supports both Debian 7 and 11 as of this writing, but I've elected for Debian 7 because it uses less of the internal flash and boots faster.
Debian GNU/Linux 7 beaglebone ttyGS0 BeagleBoard.org Debian Image 2015-07-17 Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian default username:password is [debian:temppwd] The IP Address for usb0 is: 192.168.7.2 beaglebone login: root Last login: Thu Mar 21 21:04:42 UTC 2024 from rook.pdp8online.com on pts/0 Linux beaglebone 3.8.13-bone81 #1 SMP Fri Oct 14 16:04:10 UTC 2016 armv7l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Debian GNU/Linux 7 beaglebone ttyGS0 BeagleBoard.org Debian Image 2015-07-17 Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian default username:password is [debian:temppwd] The IP Address for usb0 is: 192.168.7.2 beaglebone login: root Last login: Fri Jul 17 23:54:21 UTC 2015 on ttyGS0 Linux beaglebone 3.8.13-bone81 #1 SMP Fri Oct 14 16:04:10 UTC 2016 armv7l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@beaglebone:~# cd mfm root@beaglebone:~/mfm# ls Makefile mfm_decoder.c mfm_write1.bin README mfm_r_revab.bbio mfm_write1.p analyze.c mfm_r_revc.bbio mfm_write1.txt board.c mfm_read mfm_write_doc.html copy_emu.c mfm_read-00A0.dtbo mfm_write_doc.odt corvus_mfm_decoder.c mfm_read-00A0.dts mfm_write_doc.pdf crc_ecc.c mfm_read-00C0.dts msg.c crc_reverse.c mfm_read.c northstar_mfm_decoder.c deltas_read.c mfm_read_util_doc.html obj deltas_read_file.c mfm_read_util_doc.odt parse_cmdline.c drive.c mfm_read_util_doc.pdf perq_mfm_decoder.c drive_file.c mfm_util pru_setup.c drive_operations.p mfm_util.c prucode.hp drive_read.c mfm_w_revab.bbio prucode0.bin drive_write.c mfm_w_revc.bbio prucode0.p emu_tran_file.c mfm_write prucode0.txt ext2emu mfm_write-00A0.dts setup_mfm_read ext2emu_doc.html mfm_write-00C0.dtbo setup_mfm_write ext2emu_doc.odt mfm_write-00C0.dts tagged_mfm_decoder.c find_crc_info mfm_write.c wd_mfm_decoder.c find_crc_info.cpp mfm_write0.bin xebec_mfm_decoder.c gpl.txt mfm_write0.p inc mfm_write0.txt root@beaglebone:~# setup_mfm_read Rev B Board root@beaglebone:~# cd ~/powerfail root@beaglebone:~/powerfail# ./powerfail --debug --powercmd true --threshold 0 Average 12.23V max 12.24V min 12.22V
The powerfail system is what monitors the power supply and forces the BBG to shut down if the voltage is below a critical level. Here the voltage is as we expect, so we'll next do a test powered restart:
^Croot@beaglebone:~/powerfail# poweroff -f FATAL: read from port failed: Device not configured
The card duly goes down and immediately comes back up, so we can consider the power subsystem to be good. After logging back in we'll power down the board completely to hook it up. (You may need to forcibly remove and replace the Molex power connector after shutdown to get it to restart.)
root@beaglebone:~# halt -f
Now to start the copy, but the first time didn't quite work as expected. After logging in as root,
root@beaglebone:~/mfm# setup_mfm_read Rev B Board root@beaglebone:~/mfm# mfm_read --analyze --emulation_file ../emufile_a Board revision B detected Found drive at select 1 Drive RPM 3527.6 Found matching format Elektronika_85: good count difference 0 Selected head 8 found 0, last good head found 7 Read errors trying to determine sector numbering, results may be in error Number of heads 8 number of sectors 16 first sector 0 Interleave (not checked): 0 7 14 5 12 3 10 1 8 15 6 13 4 11 2 9 Drive supports buffered seeks (ST412) Disk has recalibrated to track 0 Stopping end of disk search due to recalibration Number of cylinders 512, 33.6 MB Command line to read disk: --format Elektronika_85 --sectors 16,0 --heads 8 --cylinders 512 --header_crc 0xffff,0x1021,16,0 --data_crc 0xffff,0x1021,16,0 --sector_length 512 --retries 50,4 --drive 1 Warning: Track data truncated writing to emulation file by 97 bytes, need 5233 words cyl 53 head 1 Warning: Track data truncated writing to emulation file by 96 bytes, need 5232 words cyl 61 head 0 ^Croot@beaglebone:~/mfm#
--analyze is intended for figuring out operating parameters on a disk you don't know, but we already know at least the geometry for the RD52, and it appears it didn't guess quite right which is why I halted it after seeing copy errors. Interestingly it detected the setup as an Elektronica_85, which is in fact one of the godless pinko Commie Soviet PDP-11 clones (please send hate mail to /dev/null).
root@beaglebone:~/mfm# mfm_read --emulation_file ../emufile_a --cylinders 512 --heads 8 --drive 1 Board revision B detected Returning to track 0 Track read time in ms min 18.857333 max 1679.306459 avg 35.408051 root@beaglebone:~/mfm# ls -l ../emufile_a -rw-r--r-- 1 root root 85393541 Jul 18 00:12 ../emufile_a root@beaglebone:~/mfm# cp ../emufile_a ../emufile_b
Finally, we power down the board again completely at this point in preparation for installing it.
root@beaglebone:~/mfm# halt -f
We'll call that our point of comparison and now do a final dry run. For this part I temporarily switched the MFM emulator over to a stand-alone power supply. Even though the caps will get the MFM unit through a power-down to enable the drive from the BBG's shell, it's possible to get the device into a state where the caps are charged just enough to make it weird, and then you have to wait for things to drain. Better in this case to just run it off something else.
With the machine off, let's bring the emulated drive up first:
root@beaglebone:~# cd ~/emu root@beaglebone:~/emu# setup_emu Rev B Board root@beaglebone:~/emu# mfm_emu --drive 1 --file ../emufile_a Board revision B detected Drive 0 num cyl 512 num head 8 track len 20836 begin_time 0 PRU clock 200000000 Waiting, seek time 0.0 ms max 0.0 min free buffers 200 bad pattern count 0 Read queue underrun 0 Write queue overrun 0 Ecapture overrun 0 glitch count 0 glitch value 0 0:test 0 0 0:test 1 0 0:test 2 0 0:test 3 0 0:test 4 0 1:test 0 0 1:test 1 0 1:test 2 0 1:test 3 0 1:test 4 0 select 1 head 0
I interpreted this as "ready." I then powered the Pro back on, and ...
select 0 head 0 Drive 0 Cyl 0->1 select 1, head 0 dirty 0 Waiting, seek time 5.8 ms max 5.8 min free buffers 200 Drive 0 Cyl 1->0 select 1, head 0 dirty 0 Waiting, seek time 4.1 ms max 5.8 min free buffers 200 Drive 0 Cyl 0->151 select 1, head 0 dirty 0 Waiting, seek time 10.1 ms max 10.1 min free buffers 200 Drive 0 Cyl 151->0 select 1, head 0 dirty 0 Waiting, seek time 4.0 ms max 10.1 min free buffers 200 Drive 0 Cyl 0->151 select 1, head 0 dirty 0 Waiting, seek time 4.0 ms max 10.1 min free buffers 200
Off and running! Except:
We can continue from this error but I'd really rather have the system come up properly. The simplest thing to do at this point is to put the RX50 drives back in and reconnect them (or replace them with Goteks, but that will be a more involved project — long story there), and power cycle the system with the MFM emulator still serving the drive.
Seemingly (that's called foreshadowing, kids) the last step should be to make the BBG automatically start serving the drive on powerup. Dave provides this facility as a systemd service. We edit /etc/mfm_emu.conf and set EmuFN1="/opt/mfm/emufile_a" in that file, then systemctl enable mfm_emu.service and put on the capacitor jumper so we have bridging power.
When I ran this all from the separate power supply, the board came up and started serving the drive image, I powered on the system, and Venix booted. When I turned off the separate power supply after powering off the system, the board properly shut down. When I ran all this from the system power supply, however, it wouldn't ever see the emulated hard disk and wouldn't ever boot. Can you figure out why?
Pencils down: the BBG wasn't booting fast enough. I let the whole thing discharge overnight, took the BBG out of the MFM cape and put it on the workbench.
root@beaglebone:~# systemd-analyze
Startup finished in 2412ms (kernel) + 34433ms (userspace) = 36846ms
root@beaglebone:~# systemd-analyze blame
31491ms networking.service
1509ms generic-boot-script.service
1209ms bootlogs.service
1081ms ssh.service
1028ms console-kit-daemon.service
1015ms udev-trigger.service
763ms wpa_supplicant.service
735ms systemd-logind.service
730ms rpcbind.service
716ms cron.service
688ms capemgr.service
615ms rc.local.service
543ms udev.service
476ms udhcpd.service
453ms motd.service
352ms console-kit-log-system-start.service
257ms systemd-modules-load.service
210ms systemd-user-sessions.service
168ms systemd-tmpfiles-setup.service
164ms sys-kernel-debug.mount
163ms dev-mqueue.mount
163ms systemd-sysctl.service
155ms sys-kernel-security.mount
130ms run-user.mount
122ms run-lock.mount
114ms systemd-remount-api-vfs.service
78ms remount-rootfs.service
57ms sys-fs-fuse-connections.mount
I am not a fan of systemd (which is why I don't run current Linux on any of my servers or server-adjacent machines), but I grudgingly admit the tooling is better. As configured the BBG was taking a whopping 37 seconds to come up, over 31 of those seconds spent bringing up the network. But we're not using the network! I edited /etc/network/interfaces and commented out everything but the loopback, then turned off the WiFi ...
root@beaglebone:~# systemctl disable wpa_supplicant.service rm '/etc/systemd/system/multi-user.target.wants/wpa_supplicant.service' rm '/etc/systemd/system/dbus-fi.epitest.hostap.WPASupplicant.service'
and restarted.
root@beaglebone:~# systemd-analyze
Startup finished in 2301ms (kernel) + 5067ms (userspace) = 7368ms
root@beaglebone:~# systemd-analyze blame
1418ms bootlogs.service
1211ms networking.service
1180ms ssh.service
1114ms console-kit-daemon.service
1042ms udev-trigger.service
727ms rpcbind.service
704ms cron.service
703ms systemd-logind.service
693ms generic-boot-script.service
646ms capemgr.service
561ms rc.local.service
560ms udev.service
443ms motd.service
401ms udhcpd.service
359ms console-kit-log-system-start.service
262ms systemd-modules-load.service
219ms sys-kernel-debug.mount
208ms systemd-user-sessions.service
175ms systemd-tmpfiles-setup.service
172ms dev-mqueue.mount
156ms sys-kernel-security.mount
154ms systemd-sysctl.service
139ms run-user.mount
130ms run-lock.mount
122ms systemd-remount-api-vfs.service
70ms sys-fs-fuse-connections.mount
57ms remount-rootfs.service
This is still not fast enough for the Pro to see the emulated disk on startup. Even hacking the first three scripts to exit 0 immediately only got me down to about 7 seconds (apparently most of the overhead is from just launching them in the first place), and we've also not accounted for the time needed to bring the MFM emulator up either. I undid these changes; everything else is too slight to significantly matter. We simply can't seem to beat the Pro's firmware to come up first before the Pro concludes no hard disk is present.
However, we have an alternative. We know that if we give the BBG enough time — and "enough time" is now around seven or eight seconds — we can get the system up. We also know from testing and Dave's estimates that the supercapacitor bank will get us at least 30 seconds of runtime (in fact, in practice it seems to be several minutes or more on this Revision B).
I logged back into the BBG, edited /etc/mfm_emu.conf and added PowerFailOptions="-w 20" . What this allows us to do is power on the Pro, charge the capacitors (very fast) and start bringing up the BBG while the Pro's initial boot fails. With our new shortened boot time the BBG will be ready and waiting by the time the Pro displays its error screen. We then power the Pro off and power it back on. As long as the power cycle is less than 20 seconds (I eventually upped this to 30 as there appears to be plenty of power available), the BBG will ride the stored charge and keep serving the emulated disk image so that on that second power-on (and every power-on thereafter) the Pro will see the drive and boot from it. When we're done with a session, we power the system off for more than thirty seconds, causing the BBG to shut down cleanly as expected.
With that sorted, let's do the memory upgrade too.
Mapping large tracts of memory on a 16-bit system is kludgey. Like the 8086, the PDP-11 is fundamentally limited to a 64K address range, being the largest quantity that can be expressed in 16 bits, and like the 8086, additional address bits to reference more memory are provided by specific segment registers. The 8086 famously uses its segment registers as the most significant 16 bits of a 20-bit address, added to a 16-bit offset. By contrast, PDP-11 systems with memory management hardware define eight available segments (which DEC documentation sometimes called "pages") that can be up to 8K/4kW in 64-byte increments and point anywhere in physical memory on a 64-byte boundary. Each segment register set controls a fixed 8K/4kW slice of the 64K logical address range (e.g., segment 6 controls logical addresses 0140000 to 0157777, or $c000 to $dfff in hexadecimal; segment 0 controls $0000 to $1fff). In the F-11 and J-11, these Page Address Registers are 16 bit, so 16 bits to specify 64-byte blocks allows 22-bit physical addressing (16 + 6). The corresponding Page Description Register has a seven-bit field for specifying the length, thus allowing a maximum segment size of 8K/4kW (128 times 64 is 8192). These segment registers exist at fixed physical locations in high memory. With eight segments of up to 8K each the 64K addressing space was thus fully populated and the mappings could be changed on the fly as needed, with security bits to set how that memory could be used by this or other processes. (Compare with bank switching schemes on 8-bit computers with similar fundamental addressing limits like the Commodore 64 or 128 or Apple IIe, or NES mappers.)
The J-11 is capable of an additional trick called split I+D, shorthand for split instruction and data. Split I+D provides two sets of segment registers, one for instruction fetches and one for data, effectively turning a notionally Von Neumann CPU into a Harvard one. Instructions, plus their operands, addresses and constants embedded in the instruction stream come from the I-space segments; loads and stores to memory addresses, however, reference the D-space segments. This effectively allows 128K to be addressed more or less at once, albeit with a bit of bookwork. (Again, also compare with the MOS 6509, a 6502 with on-board registers to set execution and indirection banks, though the banks are granular only to the 64K level.)
Programs that require a much larger code size can be linked with code mapping, where as long as individual object modules (i.e., its component .o files) are each less than 8K, segment 1 can be used to page them in and out for a program size that can be as large as physical memory minus the size of the Venix kernel minus the size of the process' data. A fixed segment containing the paging support logic, function mapping table and other code sits in the lowest 8K controlled by segment 0, with up to 48K of data controlled by segments 2-6 and stack in the usual location controlled by segment 7. Alternatively, on J-11 systems the C compiler is split I+D aware and code can be compiled to support it (though such binaries will not run on a 325 or 350). Since both code-mapped and split I+D executables necessarily can't modify their program text, they can be run "pure" too.
The PDP-11 Venices additionally provide special system calls for its own implementation of shared memory which it calls "shared data segments" (this feature was also available on Venix/86, albeit with different arguments and semantics, and Venix-specific code was generally not portable between architectures). This facility allows a second data segment to be dynamically constructed and mapped into one of the 8K segments. By using a filename a mmap()-like facility becomes possible which can also be shared by other processes, and it can page the segment window over a much larger range using a disk-backed file to handle addressing data spaces larger than 56K. IPC is further aided by a simple (though ultimately future-incompatible) implementation of semaphores, permitting local and global locks, which mainline AT&T Unix did not support until System V. Venix additionally supports real-time programming, allowing programs running as root to run at exclusive priority, lock their processes in memory, and directly access I/O by using another Venix-specific system call to point a segment at the device's physical address (usually segment 6, generally free except in code-mapped executables and programs with unusually large text segments). DEC, having a substantial investment in its own real-time operating environments for data acquisition and process automation, particularly valued a Unix option that could do so as well.
To see a bit of this in operation, consider this complete program in C (written in K&R C, because that was the era). It is a direct C-language port I made of a 4096-colour demonstration originally written in PDP-11 assembly by vol.litwr. Remember, int in this environment is 16-bit.
#include <stdio.h>
/* run as root */
/* segment 6 always starts at this location, see phys(2) */
int *videop = (int *)0140000;
pp4096(r1, r2, r3)
int r1, r2, r3;
{
*(videop + 3) = 18; /* video plane 1 move op */
*(videop + 4) = 16; /* planes 2+3 nop op */
/* store x, y, colour index, counter */
*(videop + 7) = r1;
*(videop + 8) = r2;
*(videop + 10) = r3;
*(videop + 9) = 4;
r3 = r3 >> 4;
while (*(videop + 2) > 0) { }
*(videop + 3) = 16;
*(videop + 4) = 18;
*(videop + 10) = r3;
*(videop + 9) = 4;
r3 = r3 >> 4;
while (*(videop + 2) > 0) { }
*(videop + 4) = 4624;
*(videop + 10) = r3;
*(videop + 9) = 4;
while (*(videop + 2) > 0) { }
}
pb4096(r1, r2, r3, r4, r5)
int r1, r2, r3, r4, r5;
{
int i,j,k;
for (i=r4; i>0; i--) {
k = r1 << 2;
for(j=r5; j>0; j--) {
pp4096(k, r2, r3);
k += 4;
}
r2++;
}
}
pal12()
{
int i,j,r1=0,r2=0,r3=0,r4=5,r5=2;
for (i=35; i>0; i--) {
r1 = 0;
for(j=120; j>0; j--) {
pb4096(r1,r2,r3,r4,r5);
r3++;
r1 += r5;
}
r2 += r4;
}
}
main(argc, argv)
int argc;
char **argv;
{
int i, vr4, vr6, vr8, vr14, vr16;
/* map 64 bytes to segment 6 from physical address 0x3ffb00 */
if(phys(6, 1, 0177754)) {
perror("mapping");
exit(1);
}
i = *videop;
if (i != 0x0010) {
fprintf(stderr, "unexpected value for hardware: %04x\n", i);
exit(1);
}
i = *(videop + 2);
if (i & 0x2000) {
fprintf(stderr, "no EBO? %04x\n", i);
exit(1);
}
fprintf(stderr, "ok, detected 380 with EBO\n");
vr4 = *(videop + 2);
vr6 = *(videop + 3);
vr8 = *(videop + 4);
vr14 = *(videop + 7);
vr16 = *(videop + 8);
*(videop + 2) = 0;
pal12();
sleep(10);
*(videop + 2) = vr4;
*(videop + 3) = vr6;
*(videop + 4) = vr8;
*(videop + 7) = vr14;
*(videop + 8) = vr16;
exit(0);
}
This code maps the registers for the 380's onboard video hardware into segment 6 using Venix's phys(2) system call, then manipulates the registers to draw to the individual video planes. There's no cache and the Venix PDP-11 C compiler is fairly simple-minded, so we can simply directly drive the registers in a way that would make a modern C programmer blanch. (Rust programmers, just look away and go to your happy place.) Compiled with cc -o test test.c, the result looks like this (./test):
VenturCom initially had a Unix Version 7 (V7) license, the last Bell Labs release in 1979 before AT&T took it over and the first iteration of Unix generally considered readily portable. XENIX on x86 was also initially derived from this version. V7 was the earliest mainline release to officially integrate (among other things) the Bourne shell, awk, a Fortran-77 compiler, a portable C compiler (though the C compilers in Venix/86 and Venix-11 seem to have different lineages), uucp, tar and make, though development versions of these tools appeared in other Bell Labs variants like Programmer's Workbench (PWB/UNIX). In addition to their custom changes, Venix further added several components from 4BSD, most notably the C-shell (I'm one of those people), more and vi.
V7 Unix was the basis for the original Venix-11, which wasn't much of a stretch since V7 Unix already ran there, and by descent PRO/VENIX in July 1984 on the 350. This package was sold explicitly with a future UNIX System V license which had just come out in 1983. In October 1984 VenturCom upgraded PRO/VENIX to "Rev 2.0" (and misnamed it VENIX/PRO in the release notes) which fixed some bugs and added support for the 380 while remaining compatible with the 350. I'm emphasizing the Rev part; it will shortly become salient. Here's PRO/VENIX Rev 2.0 on Xhomer, a Pro 350 emulator which provides a pre-installed disk image:
PRO/VENIX V2.0 (not Rev 2.0), however, is a different animal. It was released in July 1985 and primarily intended for the 380, though a set of 350 overlay disks patch the kernel and certain other large programs during installation; you can't boot PRO/VENIX V2.0 on a 325 or 350 without them. True to VenturCom's word, it leapfrogged UNIX System III completely and is in fact a derivative of System V Release 2 (SVR2 or V.2). The V is deliberate and capitalised for a reason: it's for System V, not short for Version. V2.0 was explicitly intended to correspond with System V 2.0. It was the final release of PRO/VENIX and the version we have on our 380 here.
As a parenthetical note, Venix/86 2.1 was the last of the original version number sequence; 2.1 is actually less advanced than PRO/VENIX V2.0 despite the lower apparent "version" number and better considered as an upgrade to Venix/86 Encore as it remains based on V7.
If you boot the operating system unattended, it will still go into normal mode (maintenance mode is single user), but it will also force an fsck whether the disk needs it or not:
The screenshot here is a direct monochrome grab from the Pro's planar video using the pscreen utility which emits the screen contents as LA50 printer codes; you can also save and load screen images with sscreen and lscreen respectively in a format I haven't currently deciphered yet. These tools are part of the graphics package and also exist in Venix/86.
We'll put /etc/getty on com1 at the highest speed available, 9600bps, and then bounce init's runlevel with telinit. When we do, we get a login prompt. There is no banner. (By default, the root password is gnomes.)
login: root Password: Not on system console login:
Well, la dee dah. I went back to the console and created a plain user the old fashioned way: I earned it made entries in /etc/passwd (no password because I don't care) and /etc/group, created a home directory for myself, and made my new account the owner.
login: spectre
Welcome to PRO/VENIX V2.0
*** important ***
Read the PRO/VENIX V2.0 Release Notes for
information on reloading diskettes from PRO/VENIX V1 systems.
[ this login message comes to you from file /etc/motd ]
news: RELEASE_NOTES greetings
$ news
RELEASE_NOTES (bin) Thu Jun 27 22:24:13 1985
NOTE: See the printed PRO/VENIX V2.0 Release Notes which are included in
the documentation set for additional information.
Do not pass a function the address of a static function if you are using code
mapping, because the loader cannot guarantee that such functions will be
properly mapped. For example, do NOT pass signal(2) the address of a static
function to handle the signal. If such usage is necessary, change the static
function to be a global one and rename it as necessary to avoid conflicts.
greetings (bin) Tue Jan 1 10:14:19 1985
*********************************************************
* Welcome to VENIX! You can find out more about *
* the "news" command by looking for news(1), in *
* section one of the User Reference Manual. *
*********************************************************
I don't have the V2.0 release notes, but I bet they were interesting. There are in fact no man pages in PRO/VENIX because you (are supposed to) have real manuals. Along the way I think we went backwards on this, somewhere. On the other hand, news(1) is not in my older copy of the User Reference Manual and appears to have been newly added to V2.0 also.
A more immediate problem: my terminal setting is pretty messed up because it assumed I was logging in from some other Pro connected via the serial port, so
$ TERM=vt100 $ export TERM
(you can't export TERM=vt100). And, well, I'm using the Bourne shell and I hate the Bourne shell, so I set it to C-shell like civilized people. Let's get our bearings.
% pwd /usr/spectre % uname -a VENIX venix SysVr2.0 85061411 PRO380 DEC00100 % date Wed Jun 28 22:21:09 PDT 1989
There's your proof that this is System V. Also, because our clock battery failed decades ago, the machine is still getting its time from the filesystem. This is useful to us because that tells us when the computer was last likely in use, as we can reasonably assume a regular user would have either gotten the battery replaced or at least set the time correctly. I should also add for the remainder of this session that it is likely this local installation of Venix had some minor removals or modifications.
Before we explore further, I'm going to customize my environment a little and make it set my terminal correctly when I'm logged in over the serial port. The current Venix license it came with (something to hack later) only allows two users, so a simplistic method will suffice. If we have a functional awk, and we should, then we can do this easily in .login.
% who
root console Jun 28 13:17
spectre com1 Jun 28 22:20
% awk 'BEGIN { print "hello world\n" }'
hello world
^C
% who | grep spectre | awk '{print $2}'
com1
% cat >.login
set j=`who | grep spectre | tail -1 | awk '{print $2}'`
if ("x$j" == "xcom1") then
setenv TERM vt100
endif
^D
That's a good Unixy demonstration right there. Now, let's look at the guts a bit.
% cat >hello.c
#include <stdio.h>
main()
{
puts("hello world");
exit(0);
}
^D% cc -o hello hello.c
% ./hello
hello world
% file hello
hello: executable not stripped
% file /bin/date
/bin/date: pure executable
% file /usr/bin/awk
/usr/bin/awk: separate I&D
% file /usr/lib/libcurses.a
/usr/lib/libcurses.a: archive
% file /usr/lib/liby.a
/usr/lib/liby.a: archive
% file /venix
/venix: separate I&D not stripped
Here we're investigating four different executables and a couple of included libraries (although program text can be shared, there are no shared objects in PRO/VENIX per se). The short program we compiled is an unstripped executable, but most of the essential system binaries like /bin/date are marked pure so that they can be shared by other logged in users. However, because awk and the /venix kernel are so large, they are compiled with split I+D ("separate I&D"), which is more efficient and has fewer restrictions than using code mapping. You can see that when we ask about the object file sizes:
% size hello 2348+244+1224 = 3816b = 07350b % size /bin/date 8320+1008+1352 = 10680b = 024670b % size /usr/bin/awk 31488+21062+11646 = 64196b = 0175304b % size /venix 52672+47552+0 = 100224b = 0303600b
Our unstripped compiled binary has a code size of 2348 bytes, a data size of 244 bytes and a BSS (uninitialized data) size of 1224 bytes. This is actually smaller than date, a "pure" executable, which has code, data and BSS sizes all larger at 8320, 1008 and 1352 bytes respectively, showing that the "purity" of an executable has no relationship to its image in memory. On the other hand, our split I+D binaries (awk and the kernel) have comparatively large code sizes. Even though the kernel has no BSS portion, there is no way its code and data could simultaneously live in the same 64K space (for that matter, neither could awk's, because the stack is a fixed 8K at the top of the address range). However, since both were compiled split I+D, they don't have to.
As a point of comparison, here's what you'd see in PRO/VENIX Rev 2.0.
A couple other things:
% strings /venix strings: Command not found. % df /usr (/dev/w0.usr ): 46892 blocks 14010 i-nodes /tmp (/dev/w0.tmp ): 865 blocks 222 i-nodes / (/dev/w0.sys ): 585 blocks 796 i-nodes
This is (well, was) an RD52, so it's a 30MB drive, the second biggest ever sold for the Pro. However, if you add these numbers up, you only get around 24MB; the rest is in fact a hidden swap partition. 6MB might seem a little excessive when the original memory size of this machine was 512K, but in Venix the swap isn't just for moving processes out so others can run — it's also used as a precache for certain pure executables that have the sticky bit set such as ls. (Again, not an uncommon feature in other operating systems of this era. AMOS could preload certain executables into the system image and always run them from RAM, for example.) These executables are copied to the swap on first use after bootup and executed henceforth from there in specific, precomputed locations, avoiding a walk through the filesystem. This also means, however, that once copied such executables cannot be deleted while the system is up or, in the words of the manual, "the file system will become slightly corrupted." (Eeeek.) Note that no version of PRO/VENIX supported demand paging; that wasn't implemented in AT&T Unix until SVR2.4.
There is no /home or other special mountpoint or partition for home directories; everything else is in /usr, as was typical for Unix of this vintage.
I later copied the files out with Kermit (it had Kermit on the hard disk) and decided to see what the Fedora Linux POWER9 would make of them.
% uname -a
Linux tim.floodgap.com 6.X.X-300.fc41.ppc64le #1 SMP [...] ppc64le GNU/Linux
% file hello
hello: PDP-11 executable not stripped
% file date
date: PDP-11 pure executable
% file awk
awk: PDP-11 separate I&D executable
% file venix
venix: PDP-11 separate I&D executable not stripped
tim:/home/spectre/src/pdp11dasm/venix/% strings venix
[...]
PRO/VENIX V2.0 [%s]
Portions (c)Copyright by VenturCom Inc. 1984, 1985
Total mem %dkb, Avail %dkb,
SN %s, %d user.
`Dada
acore
PANIC: %s
too many users
{(})|!~^`'
`|~{}\
({)}!|^~'`\\
Initialization I/O error
Bad mount table (getfs)
Bad hash table (getblk)
Swap I/O error
Bad system table (iget)
No swap space
Bad diskinfo block
No space
Bad block
Out of inodes
Bad superblock count
Error
Fast alarm overflow
In core file table full
Segment table full
In core inode table full
Inode disk address > 2^24
No swap space for exec args
%s on the %s, unit %d
reading
writing
%s while %s block number %D. Status 0%o
Can't allocate message buffer.
VENIX
SysVr2.0
85061411
PRO380
[...]
The strings aren't too-too interesting, but it is notable that in 2025 my Linux box still recognizes what type of executables these are.
Anyway, let's dig around in the filesystem.
% ls -l / total 264 drwxrwxr-x 2 bin bin 1792 Jun 20 1985 bin drwxr-xr-x 2 bin bin 576 Jun 28 22:14 dev drwxr-xr-x 3 bin bin 896 Jun 28 17:55 etc drwxr-xr-x 2 bin bin 32 Jun 19 1985 f0 drwxr-xr-x 2 bin bin 32 Jun 19 1985 f1 drwxrwxr-x 2 root sys 224 Jun 28 16:46 fun drwxrwxr-x 2 bin bin 240 Jun 19 1985 lib drwxr-xr-x 2 bin bin 32 Jun 19 1985 lost+found -rw-rw-r-- 1 root sys 214 Jun 28 07:20 thankyou -rw-rw-r-- 1 root sys 19006 Jun 20 1985 tmac.m -rw-rw-r-- 1 root sys 2910 Jun 20 1985 tmac.mcs -rw-rw-r-- 1 root sys 1885 Jun 20 1985 tmac.mtc drwxrwxrwx 2 root super 48 Jun 28 22:16 tmp drwxr-xr-x 18 bin bin 320 Jun 28 13:19 usr -rw-r--r-- 1 bin bin 100336 Jun 19 1985 venix
Whoever had the system last didn't really clean up much; the tmac.* files in particular are macro definitions that look like they were supposed to be put somewhere else. Here's root's .profile, by the way:
% su Password: # cat /.profile : # @(#).profile 1.5 # "root" login .profile set `who -r` if [ $7 = "S" ] then trap 'echo " Exiting Maintenance mode. Choose run level 2 to enter Normal mode. Choose run level s to return to Maintenance mode."' 0 echo "You are now in Maintenance (\"single-user\") mode." echo "The system may now be safely halted." echo "Type \"telinit 2\" to enter Normal mode." sync PATH=:$PATH export PATH PS1="MAINT> " else PS1="SUPER> " fi if [ ! -s /etc/mnttab ] then echo "*** Warning: /usr and /tmp are not mounted. ***" fi echo "\nBeware - you are a super-user!" # ^D
.profile must live in / because, during maintenance (single-user) mode, /usr and /tmp aren't even mounted. Once in single-user mode, the system can be powered off.
/f0 and /f1 are mount points for the two RX50 floppies. But, in case you thought Venix could get around the RX50 formatting restriction, guess again: "On PRO/VENIX, floppy formatting is not possible; format is useful only for creating file systems on factory-formatted diskettes." Damn you, Kenneth Olsen. Better go buy that Rainbow.
This next file did not come with Venix:
% cat /thankyou
THANK YOU FOR RESCUING ME
******
* *
* * * *
* *
* * * *
* * * *
* ** *
* *
******
I don't know who did that. It's among the last files created on the system before it came into my possession. I assume this was directed to that late anonymous Caltech employee, but regardless, you're welcome, little buddy. You're welcome.
% ls -l /fun total 37 -rw-rw-r-- 1 root sys 237 Jun 28 09:50 bar.data -rw-rw-r-- 1 root sys 121 Jun 28 10:19 chart.data -rw-rw-r-- 1 root sys 74 Jun 28 10:20 chart.test -rw-rw-r-- 1 root sys 24 Jun 28 10:23 chart.tt -rwxrwxr-x 1 root sys 388 Jun 28 11:04 demo -rw-rw-r-- 1 root sys 135 Jun 28 09:53 pie.data
I suspect this directory did come with the system, but it's been modified, and I even played with the demo script and data files a little myself. There is no demo login on this system (it might have been removed), though if you run that shell script you'll see some plots that serve a similar function. Here are two:
% ls -l /usr total 23 drwxr-xr-x 3 bin bin 80 Jun 28 22:34 adm drwxrwxr-x 2 bin bin 1952 Jun 28 22:34 bin drwxr-xr-x 3 bin bin 96 Jun 19 1985 games drwxrwxr-x 2 guest visitor 272 Jun 11 13:49 guest drwxr-xr-x 2 bin bin 64 Jun 19 1985 help drwxrwxr-x 3 bin bin 880 Jun 19 1985 include drwxrwxr-x 2 root sys 656 Jun 19 1985 kermit drwxrwxr-x 16 bin bin 1312 Jun 19 1985 lib drwxr-xr-x 2 bin bin 512 Jun 19 1985 lost+found drwxrwxr-x 2 bin mail 64 May 2 1986 mail drwxr-xr-x 2 bin bin 64 Jun 19 1985 news drwxr-xr-x 2 bin bin 64 Jun 19 1985 pub drwxrwxr-x 3 spectre other 304 Jun 28 22:11 spectre drwxr-xr-x 6 bin bin 96 Jun 19 1985 spool drwxr-xr-x 4 bin bin 128 Jun 19 1985 sys drwxrwxrwx 2 bin bin 80 Jun 2 1987 tmp
The only change to /usr/bin was me copying /bin/date there for a reason I'll get to in a moment. The rest are as they came.
At one time there was a guest login (it's no longer in /etc/passwd) and it has one file.
% ls -l /usr/guest total 1 -rw-rw-r-- 1 guest visitor 148 Jun 11 14:16 tom % cat /usr/guest/tom Tom Caugheyt %vi tom wq qw TOM wq tom [...]
This is not unlike my first time trying to quit vi, though today you wouldn't catch me dead using emacs.
Unfortunately no other names appear on the disk, and there are no other files on the system that appear related to his research, or anyone else's. There are also no mail files to read, and while this version of Venix supports UUCP, it doesn't look like it was ever used.
% ls /usr/mail % ls /usr/tmp % ls -l /usr/spool total 4 drwxr-xr-x 4 bin bin 64 Jun 19 1985 cron drwxr-xr-x 7 lp bin 320 Jun 28 22:14 lp drwxrwxrwx 2 bin super 48 Jun 28 18:44 uucp drwxrwxrwx 3 uucp sys 48 Jun 19 1985 uucppublic % ls -l /usr/spool/uucp total 0 % ls -l /usr/spool/uucppublic total 1 drwxrwxrwx 2 root bin 32 Jun 19 1985 receive % ls -l /usr/spool/uucppublic/receive total 0
UUCP (Unix-to-Unix Copy) was the only networking option supported by Venix of this vintage; no PRO/VENIX or Venix-11 version supported TCP/IP or any other means of networking, serial line or otherwise. Only P/OS officially supported the CTI Ethernet card.
A subset of the Unix games package is in Venix. The manual says, "If you find that the User Reference Manual is rather prosaic reading, see section 6 for games." Strangely, this section of the manual is actually in the Programmer Reference Manual, and I don't like what this is implying. PRO/VENIX Rev 2.0's set is abbreviated compared to V7 Unix's complement, possibly for space reasons.
% ls -l /usr/games total 106 -rwxr-xr-x 1 bin bin 10534 Apr 3 1985 bj -rwxr-xr-x 1 bin bin 6156 Apr 3 1985 fortune drwxr-xr-x 2 bin bin 80 Jun 19 1985 lib -rwsr-xr-x 1 daemon bin 34812 Apr 3 1985 snake % /usr/games/fortune Take care of the luxuries and the necessities will take care of themselves. % /usr/games/fortune Colorless green ideas sleep furiously. % /usr/games/bj Black Jack! New game Shuffle JC up JS+6D Hit? n You have 16 Dealer has KH = 20 You lose $2 Action $2 You're down $2 New game TD up TH+KS Hit? ^C Action $2 You're down $2 Bye!!
snake worked pretty well too.
A copy of C-Kermit was also installed, along with source code.
% ls -l /usr/kermit total 1274 -rw-r--r-- 1 root sys 6197 Jun 28 1985 DECnotes -rw-r--r-- 1 root sys 7339 Jul 1 1985 KERMIT_INFO -rw-r--r-- 1 root sys 2971 Jun 24 1985 ckaaaa.hlp -rw-r--r-- 1 root sys 5310 Jun 24 1985 ckc40.ann -rw-r--r-- 1 root sys 3076 Jun 24 1985 ckc42.ann -rw-r--r-- 1 root sys 5207 Jun 24 1985 ckc4c.ann -rw-r--r-- 1 root sys 2541 Jun 24 1985 ckcdeb.h -rw-r--r-- 1 root sys 13598 Jun 24 1985 ckcfn2.c -rw-r--r-- 1 root sys 26659 Jun 28 1985 ckcfns.c -rw-r--r-- 1 root sys 3649 Jun 24 1985 ckcker.h -rw-r--r-- 1 root sys 8399 Jun 28 1985 ckcmai.c -rw-r--r-- 1 root sys 14406 Jun 24 1985 ckcpro.c -rw-r--r-- 1 root sys 7948 Jun 24 1985 ckcpro.w -rw-r--r-- 1 root sys 26514 Jun 24 1985 ckucmd.c -rw-r--r-- 1 root sys 1712 Jun 24 1985 ckucmd.h -rw-r--r-- 1 root sys 7349 Jun 28 1985 ckucon.c -rw-r--r-- 1 root sys 23054 Jun 28 1985 ckudia.c -rw-r--r-- 1 root sys 24520 Jun 24 1985 ckufio.c -rw-r--r-- 1 root sys 11545 Jun 24 1985 ckuker.bwr -rw-r--r-- 1 root sys 87779 Jun 24 1985 ckuker.doc -rw-r--r-- 1 root sys 6713 Jun 24 1985 ckuker.mak -rw-r--r-- 1 root sys 14464 Jun 24 1985 ckuker.nr -rw-r--r-- 1 root sys 12731 Jun 24 1985 ckuker.upd -rw-r--r-- 1 root sys 8533 Jun 28 1985 ckuscr.c -rw-r--r-- 1 root sys 42044 Jun 28 1985 ckutio.c -rw-r--r-- 1 root sys 15099 Jun 28 1985 ckuus2.c -rw-r--r-- 1 root sys 21090 Jun 24 1985 ckuus3.c -rw-r--r-- 1 root sys 34377 Jun 28 1985 ckuusr.c -rw-r--r-- 1 root sys 4345 Jun 24 1985 ckuusr.h -rw-r--r-- 1 root sys 2974 Jun 24 1985 ckuv7.hlp -rw-r--r-- 1 root sys 5556 Jun 28 1985 ckvcon.c -rw-r--r-- 1 root sys 16327 Jun 28 1985 ckvfio.c -rw-r--r-- 1 root sys 3970 Jun 28 1985 ckvker.com -rw-r--r-- 1 root sys 2190 Jun 28 1985 ckvmak.com -rw-r--r-- 1 root sys 583 Jun 24 1985 ckvmak.hlp -rw-r--r-- 1 root sys 25766 Jun 28 1985 ckvtio.c -rw-r--r-- 1 root sys 12553 Jun 24 1985 ckwart.c -rw-r--r-- 1 root sys 4018 Jun 24 1985 ckwart.doc -rwxr-xr-x 1 bin bin 101706 Jul 1 1985 kermit % kermit C-Kermit, 4C(053)+1 21 Jun 85, AT&T System III/System V Type ? for help C-Kermit> ? Command, one of the following: ! bye close connect cwd dial directory echo exit finish get help log quit receive remote script send server set show space statistics take C-Kermit> quit
This is a different Kermit build than the executable for Rev 2.0, which is a Venix-specific one rather than a generic System III or System V target. It is the easiest way to interchange files with Venix; I used Kermit as the terminal program on the Linux side and on the Venix side used kermit -is to push files, or kermit -ir to receive them. On the Linux side, transfers should always be in binary mode. A bit of garbage follows the transfer but the files always checked out.
% ls -l /usr/news total 3 -r--r--r-- 1 bin bin 513 Jun 27 1985 RELEASE_NOTES -r--r--r-- 1 bin bin 294 Jan 1 1985 greetings
We saw those already with news(1).
% ls -l /usr/help total 5 -r--r--r-- 1 bin bin 993 Feb 13 1985 basic.help -r--r--r-- 1 bin bin 1094 Feb 12 1985 more.help
These are a couple sundry short help files (remember, no man pages). more.help just explains how more works. basic.help is for the built-in copy of UBC (University of British Columbia) BASIC, which is a "an ANSI compatible BASIC interpreter that runs under VENIX." It is a standard part of the operating system and can either run separately written programs or act as a simple REPL like other BASICs of the time. There is no graphics support, but it does have floating point. The interpreter is started with the basic command:
% more /usr/help/basic.help Help information for UBC Basic: ! cmd issue system command "cmd" (e.g. !who) auto L1,L2 provide line numbers starting at L1, increment of L2 bye exit from basic catalog list files in user's catalog (directory) clear clear stack + clear vars clear stack clear execution stack clear vars clear variable symbol table del L1,L2 delete lines between L1 and L2 dump print out current variable names edit use system editor on program help print out help file list L1,L2 list program between lines L1 and L2 load file load the program from "file" merge file merge "file" with existing program old file load the program from "file" renumber L1,L2 renumber program starting at L1 with increment L2 run L1 start program running (at L1) save file save the current program in "file" scr scratch the program, variables etc. timeoff turn off run command timing % basic >bye
bye returns to the shell. Interestingly, instead of new, UBC BASIC uses scr to reset the program and variable area.
A couple more sundry files are in /usr/pub.
% ls -l /usr/pub total 12 -rw-r--r-- 1 bin bin 2114 May 30 1985 ascii -rw-r--r-- 1 bin bin 3200 Dec 2 1984 eqnchar % head -4 /usr/pub/ascii |000 nul|001 soh|002 stx|003 etx|004 eot|005 enq|006 ack|007 bel| |010 bs |011 ht |012 nl |013 vt |014 np |015 cr |016 so |017 si | |020 dle|021 dc1|022 dc2|023 dc3|024 dc4|025 nak|026 syn|027 etb| |030 can|031 em |032 sub|033 esc|034 fs |035 gs |036 rs |037 us | % head -4 /usr/pub/eqnchar '''\" apseqnchar (@(#)apseqnchar 2.2) .EQ tdefine ciplus % "\o'\(pl\(ci'" % ndefine ciplus % + %
Finally, let's look at what commands are installed.
% ls -C /bin STTY dd fsck ls pr strip umount adb df grep m86 printenv stty uname ar diff head mail ps su vax as dirname ice make pwd sum vedit basename du ipcrm mesg red sync vi cat echo ipcs mkdir rm tail view cc ed kermit mount rmail tar wc chgrp edit kill mv rmdir tee who chmod env l nice rsh time whodo chown erase lc nm sed touch write cmp ex ld nohup setscreen true cp expr line od sh tty csh false ln passwd size u370 cut file login pdp11 sleep u3b date find lorder plot sort u3b5 % ls -C /usr/bin admin cflow dc fsplit lpstat paste sccsdiff uulog asa chart delta get lscreen pc spell uuname at checkeq deroff getopt m4 pcat spline uupick awk col disable graph mkstr pg split uustat banner comb dplot help mm pie sscreen uuto bar comm dtree hist mmchek pplot tbl uux basic cpio edebug hplot more prof tek val batch cpplot egrep id neqn prs tic what bc crontab em1 iplot newform pscreen tput xargs bdiff csplit enable join newgrp ptx tr xstr cal ctags eplot lex news ranlib tsort yacc calendar ctrace erspc lint nl regcmp unget cancel cu erstek logname nroff rmdel uniq cb cxref f77 lp pack sact unpack cdc date fgrep lplot page scat uucp
I'm not going to go through all of these, and I don't have manual entries for all of them either, but it is a substantial complement and appears to have all of the base tools in System V R2.0 plus the Venix value-adds from 4BSD and a handful of Venix-specific utilities. The ps utility in particular is more of a system status utility, printing not only processes and their flags but also swap and memory status. This system additionally has Ted Green's vedit (probably a port of the C-language version developed for Xenix) and what look like cross-assemblers. You can also see the tools that were used to draw the graphs I showed you.
Here are the libraries. Remember, they aren't shared, although the programs that use them might be.
% ls -C /usr/lib accept flip libt4014.a llib-lmalloc.l pc_prlib.a acct help libtdec.a llib-port pscreen calprog lex libteps.a llib-port.ln reject cron lib.b libthp.a load_kit spell ctrace libF77.a libtids.a lpadmin suftab dag libI77.a libtlvp.a lpfx tabset diffh libPW.a libtpro.a lpmove term eign libbcurses.a liby.a lpsched terminfo em1 libcurses.a lint1 lpshut tmac em1_mon.a libl.a lint2 macros uucp em1_pc.a libmalloc.a llib-lc mv_dir xcpp em1_pr.a libmon.a llib-lc.ln nmf xpass ex3.9strings libpc.a llib-lm pc yaccpar f77pass1 libplot.a llib-lm.ln pc_emlib.a
Finally, the pieces of the kernel. This isn't in PRO/VENIX Rev 2.0 either, but Venix/86 2.1 does have the ability to rebuild its older V7 kernel (there are no PDP-11 targets, however).
% ls -l /usr/sys total 407 -rw-r--r-- 1 bin bin 45764 Jun 19 1985 IOLIB.pro -rw-r--r-- 1 bin bin 19776 May 27 1985 MDLIB.11.p350 -rw-r--r-- 1 bin bin 14640 May 21 1985 MDLIB.11.p380 -rw-r--r-- 1 bin bin 123192 Jun 6 1985 OSLIB.11 drwxr-xr-x 2 bin bin 272 Jun 19 1985 conf drwxr-xr-x 2 bin bin 96 Jun 19 1985 io.pro % ls -l /usr/sys/conf total 103 -rw-r--r-- 1 bin bin 7214 Jun 9 1985 Makefile -rwxr-xr-x 1 bin bin 16678 Jun 4 1985 config -rwxr-xr-x 1 bin bin 8332 May 13 1985 kfix -rw-r--r-- 1 bin bin 40 May 13 1985 last.o -rw-r--r-- 1 bin bin 1340 May 16 1985 low.pro.o -rw-r--r-- 1 bin bin 698 May 13 1985 master -rw-r--r-- 1 bin bin 578 May 21 1985 params.p350 -rw-r--r-- 1 bin bin 567 May 21 1985 params.p350f -rw-r--r-- 1 bin bin 588 May 21 1985 params.p350x -rw-r--r-- 1 bin bin 578 May 21 1985 params.p380 -rw-r--r-- 1 bin bin 567 May 21 1985 params.p380f -rw-r--r-- 1 bin bin 136 Jun 19 1985 uts.p350.o -rw-r--r-- 1 bin bin 136 Jun 19 1985 uts.p380.o -rwxr-xr-x 1 bin bin 7000 May 15 1985 vstrip11
No source code is included, just object files. Here are relevant sections of the Makefile with the supported targets and the Pro-specific targets. In the extracts below, the XFER kernel refers to the bootable mini-kernel on the first install floppy disk. win doesn't mean Microsoft Windows; it's just an abbreviation for a Winchester hard disk.
# @(#)Makefile 1.22 venturcom
#
# Put the kernel together for various hardware configurations.
#
# Makes:
# venix == winchester kernel for current machine type
# venix.86.xt == winchester based with floppy driver
# venix.86.xt.f == floppy based with winchester driver
# venix.86.xt.fo == floppy based
# venix.86.xt.x == XFER kernel
# venix.p350 == Pro 350 winchester based, full system
# venix.p380 == Pro 380 winchester based, full system
# venix.p350f == Pro 350 floppy based
# venix.p380f == Pro 380 floppy based
# venix.p350x == Pro 350 XFER kernel
# venix.86.at == win based, compatibility mode
# venix.286.at == win based, protected mode
# venix.86.at.f == floppy based, compatibility mode
[...]
#
# Pro 350/380 kernels
#
# ld flags to force proper loading of modules
U =-u _sureg -u _mapallo
venix.p380: $M.11.p380 $I.pro $O.11 low.pro.o c.p380.o last.o
$(CHECK) make uts.p380
$(LD) -k -i -X -x $U low.pro.o c.p380.o \
$M.11.p380 $I.pro $O.11 uts.p380.o last.o
kfix a.out venix.p380
vstrip11 venix.p380
rm a.out
chmod 444 venix.p380
c.p380.o: params.p380 master $(INC)
config -m master params.p380
$(CC) -c -I$(HD) conf.c
mv conf.o c.p380.o
venix.p350: $M.11.p350 $I.pro $O.11 low.pro.o c.p350.o last.o
$(CHECK) make uts.p350
$(LD) -m -k -X -x $U low.pro.o c.p350.o \
$M.11.p350 $I.pro $O.11 uts.p350.o last.o
kfix a.out venix.p350
vstrip11 venix.p350
rm a.out
chmod 444 venix.p350
c.p350.o: params.p350 master $(INC)
config -m master params.p350
$(CC) -c -I$(HD) conf.c
mv conf.o c.p350.o
The 380 target passes -i to the linker to enable split I+D spaces. Since the 350 doesn't support that, its target passes -m instead to generate a (slower) code-mapped kernel. This won't run as well as Rev 2.0's, but because the kernel is now much larger, it's the only way to boot V2.0 on the 350 at all. The 350 overlay disks replace all split I+D programs, including the kernel, with code-mapped versions. (See these "reconstructed" PRO/VENIX V2.0 disk images.) It is also worth noting that there is no target for Venix-11 anymore (on real PDP-11 hardware), which seems to have become unsupported by VenturCom after the Pro port. Although the 80286 port comes in both real ("compatibility") and protected mode variations, the kernels otherwise have the same features, though of course you can't actually build a PC kernel on the Pro because there are no binaries and no x86 linker.
Also, as written, no target will actually build anything because by default there is no /usr/bin/date, and there's also a CHECK = -@[ -f uts.c ] || exit 0 && in the Makefile — since uts.c is not present, the build will fail when this check is run as well. uts.c can be reconstructed and a very small one will suffice. However, given the absence of anything to write drivers for or a kernel ABI to write them to, or for that matter any source code, building a new kernel right now is mostly an academic exercise.
Let's finish our twin stories, starting with Venix. PRO/VENIX doesn't seem to have sold much given that not many Pros got sold to begin with. This worsened after DEC started to emphasize the Pro's "PDP-11 compatibility," such as it was, since most of these later customers had prior experience with DEC and ran it under P/OS so that they got RSX-11M, or with the RT-11 or COS ports instead. (There was even an unofficial 2.9BSD port to the Pros, included as an example disk image with Xhomer, though none of DEC's own Unices like Ultrix ever made it.) By then VenturCom was making most of their money from the x86 versions instead, so cutting the other ports out was no great loss. VenturCom continued aligning Venix releases with System V release numbers for the rest of Venix's commercial existence; Venix's last SVR2 was V2.4 for the 80286 and 80386 in 1988.
Although Bill Gates had been their biggest nemesis early on, most of the little Unices that flourished in the 1980s and early 90s met their collective demise at the hands of another man: Linus Torvalds. The proliferation of free Unix alternatives like Linux on commodity PC hardware caused the bottom to fall out of the commercial Unix market, leaving proprietary Unix's last bastion on legacy "big RISC" systems like IBM POWER (AIX) and Sun SPARC (Solaris) — a situation not unlike what the mini vendors faced back in the late 1970s. VenturCom ceased development of Venix after V4.2.1 in 1993 and shifted to the Windows NT market in 1995, developing an embedded real-time version of NT called RTX under license. Some of this work, including VenturCom's development tools and likely some low-level ported pieces of Venix, became part of the official Windows NT Embedded kernel in 1999. The company later became better known for their UDP netboot infrastructure allowing any x86 PC to be brought up or re-provisioned completely over the network. Changing their name to Ardence in 2004, they were bought out by Citrix in 2006, though former Ardence executives acquired the real-time stack and spun it out into new company IntervalZero in 2008. RTX and RTX64 are still sold today as MaxRT.
Meanwhile, the new DEC personal computer strategy did about as badly as the prior one, though mostly due to the Rainbow which by now was seen by the market as so thoroughly idiosyncratic and incompatible that sales had no chance of rebounding. DEC completed a port of Windows 1.0 to the Rainbow but it made little change to its perception. In 1986 Digital introduced the VAXmate, ostensibly side-by-side with the Rainbow, but secretly intended as its replacement. The VAXmate was a true AT-class all-in-one clone PC, not based on the VAX architecture, but was notable that it could netboot over Ethernet from a VAX/VMS server as well as run regular MS-DOS from a conventional hard disk. Instead of incompatible RX50 floppy drives it had the lower-capacity but PC-interchangeable 1.2MB 5.25" RX33, and did not need nor use Rainbow peripherals. The new 380 did have some takers, but that was a relative statement especially since the PDP-11 market was fading generally and other business units at DEC wanted to promote VAX systems.
DEC ultimately cancelled both the Professional and Rainbow families in 1987, replacing the 380-based VAX Console with a MicroVAX II for the second-generation VAX 8800s. Of the original 1982 rollout only the DECmate series survived, sold as the DECmate III+ until 1990 when it was no longer seen as competitive with PC word processing options. DEC nevertheless kept trying to sell their proprietary architectures as microcomputers, particularly in the form of the later VAXstations which primarily ran VMS as workstations and were generally compatible with bigger VAXen yet ultimately suffered a similar fate to the Pros. Digital did sell their own lines of PC clone desktops and laptops, and the Alpha had some modest initial success as a high-end PC competitor under emulation, but on the whole there were a lot fewer DEC computers in the home than there should have been. DEC was bought out by Compaq in 1998, and Compaq itself was acquired by Hewlett-Packard in 2002.
This isn't the last you'll see of this machine. I'd like to explore writing some userspace networking options, and like I say, there's a lot of untapped potential in that graphics hardware. Stay tuned for future articles.
No comments:
Post a Comment
Comments are subject to moderation. Be nice.