This Refurb Weekend is a sequel in two ways. Six years ago I fixed the power supply and case fan in my 68EC030-based Alpha Microsystems Eagle 300, a more modernized and substantially faster Alpha Micro running AMOS, their unique DEC-inspired multiuser operating system. These blue-collar boxes were very common in many vertical markets due to their tightly integrated business-specific software packages, and are especially unusual for running their big-endian 68000-series processors little-endian (for data file backwards compatibility with their WD-16 ancestors). The 1990s-era Alpha Micro Eagle family improves on the originals with later 68K and even ColdFire CPUs, plus Ethernet and faster SCSI. The second way it's a sequel is to our previous Alpha Micro refurb weekend, a double header restoring an Alpha Micro AM-1000 and AM-1200, two members of Alpha Micro's most popular series of computers and some of the closest things they made in the early '80s to desktop workstations. From the outside, the Eagle comes in a PC-style case, but it's not a PC: ampm.floodgap.com using the webserver provided with AlphaTCP — yes, Alpha Micros can be networked — and its own on-board Ethernet. At the time the cooling fan failure was putting a lot of strain on the hard disk because it was overheating, and since this was my first Alpha Micro and I wanted to keep it in good nick, I decided I would put a SCSI2SD in it after the repair and get rid of the spinning disk entirely. Fast-forward to last fall, a little over a year ago, when I tried to do exactly that with a ZuluSCSI. And then it wouldn't start. thought was a replacement unit I could raid for parts, but it turned out to be something rather more special — and then I was even more fortunate when I got the Eagle 300 back out of storage to make one last attempt at reviving it. To cap it off we'll go stick ZuluSCSIs in everybody else, including my Motorola ColdFire-based Eagle 450, the first ColdFire server ever produced and what used to be the fastest Eagle in the house until the new hotness came. I even converted the external BlueSCSI the AM-1200 was using to an internal ZuluSCSI too. Now nearly everybody's got a solid-state boot disk and they're all a good bit more zippy, so we'll gawk at the internals, compare 68K CPU and storage benchmarks and most importantly learn from my mistakes, because as my late father always said, "I'd rather be lucky than good." On a more solemn note, we'll also observe a moment of silence for one of the line's creators who passed away last year. It's time for a Refurb Multi-Weekend Sequel. Alpha Microsystems, founded in Orange County, California in 1977, produced what were considered some of the earliest "poor man's minicomputers," smaller and more affordable multi-user systems that run a bespoke, Digital Equipment Corporation-influenced operating system named AMOS. In our previous entry we discussed their history in detail. First-generation Alpha Micros like the AM-100, designed by Dick Wilcox who also wrote most of the operating system, used large S-100 cases and a CPU chipset called the WD-16, derived from the Western Digital MCP-1600 chipset — the same one used in DEC's LSI-11 CPU — but with higher performance microcode developed by Rich Notari. These machines thoroughly outclassed low-end PDP-11s yet were substantially cheaper, and Alpha Micro found a ready audience initially with hobbyists and then later corporate turnkey environments, where its integrated AlphaBASIC and database functionality gave it a competitive advantage. As the WD-16 had little elbow room to evolve, in 1982 Alpha Micro introduced new systems based on the Motorola 68000, porting AlphaBASIC and AMOS to run natively, but swapping address lines to make it appear little-endian for compatibility with WD-16 data files and AlphaBASIC P-code. These new machines included the AM-1000, Alpha Micro's most popular single model, and by 1984 it constituted the majority of the over 20,000 Alpha Micro machines then in active use. An idealized Alpha Micro office from the 1980s might look like this photo, from their actual advertising of the period. The main system is an AM-1042E, the S-100 box sitting on the pedestal next to the printer, using an AM-100/L CPU with an 8MHz 68000 (the same as the AM-1000, which was integrated into a desktop case), and in the factory-standard configuration shipped with 512K of RAM and a 60MB Winchester ST-506 hard disk. The system served some number of local users connected directly via serial ports, in this case the two administrative assistants with AM-60 terminals (a modified and rebadged Wyse WY-100). The fact everyone here was in the same room with the machine was helpful, because AMOS is a strictly real-memory operating system and executable code ran from where it was loaded in the user's fixed memory allocation — there was no memory protection. Although the admin assistants' explicit permissions were limited by which account they were logged into, using the same style of project-programmer numbers as DEC (e.g., [1,2] being the operator account), an errant job of theirs could readily stomp on another and it was not rare for busy systems with buggy software to regularly crash. On the other hand, this also made it fast and efficient with little separation between you and the hardware, and even Alpha Micros with fairly modest specifications could support hundreds of simultaneous users. Alpha Microsystems tried multiple times to broaden the line technologically, though these efforts were largely for naught. Early attempts to put equivalent hardware onto a PC ISA co-processor card, with software to interchange between MS-DOS and AMOS, yielded only an expensive and poorly-selling PC that wasn't good at either OS (eventually the company gave up producing turnkey systems and just sold the card). In 1984 Alpha Micro introduced UNIMOS, a licensed version of AT&T System V UNIX which ran on modified AM-1000 hardware with an MMU, but it was likewise too expensive and garnered little interest from new users nor demand from existing ones. The cost of its development, the Unix license and its associated royalties, and a simultaneous lawsuit from DEC over AMOS's similarities subsequently caused lasting damage to the company, and by the end of the decade Alpha Micro found itself almost entirely dependent on legacy AMOS users. In the wake of Wilcox's 1990 retirement and original investor Bob Hitchcock's own departure in 1991, new management tried once more with Unix systems based on the Motorola 88000 — which Motorola abandoned shortly afterwards for the PowerPC AIM alliance, and so no hardware ever shipped. anybody — yes, really, just two months after the '030's October introduction — initially offering a 20MHz CPU, 32K of L2 cache and supporting up to 360 simultaneous terminals, but even the lowliest 30-user configuration started north of $40,000 [about $117,600 in 2026 dollars]. By contrast, Alpha Micro was uncharacteristically tardy in adopting the 68040 and didn't release the 33MHz AM-4000 until 1993. It was nevertheless nearly as expensive, and for most small offices, which were now increasingly Alpha Micro's financial anchor, that kind of money was simply beyond consideration. In 1993 the company settled on a two-board approach to solve both problems at once. The CPU board, dubbed the Roadrunner and designed by engineer Joshua Stumpf, contained the new processor, standard RAM SIMM slots, L2 cache (if present), and SCSI controller. This board was specifically designed to also fit in legacy machines, specifically the desktop AM-1000, AM-1200 and AM-1600 and server AM-2000 and AM-3000 systems, and initially came in a 68030 and two 68040 versions. A second board served as the CPU board's system interface, linked together using a custom "X-BUS" interconnect over twin 34-pin cables. For legacy installs, this second board was an active interposer physically replacing the original processor, which in elderly units sometimes needed to be desoldered (though that was also true for the few third-party CPU upgrades then extant, like InterLink's Dimension-030, so the Roadrunner was at least no worse). But this second board could be a whole new system architecture of its own, and that was what the I/O board was, designed by Rod Hewitt. It carried the power supply connectors, controlled the system front panel, contained the System Security Device for licensing (more on this later), presented built-in external ports for parallel, SCSI and (for certain loadouts) Ethernet, had an internal port for an optional floppy drive, and provided SIMM-format "paddle card" slots for option cards. Best of all, these boards were smaller and — by using off-the-shelf commodity hardware — cheaper to manufacture, and could be paired into multiple configurations, together becoming the company's long-promised updated low-end and mid-range systems. reasons I've related elsewhere, and I managed to land it for just a couple hundred bucks in fully working order. (Boy, are those days gone.) Based on the software still on the hard disk, this machine was previously used at a chain of three party stores in Washington state as a centralised rental and point-of-sale system, a common turnkey application. On arrival it sported the same loadout as in this article's first picture except for its original smaller-capacity Tandberg QIC tape drive, which in Alpha Micro parlance is called a tape streamer. Since these systems don't boot from CD, QIC tape is your only way to cold start and restore most 68K Alpha Micro computers if the hard disk fails. These systems also don't support the old Alpha Micro VHS backup system, hopefully to be the subject of a future article, which was ubiquitous in their early hardware. There is a single hard disk in the second 5.25" bay, though these first-generation systems also supported 5.25" and 3.5" floppy drives using an AM-219 controller board. original Refurb Weekend. our previous Alpha Micro foray we discussed the SSD's role, a chip installed in every 68K (and later x86) Alpha Micro, even the earliest S-100 boards, used by the operating system and any installed VAR software packages to enforce copy protection and license caps. The SSD number on the rear is just a serial number, printed on the rear plate for convenience and engraved on the SSD chip inside, which I'll show you in a moment. This number is not the key stored inside the chip, up to 256 bytes in length, which only Alpha Micro recorded. When a VAR wanted to lock an install to a particular system, they would provide their private code to Alpha Micro plus the user's SSD serial number, and Alpha Micro would look up the key and generate an alphanumeric PIC (Product Installation Code) that the VAR either used for direct installation or to provide to the user. During the installation process the PIC (usually irreversibly) encoded a binary overlay for the protected executable(s), making it impossible to run them on a system where the SSD didn't match. To facilitate logic board swaps and upgrades, the SSD is socketed and easily transplanted into a new board, but PICs were expensive then and unobtanium now, another reason hard disk backups were so critical. % curl -I http://ampm.floodgap.com/ HTTP/1.0 200 OK Date: Sun, 11 Oct 2026 23:43:03 GMT Server: AMOS-HTTPD/1.3C(111) MIME-version: 1.0 Content-type: text/html Last-modified: Sun, 11 Oct 2026 23:42:00 GMT Content-length: 30242 Content-encoding: 7bit in our most recent article. In this picture it's also attached to an AM-401 CD-ROM, which is the trusty Toshiba XM-5401B in an external case, though only specific ROM versions are supported. It can't boot from this drive, but it can read AMOS-formatted partitions, and with external software can also access ISO 9660 filesystems. Onscreen is a performance estimate using the built-in SI.LIT tool, which we'll be using to benchmark our new solid-state disks when we get them in there. Here's that output. .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68030 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484) Boot PROM revision: M00 Number of SSDs: 1 Total Memory: 16384 K-bytes Resident Monitor Memory: 6218 K-bytes Computing Index (CX), relative to AM-100: 36.9 48 bit FP Index (4X), relative to AM-100: 36.3 Floating Point Index (FX), relative to AM-100/L: 5.6 Disk Index (DX), relative to ST-506: 15.3 I don't know why it identified the 68EC030 as having an MMU, because it doesn't, but we're mostly interested in the "computing index" figure (SI's equivalent of an integer score) which is 36.9 times faster than Alpha Micro's original AM-100, and the "disk index" hard disk throughput test, which rates the spinning disk it came with as 15.3 times faster than their early ST-506 drives. Remember these figures as a baseline; we'll be referring to them again. On the front panel in both pictures you can see the number "0" in the LEDs. That's where the system status is displayed, initially by the firmware, then the OS monitor during boot and then in operation. We'll come back to this as well. original Refurb Weekend involved replacing the old AT supply with an ATX one and a converter. Since that post I found a NOS AT supply for cheap and I needed the ATX supply for something else, so I removed the converter and installed the new AT supply. This is that unit. The CPU and the 53C710 are both clocked by an 80MHz crystal divided down to 40MHz; there are also 16MHz and 50MHz oscillators on the board which appear to be used for the PLD and bus logic. Likely for cost reasons there is no L2 cache, though another thing to keep in mind is — so I'm told — that for compatibility reasons with 68000 and 68010-era AMOS software it is not possible to enable the data cache (or at least not without substantial difficulty). In fact, we observed exactly this phenomenon when looking at the driver for the InterLink Dimension-030 CPU upgrade, which puts a 68030 in an AM-1000: it never set the data cache bit in the '030's CACR at all. Although some machines can accept an external L2 cache, including one we'll look at in detail, anything it would provide is strictly I-cache. but is functionally equivalent in AMOS. not). I have such an example later on. Other serial paddlecards can also be installed. The AM-314 provides only four serial ports, but is not merely a cut-down AM-318 — the AM-314 can also be configured for RS-422 (the AM-318 is strictly RS-232) and supports all RS-232 handshake lines (the AM-318 only RTS/CTS), and in certain configurations can trigger a remote reboot from a connected distant console by grounding pin 1 with pin 7. By contrast, the more exotic AM-338 provides an IBM Binary Synchronous Communication "Bisync" link, typically used for Remote Job Entry (RJE) or CICS connections with IBM mainframes, but could theoretically have also worked with some early point-to-point networks like BITNET. It connects to an AM-339 which provides the physical port. a future article. Notice how many of these PCBs say "Made in USA"! A different era. from my SGI Indigo^2 retrofit to see if it could sit on them. It did, so I sheathed them in electrical tape as a "bed," put the ZuluSCSI into initiator mode, connected the old hard disk and the ZuluSCSI to my copy rig, and left it to image the drive to the SD card. didn't change: the boot sequence wasn't starting. I freaked out, immediately powered it off, and checked everything inside that I'd touched to find I had not properly reconnected the CPU board's power connector. original. I dug up Rod's old E-mail to see if there were any clues in it and recalled what he'd said about the PLDs being dynamically reprogrammed on every startup — from the CPU board. I also knew from the service manual that the X-BUS cables, the only connection between the I/O board and the CPU board, had to be correctly connected or the service manual warned damage could result. A horrible theory stirred in my head: perhaps I had managed to accidentally corrupt the PLDs by effectively bringing up the I/O board without the CPU board, where the boot PROMs used to reprogram them are located. However, that also suggested a solution — there are many undocumented jumpers on the AM-319 and I wondered if one of them could be used to trigger a clean reset of the programmable logic. in a future article). He also had an interest in digital television, developing TSReader, a way to analyse the MPEG-2 transport streams commonly used for satellite, cable and IPTV transmissions. ZTERM and in particular TSReader became far and away his most popular software packages. However, a few years prior and unbeknownst to many, he had quietly entrusted a copy of the TSReader source code to a friend officially "just in case," and sold ZTERM to MicroSabio, a long-time Alpha Micro support company that maintains A-Shell, a way of running AlphaBASIC applications on modern operating systems. The reason became clear later — he was dying, and it was not treatable. The source code for TSReader was duly posted after his passing and remains today as his most popular legacy. Rest in peace, Rod, and thank you. Without Rod's guidance, though, there wasn't much more I could think of to do at that point. I unplugged it, pulled the clock battery and let it sit for a couple days to see if that was enough to reset the PLDs, assuming that was the actual problem, and it didn't. It still seemed like it should be repairable if I could only figure out how, but as there was little point in having it sit fruitlessly on the workbench I removed all the remaining cables from the system board and moved the machine to cold storage until I could come up with something else. In the meantime I turned to my alternative system to get ampm.floodgap.com back up and running, though to discuss it we need to bring the history forward some more. only in the E500: a junior-varsity 68040, which is what the E400 was, didn't have much appeal. Both the E200 and E400 were quietly dropped. For large installs that required substantial numbers of serial ports, the existing AM-319 board had to be expanded. The revised AM-319-20 board, providing four built-in serial and parallel ports with a UPS monitor port and a higher-performance DP83902 Ethernet NIC, still had two paddlecard slots, but these slots were widened to 60 pins and could now be part of a bus connected to an external chassis. Alpha Micro had long sold the AM-990, a large capacity case (in this image as used for the AM-4000, though I apologise I don't have a better image of it) and the AM-990 Jumbo, which was even larger. A new higher-performance serial card was developed to take advantage of the widened paddlecard slots, an optically-isolated eight-port card called the AM-359. Twelve AM-359s could be installed in the AM-990, yielding 96 ports when connected to a fan-out in one of the AM-319-20's paddlecard slots (the four on-board ones made an even hundred); the Jumbo could take another twelve AM-359s for another 96 ports connected to the second, a whopping total of 196 serial ports when combined with the base four. If you needed even more, the AM-3501 sidecar chassis could take you well beyond. There was no point in supporting the 68EC030 with such a monster: this new Eagle, officially the Eagle 550 Super Eagle, was 68040 or bust. that large, a Super Eagle in the standard case could support up to 60 ports, four on the AM-319-20 and then seven AM-359 cards in the usual position. The E550 Super Eagle additionally came as a separate upgrade kit for the E500 and the few E400s that sold, essentially a system board swap, though when sold as a turnkey system it was always with the 40/80MHz CPU. The E550 introduced a new Seiko timekeeper chip as well which not only maintained the time but also the "CMOS settings," the first Alpha Micro with an on-screen setup utility in ROM allowing boot configuration. Subsequently the company was tardy once again in adopting Motorola's newest 68K CPU, this time the superscalar 68060, which had come out in 1994 aimed squarely at the Intel Pentium but didn't reach Alpha Micro customers until mid-1997. This took two forms, a new 66MHz '060 Roadrunner upgrade option for the E550 Super Eagle and the AM-4000 (lesser Eagles need not apply), and a new AM-6000 large system. Interestingly, the AM-6000 is strongly based on the E550, reflected in its internal designation as the AM-3500-6000 making it a "stealth" Eagle. The '060 Roadrunner not only included the new CPU but also 64K of L2 cache, support for up to 256MB of RAM in four SIMM slots, and 68-pin Fast and Wide SCSI-2 using the NCR 53C770. along with E100s and a smattering of E500s and Super Eagles. However, it was not lost on company management that Motorola believed the 68000 family was fast approaching a performance wall. This was made most clear by their then-enthusiastic participation in the PowerPC AIM alliance, but also the rise of ColdFire, which Motorola had first announced in 1994 as well. ColdFire was in its own way Motorola's oblique admission that 68K was losing desktop competitiveness to x86, an attempt to scale the ISA down to embedded markets where its familiarity could be an asset. Approximately 20% of the instruction set such as BCD and certain addressing modes were eliminated, meaning the canonical ColdFire could not be fully binary-compatible with any extant 68K. On the other hand, such cuts enabled the core to execute nearly every remaining instruction in a single clock cycle, and the initial die was a miniscule 4.4mm² at 0.5μm, a third the size of Motorola's own 68300-series CPU32+. Some amount of this work was done by altering the microcode of the 68040V, a fully static 68LC040. Mindful that ColdFire's incompatibility might impair adoption, Motorola chose to create a bridge first-generation chip from this altered 68040V where omitted user mode instructions were left in, demonstrated on die photos. While the new chip had smaller 2K instruction and 1K data caches than the 68040V, and the MMU was also eliminated, this deviation from spec was still sufficient to run regular 68EC040 code at the user level. Motorola called this first-generation ColdFire chip the MCF5102, produced on a 0.6μm process, and introduced it in 1995 drawing 0.8W at 20MHz and reaching 33MHz. Clock-for-clock there was no way this chip could eclipse an '060, and the emerging "true" ColdFire 520x series couldn't run existing Alpha Micro software, but the MCF5102 was still faster than an '030 and nearly as fast as an '040 — in fact, we'll prove it. On top of that it was cheaper and AMOS didn't need the MMU anyway, making for a plausible mid-range machine that wouldn't imperil (much) sales of the E500 or E550. alt.sys.alpha-micro, though credit must be given to John F. G. Leighton, then Alpha Micro's VAR marketing manager, who chose to print the review unedited in marketing materials, even Rod's gentle complaints. Since this is the only E450 I have personally laid my hands on, we will be referring to his comments liberally as a point of comparison, and consequently the E450's history is probably the best documented of any 68K Eagle. It rolled out to users in October at the annual meeting in nearby Riverside, California. This particular system was a gift from someone who inherited it from an 9-1-1 emergency dispatch centre and wanted to find it a good home, another way that running an Alpha Micro-powered web server has paid off. I was able to quickly get into the system (if it's not clear by now, I love hacking into Alpha Micros) and reconfigure it, and it had lurked as the E300's work spare and a test unit since then. Like the E300 it has a bootable tape drive, but this time it's a more modern DDS/DAT. E450, and it claims not to have an SSD at all (untrue). As such, I'm not sure I can believe the stated manufacturing date of September 2002, and at least one date inside directly contradicts it. It's possible this was a case with a transplanted board. 1999 as prerequisites for the AM-370, an unidentified off-the-shelf 100Mbit PCI NIC that goes into the "slot" at J5. To access these PCI slots, that rear panel I pointed out needs to be removed. The AM-370's availability implies all shipping E450s should have had them by then — there was even an alleged board-swap program to do so. I've yet to find another one, so I don't know if that's true, but it would be interesting to find out because with this card or the OEM equivalent you would have two fully operational NICs and multihoming was reportedly supported. I also don't know what's going on with the unpopulated "option connector" at P5 to the right/east of the AT power connectors. other slots. The E450 is one of only a few Alpha Micro systems that can accept an optional external L2 cache, though as mentioned this cache is only enabled for instructions, and the form factor does not match any PC cache stick — in fact, it's the same as a 72-pin SIMM, so don't put the wrong one in the wrong place (Rod also objected to this). The only size supported is 64K, the same cache stick used for the AM-6000 and the '060 Roadrunner, part #PDB-00701-00. I've never seen this cache stick and comparison of his numbers with my cacheless E450 suggests it only yields around a fourteen percent boost, not nothing but not much, likely because it can't do anything for the data cache (though stand by for a very important observation on actual clock speed). The E450 also has two 72-pin SIMM slots, which need not be paired and support up to 256MB, though as with the earlier systems the machine needs to be jumpered to tell it how much is there. The tag on the one in J11 (service order 13009, apparently) is dated January 18, 2002: that makes this machine at least eight months older than its alleged manufacturing date, and to have received an upgrade suggests it's even older than that. Between the two sticks this system has 72MB of RAM. Below/south of the RAM SIMMs are the three paddlecard slots. Also in this image is another obvious non-populated area: a pin-grid array marked "PGA040" at U89 in the northeast/upper right hand corner. That sounds like somewhere the CPU would go, and the footprint looks like an '040. So where's the actual processor? fast is it doing it, though? While Rod's review stated his prerelease system was apparently running at 33MHz, the oscillator closest to the CPU can be seen clearly in this photograph, and it's ... 25MHz. There are no other crystals on the board except for the serial port one you saw earlier, the official marketing announcement has a board layout that also clearly labels this crystal as 25MHz, and nothing in the MCF5102 user's manual says the chip does anything tricky with the clock. As it happens, the only place in Alpha Micro documentation where the E450's CPU speed is given is Rod's review: everywhere else, even the data sheet, simply says it's a ColdFire and nothing more. Since mine is only 14% slower than his, and his had the cache, his can't possibly have been running at 33MHz either. The E450 is a 25MHz ColdFire, full stop. In a backwards way, however, this is nothing less than validation of how performant early ColdFires could be. Recall that our E300, a 40MHz 68EC030, had a "CX" computing index score on the SI.LIT benchmark of 36.9. The same benchmark on this E450 with a 25MHz MCF5102 gets a score of 59.9, and Rod's with 64K L2 came in at a whopping 68 (Alpha Micro said 68.5; either one is around 14% higher). By contrast, the E550 Super Eagle, with a full 40MHz ("80MHz") 68040 Roadrunner clocked 60% faster and 32K of L2 cache, officially gets ... 79.9 (note from the future: my figure is 83.6) — the full cached-up faster-clocked 68040's performance on the same code is only around 33-40% better, and just 16-22% or so if the E450 has its cache too. Put another way, the CX/MHz ratio of the faster 68040 was right around 2.0, while the CX/MHz ratio of the MCF5102 is 2.4 without the cache, and almost 2.75 with it. Likely because the lower clock speed would have looked bad in marketing materials, similar to why General Magic never mentioned the clock speed of the DataRover 840, Alpha Micro simply chose not to mention it either. Still, this machine's surprising efficiency proves ColdFire, at least early on, definitely had legs. I'm not sure how Rod got it wrong except that an earlier version may indeed have run that part, though with these numbers, if there had ever been a production 33MHz E450 it might have seriously endangered sales of Alpha Micro's remaining '040s — perhaps that's why they didn't use it even though the faster part existed. Best guess is that the AM-138 was originally designed for the 68040 and then quickly retrofitted for ColdFire, leaving the PGA region as an "R&D test point" (as documented). our prior entry, and he referred me to a longtime Alpha Micro vendor that they still partner with for existing installations. It took a few months, but this vendor was able to locate what appeared to be another E300 with working boards and we negotiated a price and getting it shipped. "everything console" connected to the top left port (G1) via the dongle at the typical speed of 19200bps. Good, it booted fine, we got a dot prompt, we can get into it, networking is already configured, and (as is typical for most Alpha Micro installations of the era) there is no password on the operator account. I powered it off and now that we know where the system thinks the console is, we'll get a proper self-test readout. I powered it back on with the reset button held in and the self-test came right up. The self-test can autosense the baud rate by mashing the spacebar when the front LED flashes "5b," and then the test runs, with the LED showing the current state and additional details sent to the serial port. ---------------- SYSTEM SELF-TEST ---------------- Version 2.1(120) Prom Rev. N00 for the AM-174 board. polling complete. Boot configuration: Processor - 68040 Memory detected - 32M bytes Primary serial ports - 4 SCSI Controller press [space] to bypass memory test MEMORY TEST passed - 32M bytes TIMER TEST passed SERIAL PORT TEST Primary serial ports - 4 Port # 0 passed Port # 1 passed Port # 2 passed Port # 3 passed SCSI Controller Controller Self-test passed SCSI drive Self-test passed Find diagnostic cylinder passed Write/read test passed 40?! This is not a Eagle 300! We need to open this thing up. didn't expect was the CPU board on the bottom: it's a full 68040, just like the test said. Bclk for the bus clock, and then a second exactly twice as fast labeled Pclk as the so-called processor clock. In the 68020 and 68030, which accept a single clock signal, their internal ALU runs at only half the bus speed such that the 40MHz 68EC030 in the Eagle 300 actually has an ALU running at just 20MHz. For the 68040 Motorola removed this limitation to run its ALU at full bus speed, but the chip designers also studied trace data to optimize for the most common instructions, implementing a 7-stage pipeline where most effective address calculations and fetches occur with no penalty. The upshot of this was to cut most instructions' cycle count in half or more. The 2x processor clock is truly used, but not to speed up the ALU, so it's wrong to say the 68040 is "double-clocked." In a two-part 1990 article in IEEE Micro, Motorola explains that "Pclk provides timing reference points within each Bclk period," employing it for synchronous sub-cycle timing, and furthermore explicitly states that "all internal operations cycle at the Bclk rate." Still, the fact this clock signal was present at all gave Apple an excuse to tout both timings for '040 Macintoshes, and Alpha Micro cheerfully reported just the faster one, even though the chip only appears to run at that comparative speed from its larger 4K L1 cache, unhindered ALU and reduced cycles per instruction. On this board, Pclk is provided by the same 80MHz crystal we saw on the AM-172, divided down by two to yield Bclk in the same way the 68EC030 board does for its single 40MHz clock. (For the E400's AM-174-00, this crystal would have been 66MHz divided down to 33MHz.) The single parity FPM SIMM slot and 16MHz and 50MHz oscillators are also present, as well as the same 53C710 SCSI controller, here a genuine NCR part. However, new for this board is 32K of L2 cache at the upper right/northeast corner, implemented with two IDT 71B74 8K cache-tag RAMs together providing 29 bits (512MB) of address comparison, and then four Cypress CY78C185 8K SRAMs for the cache itself. Remember, however, that in AMOS all cache is I-cache. Effectively this 40/80MHz AM-174 makes our new system a full Eagle 500, so why is it labeled as "only" an E300? I don't how how these systems originally shipped from the factory nor whether the E500 designation actually appeared on the back, but Alpha Micro did run a promotion in late 1997 where you could upgrade any Roadrunner '030 to a Roadrunner '040 by swapping the CPU board. My guess is this is one of those systems, and because that upgrade kit wouldn't have changed the plate on the back itself, the reseller simply noted it to be a working E300 and sold it to me as such. While that wasn't exactly what I was hoping for, it's a really nice bonus, as evidenced by the system benchmark (taken on the SCSI hard disk it shipped with): That score officially makes it the new fastest Alpha Micro in the shop by far (this is where that prior 83.6 number came from, compared to the E450's 59.9 and E300's 36.9). It seemed a shame to carve it up as spare parts, so let's have a little look around. A surprising thing about the system configuration file (SYS:AMOS32.INI, a/k/a AMOS32.INI[1,4]) is that only one terminal is actually defined, which makes you wonder what those two RJ-21s are doing. Best guess is that this machine passed through a couple hands and ended its prior service as a single user's toy, much as my own machines are now. In a related phenomenon an annoyingly small number of terminal types are defined, all inconvenient, likely to save memory. On the other hand, the full AlphaTCP suite (based on SpiderTCP and SpiderStreams, best known as the Windows NT TCP/IP stack before 3.5) is defined and present, and we saw it running before, so we ought to be able to make use of that. That's its IP address, and we saw Telnet was running (TCP:TELNED.LIT), but there's a snag: The TCP:CONFIG. file sets up TCPEMU, AlphaTCP's master daemon, acting as its service description file (really a sort of up-script). This line for the Telnet daemon causes an automatic log-on from a Telnet session and inconveniently forces the FWYCOL terminal type, intended for a real Wyse WY-370. That's also the terminal setting for the single serial port which our "everything console" doesn't speak, meaning I can't visually edit anything without making a big mess. Ironically, that AM-75 colour head my E300 uses is itself a modified WY-370, but no longer speaks that terminal emulation either. But we have another option! Now knowing its IP address, I set up a small wired network to my MacBook Air. Although some terminal programs like Kermit 95 can speak WY-370 over Telnet, using MacWise — now freeware and runs on Tiger and Power Macs all the way to Tahoe on Apple silicon — I managed to discover that its TeleVideo 925 emulation will partially match FWYCOL. This was just enough to, with some care, edit TCP:CONFIG. and remove all the defaults so that I could manually select the terminal type on Telnet login. I then reset the FTP user credentials in TCP:FTPUSR., uploaded a copy of ANSI.TDV from the Eagle 450, and changed the TDVDEF line in a test copy of SYS:AMOS32.INI to allow it as a terminal type, which at last got me a proper session. I'm not sure of this system's most recent owner and the seller didn't know either, but there were two interesting domains in its TCP:HOSTS. file (identical to /etc/hosts) for that IP address. One domain name belongs to someone who appears to have been a recording engineer (!). This domain still exists, but is only partially functional, so I've chosen not to link it here. The other domain name was for a personal genealogy site, now parked, and that site appeared to be what it was currently offering via the Web server on HTM:, mapped to PPN [7,77]. However, because the HTML files were not on an extended directory device, I can't tell when the site was created because the old AM file system doesn't preserve modification times: Looking up this domain in the Wayback Machine, it seems to have been active in the early 2000s. Still, not bad assuming it was still serving it then. differently on the AM-172 and AM-174s, so it seemed safer just to never separate them in the first place. I wasn't even going to move the SSD and hard disk — since TCP/IP networking was already set up on the E500, I could just upload the site to the E500's hard disk instead. Only the E300's power supply, serial port cards and Tandberg QIC streamer would stay. Once the new transplanted system was working, then I'd see about doing the ZuluSCSI upgrade again. It tried to boot. Startled, I powered it off, connected the everything console, and turned it back on with the reset button held in to force a self-test. Except for the missing hard disk, it passed the self-test — even the SCSI controller tested good. I decided to push my luck and connect the ZuluSCSI, and this time it did throw a 2d. I freaked out again, powered it off, let it sit and then gingerly turned it back on. It still did it. However, when I disconnected the ZuluSCSI, it went back to trying to boot, and a repeated self-test was still clean. This was clearly new behaviour — beforehand, it wouldn't do anything, not even enter the self-test, let alone attempt booting. Recall that error 2d had two mentions in the manual, the second one referencing the primary and secondary boot devices. Since the self-test said the SCSI controller was fine, this made me suspicious that there was something about the ZuluSCSI's configuration the machine didn't like. Knowing some systems can get finicky about sluggish devices immediately after power-up, I reconnected the ZuluSCSI and powered the E300 back on. Code 2d duly appeared, but this time instead of turning it off, I hit the reset button just to see what it would do. SI.LIT had actually dropped to around 10, which was 33% slower than its original hard disk. .scsi Dispatched SCSI port: SCSI id 7: (reserved) SCSI bus host adaptor SCSI id 6: No device or unable to report SCSI id 5: No device or unable to report SCSI id 4: No device or unable to report SCSI id 3: SCSI-2 (tape) TANDBERG TDC 4200 =08:01CREATED12119 SCSI id 2: No device or unable to report SCSI id 1: No device or unable to report SCSI id 0: SCSI-2 (disk) ZULUSCSIHARDDRIVE 2.3BZuluSCSI .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68030 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484) Boot PROM revision: M00 Number of SSDs: 1 Total Memory: 16384 K-bytes Resident Monitor Memory: 6218 K-bytes Computing Index (CX), relative to AM-100: 36.8 48 bit FP Index (4X), relative to AM-100: 36.3 Floating Point Index (FX), relative to AM-100/L: 5.6 Disk Index (DX), relative to ST-506: 41.2 .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68030 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484) Boot PROM revision: M00 Number of SSDs: 1 Total Memory: 16384 K-bytes Resident Monitor Memory: 6218 K-bytes Computing Index (CX), relative to AM-100: 36.9 48 bit FP Index (4X), relative to AM-100: 36.3 Floating Point Index (FX), relative to AM-100/L: 5.6 Disk Index (DX), relative to ST-506: 100.4 six times faster than the original hard disk). There's no obvious caching in the Blaster's firmware that I could see, and although the AMOS system-wide disk cache was on, the test is supposed to be unaffected by OS-level caching. On the other hand, when I rebooted AMOS from software, its score went back to 41 and 100 thereafter. More on this phenomenon later. Termination power was sufficient to power the Blaster. But what the Blaster didn't fix, even with its later firmware, was the 2d code the E300 kept throwing from a cold start. Although booting after a manual reset was still fine, it refused to start after a power cycle without assistance, which I need it to be able to do if there's a power outage when I'm not around. .ini file, but since the issue appeared to be what the E300 thought was the secondary device and I knew the streamer was connected and working, I had a look at the back boot DIP switches first. The previous setting was #1 and #3 on, which would attempt a boot from the (non-existent) floppy drive first, and then try the SCSI hard disk. This had always worked before, but we have no floppy drive and I'm not likely to find an AM-219 anytime soon, so I tried the other boot position where it attempts a boot from the streamer first — again, known good electronics — by switching #4 on. And that worked: now it boots reliably. The conversion is complete. So, with the E300 resurrected and finally successfully converted to solid state, let's really push our luck here ... by doing the same with the others! (I should note I excluded the E100s this time around; I haven't found a special task or physical location for them yet.) SI.LIT disk score of 30.9. For this system I bought a ZuluSCSI Wide, which tops out at 34 MB/s read and 15 MB/s write, and which I already use in my Apple Network Servers with a similar NCR 53C825A. .scsi Dispatched SCSI port: SCSI id 15: No device or unable to report SCSI id 14: No device or unable to report SCSI id 13: No device or unable to report SCSI id 12: No device or unable to report SCSI id 11: No device or unable to report SCSI id 10: No device or unable to report SCSI id 9: No device or unable to report SCSI id 8: No device or unable to report SCSI id 7: (reserved) SCSI bus host adaptor SCSI id 6: No device or unable to report SCSI id 5: No device or unable to report SCSI id 4: No device or unable to report SCSI id 3: No device or unable to report SCSI id 2: SCSI-2 (tape) HP C1533A A907 9 SCSI id 1: No device or unable to report SCSI id 0: SCSI-2 (disk) ZULUSCSIHARDDRIVE 2.3WZuluSCSI .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68040 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484)-15 Boot PROM revision: D00 Number of SSDs: 1 Total Memory: 73728 K-bytes Resident Monitor Memory: 4366 K-bytes Computing Index (CX), relative to AM-100: 59.9 48 bit FP Index (4X), relative to AM-100: 58.2 Floating Point Index (FX), relative to AM-100/L: 7.9 Disk Index (DX), relative to ST-506: 51.0 .si dsk0: [...] Disk Index (DX), relative to ST-506: 52.2 . the last Alpha Micro article we booted our AM-1200 desktop system using a BlueSCSI attached to its external 50-pin Centronics-style SASI port, which with some tweaks to the settings file can be made compatible enough for its very old bus. But I'd like to use that device for other things, so we'll put the old ZuluSCSI card — more than fast enough for this thing — inside. To avoid me having to dismantle it every time I want to switch the disk image, I disconnected one of its unused serial ports and threaded a USB cable there. SUB0:. It's as fast as the BlueSCSI was, probably because both devices can easily saturate its slow SASI bus: AMOS 1.4 misdetects its 68010 as a 68000 (AMOS 2.3A detects the CPU correctly), but like the E450, there was no second test bump either. "everything console." I should point out that the E500 has a slightly later version of AMOS than the E300 and E450 and we get a little more explanation with the bus readout: While all three systems support synchronous SCSI, this version of AMOS actually reports it, along with the width (8-bit, because it's only Fast SCSI, not Wide). Now, what about performance? The ST32272N we replaced is a 7200rpm drive while the ST310151N in the E300 was only 5400rpm, thus accounting for the E500's better baseline disk score, and the E500's faster CPU probably explains its slightly higher first-run result of 46.3. But the second run is even more lopsided than what we saw with the E300, a massive 180.7. Since two of the systems were doing it, it was time to dig in a little more. The ZuluSCSI Blaster has a debug mode switch which echoes status and current operation to a connected machine over USB serial at 115200bps, so I hooked up both the E500's serial console and the USB port of the Blaster simultaneously to the MacBook Air to watch what SCSI operations occurred during the benchmark test. very unusual: there wasn't any. In fact, even though the baseline score had sunk down to a dismal 10 or so because of all the debugging data it was emitting, the second run was still a blistering 180.7. This really sounded like operating system caching, but except for the AM-1200 where I wasn't running it to save memory, the other three systems were running the standard disk cache as virtually any performance Alpha Micro would — and allegedly SI.LIT should be unswayed by it. For some reason the E450's cache configuration wasn't locking UFDs (user file directories, i.e., PPNs), but turning that off on the E500 and E300 didn't make a difference, and all three were caching everything else including the MFD (master file directory). However, when I turned off caching altogether at runtime (using the CACHE.LIT tool and disabling with OFF), though the scores got really low, they were now consistent from run to run. Do note our observation isn't enough to fully explain the E450, which also runs the OS disk cache, but didn't have a second run bump. If you disable the cache on the E450, although its overall score declines, it still remains consistent from run to run. One possibility is that the driver for its later SCSI controller just isn't as aggressive. Although the overall issue certainly calls into question how useful SI.LIT is as a disk benchmark, despite being likely the only Alpha Micro benchmark tool you can expect most recent systems to come with, the question then becomes how comparative disk performance on an Alpha Micro should be measured. Was it still fine for me to continue with my usual practice of leaving the cache on and testing immediately after boot? It's probable that there'd be little in the cache by that point, whatever would be there would likely be similar from system to system (assuming the same version of the operating system), and likelier still that whatever was present in the cache wouldn't be very germane to SI.LIT. Under my current knowledge of AMOS I think these numbers are still broadly comparable; I just have to keep in mind that the score on subsequent runs is likely to be bogus. precisely even with our E450 here). The E100 was discontinued shortly afterwards in 2001. SI.LIT CX score of 816 (!) on dual Athlon 2800+ CPUs. Later AM-113 SuperFalcons were just serial ports and a socket for the SSD; the main system was now more than suitable to service them, and Motorola wasn't making any more 5102 CPUs either. The Eagle 800 that same year ran the same technology in miniature, bringing the great experiment to a close with the discontinuation of the last E250 and E450 systems, and today's systems sold by the reformulated Alpha Microsystems LLC use the same x86-based architecture. Over their production lifetime, analysis of known serial numbers suggests around ten thousand 68K Eagles were ultimately sold, and now I've got five of them. Rest in peace, Rod. They're still great machines.

As is typical here in the Floodgap lab, it all started so innocently: rebuilding a flaky Apple Workgroup Server 9150, the odd duck of the Workgroup Server line and older cousin to our beloved Apple Network Server. And then I just had to pimp it out for MkLinux. sui generis IBM AIX-based Apple Network Server, one of our favourite machines here at Floodgap, there were the WGSes, the Workgroup Servers, Apple's well-intentioned but conflictingly received line of Macintosh rebadges hopped up with high-spec options and special server software. While certain users had long repurposed desktop Macs as ad-hoc servers, these computers were the first Apple systems explicitly positioned and sold as such, and the first generation was even advertised with A/UX, Apple's own hybrid System V UNIX implementation. Rebuilding the Green Giant Before we get into that, however, I've previously talked at length about Apple's early 1990s server strategy as it pertained to how the Apple Network Server ended up running IBM AIX, though not much about why CEO John Sculley's Apple embarked on a server line in the first place. Likewise, we've said very little about the parallel evolution of the Workgroup Servers and their relationship to the core Macintosh product line. Let's consider those topics now. As an upstart in the age of microcomputers, Apple never had a history of making big iron, and the emergence of its server line can actually be traced back almost directly to the failed Macintosh Office concept. In January 1985, Apple's infamous "Lemmings" ad led its new hardware and peripherals announcement, including the AppleTalk Personal Network (what we now call LocalTalk) to set up multidrop serial links between computers and networked devices, the new LaserWriter printer, and a revamped Lisa 2/10 with more RAM and hard disk space newly subsumed into the Mac fold as the Macintosh XL. For a not completely eye-watering amount of money, Macintoshes could talk amongst themselves and send jobs to a high-quality shared printer, with network file storage on the XL's 10MB "Widget" hard disk to come shortly and support for suitably equipped PCs to follow. Steve Jobs, then both chairman of the board and veep of the Macintosh division, confidently predicted 10,000 Macintosh Office networks by the end of the year. While the LaserWriter started at $6995 [$21,750 in 2026 dollars], the refreshed Lisa, er, Macintosh XL now started at a surprisingly competitive $3995 [$12,450], some $6000 less. However, the dirty little secret was that the Macintosh XL was only supposed to be a stopgap, a way to both slowly wind down the hardware and also buy time pending the real Macintosh Office centrepiece: Jobs' new leap forward, the "Big Mac." Big Mac had many vague ideas associated with it, though most of them converged on it being a file server or high-end workstation running some sort of Unix, possibly with the Macintosh interface layered on top. As such, being the most powerful machine in the constellation, it couldn't help but be fated for a central role in the new Macintosh Office. Later in design it was also internally known as the "3M" project, because it would generate at least a megapixel display (its most famous surviving mockup even put it in portrait orientation), provide at least a megabyte of memory, and run at least a million instructions per second on the new 68020. Unfortunately for John Sculley, the company grossly underestimated the XL's appeal at its new lower price. What Apple expected to sell in eighteen months sold in three, emptying the parts inventory so rapidly that Sculley was forced to end its availability in April with Big Mac and its software still stuck in development. ("Apple's strategy may have been too good," mused InfoWorld.) Neither could Apple keep up with demand for the LaserWriter, becoming deeply backordered from manufacturing delays and only shipping 2,500 printers by June. Third-party products ended up filling the gaps, including networking hardware from 3Com and the Centram TOPS file sharing suite. Meanwhile, the Apple board, increasingly concerned about Jobs' excesses in his dual role, ordered Sculley to contain him, after which Jobs was cashiered in May and departed in September. Now in practical ruins, even though Apple promised all shipping products would remain available, the Macintosh Office initiative was officially shut down the same month. sensu stricto was so identified with Jobs internally that it became a political liability in the wake of his precipitous exit. For his part, new Mac product manager Jean-Louis Gassée considered it a "toy" and wasted little time officially canning it, instead promoting the Milwaukee project which had been quietly launched without Jobs' knowledge to create the future Macintosh II. Consequently, Apple's image began to suffer with corporate consumers as they lost confidence in the company's suitability for large office deployments. Sculley addressed this perception head-on at the 1986 introduction of the Macintosh Plus, telling attendees, "I know the real commitment from business customers must be earned by meeting customer needs, by living up to expectations and by keeping promises. We intend to do all of that." The legacy of Big Mac nevertheless persisted in the Macintosh II's development, which at one point was even codenamed "Little Big Mac," and AppleShare's tardy arrival in January 1987 finally made a basic server platform possible. At launch AppleShare was targeted at any Macintosh Plus with sufficient external storage, though in initial versions a machine chosen for server duty had to be all but completely dedicated to the task. Introduced in March, the Mac II, compatible with the new AppleShare as well, would subsequently go on to largely achieve the 3M project's aims. System 7's impending development continued in the background, Apple added X11 support as an option in part to address these and other deficiencies in the graphical interface. "Our first goal was to do a solid Unix," argued Michael J. Homer, technical markets director. A/UX 2.0, introduced in 1990 before System 7's rollout, made good on the majority of Apple's promises: most 32-bit clean applications could now run under a new compatibility layer, MultiFinder was supported, and Macintosh, command line and X11 applications were finally able to coexist on one screen. It was exceptionally well-received by reviewers and users alike, with MacUser approvingly calling it "the most interesting and impressive software to have come out of Apple since HyperCard." Subsequently in July 1991, after System 7's May launch, Apple and IBM announced their new partnership around the PowerPC and a future AIX incorporating the Mac Toolbox. In November this idea was broadened into the future A/UX 4.0, with Apple introducing the System 7-based A/UX 3.0 at the same time. (Another, less-well-known alternative also emerged around this period, but we'll talk about that later when we discuss the history of MkLinux.) hardware, and Macs pressed into server duty in those days were otherwise just Macs. One I particularly remember as an undergraduate at the University of California San Diego was an SE/30 (userserve.ucsd.edu) down in the AP&M B337 lab, running AppleShare version something-or-other and an unknown Gopher server that we all accessed for software resources. I was fortunately able to save its contents before it was decommissioned, since it could still be accessed off-campus at the time. As such, Apple management concluded their persistent lack of a turnkey server configuration was harming additional institutional uptake. At Mactivity '92, the Enterprise Services Division (what would become Apple's Server Group) quizzed attendees for desired features; respondents nearly unanimously favoured high-end hardware on a Unix platform. Fortunately, Apple now credibly had one. In March 1993 the company announced the first Macintoshes to officially be called servers: the Workgroup Server 60, Workgroup Server 80 (collectively codenamed "Blugu") and Workgroup Server 95 ("Chinook"). came with A/UX 3.0.1, a requirement of the included high-performance PDS SCSI and L2 cache (128K to 512K) card, plus an optional 200-seat AppleShare Pro license for file and print services (a separate configuration targeted databases, with Oracle 7 specifically mentioned). In fact, when the demo machine reportedly got stolen shortly before Mactivity93, product manager Marv Su had to "make one" out of a Quadra 950 and a spare card to show to attendees. An optional tray could carry up to five internal hard disks, sitting on top of the system's drive shelf. While the AWS 95 could still run System 7, the PDS SCSI/L2 card was only fully supported in A/UX, and blocked one of the five NuBus slots when installed. The other two systems came with a 50-seat AppleShare 4.0 license and System 7.1, and both the AWS 95 and the AWS 80 had optional built-in DDS (DAT) tape backup. The 60 and 80 launched two months after the 95 in June; Apple started the three systems at $3079, $6399 and $7589 [$7150, $14,850 and $17,600] respectively. The most expensive AWS 95 loadout had 48MB of RAM, a 230MB and a 1GB disk drive, DDS-1 tape and 512K of L2 cache, and sold for $12,929 [$30,000]. itself was the operating system. This port was variously codenamed "Wormhole" and/or "Deep Space Nine," borrowing code from the existing IBM AIX port of Portable NetWare — AIX was PowerOpen too, after all — but modified to run via System 7; Wormhole would then run on the new high-end server, codenamed "Green Giant," using the fastest PowerPC 601 then available in a Quadra 950-style case. Novell NetWare was, of course, the premier network operating system of the early 1990s, but many believed it was already on a slow decline, and the overwhelmingly negative reaction Wormhole provoked from testers who still preferred Unix caught the Enterprise Services Division off guard. Spindler remained doggedly convinced NetWare was the way forward, but as it was imperative the PowerPC server reach market with or shortly after the desktop Power Macintosh, at least initially Green Giant would have to be System 7 — any other options could come later. (As we'll discuss.) 2GB drives and 24MB of RAM. You could also get a 9150 logic board to install in a Quadra 900 or Quadra 950 or, for that matter, an AWS 95, and it would fit your physical case if not your use case (if you were using A/UX). The rebuild came when it started getting flaky last year and intermittently crashing, but the RAM tested good and replacing the boot disk didn't make it better. Since these early 601s can run a little warm, I next redid the heat grease with proper modern compound to see if that would help, and it didn't. While my personal experience has been that these systems don't universally have the bad capacitors that '030 Macintoshes and their contemporaries (e.g., the Macintosh Portable) do, others have reported bad caps on their own early Power Macs, so that was the last thing to try. I sent the board off to Garrett Bunge for a professional recap, who reported there might have been a tiny bit of leakage, but either way it came back looking great. We'll come back to the history when we get to our choices of operating system. Let's first get it back together, starting with the bare case. the PowerBook 1400. this post explains how Apple's serial numbers worked at the time). additional 50-pin header at J9 with no markings. This port is yet another holdover from the Quadra 900, the first Macintosh to implement a separate internal SCSI bus, and later duplicated on the Q950 and AWS 95. On these machines the internal SCSI is a separate second bus from the external SCSI, but there are internal headers for both busses so that internal devices can be on either bus. The 9150 still has this feature and thus still has a port in the same place to handle upgrading machine configurations that need it, but it was officially undocumented and its use otherwise discouraged, and any internal devices connected to J9 will be on the slower CURIO. We won't be using it here. some sort of upgrade pathway, either through their CPU slot or (in this case) as a PDS card, with the notorious exception of the Power Macintosh 7200, 8200 and Workgroup Server 7250 for which Sonnet eventually produced a PCI card to carry a G3. with nothing installed at all. In fact, according to Apple's own tech note, the PDS terminator was only ever intended and shipped with the WGS 8150 and 9150, and it cautions these systems will not work without one if the Processor Direct Slot is empty. the musical sting! (These Power Macs do not make a Mac "bong.") I then got out my customized Mac OS 8.6 boot CD — I prefer 8.6 on Macs on beige pre-G3 Macs without an upgrade card — and put it in the optical drive, and got a Happy Mac! But was it stable? Let's burn it in before we go further with this process. Power Mac 6500 has a 1MB cache, I left it there because that machine is intended primarily as a BeOS box and BeOS doesn't support L2 G3 upgrades, whereas we might be able to dual boot with a G3 in this one even if MkLinux won't support it. (Note from the future: this can work.) not to mess around with the NuBus, PDS or cache slots without unplugging the machine, even if the key is turned to off — there's apparently some trickle power even in the fully-off key position. With the plug out I switched (with difficulty) the ROM into the top slot and put one of the 256K cache sticks in the bottom one. For storage, next we'll prep the ZuluSCSI. I got out a new SD card and created three disk images: a 4GB disk image exclusively for Mac OS (as HFS+), a 4GB disk image for MkLinux (as ext2), and a 1GB image to be partitioned into MkLinux swap and an HFS (not HFS+) exchange partition, since the HFS toolkit included with MkLinux only understands original HFS. We'll need this exchange partition for building custom kernels, since the kernel is booted from the Mac OS side. I chose to make smaller individual devices rather than carving up a larger disk into LUNs simply for ease of organization; the SCSI emulator doesn't really care one way or the other, and I can also separately back the image files up. MkLinux, or, Linux at Mach 3 At this point we'll configure the machine to dual-boot MkLinux, so let's talk some more backstory before we do. the NuBus-compatible version has survived. Because of the age of its System file, the 9150 ironically can't boot from this only known build. (Photo credit, Joe Pugliese, Associated Press.) arresting crimson prototype board complete with populated debug header, additional test points and a silkscreened train logo.) All three PowerPC Workgroup Servers now came with 16MB of base RAM plus System 7.5 and AppleShare 4.1, the 6150 and 8150 got smaller speed bumps of their own to 66MHz and 110MHz, and Apple's software RAID remained supported. software strategy was becoming. PowerOpen-A/UX 4-AIX and Taligent-Pink were still shambling around Cupertino development hell, causing Apple in May 1994 to embark upon an alternative stepwise approach in the form of Copland. Meanwhile, despite claims of Cyberpunk's continued progress, at the April 1995 refresh Spindler had little other choice than to double down on then-current Mac OS with the Apple Internet Server Solution. AISS had the distinct stench of a product assembled under duress, nothing more than a cobbled-together bundle of largely pre-existing software shipped with your choice of Workgroup Server, though the software would of course run on any Power Mac. Other than MacDNS, which wasn't even finished when AISS was launched, plus AppleSearch and "player" versions of HyperCard and FileMaker Pro, everything else was third-party: WebSTAR for server software, Bare Bones' BBEdit as an HTML editor, Adobe Acrobat Pro as, uh, Adobe Acrobat, Netscape Navigator and Everywhere Butler SQL. Apple threw in CGI support for AppleSearch and templates for web pages to be customized. AISS' spec sheet promised even the wimpiest 6150 could handle 3,000 to 5,000 connections per hour (how cute!) and more still was possible by using MacDNS for round-robin load balancing against multiple redundant Workgroup Servers. However, there was one Workgroup Server that couldn't run AISS: the AWS 95. Even as Shiner was supposed to be Apple's next big Unix box, the company seemed to outright repudiate its previous Unix efforts, explicitly claiming that "you don't need to be a Unix nerd" to use a Mac server. The AWS 95 was quietly cancelled in October 1995 at nearly the same time as the collapse of Cyberpunk, marking the end of Apple's inexplicable flirtation with NetWare. With the recognition that A/UX 4 might never ship, Shiner was retrofitted to run standard AIX 4.1 with Apple's extensions, yielding our beloved Apple Network Server in January 1996. Unfortunately for Spindler, Apple's finances were thoroughly in the weeds by then, and his announcement of further staff and model cuts was too much for shareholders who hastily replaced him with Gil Amelio in February. However, the Network Server, defiantly no Macintosh, turned out to be not the only Unixy thing at Apple then either. In 1989 Apple bought out Coral Software in Cambridge, MA (not Corel), developer of Allegro Common Lisp for the Mac, as part of an initiative for new programming paradigms on the Macintosh but also the Newton PDA. The deal involved Coral's team joining Apple's Advanced Technology Group at a new ATG lab to be established there, and Ike Nassi, a veteran engineer and scientist at DEC and part of the initial team at Encore Computer Corporation, was recruited to Apple by then-Newton chief Larry Tesler to run it. Initially Nassi managed the Dylan programming language (at the time written in Macintosh Common Lisp and originally intended for, but never used by, the Newton) and Sculley's Knowledge Navigator passion project before Apple software VP Dave Nagel asked him to move west in 1993 to assist with the software division. Nassi started as VP of development tools, his portfolio notably containing MacApp and the Macintosh Programmers' Workshop, but less than a year later was asked to take over the operating system group. As the PowerPC transition progressed, Nassi became concerned by efforts to build the Common Hardware Reference Platform, believing it would stunt the growth of the Power Macintosh, and positively alarmed by the growing debacle around Copland's infamous NuKernel core, which he said later to the Computer History Museum "was just not going to fly." pairs of National Semiconductor NS32032-family processors. (At my first job out of college, the HP 9000-K250 I was hired to work on had recently replaced what I think was a Multimax.) In fact, Apple already had experience with the Mach microkernel in the form of MacMach, a 1991 CMU research prototoype which ran 68K System 7 as a virtualized task under Mach parallel with its 4.3BSD-derived operating system core — not unlike Classic under Mac OS X many years later, and not to be confused with MachTen, a separate commercial effort from Tenon Intersystems developed independently from CMU or Apple, which runs Mach as a task under Mac OS. MacMach was the product of a joint effort to allow programs from CMU's Andrew Project distributed environment to run directly on the Macintosh II, and Apple provided both financial support and source code from System 7 to aid in development. Notwithstanding the impressive technology, however, MacMach's potential was unavoidably limited. Its reliance on the 4.3BSD codebase incurred the strict requirement that users hold a valid AT&T Unix source code license, all but ensuring it could never be a plausible alternative, let alone threat, to A/UX; and like A/UX, it was never directly ported to PowerPC, condemning it to obsolescence. In the time since, Nagel had moved to VP of engineering; Nassi, who succeeded him as head of the software division, convinced Nagel in August 1995 that resurrecting the concept might pay off. The idea was controversial within Apple, especially with Macintosh division head Howard Lee, who believed it would maroon the Macintosh if IBM considered Mach's highly portable nature as evidence Apple wasn't committed to PowerPC. Lee's fear was not without reason: Spindler previously had to cancel the System 7 port to Intel (i.e., the Star Trek project, instigated by Novell) as a potential threat to the alliance, and of course Project Marklar much later directly led to Apple indeed leaving PowerPC in 2006. Becaue of the internal political ramifications, the PowerPC Mach group initially had few staff resources and operated in near-secrecy for many months. Brett Halle, then manager of the kernel team, suggested to Nassi that a Linux port, modifying the Linux kernel to run as a task under Mach, could demonstrate the microkernel's viability. It even had an obvious name: MkLinux. With Nassi's blessing, Halle quietly sponsored a small team from the Open Software Foundation's Grenoble, France office to begin both the Mach port work and the Linux kernel conversion to run under it. OSF had extensive experience with Mach dating back to their 1989 use of Mach 2.5 as the basis of OSF/1 ("osfmk," intended also as part of the foundation of A/UX 4.0) but this team operated separately, later with a single part-time Apple engineer. The host machines used for initial development were both x86 PCs running regular Linux and HP 9000/700 PA-RISC workstations with OSF/1, with the x86 hosts migrated to an MkLinux port of their own as a self-hosting alpha test. PowerPC objects were cross-compiled using gcc 2.7.1, with cross-platform debugging with gdb over a serial port. For simplicity of development, the Linux task ran under OSF MK as a single monolithic server, though the developers admitted this wouldn't be an ideal system design for a Mach-based platform. The group's rapid progress impressed Nassi, and shortly before the first Developer Release in May 1996 he made the effort official as Apple's "Leveraged Technologies Group." Using the new kernels with tools and pieces previously ported by Thomas and others on top of a modified Red Hat distro, MkLinux DR1 CDs were finished, pressed and handed out, complete with source code, to WWDC attendees that year. The LTG represented Apple's first official attempt to support an open-source software project, and within six months had increased to seven members, five at Apple and two at OSF. An important consequence of its isolated development, however, was its limited hardware support. Apple had since moved from NuBus to PCI with the introduction of the Power Macintosh 9500 in June 1995, and the Workgroup Server line subsequently followed suit. In February 1996 Apple introduced the Workgroup Server 7250 (derived from the Power Macintosh 7200), using the same 120MHz 601+ as the 9150/120, and the first Workgroup Server to use a 604, the 132MHz Workgroup Server 8550 (from the Power Macintosh 8500), along with an updated AISS 2.0 — at which point the 6150, 8150 and 9150 were all discontinued, though the new AISS would still run on them. But, because the LTG had only developed on NuBus Macs, DR1 only officially ran on the 6100, 7100, and 8100 (plus Power Computing's clone Power 100 family), all of which had also been discontinued by the time DR1 emerged. Not even the NuBus PowerPC Workgroup Servers officially appeared in the support list, though of course it would run on them too. As the distribution files were large downloads for the era, partner Prime Time Freeware produced pressed CD-ROMs for a nominal cost. replaced by DR2 in September 1996, primarily a bug-fix and performance release, which in turn was used to supplement an early direct port of the Linux kernel (then called linux-pmac) to PCI Power Macs. For his part, Nassi was pleased with MkLinux's promising launch. However, without a compatibility pathway it could not be an obvious successor to Mac OS, and while Nassi had plans for running the Mac OS under this "PowerPC MacMach" as 68K MacMach did, that goal was never achieved. Nassi quietly disagreed with Gil Amelio's pursuit of Jean-Louis Gassée's BeOS, believing Mach to be the superior platform, and left Apple in November 1996 before Apple's acquisition of Steve Jobs' NeXT — itself of course powered by a Mach-based OS, as is its descendant, modern macOS. MkLinux nevertheless progressed further at Apple after his departure. DR2.1 was announced in March 1997 as the first release to itself run on both NuBus and PCI systems, supporting the 601 and 604 CPUs in the Power Macintosh 6100, 7100, 8100 and 7200, 7500, 7600, 8200, 8500, and 9500. Prime Time duly released CDs of these as well and Apple dubbed 2.1 the "Reference Release," sponsoring Prime Time and editor Rich Morin to release a book-and-CD kit with the tree from January 1997, just before the official announcement. The x86 and PA-RISC ports were also made available (since they already existed), though of course OSF MK could run on many more architectures than that. On the other hand, the Apple Network Server, at the time Apple's only true-Unix machines, never ran it. Cyberdog and OpenDoc and terminate further development of the Network Server, and MkLinux was just as vulnerable because in Jobs' mind it had already achieved its maximal corporate utility: OSF and the LTG had done most of the work porting the microkernel, and with NeXTSTEP's ready BSD foundation Apple had no further need of Linux. Apple disbanded the LTG and transferred control to the community MkLinux Developers Association in 1998 for the release of DR3 in July, by which point MkLinux could run on nearly every four-digit Power Macintosh (now explicitly including the Workgroup Servers) and even early beige G3 models, plus the PowerBook 3400 and the Kanga PowerBook G3. (Apple had since abandoned the 620, which had become hot, expensive, and increasingly surpassed by the cheaper 604 family. Notably, although the 750/G3 completely outclassed it as well, the G3 did so with some features introduced in the 620 like backside L2 cache.) In those days the website was reportedly even hosted on an 80MHz 7100 for some period of time, and allegedly other PowerBooks like the 5300 could boot it also. Mac-specific device support lagged, however, and the project's lack of resources combined with the continual need for Mach-specific changes to the Linux kernel slowed progress further during Apple's transition to the New World Mac. R1 was released in December 1999 and the final release, "pre-R2" (but basically R2 and that's what I'm going to call it), was closed out in August 2002. Although the MkLinux website remains up and accessible today, no new official work on it was subsequently done, and the direct LinuxPPC port replaced it as the de facto Linux basis for Power Macintoshes and the Network Server. Given that complicated tale you might well wonder why we're even bothering with MkLinux at all, especially since non-Mach Linux also eventually supported NuBus Power Macs, including the 9150. The reason is simply historicity: it was the only official "Apple Linux," the only Linux distribution Apple had a direct hand in developing, the only Unixy thing of any kind Apple even vaguely supported on any PowerPC Workgroup Server, and for years was the only Linux that could run on the NuBus ones. With the weight of that behind it and me being a history nerd first and foremost, I never considered running anything else. Before Brinton's freakout and rebuild, I had MkLinux "pre-R2" on it, so now that we're starting fresh we'll hopefully learn from those mistakes I made the first time (at least, if I can remember them). /home and one for everything else in /. Since we want to do this precisely, we'll click Custom. from the Internet Archive or a Garden of other Macintosh sites. The R2RC5 CD also contains components for the contemporary release of LinuxPPC, but it doesn't run on the 9150, so we will not discuss it further in this article. MkLinux-install folder are multiple pieces to copy to your main Mac OS volume's system folder (to the Control Panels, Extensions and Preferences folders). A booter extension (named, oddly enough, MkLinux Booter) is used to launch the Mach kernel portion before the rest of Mac OS loads. This kernel is stored on the Mac filesystem, not the Linux one. The MkLinux control panel is used to pick the boot default, either Linux or Mac OS. The MkLinux Booter extension understands LILO configuration files and one is provided. Open lilo.conf from your Preferences folder after you've copied it. Alternatively, you can click the Custom... button in the MkLinux CDEV. rootdev=/dev/scd0 line is uncommented, and no other rootdev= lines are specified. If you have multiple possible CD-ROM drives or emulated CDs available, you may need to change this number. The other important part of this file is the mach_options= line, down at the bottom. These are the command line arguments passed to Mach. Despite the -v option shown there prominently, which would be expected to trigger a verbose boot, pretty much any boot is verbose in MkLinux. We'll have another use for this field when we get to our upgrades. scri (technically a WorldScript extension, but otherwise loadable as a "regular" extension), not INIT, which causes it to load before other INITs and CDEVs without resorting to trickery like putting a whole lot of spaces before the name. BootX uses the same method. The window here is as close to an About box as you'll get for MkLinux. The staff list appears to date from just before the disbanding of the LTG: from Apple, Brett Halle, Michael Burg, Vicki Brown, Gilbert Coville and Eryk Vershen, and from OSF Research Institute, Nick Stephen, F. Barbou des Places, Éamonn McManus and Gary Thomas. Notice that in this screen booting MkLinux is the default. The default choice is set in the MkLinux control panel. Regardless of what the default actually is, press RETURN to accept it, and ESC to accept the other option. COLOR line when specifying the video console, and compare it with this: COLOR line appears, with the same colours in the same order, and almost certainly descends from the same block of code. Apple implied as much in the December 2000 Kernel Environment documentation, saying, "Other parts of the system software, such as Mach, are based on technology previously used in Apple’s MkLinux project, in Mac OS X Server, and in technology acquired from NeXT." This particular message disappeared in 10.3 as there was no need to specifically call out the console as colour by then. default_pager), the virtual memory manager, is started next. The bootstrap loads the Linux kernel as the next task, which should start from its initrd and finally enter the installer. Unfortunately, at this point we got no more messages from the MkLinux Mach kernel and the 9150 completely ground to a halt. A brief moment of panic ensued because MkLinux used to work. Was the machine shot after all? After I got the conniption out of my system, I thought a little more carefully and realized that this new 9150 configuration was not the same as the old 9150 configuration: we have a ZuluSCSI, and we have approximately double the RAM. I could believe the ZuluSCSI was at fault if we were booting from it, but we were booting from the same CD-ROM I installed MkLinux from before, so that possibility seemed unlikely. That left pulling out half the RAM SIMMs. can do that much without having to disassemble the machine again to get the power supply out. It's putting the SIMMs back in that's the fun part, but right now we just have to make sure this can work. larger fifth free region. gcc 2.95.2 (I don't know where the line noise came from there, and I don't know why it says "hello"). The initrd then transfers control to the Red Hat installer, without using systemd, which we shall consider a feature. I ignored them, anyway. mac-us-std suffices. second volume on /dev/sdb. The two 2GB partitions we created are /dev/sdb3 and /dev/sdb4, which the MkLinux installer has treated as "Linux native." We move to /dev/sdb3 and select Edit. /dev/sdb3 will be /, so we provide that path and select OK. /dev/sdb4 will be /home. / and /home formatted, but we needn't check for bad blocks on them either, and select OK once again. / and /home are created, the packages are scanned ... glibc provided is 2.1.3. dreadfully slow, and the weak onboard video does it absolutely no favours. I recall finding AfterStep (ah, the irony), also included, more tolerable. Admittedly, Apple didn't really intend the 9150 to be a workstation and as such we're not going to struggle with it this time around, but we may possibly do so in a future article. brinton.floodgap.com. lilo.conf in the Mac side's Preferences folder to now point to the new root on /dev/sdb3. I have never tried this with an HFS file system, but it cannot mount (let alone write to) an HFS+ file system, so we'll need to do that on the 8.6 side afterwards. lilo.conf as instructed (from Preferences, or by clicking Custom...), and then restart the Mac. fsck since for some reason the installer did not cleanly unmount the root filesystem. Apple's Linux, after all, even though it was recently removed from the modern Linux kernel — and SMB services. If you had period clients, this could definitely have been your file server, and that would have been an absolutely appropriate purpose for the 9150. brinton:/home/spectre/% uname -a Linux brinton.floodgap.com 2.0.38-osfmach3 GENERIC_09 #9 Tue Mar 7 10:51:13 PST 2000 ppc unknown brinton:/home/spectre/% gcc -v Reading specs from /usr/lib/gcc-lib/ppc-yellowdog-linux/2.95.4/specs gcc version 2.95.4 20010319 (prerelease/franzo/20011204) brinton:/home/spectre/% ls -l /mach_servers total 3615 -rwxr-xr-x 1 root root 1349896 Jan 7 2001 Mach_Kernel -rw-r--r-- 1 root root 119033 Jan 7 2001 Mach_Kernel.map -rwxr-xr-x 1 root root 131314 Apr 19 2000 System.map -r--r--r-- 1 root root 123 Feb 22 1998 bootstrap.conf -rwxr-xr-x 1 root root 205690 Jan 7 2001 default_pager -r-xr-xr-x 1 root root 257371 Feb 22 1998 mach_init -rwxr-xr-x 1 root root 1614475 Apr 19 2000 vmlinux Sing it with me: Startup, shutdown, startup, shutdown, swiftly fly the rc files ...) Pimp My Green Giant Ride We have now returned to the functionality of our prior configuration: we can dual-boot MacOS and Linux. However, with motherboard video, the baseline CPU, half its maximum RAM, and half the L2 cache it originally shipped with, right now it's not a particularly strong performer in either operating system. Of course, the set of what upgrades are supported in Mac OS 8.6 is rather larger than the set of what upgrades are supported in MkLinux R2. For example, while G3 upgrades are available for the PDS connector in NuBus Power Macs and generally work well in Mac OS, most of them don't work in MkLinux, and MkLinux doesn't support NuBus video cards either. There is also the matter of that 128MB of RAM we had to remove that we would like back. Ideally, with these plastics continuing to crumble, we would like to find a maximal configuration suitable for both operating systems that can be changed through software as needed, rather than having to keep opening it up. MkLinux FAQ-O-Matic has somewhat conflicting information about which CPU upgrade cards work where and how, though the various reports do seem to agree that Sonnet cards won't work at all. On the other hand, while one reporter indicated success with a Newer Technology MAXpowr G3, I'm not entirely confident in his recollection because despite being a PDS card he said it displaced the L2 cache. The MAXpowr G3 PDS also lists the 6150 and 8150 but not the 9150 as compatible, even though the PDS connectors are the same; there may be a form factor limitation. But the 9150 is specifically listed as compatible for the Sonnet G3, and Sonnets are much more common. As long as the Sonnet extension loads after the MkLinux Booter extension, the upgrade card should remain inactive, and MkLinux can run unmolested on the 601 (we can leave the L2 cache stick in, even). For the Mac OS, we can use the G3 there. As it happens, I have a couple spare G3 cards in the stock closet and this seems like the perfect time to put one in service. the Power Mac car crash sound (further yelling censored). After unplugging it, pulling the G3 completely and putting the PDS terminator back in, I got the normal startup chime and a normal boot, so I put the G3 back in. This time it booted as well. (It also appears that the PDS terminator is not needed in this card; it seems to terminate the bus just fine by itself.) actual system bus is not doubled, which is to say that any bus access these CPUs make could stall depending on whether it corresponds to the real bus clock. These cards therefore must have a crapload of cache to smooth such gaps out, and indeed both of these fastest cards have a full 1MB of backside L2. The backside cache bus runs at double the system bus speed, but the cache is on the doubled "local" bus, so the cache speed is effectively 4x the system bus. The 9150/80 here is a 40MHz bus system, meaning the G3 card's local bus runs at 80MHz, the backside cache at 160MHz, and the CPU at a 5x multiplier for the full 400MHz. Even if I hunted down a 500MHz G3, and while I'm crazy I'm not made of money here, I would only see 480MHz on this system (6x multiplier). Sonnet's Metronome faithfully reports all these numbers, but Apple System Profiler doesn't know about the doubled "local" bus, so it erroneously thinks the CPU is only 200MHz. scri, then inserting spaces and/or changing its filename to sort above it. INIT to load it later. That way we can continue to boot MkLinux normally on the 601 (with the motherboard L2 cache, which we never removed), yet still enjoy the benefits of the G3 — and it is much snappier — in Mac OS 8.6. an -m option that caps the amount of RAM Mach will use. You pass it on the mach_options= line in lilo.conf, e.g., mach_options=-m136. To test this, we'll need to install the full 264MB. With some difficulty you can worm the SIMMs back in without removing the power supply. However, that also knocked the board back into the interrupt and reset switches again, and the second time around was not much more reassuring. Too much memory was apparently a significant problem in some configurations of MkLinux, and values that work for booting the installer for testing purposes may not necessarily work for an installation (for example, I tried -m200, and while this worked for the installer it could not start the kernel installed on the ZuluSCSI image). A cursory look at the Mach kernel source suggests that there is a hard upper limit on the number of VM hash buckets and when this overflows, the kernel goes into never-never land. -m191 seemed to be the highest value that would work either way, but I left it at -m136 since that was the RAM amount that we started with and that I knew was reliable. I was now pretty thoroughly irked by the problem with the front switches and decided I needed to do something about that. carefully at low speed. mostly stable. will use the Velcro straps to neaten everything up. I put the SCSI cable's excess length into the bottom compartment of the hard disk tray. much they wouldn't work. In my parts bin is a Radius PrecisionColor Pro 24XK. The reason I marked the name on it is that the 24X, 24XK and 24XP are closely related and can be hard to distinguish visually. From my experience the highest-end 24X has all 12 RAM chips along the top instead of the 11-1 arrangement here on the 24XK and 24XP. Another difference appears to be the speed of the Brooktree Bt473 RAMDAC, which is the silkscreened number at the end of the chip identifier (the 24X is 110MHz, this 24XK is 80MHz and the 24XP is 66MHz). Kan's page claims it does, so I just have to push it. This card has both composite video in and out as well as a conventional Mac DA-15 video port. Although the card is slower than the HPV card, it has 2MB of VRAM and correspondingly more colour depth and resolutions, so it's worth giving a shot. as directed and installed it that direction in the middle NuBus slot. It still needed some squeezing to make it and may have nailed the frame around the NuBus slots, but it fits. a future article and see if any hacks in the kernel are possible to improve the situation. If not, at least we'll have fun exploring the infrastructure. The Workgroup Servers did not survive the axe of Jobs either: after the 7250 and 8250, the last Macintosh systems to bear the Workgroup Server name were the Workgroup Server 7350 and Workgroup Server 9650 in April 1997, which were cancelled less than a year later in March 1998. With the introduction of the beige G3, the "Workgroup Server" brand was retired for the "Macintosh Server G3," which encompassed both the beige mini-tower in March 1998 and later the "Yosemite" Blue and White G3 in January 1999. Apple did not reintroduce bespoke server hardware to their product line until the rackmount Xserve G4 in 2002, which survived in G5 and Intel-based incarnations until 2011 when they were cancelled — per Jobs — "because hardly anyone was buying them"; a 2009 server version of the Intel Mac mini, in some ways a spiritual descendant of the Workgroup Servers, was itself cancelled in 2014. Even though there are still lots of Macs in offices, to date no official server hardware has ever returned to Apple's product line-up since.

Reports coming in of the death of John C. Dvorak, apparently passed away on Monday (July 20th) from complications of heart bypass surgery. Dvorak started in wine and moved to silicon as an early columnist at InfoWorld, one of the pillar references for this particular blog because of its studious regular reporting, and most notably for PC Magazine where he had no less than two columns since at least 1986. In addition to this and other tech journalism credits, he was on the flagship CNET Central cable TV program in the mid 1990's with his "Buy It, Try It, Skip It" reviews, plus other shows hosted on NPR and then-ZDTV. He was also a regular guest on Leo LaPorte's syndicated radio program and podcasts, and joined former MTV veejay Adam Curry (well known to us in Gopherspace for MTV Networks v. Curry, and an early user of TTYtter before Twitter started to suck) in 2007 as co-host of the No Agenda podcast, a role he maintained until his death. Dvorak hailed from a different generation of tech journalists, far more personal and yet far more technical, and even his detractors (given his political views, which we won't talk about here, there are many) would admit he was at least entertaining. He was 80. Rest in peace.

Some of our recent (and some upcoming) projects are oriented to systems with serial consoles, but it's been getting pretty old dragging around old CRT terminals or tying up Mac laptops with a serial port. I'd like something that's self-contained, a little more portable and a bit less heavy. I'm sure there's any number of all-in-one setups you can buy to do this, but I'm cheap, so I'm going to DIY it. from 2004 to 2014, so it's almost on-topic for this blog, even. I chose it because it was a little banged up and the LCD had some areas of damage (probably improperly closed on something), and the seller had priced it accordingly, but the screen was still sufficiently legible and the keyboard looked fine. Naturally you can do mostly what we're doing here with any of the similar Dell or HP or etc. units that can also be easily found. an UltraNav, the fact it gives you a choice of pointing device is rather nice: if you like TrackPoints (I don't hate them), you can use that, or if you prefer trackpads (I don't hate them either but I'd rather use the TrackPoint), you can use that. The keyboard and UltraNav are implemented as HIDs on a single hub which also offers two more USB ports. fine." Like I say, there was some damage, probably because it got closed improperly on something and messed up the display, but it's sufficient as a simple terminal or here connected to the M1 MacBook Air with a USB-C dongle. you need to do is pick what is the most convenient for you and has the right features. There are slightly more such devices which use a PS/2 port, but I decided to stick with USB since it would be more flexible and if I really needed something else, I could use an active converter like a ps2x2pico for PS/2 or a Wombat for Macs with ADB. I eventually selected this one from Tattler Solutions (not affiliated) because it ships from the United States (damn you UPS, you still owe me $600 on that tariff you stiffed me on), comes in a nice self-contained case and can be USB-powered, runs up to 115200bps, and has demonstrably good VT100 terminal support. All up it cost me $86 shipped. However, it also has a big drawback: its USB controller does not support combo devices like our IBM keyboard, which he does warn you about, and believe me, I tried really hard to get that to work because I really like the keyboard. Unfortunately, it truly is (and in fairness, as described) a fundamental hardware limitation that can't be programmed around, so that means we can't use our nice UltraNav. days. The first time I tried it, I tested it out after 24 hours as suggested and while the excess silane glue exposed directly to air had cured, the silane between the metal had only partially done so and the whole thing peeled right off. The second time I let it sit for a week. That seemed stable. Raptor Blackbird, using a VGA-to-HDMI dongle on the Blackbird side. Folded up more flat this time, ready for the next project. A latch and a handle would also help to make this more portable, though I suspect some drilling may be required for that. I'll look at some options. For now, this suffices.