An inevitable side-effect of having the Bikelab at Sun Microsystems was my exposure to a whole new computing culture… I was a Unix and SPARC noob when I landed there, and the learning curves were steep and plentiful. This article, which also kicked off an ongoing series in SunWorld Japan, reflected some of the ways that Sun’s technology was affecting the BEHEMOTH project.
A common and reasonable question there was, “why do you need all those OTHER computers?” The answer boils down to power management, and is still, 20 years later, a significant design issue.
by Steven K. Roberts
SunWorld – April, 1992
and SunWorld Japan – December, 1992
You can take your SPARCstation with you — even if your preferred method of transportation is a bicycle.
My life as high-tech nomad began innocently enough. The year was 1983, about the time a few visionaries out west were launching a radical start-up venture called Sun Microsystems. As a struggling free-lance writer and microcomputer consultant in Columbus, OH, I was far from that world, but a dramatic change in lifestyle eventually would lead me to Sun’s doorstep.
Disenchanted with my career and dreaming of freedom, I resolved to create a life centered around my passions: travel, learning, publishing, computer networking, ham radio, and bicycling. I spent six months repackaging my life onto a custom-built recumbent bicycle, then set out with everything I owned crammed into packs or linked to me via the 300-bps modem in my shiny new Radio Shack Model 100 laptop.
For 10,000 miles, I wandered the U.S., landing in Silicon Valley with a book under my belt and a new dream: to erase the technological distinctions between movement and stasis. Although I had upgraded to a capable (for its day) HP Portable, I still couldn’t write while riding and felt locked in an endless quest for modular phone jacks and places to sleep.
The solution was Winnebiko II. The bike hit the road in 1986, equipped with an eight-key handlebar keyboard, built-in microcomputers, an amateur packet radio, and 20 watts of solar power.
Another 6,000 miles passed, and although the new system was liberating, it was architecturally inflexible. Changes involved editing with a soldering iron. All signals were routed through switches on the bike’s front panel, and serious noise battles frequently broke out between those old arch-enemies, computers and radios. Worst of all, technology was racing ahead. It was 1989 and time to do it right.
BEHEMOTH is born
A 105-speed, 580-pound bicycle may not meet most cyclists’ conceptions of doing it right, but my objectives have grown far beyond touring. I want a mobile computing and communications platform that is powered by the sun, easily maintainable and expandable, and entirely bus-structured and software-driven. I want my whereabouts to be irrelevant. And my information-processing goals have expanded well beyond manipulating text to include capturing still video images, mapping and satellite navigation, data collection, 24-hour wireless Internet, e-mail, an entertaining development environment, a smart security system that can interact with intruders and call for help if necessary, and a suite of voice and data communication modes that let me send and receive messages — at any time from anywhere.
The new machine, dubbed BEHEMOTH (for big electronic human-energized machine … only too heavy), comprises a suite of about 45 microprocessors, including those embedded on specialized controller boards. At the low levels of BEHEMOTH’S computing environment, a trio of New Micros 68HC11 boards running FORTH handle security, power management, data collection, keyboard processing, and network control.
At the apex of this collection of processors lies a Macintosh Portable and a Sun IPC. The former functions as a full-time GUI to the bike’s control systems; the latter is the main computing engine, mail-spool environment, frame grabber, and owner of a high-speed Telebit CellBlazer modem. A DOS machine (a lightweight, low-power Core Module XT from Ampro) manages my databases and provides a terminal window for accessing the various low-level microprocessors when debugging is required.
As you might expect, the SPARC’S hardware environment is a bit unusual. It consists of the Sun IPC board, modified slightly to accommodate an LCD interface card from RDI that supports the bike’s 640- by 480-pixel Kyocera monochrome display. Because space is limited, the IPC’s screen is mounted behind the Mac’s. When I need to work in the Sun environment, I simply flip up the Mac screen. I have put off until later the addition of a dazzling new Sharp 640- by 480-pixel color LCD because integrating it requires major hardware changes that will take a few months. The new addition will consume about 20 watts, a considerable power drain, but well worth it for mapping, CAD, and video applications.
The SPARC is powered by an RDI DC-DC converter board made for the BriteLite laptop; it gets mouse input from both a Logitech ultrasonic head tracker and a thumb mouse made by Measurement Systems. Keyboard input is provided by Infogrip’s seven-key BAT keyboard, which is built into the handlebars and controlled by one of the Mac’s FORTH engines. The system’s two hard disk drives are Conner Peripherals’ new 1-inch 212-megabyte laptop models.
The net effect? A robust Unix workstation on a bicycle. But this robustness, and the number of resources that must be interconnected, create a challenge.
A question of balance
Linking all your hardware to a network is appealing in an office setting, but senseless here because it would involve so many interfaces and consume too much power. As a result, all interprocessor communication takes place through a massive “crosspoint” network — a matrix of serial connections that allows any devices on the system to communicate. This setup reduces all devices to physical addresses. The bike’s audio functions are handled in the same way. Audio and serial connections are thus controlled entirely by software — as is power.
The need to work out power-conservation measures such as this is one of the main reasons I sought out Sun’s expertise and have spent the last year of this three-year project working in a Sun-sponsored lab. Sun offered lab resources, computers, and an assemblage of clever people in exchange for the public relations the bike project delivers and the opportunity to test out new ideas.
One of the questions about this grand Turing machine that I often hear at Sun is, “Why do you need all those other computers?” After all, once I decided to excise the PC laptop from the console and replace it with a Sun IPC board and RDI display, I suddenly had enough computing horsepower on wheels to render everything else superfluous — in theory.
If the SPARCstation were the only computer on board, however, it would have to be on all the time. But with my present setup, I can turn on the big machine when applications justify it and save precious battery power at other times. And I don’t have to give up the efficiency of the Mac as a graphical interface, the quick access of the DOS system for database management and notes, or the simplicity of the New Micros FORTH boards for all real-time control and resource management.
The people I meet on the road and during speaking engagements ask a different question, “Why a Sun workstation and a color display?”
In addition to the obvious graphic applications — such as OrCAD, still video, and mapping — that will shine when I upgrade to color (and the ability to emulate DOS and run a few of its applications), the Sun system will help manage my flood of e-mail, one of the biggest challenges posed by my high-tech nomadic lifestyle.
There are two primary mail paths from the bike to the outside world (not counting trusty old laptop-to-modular-jack sessions). The Mac is my primary vehicle for reading and responding to mail. It runs Eudora, a public-domain mail system written by Steve Dorner at the University of Illinois. Eudora’s primary link to the world beyond the bike is through a Qualcomm OmniTRACS satellite terminal, the white dome mounted to the rear of BEHEMOTH’S trailer. The terminal is in constant communication with the GTE GSTAR satellite, which forwards messages to and from the Qualcomm hub in San Diego. There, a Sun-4/260 performs essential magic to render Eudora’s encapsulated messages appropriate for the Internet — and vice versa. Incoming mail from the satellite simply appears on the Mac, and I can deal with it as I pedal.
A secondary mail path exists because I receive a great deal of mail and don’t want to tie up satellite communication unnecessarily. A SPARCstation 1+ in my base office filters all incoming mail into two piles: urgent messages to be handled by the satellite and the rest, which goes to uucp. Twice a day, a FORTH task on the bike powers up the bike’s SPARCstation and attaches it to the CellBlazer modem, which in turn is connected to an Oki cellular phone via a Telular Celjack. This magical unit generates the equivalent of a modular phone line from a cellular transceiver.
Twice a day, the SPARCstation on the bike calls the SPARCstation at my base office and, via uucp, downloads my low-priority mail, dials MCI and GEnie to pick up messages from my commercial net connections, and repackages each item so each one appears as Internet mail. The cellular system is then shut down, and Eudora establishes a local link to the SPARC to incorporate all mail into a single queue. This arrangement greatly simplifies mail management when I’m on the road and can’t glide from machine to machine in my swivel chair.
I also get a great deal of flexibility. I can maintain aliases, receive a limited news feed, use net services, and take advantage of the efficiency and familiar tools of the Open Look environment. Computation-intensive tasks such as image compression (via the Sun VideoPix SBus card) and map generation run as easily on BEHEMOTH as they do on a desktop workstation.
And culturally, I enjoy all the advantages of the Internet world — my home-town — without giving up machines that are easy to work with and that have low enough power needs that I can maintain permanently active bike accessories and low-level, 24-hour control.