MacOS Extensions Pack for the Apple Network Server v1.0

Background and ROMs

The ANS was strongly based on the Power Macintosh 9500 and Apple was known to have demonstrated the ANS with Mac OS during development, but this confused potential buyers, causing the ability to boot Mac OS to be stripped from production systems.

While then-CTO Ellen Hancock claimed in 1997 a ROM swap would enable the ANS to boot Mac OS again and Windows NT, these ROMs were believed to be vapourware until a former Apple employee presented a working dump of both the preproduction ROM and the later ANS Mac OS ROM.

A prototype Windows NT ROM also emerged from another former employee, though there are pieces missing and booting Windows NT natively on the ANS is still a work in progress (hopefully to be the subject of a future article).

It turned out I had one of the preproduction ROMs myself and didn't realize what it was. Because the later Mac OS ROM was apparently unfinished, it doesn't properly support the L2 cache and consequently runs substantially slower, and it can't boot AIX.

The preproduction ROM does boot both operating systems and does support the cache. On the other hand, it doesn't support the on-board video or the front Fast Wide SCSI-2 controller, the on-board MACE Ethernet doesn't work, and after MacOS first boots, the next restart without zapping the PRAM will come up with a black screen.

The good news is, many of the issues with the preproduction ROM in Mac OS can be fixed or worked around in software. So I've fixed or worked around many of them in software: the MACE Ethernet is fixed, the on-board video is now supported, and the ANS can restart properly back into Mac OS.

Plus, because it's the preproduction ROM, you can still boot AIX, thus preserving the entire historical reason for Shiner's existence. Here's the first cut of that software and how it was developed.

Getting the Hardware

Naturally, the first order of business is to get an Apple Network Server and the 1.1.20.1 preproduction ROM (the production ROM is version 1.1.22).

I can't help you with the first part, but replica ROMs now exist to cover the second part, and as of this writing Joe's Computer Museum has a few in stock (not affiliated, just a satisfied occasional customer).

I tested the original design of these ROM DIMMs, kindly provided by Jeff Walther. Jeff assembled and donated this particular batch to Joe Strosnider, who is selling them and donating the proceeds in turn to the maintenance of the Tinker Different forum, where this whole thing started.

Now that you have the basic hardware, you'll then need to install Mac OS to an external bootable SCSI volume. For this project I use a 25-pin BlueSCSI which connects directly to the ANS' rear SCSI port and runs on termination power.

Set up a blank disk image of the desired size to the device's (micro)SD card and rename it to the desired SCSI ID, which for the ANS is typically SCSI ID 2.

If you have another Mac with a SCSI port handy, it's easiest to do the MacOS installation to the external volume with that system. Make sure it installs Mac OS for any supported Mac, especially if you are using a model-specific installer CD; up to Mac OS 9.1 inclusive will boot directly on the ANS, and 9.1 is what I'm using here.

7.6 will work and late versions of System 7.5 might work, but I recommend at least 8.1 or later.

If you only have the ANS and/or have no other suitable vintage Mac that can perform the installation, you can do it on the ANS itself with a bit more difficulty. For that you'll need to not only create the blank disk image but additionally include an ISO of a bootable MacOS CD (use ID 0), plus install a Power Mac-compatible PCI video card - I use a Twin Turbo 128MA but any ATI Mac-specific card of the era should also work, such as the Rage Orion.

Finally, unplug the server, unlock and pull open the mainboard drawer, remove the PRAM battery, install the preproduction ROM DIMM, and leave the drawer open and the system completely depowered for at least several minutes while you enjoy the droll prose of this blog post.

