A huge roller-coaster of a novel crammed full with sizzling gypsies was how Edmund Blackadder, the comic creation of Rowan Atkinson described a book of his. Compared to this, the PowerPC Reference Platform Specification (Beta Version) will find itself struggling to compete on the stage of world literature. There are no gypsies, only some sizzling bus specifications. Neither is it huge. Anyone that has seen PowerOpen’s mammoth applications binary interface and applications programming interface specifications, will find PReP’s 236 pages quite skimpy. Nonetheless, the ring-bound soft-covered volume is being pored over by well in excess of 1,000 systems designers today as they try to decide whether to build PowerPC machines. It is no exaggeration to say that the PowerPC’s success on the desktop will be built on three foundations: the inherent power of the chip itself; operating system and application support; and the care with which PReP is constructed. As we have reported in the past, the PReP specification is a collaborative work, currently under the control of IBM Corp, which lays out in some detail the specifications needed to build a PowerPC machine capable of running the Workplace OS, Windows NT, AIX; Solaris and Taligent. Ignoring the thorny question of how acceptable PReP is to Apple Computer Inc, IBM reckons that the document is nearly finished. It needs to be – IBM’s Power Personal Division is committed to shipping several machines that comply with the PReP specification in the second half of this year. Prolonged wrangling over the spec would either entail a delay to the machines’ launch or a machine that pre-empted the finished standard. In the alpha version, only the Windows NT appendix was in anything like a finished state. This time around the AIX specifications have been fleshed out and Workplace OS makes a debut.
LocalTalk
This leaves the Solaris and Taligent entries completely blank. Workplace OS is not the only addition; since the first version, the authors have made some 67 changes to PReP’s pages. LocalTalk now joins Ethernet as a recommended networking standard – an obvious nod towards Apple Computer. Compliant machines should now be able to support both Endian modes of operation. The section on firmware development has been deleted on the grounds that it was too product-specific. VGA hardware emulation disappears, 640 by 480 resolution is added. More detail is added to the multiprocessing section, particularly on the interrupt handling side. The Power Management section has virtually been re-written. Non-volatile RAM structure is defined for the first time. And for the first time, the document outlines a general procedure for getting systems certified as PReP compliant. However there are still some places where the specification remains very sketchy. Don’t expect much on audio support, for example; all you will receive is the bald statement that compliant systems must be able to get analogue noises in and out and must provide 16-bit stereo samples at a sampling rate of 44.1KHz and 22.05KHz and that is it. One of the most quoted items in the whole document must be the table at the end of chapter two that defines hardware requirements for the various operating systems.
By Chris Rose
To be precise, there are two tables, one that describes typical configurations for portable, media-less, desktop, technical and server machines. The other describes the resources required to run Windows NT, AIX and Workplace OS. So, all PReP-compliant computers must have a minimum of 8Mb of RAM, but it is recommended that they be expandable to at least 32Mb. Windows NT and AIX need 16Mb to run, with the claim that the svelte Workplace OS will fit into 8Mb. Hard disk capacity is a little trickier: the tables show that 80Mb is the bare minimum, however all the operating systems will apparently require at least 200Mb of disk space to run. Indeed 240Mb is recommended for all but servers, which should have at least 400Mb. On communications, Ethernet or LocalTalk are the recommended standards to be supported. No mention
of Token Ring – and few of Micro Channel IBM is taking consensus-building seriously. Recommended expansion buses are Peripheral Component Interconnect, PCMCIA and/or AT. Others can be used, but will need changes to the operating system’s abstraction layer. Abstraction is word that you cannot avoid when talking about PReP – chapter 4 is devoted to it and the concept is key to the document’s need to serve two opposing masters. On the one hand it has to promote standardisation, on the other, it has to give manufacturers enough leeway to differentiate their products. Abstraction is the mechanism chosen to satisfy these twin goals. Abstraction software concentrates all of the hardware-dependent operating system code into a single bundle with well-defined interfaces to the operating system kernel. The idea is to isolate the operating system from the vagaries of the hardware so that the hardware designer can do anything he or she likes under the hood, as long as the correct set of interfaces are maintained. To the casual observer, the way in which PReP places the onus of abstraction on the operating system writer is curious. It might be thought that the hardware manufacture should be responsible for hiding the details of implementation under a thin software abstraction layer, but PReP makes it clear that it is the operating system writer’s responsibility to write the initial abstraction software, and he or she must also provide a mechanism so that the personal computer maker can amend those parts that need to be changed to support to proprietary hardware technology. The abstraction software falls into three main classes; Boot-Time Abstraction Software, BTAS, Run-Time Abstraction Software, RTAS, and device drivers (shamefully, these don’t have an abbreviation). The Boot-Time software abstracts the hardware used to boot the machine: this includes disk and network interfaces needed to load the binary into the machine, as well as the keyboard and display. The Run-Time software handles stuff like interrupt controllers and cache configuration.
ROM-based Forth
Again, the boot process merits a substantial section of its own and chapter 5 goes into considerable detail explaining what should load what into where. It is a strategic objective to see PReP-compliant hardware conforming to the IEEE P1275 Open Firmware draft standard. Why? So that a standard boot process can be used irrespective of system configuration. Open Firmware goes way beyond the ability for a machine to boot its core services; it gives adaptor board manufacturers the ability to design boards that will work irrespective of the processor type. Put very simply, the Open Firmware-compliant machine will include a ROM-based Forth interpreter, while the boards will contain small programmes written in Forth that specify their set-up and configuration. There are a number of refinements, of course – the Forth commands are held in a ‘tokenised’ form, called FCode, to save space, for example. The net result is that everything from the initial hardware test, through discovery and initialisation to starting up the console, can be placed under the control of the open, extensible Fcode language. The early work on what is now called Open Firmware was carried out by Sun Microsystems Inc and the technology already appears in Sun’s machines.