October 90 - INSIDE THE MACINTOSH COPROCESSOR PLATFORM AND A/ROSE
INSIDE THE MACINTOSH COPROCESSOR
JOSEPH MAURER
The Macintosh® Coprocessor PlatformTM provides a foundation for connectivity
products such as the Serial NB Card, the TokenTalk NB Card, and the Coax- Twinax
Card. Its operating system is A/ROSE, the Apple Real-time Operating System
Environment. This article introduces you to the Macintosh Coprocessor Platform and
A/ROSE, and gives you a taste of what is involved in developing a connectivity product
on this foundation.
The Macintosh Coprocessor Platform and A/ROSE together provide a hardware and
software foundation for developers who want to create NuBus TM add-on cards for the
Macintosh II family of computers. The developer's guide that comes with the kit is a
hefty 400-page tome. If you're curious about how NuBus cards are built but not
curious enough to tackle the developer's guide, read on. This article gives you an
overview of the origins of the Macintosh Coprocessor Platform, its architecture, and
details of its real-time, multitasking, message-based operating system, A/ROSE. It
shows you some A/ROSE code. And it shows you how to experiment with some A/ROSE
applications included on the Developer Essentials disc.
HOW IT ALL BEGAN
When development of various networking and communications products for the
Macintosh II started at Apple, around 1987, it became obvious that the Macintosh
Operating System didn't meet these products' needs for processing power and operating
system capability. After all, the Macintosh OS was designed for human interaction
rather than for connectivity to mainframe computers. It is not real-time (interrupts
can be disabled for longer than is acceptable for fast interrupt-driven input/output),
and it aims to provide a pleasant and efficient graphic user interface, rather than
processor-intensive I/O handling. The solution was to make an "intelligent" NuBus
card, with its own 68000 processor, its own working space in RAM, and its own basic
operating system services; and to design this card not only as a basis for Apple's own
products, but also as a tool for NuBus expansion card developers. The result was the
Macintosh Coprocessor Platform. Its operating system, A/ROSE, was designed to
respond to the needs of connectivity products, complement the capabilities of the Mac
OS, and yet be generic enough to become the foundation for a new breed of
message-based, distributed software architectures. The work on A/ROSE started in
August 1987, and the first version was operational by February 1988.
Today, developers can build on this platform in designing products for communications
and networking, data acquisition, signal processing, or any other heavy-duty
processing. Time- consuming and/or time-critical tasks can be offloaded from the
main logic board to a dedicated processor on the NuBus card. This increases the overall
computational speed, of course, and allows for faster response times in the foreground
applications. Moreover, unlike the standard Mac OS, A/ROSE provides the real-time
and multitasking capabilities required for handling multiple communications
protocols.
Nevertheless, A/ROSE on a Macintosh Coprocessor Platform still depends on the Mac
OS (and its limitations--see Technical Note #221) for transferring large amounts of
data across the NuBus through a driver to a Macintosh application. This means that
ample data buffering (and careful error handling) should be provided on the card if the
project requires high-performance data transfers. As you'll see in the next section,
the card provides plenty of room for large buffers.
THE MACINTOSH COPROCESSOR PLATFORM UP CLOSE
The most prominent feature of the Macintosh Coprocessor Platform card is all the
empty space on it, inviting hardware developers to heat up their soldering irons and to
put plenty of advanced hardware on it. A complete master-slave NuBus interface comes
for free, implemented by means of two chunky Texas Instruments ASICs
(application-specific integrated circuits), 2441 and 2425. This interface manages to
give the on-board MC68000 access to the whole 32-bit NuBus address space (by
means of an address extension register). Conversely, the 24-bit address space of the
local MC68000 can be accessed directly from across the NuBus. Custom hardware on
the card can be enabled to take over the 68000 bus and even go to the NuBus, but
A/ROSE tasks usually take care of servicing chips on the board, and communicate with
the higher levels of the software design.
Figure 1 The Macintosh Coprocessor Platform Card
Figure 2 Memory Map of the Macintosh Coprocessor Platform With A/ROSE Running
The MC68000 on the Macintosh Coprocessor Platform card runs at 10 MHz (the
NuBus clock speed) without wait states. Standard 512K of dynamic RAM is expandable
up to 4M. Two 32K EPROMs contain the declaration ROM code needed to make the
SlotManager happy, plus some pieces of code to help the MC68000 out of a Reset and to
provide low-level diagnostic routines. The card also carries a programmable timer,
used by A/ROSE for scheduling time-sliced tasks.
A/ROSE UP CLOSE
A/ROSE is a minimal, multitasking, distributed, message-based operating system.
Here's what this means, in real terms:
It's minimal: The module that provides basic A/ROSE functionality, the A/ROSE
kernel, fits into 6K; and a complete standard configuration of A/ROSE on a NuBus card
amounts to only 23K of code and takes up only about 48K of buffer space. This leaves
more than 400K for your code on a standard 512K RAM card. Still, as you will see,
A/ROSE is a strong software platform to build on.
It's multitasking: A/ROSE does pre-emptive multitasking, with round-robin task
scheduling (taking 32 priority levels into account).
It's real-time: A/ROSE offers 110 microseconds context switch time, with 20
microseconds of latency (guaranteed interrupt response time).
It's distributed and message-based: The A/ROSE software can be present on
several cards, and it is completely autonomous and independent on each card. Tasks
defined by users and by A/ROSE communicate with each other, even across the NuBus
to other slots or the Mac ® OS, by means of messages. These messages can carry
pointers to data buffers along with them. Thousands of such messages can be passed per
second (fastest from task to task within a card, and slower, of course, between
different slots).
The A/ROSE kernel is responsible for task scheduling, interprocess communication,
and memory management. The calls that correspond to these responsibilities are shown
in Table 1. The standard configuration also includes utilities for bookkeeping and timer
services. These utility functions are carried out by the A/ROSE managers: the Name
Manager, the InterCard Communication Manager, the Remote System Manager, the
Echo Manager, the Timer Library, the Trace Manager, and the Print Manager.
Table 1
The Ten A/ROSE Primitives
Name Description
AROSEFreeMem() Frees a block of memory*
FreeMsg() Frees a message buffer*
AROSEGetMem() Allocates a block of memory*
GetMsg() Allocates a message buffer*
Receive() Receives a message+
Reschedule() Changes a task's scheduling mode
Send() Sends a message*
SpI() Sets the hardware priority level
StartTask() Initiates a task
StopTask() Stops a task
Notes:
* Implemented in A/ROSE Prep with the same parameters.
+ Implemented in A/ROSE Prep with a supplementary parameter.
The A/ROSE architecture, shown in Figure 3, is completed by A/ROSE Prep, a version
of A/ROSE that runs on the main CPU under the Macintosh Operating System and that is
necessary to establish communication between the Mac OS and A/ROSE. The A/ROSE
Prep file has the file type INIT, and contains among its numerous resources a DRVR
named .IPC (for interprocess communication), and an INIT that executes at INIT31
time and basically installs and opens the .IPC driver. The .IPC driver takes care of the
communication of Mac OS processes with A/ROSE tasks. Nothing can be downloaded to
the Macintosh Coprocessor Platform if the A/ROSE Prep file is not in the System
Folder: it contains card-dependent information needed for the download routines to
succeed. The programming interface to the .IPC driver (described in the A/ROSE
header files arose.h, os.h, managers.h, iccmDefs.h, ipcGDefs.h, and provided through
the library IPCGlue.o) mimics that of A/ROSE itself as closely as possible, providing
the look and feel of A/ROSE even if there is no A/ROSE around. More practically
speaking, with the A/ROSE Prep file in your System Folder, you can do a lot of
interesting A/ROSE experiments even without a Macintosh Coprocessor Platform. For
your convenience, the A/ROSE Prep file is included in the A/ROSE folder on the
accompanying Developer Essentials disc.
Figure 3 The Architecture of A/ROSE
WHAT'S THIS ABOUT MESSAGES AND TASKS?
Interprocess communication in A/ROSE takes place by means of messages passed back
and forth between tasks. A typical example consists of a client/server relationship
between A/ROSE program modules, as illustrated in Figure 4 on the next page.
The client task needs to know that the required server task exists; thus, the server
task is initialized before the client task. Next, the client task issues a GetMsg() call
to request a message buffer from a preallocated pool of message buffers that is
maintained by A/ROSE and the size of which is specified by the user. After the message
is filled with addressing information, command codes, and parameters, it is sent to the
server task. At this point, the sending task loses rights to the message buffer, and
should not use it again until it comes back through a Receive() call. On the other
side, the server task usually sits in an infinite loop, waiting for messages requesting a
service, handling these requests, and sending replies.
Figure 4 How Interprocess Communication Takes Place in A/ROSE
After receiving the reply, the client task can reuse the message buffer for subsequent
requests, or release the buffer by means of a FreeMsg() call and go ahead with other
business.
A message provides up to 24 bytes of user data, and is fixed length and asynchronous.
If the data to be sent does not fit into the message proper, then it can be put anywhere
in the sender's memory and the address and size of the data area can be passed in the
message.
Each message is identified by a message ID and a message code. The message code is
defined by agreement between the sender and the receiver. A convention followed in
A/ROSE is for outgoing messages to use an even-numbered code and for replies to those