Although the Mac OS license is much more expensive than Microsoft’s Windows 95 license (two to four times as much, according to sources), IBM Microelectronics and Motorola Semiconductor have kept the prices of PowerPC CPUs sig- nificantly below those of Pentiums. According to several Mac makers, this means the overall cost is roughly a wash, even when you factor in the extra circuitry required on Macs for SCSI (an option on most PCs) and ADB.
Adding PC Technologies Motorola Computer Group and Umax Computer provided Macworld with two prototype CHRP motherboards that show the technologies in place–and the flexibility offered by an open architecture. Both companies’ prototypes have extended traditional Mac features with PC capabilities, as seen in the sidebar “Up Close: What Two Open Mac Designs Offer.”
For example, the Motorola system includes a parallel port that accommodates standard PC printers, while the Umax system has an ISA slot that lets you use a standard internal PC modem rather than a box hanging off the back of your Macintosh. Note that these are prototype systems, and what the companies actually ship to customers may differ.
The ROM Bottleneck Although CHRP systems are almost here, the effort is not over. In the longer term, Apple faces an unknown amount of work and time to make a Mac OS that removes all vestiges of the Mac ROM.
The ROM contains part of the Mac OS, and the various Mac models’ ROMs have always been written with specific hardware configurations in mind. That’s why OS up-dates are sometimes required to make the Mac OS run on new systems. (For example, a hardware dependency in the ROMs used in the Power Mac 7300, 8600, and 9600 this winter caused them not to run Mac OS 7.6, forcing Apple to develop Mac OS 7.6.1 after the new Power Macs were shipping.
Such dependencies could also cause a nightmare for CHRP designers and Apple OS engineers, since a CHRP system using components that the OS doesn’t know about could require an OS patch, just as happens in Apple’s proprietary Mac designs. But with CHRP, which is open to a variety of components–more than Apple uses now–the potential for incompatibilities is much greater.
This means that Mac makers will at first rely on tried-and-true components, and will need to introduce new components slowly so they have time to create patches that allow compatibility.
Even so, expect some compatibility issues to surface initially. For example, because of a flaw in the design of common IDE controller circuits, the first CHRP-enabled Mac OS (version 8.0, due out in late July), won’t support IDE drives. Mac makers say there are several other minor compatibility issues with various components in Mac OS 8. Because of these issues, Apple will release a Mac OS 8 update–varyingly called Mac OS 8 1.1 and CHRP OS 1.1–that will work around the IDE controllers’ flaw and fix the other compatibility issues. That update should be available in late August or September, and most Mac makers will delay their systems until it is available.
Jon Rubinstein, chief systems hardware engineer at Apple, says he’s not sure how long it will take to wean the Mac OS completely from hardware dependen- cies. Eighteen months was an off-the-top-of-the-head guess, he said.
Apple needs to create a hardware abstraction layer (HAL) that separates the hardware components from the operating system, eliminating the need for hardware-specific code in the OS. The HAL sits as an intermediary between the OS and the motherboard; the motherboard communicates with the HAL via software drivers that translate the peculiar needs of hardware components into standard descriptions for the OS. Rubinstein says Apple is taking a HAL approach for its Rhapsody OS.
Apple has completed the work to eliminate the ROM chip, but the “ROM in RAM” solution that should be available with Mac OS 8 1.1 merely moves the ROM into software. Still, ROM in RAM helps Mac makers in two ways:
*They don’t need to worry about availability of a physical part. The need for a physical ROM chip can slow down Mac makers’ ability to deliver CHRP systems when there are supply hiccups.
*They can reduce the number of patches in the Mac OS, since they can replace a problem in the ROM rather than load a patch. (With physical ROMs, the OS can’t remove bad code, so it has to load a patch from the Extensions folder.)
But until the need for a ROM is completely removed, Mac makers still have to be careful when they adopt new or modified components.
Sources at several companies tell Macworld that some of the delay in CHRP is due to political issues–that Apple is concerned about releasing a floodgate of CHRP systems that could further erode sales of its profitable Macs. Apple denies this, refusing to discuss specifics.
With the ROM moved to RAM, Apple cannot control how many systems a Mac maker has by rationing the ROM chips. Within Apple, a faction was opposed to losing this control, according to sources, especially now when Apple has been late in shipping its profitable systems, such as the 8600/200, and has seen Mac licensees aggressively target the high-end market. However, the licensees also have helped keep the overall Mac market share from dropping precipitously even as Apple struggles with supply problems.
Another bone of contention has been licensing terms for Mac OS 8 (which includes CHRP systems). For several months, Mac licensees voiced frustration over what appeared to be delays in licensing Mac OS 8 and attempts by Apple to impose a certification process on CHRP-based systems that would give Apple some control over engineering choices (see “Apple Pins Hopes on Gossamer,” News, August 1997, and “Apple’s Clone Support in Question,” News, June 1997).
And Apple has resisted efforts to add notebook support to the CHRP specifica- tion as it has sought to prevent competing Mac notebooks. (Apple has also refused to license the Mac OS components required for notebooks.)
Mac makers have been a bit skittish about CHRP for the last several months since Apple officials said that the company will not entirely adopt CHRP itself. This raised fears that CHRP is a Trojan horse strategy that will make Mac OS support for CHRP a low priority, while forcing licensees to use only those technologies Apple has endorsed through its certification authority. Licensees fear that if these endorsed technologies are inferior to what Apple uses in its own systems, CHRP could become a vehicle for holding licenses back.
At press time, Apple seemed to have taken a more moderate stance, and the licensees were cautiously optimistic that an acceptable solution to all these issues would be in place by the time you read this. (See “Possible Hope in Licensing Fracas,” elsewhere in this section. To follow this ongoing story, see Macworld Daily at www.macworld.com/daily/.)
A Rocky Road CHRP has not had a smooth ride from concept to completion. It even had a rocky birth: Apple, IBM, and Motorola hammered out the CHRP specification–which was also known briefly as the PowerPC Platform (PPCP)–in spring 1995, about six months after the companies joined forces to create an industry-standard architecture around the PowerPC in November 1994. Until that decision, IBM had been promoting its PowerPC Reference Platform (PReP), which did not support Mac-specific technology.
Even once the CHRP specification was finalized in 1995, CHRP was delayed. Apple was supposed to have a version of the Mac OS that ran on the CHRP architecture in July 1996, but that was delayed along with the abortive Copland OS. Skirmishing over the CHRP specification helped slow down progress. Apple’s CHRP OS was also delayed this year.
Mac OS 7.6 for CHRP was completed this spring, but Apple decided not to release it because Mac OS 8 was imminent.
Although there’s still a chance for further delays, it appears that with the release of Mac OS 8 1.1 late this summer, Mac makers will be able to deliver on the promise of CHRP, taking the technology from their labs to your desk.