Here's the back of my testing ANS 700. The monitor is connected to the 700's video port, the BlueSCSI is plugged into the SCSI connector, and a Farallon standard AAUI-to-twisted pair dongle is attached to the on-board MACE Ethernet AAUI port (Apple's perverse little rework of AUI to avoid confusion with the Mac DA-15 video port).

Technically that should be all you need to run Mac OS or AIX. However, I also have the Twin Turbo video card in slot 1 (where it would usually be in a 9500, the closest hardware relative to the ANS), and as an alternative for the MACE Ethernet I have one of the unobtainium 10Mbit ANS Ethernet PCI cards in slot 6 that I ordered from Apple Austin when they were blowing out leftover Shiner hardware.

This card works in AIX and later versions of Mac OS (not 7.6, possibly 8, definitely 9); my only 100Mbit ANS Ethernet card is in the 500. A regular Power Mac-compatible Ethernet PCI card will suffice if all you want to do is run Mac OS.

Drivers and PCI Devices on Power Macs

Denizens of the classic Mac OS are painfully familiar with INITs and CDEVs, which is to say, the extensions and control panels which extend the operating system (and in many cases constitute substantial parts of it).

Adding device support to the operating system required a DRVR resource, which could be stored in:

• the declaration ROM of a NuBus card and available at power-on, or
• in an INIT or CDEV and made available during the boot process, or
• in a regular application and loaded on demand.

(Parenthetically, desk accessories were also implemented as DRVRs.)

Even after the 1994 transition to PowerPC, some, if not all, of such code still had to be 68K for backwards compatibility, and thus required emulation on a Power Macintosh.

Copland and Native Drivers

Since this requirement was an obvious performance bottleneck, Apple attempted to address it in Copland, Apple's fallback attempt to modernise the Mac OS stepwise amid the slow-motion death marches of Taligent and PowerOpen-A/UX 4.

Copland's tale of woe is a much longer story, to be the topic of a future article, but the part relevant to this piece was the new driver architecture it introduced. This aspect was part of how Copland's design partitioned its components in memory to avoid the attendant pitfalls inherent in the classic Mac OS.

In order to wall the old Mac OS world off but retain compatibility, everything that was 68K code lived in the so-called "cooperative" address space and was treated as data to be interpreted by the Power Mac 68K emulator, including 68K portions of the Toolbox; even PowerPC-native System 7 applications ran here.

This cooperative address space would theoretically allow most applications to run as they did before, but intentionally without privileges to the rest of the system nor access to Copland's hardware abstraction layer (HAL). As such, Copland drivers necessarily were fully native code, in this case implemented as regular PowerPC code fragments.

These drivers hooked into the HAL and the Name Registry, an object database that tracked devices on the system and mediated loading and unloading device drivers as needed, and were collapsed into a separate global region at a lower execution level where only limited operating system functionality was available.

Although such limitations restricted their ability to integrate with the operating system, it also enabled those drivers to run early in the boot process and remain protected from user code. This new class of driver was called a native driver.

Although Copland suffered from terminal second-system effect just as badly as its contemporaries, it was modular enough for parts of it to be used as transitional enhancements - such as its visual language, which later became the basis of Mac OS 8's Platinum theme, and other pieces that shipped more quietly.

Germane to our discussion here was Apple's transition from NuBus to PCI, one not uniformly well-received by users, though in fairness it was effectively forced on Apple when IBM wouldn't support NuBus in the PowerOpen-based AIX 4. For these first PCI Power Macs, starting with the 9500 in 1995, Apple added a port of the Copland Name Registry to their ROMs as well as Eric Traut's faster dynamic recompiling 68K emulator, also intended for Copland.

How PCI Power Macs Boot

In this scheme the system ROM initializes the hardware and hands control to its onboard copy of Open Firmware, which creates the device tree for all devices on the system, necessarily including PCI cards but also processor and logic board resources.

The Code Fragment Manager, also in the Power Mac ROM, then runs code from any PCI card expansion ROMs and drivers in the Mac ROM itself. This code typically contains a low-level "expert" that creates a node in the Name Registry with sufficient information to identify the device and enable a driver to match against it.

Once the Name Registry is built out, the Mac ROM starts the Display Manager, SCSI Manager and/or ATA Manager, as needed, as part of booting the Mac OS kernel. These Managers in PCI Power Macs implement a different type of "expert" called a family expert.

When the MacOS File Manager and Resource Manager are up, the Extensions folder is scanned for native drivers (stored as code fragments with a Type of ndrv, but otherwise the same general structure as their Copland antecessors) and handed to the expert of each particular service category for device classes the family expert supervises.

Eligible and matching ndrvs, be they in ROM or on disk, are loaded before any other extension is ever invoked, and the family expert activates and wires them into the operating system.

Apple produced a driver development kit for PCI card vendors that included various debugging tools. This is the Display Name Registry browser from the PCI DDK 3.0, which I got off one of my Apple Developer CDs (there are other tools that do this like @joevt's, whose assistance with certain parts of this project is gratefully acknowledged), showing defined nodes on the ANS 700 booted into Mac OS 9.1 using the 1.1.20.1 pre-production ROM.

The Name Registry on the ANS

The most important thing to notice here is that even though the Name Registry was first added to PCI Power Macs, there are many more nodes here than merely PCI cards, as there would have been in Copland.

Both our PCI cards indeed do appear, connected to one of the Bandit PCI controllers (the ANS has two but mapped differently than the 9500, and there is reserved address space for up to four). However, so do things like the CPU, L2 cache, Mac ROM, and devices attached to Grand Central, which acts as a bridge between PCI and traditional Mac devices like the AWACS sound chip (Crystal CS4217 codec), Grand Central's internal SWIM III floppy controller, and the AMD AM79C950KC "Super Combo" CURIO, containing the equivalent of an NCR 53C96 SCSI controller (for the external port), an AMD 85C30 serial chip and an AMD 79C940 Media Access Controller (MACE) for the on-board Ethernet.

There are also various nodes that don't correspond to any physical device, such as the ROM software components making up the AIX booter and XCOFF executable loader.

The Display Name Registry browser is interactive and you can drill down into the tree to show a node's properties. I've chosen these two on purpose because they're unique to the Apple Network Server: one of the two NCR 53C825 Fast'n'Wide SCSI-2 controllers, and the Cirrus Logic 54M30 video chip, better known to PC users as the STB Horizon+.

These devices are both internally connected via PCI to the first Bandit. Drivers can match on their mandatory name property, which is its primary identifier (53c825 and 54m30 respectively), or the optional compatible property generated from the vendor and device IDs.

The Extensions Pack Components

This first version has three components:

• two for the Extensions folder, the ANS MACE Fixer, an INIT which patches the Ethernet configuration, and the ANS Video Enabler, an ndrv which allows the 54M30 internal video to be used in 8-bit mode;
• and for the Startup Items folder, the ANS Startup Fixer, a regular application which rewrites NVRAM to remove inappropriate settings placed there on every boot by the operating system.

Extracting the Video Driver

The initial piece I put together was the video driver, which is in fact ripped directly out of the 2.0 ANS Mac OS ROM.

Hex Fiend has a rich and extensible Tcl-based template system, including the ability to parse many classic Apple binary formats like resource forks and PEF. Eric Harmon's ROM Fiend extension builds on this by allowing you to parse components of classic Mac ROMs, here a dumped ANS Mac OS ROM provided by our former Apple employee.

ROM Fiend splits the ROM into the declaration component and the system ROM ... ... and then allows you to walk the resources within it. This is the video driver embedded in that ROM. Notice the name of the resource is 53m30, which was almost certainly an error.

The actual driver itself is the data portion. The magic sequence Joy!peffpwpc heralds a Preferred Executable Format binary (specifically these three FourCCs indicate an Apple-specific container, that the container is a PEF, and that the architecture is PowerPC) with code fragments.

We clip out starting from there ... ... to the end of the data portion and the beginning of the next resource, and emit that section to disk as a separate binary.

All such drivers have a description block, usually heralded by the FourCC mtej (this code seems like it was based on someone's name - spill the beans in the comments if you know). The exact binary format is obscured a bit here by PEF's trivial packing method, used to reduce its footprint in ROM, but note the node name stored as a Pascal string (i.e., length byte first), and then the driver name, also stored as a Pascal string and invariably starting with a dot.

Immediately before the driver name length byte is an $06. The two bits set in this byte indicate that the driver is opened as soon as it is loaded (kDriverIsOpenedUponLoad, $02), and that the family expert is responsible for