Computer and Control Systems This is BEHEMOTH's heart, or perhaps I should say hearts. When everything is active, there are a number of microprocessors working in harmony -- some as highly localized embedded controllers, some as bike-management systems, and some as high-level applications platforms. I will not attempt a complete inventory here, but an architectural overview is in order. The primary user interface to the bike is partially implemented in HyperTalk on a repackaged Macintosh Portable, whose hinged screen is at the top center of the control console. Mouse pointing can be done with head movement (via ultrasonic sensors and a dedicated controller) or via a torque joystick in the right handgrip. Data entry is via the handlebar keyboard that serves all machines, or via a plug-in QWERTY keyboard for use when stationary. Synthesized keyboard events are passed to the Mac via the Apple Desktop Bus, eliminating any need to hack the Mac logic. HyperCard and the Finder run in RAMdisk, minimizing the need to spin up its 40-megabyte hard drive or floppy while mobile. All bike control is ideally represented through a variety of "views," each bearing graphic elements that are linked through external commands to the bike's trio of control systems, layering the smooth Macintosh mouse-driven user interface atop the FORTH command lines. These control views are divided along application boundaries, such as security, power, network configuration, maintenance, data collection, ham radio, packet datacomm, and so on. The point of all this is complete flexibility in interface design (the precise opposite of the Winnebiko II, whose hardwired console was virtually impossible to reconfigure). As with many other parts of BEHEMOTH, we ran out of time before this was fully finished, but the concept was proven well enough that it is now being implemented on a much larger scale in the Microship. Other Mac applications include biketop publishing, Eudora for electronic mail, word processing, communications, MIDI system control, and a slide show of graphics and scanned "electronic sponsor decals" for use when BEHEMOTH is on public display. Flipping up the Mac screen reveals a Sharp VGA LCD driven by an Ampro Little Board 286 system, essentially a 16 MHz AT-class DOS PC packaged for industrial control and drawing about 8 watts (including math coprocessor, 4 megabytes of RAMdisk, 3.5-inch floppy, and a second shock-mounted Conner 40 meg hard drive). The backlit screen allows any robust DOS graphics application to execute perfectly well on the bike. This translates into easy use of OrCAD, Autocad, programmable gate array software, computer-generated maps, and much more. A second DOS system, located behind the seat, runs a number of applications including Reference File, a pop-up database manager that allows me instant access to about 5,000 contacts around the world. Since this was in frequent use on the road, it lives in the system that drives the heads-up display on the helmet -- Reflection Technology's Private Eye. This 720X280 screen presents the illusion of a floating display just below my center of vision, no matter where I happen to be looking (even in rain, darkness, or direct sunlight). The console also carries a third DOS system, based on the innards of a Toshiba T1000. It may seem redundant, but remember the power- management problem -- often, all I really need is a simple large-print text editor (Eye Relief) or communication program. This was intended to run a TSR called PRD+ that can be piped into the text path from the handlebar keyboard, allowing me to type in a sort of shorthand to double or triple my effective data rate. It was also to handle the Covox speech-recognition system, enabling voice command of basic bike functions via helmet or remote radio (but not continuous text entry, not quite yet...). It came up fine in the lab, but I never really needed it on the road. I also carried a fourth DOS machine in the form of a laptop (later a Macintosh PowerBook 170) in the trailer. This allows routine text work and software development when I'm off-bike with the manpack, and also allows full remote control of the on-board systems from up to 2 miles away via a business-band packet data link (described later). Finally, just before departure we added a Sun Microsystems SPARCstation to BEHEMOTH's applications layer. I have always wanted to ride a unixycle, and besides... that kind of horsepower is an excellent environment for map generation and computation-intensive CAD. It also made the bike a roving TCP/IP node, tied directly into Internet/Usenet via a Telebit CellBlazer modem and Morningstar PPP software.The control environment also includes multiple processors, with the stars of the show being a trio of New Micros FORTH 68HC11 systems. These low-power machines wake up in FORTH, making them exquisitely hackable without external development systems or the traditional edit- compile-debug cycle, and they are I/O-rich and slow-clockable to minimize current drain when the computation load is light. The main machine here is the BCP, or Bicycle Control Processor. It has, in addition to its console port to the Mac, a pair of serial ports on dedicated lines to the RCP and TCP -- similar systems in RUMP and trailer. Even though a single 68HC11 could handle all the control tasks on the bike, doing it this way significantly reduces cabling and complexity. These controllers handle everything: load switching, data collection, security, handlebar keyboard decoding, power-management, and network configuration. One of the most significant tasks is managing the crossbar switch matrices through which pass all audio and serial communication in the machine. Within each major site (console, RUMP, and trailer), a Mitel 8816-based matrix is wired to all local devices. These are tied together by 12 shielded "long-lines" (8 audio and 4 serial), which are dynamically allocated to communication events as they arise. An incoming cellular phone call while mobile, for example, could result in the phone's speaker and mic audio being assigned to buses, which are then switched to the helmet's boom mic and left earphone (while the right ear may remain connected to the Audapter speech synthesizer or other audio source). Again, the whole idea here is flexibility. I could not possibly anticipate all future enhancements, so a system architecture that treats every device as an addressable node with a minimum of dedicated interface circuitry is most likely to remain useful for the design life of the machine.