A/ROSE and the MCP originally came about in August 1987 during the gestation of the Macintosh II project. While working on various networking products for the new system, the developers realized that the existing Mac OS would make any "serious" card difficult to create, due to large latencies and the difficultly of writing complex device drivers. Their solution was to make an "intelligent" NuBus card that was essentially an entire computer on a card, containing its own Motorola 68000 processor, working space in RAM mirrored in the main system, and its own basic operating system. The first version of the system was ready for use in February 1988.
A/ROSE itself was very small, the kernel using only 6k, and the operating system as a whole about 28k. A/ROSE supported pre-emptive multitasking with round-robin task scheduling with a 110 microsecond context switch time and only 20 microseconds of latency (guaranteed interrupt response time). The system's task was primarily to move data around and start and stop tasks on the cards, and the entire API contained only ten calls.
A/ROSE was a message passing system, and the main calls made by programs running under it were
Receive(). Messages were short, including only 24 bytes of user data, and sent asynchronously. To find the appropriate endpoint, A/ROSE included a name server that allowed the applications to bind their names to their task ID's, allowing them to move in the system and be found dynamically. The OS also supported a number of routines for finding, starting and stopping tasks on other cards, one of those "cards" being the host computer.
To coordinate communications and provide a mechanism for talking with the host's CPU, a cut-down copy of A/ROSE also ran inside the Mac OS in the form of a system extension, or "init", known as Prep (which can be confused with the later PReP hardware standard). Device drivers for A/ROSE cards were also written as inits and started up automatically. After starting they would find the Prep stub and use the normal A/ROSE communications channel it provided to communicate with the cards.
For instance, the Apple TokenTalk NB card installed its driver as an init, and optionally installed the Prep stub, assuming it had not been installed before. On startup the driver would find the Prep stub and ask it to enumerate the TokenTalk cards installed in the machine, and optionally upload code or settings to them. From that point on, Prep handled the communications with the card, handing off the results to the TokenTalk driver.