Since most of you reading this are software developers, I thought I'd let you in on the details of how the hardware is done.

We'll skip the "easy" parts of thinking up a product to build, writing a business plan, building up a company, and getting funding, and go straight to the fun parts.

First, you need to write specifications and draft block diagrams. This is where you make your first cut at what kind of and how many I/O slots and devices you want to include, what chip sets you're going to use, and how features will be implemented. In other companies this is where you propose new ASICs and describe their functions. We don't do ASICs at Be: Like the PC clone makers, we use commercially available chip sets to do the job. This does limit our design flexibility, but it removes many of the cost and schedule risks that could cripple or kill a small company. Since the BeBox uses both PCI and ISA buses, much research was required to ensure that the BeBox would be compatible with legacy hardware. I dug through PC system schematics, looked at motherboards and I/O cards, and even took apart mice and joysticks to get closer to the hardware. About this time I started to joke that "I'm not a computer architect, I'm a computer archaeologist!"

To generate the specs you'll need a word processor and a drawing package. I used MacWrite Pro and Claris Impact (quickly replaced by Claris Draw). Remember that eventually you'll use these drawings as GIFs on the Internet. To make sure they look good at screen resolutions, use a grid that's compatible with 72 dpi.

The spec is sent to those concerned for comment. For us this was the point where the serial 3 & 4 channels, the second MIDI port, the infrared ports, and the GeekPort were added.

Next you get to figure out the mechanicals, the board outline, and connector locations. Time for a mechanical CAD Package. I used Claris CAD (no longer available, but well loved) to create accurate drawings of the board and connectors. These drawings were used to place the parts on the PCB and to design a prototype chassis for the initial units. This is a good time to learn about the capabilities of PCB fabrication houses, and about the raw materials you'll be designing with. The BeBox motherboard is specifically designed to fit two-up on a 24x18 panel, which is 1/4 of a 36x48 sheet. The two fit I/O-to-I/O and take up all of the available space in the 24" dimension.

Now it's time to do schematics. I used PADS Logic for Windows from PADS software. It's not the most advanced or easy-to-use system, but it had two endearing attributes. One, it worked. Not elegantly, but it worked. And two, we owned a copy. I've used a half-dozen different schematic tools in my time, and I find that I can put up with some pretty bad behavior as long as the tool produces the results I want.

We're not done yet. Now it's time to lay out the PCB, to actually create the artwork used to create each of the layers of the board. For PCB CAD, we use PADS Perform on Windows. Perform is surprisingly powerful for a PC-based tool. I've used Cadnetix and, to a lesser extent, Racal Redac on workstations for board layouts, and Perform compares favorably to both systems. The user interface is function-key driven, hardly state of the art, but like a musical instrument, once you learn the commands you don't need to think about them, you think about what you're doing. The motherboard was designed first. We chose a conservative technology of .006" traces with .0065" spacing, along with .012" vias. This permits nearly any modern fab shop to build the boards. A six-layer board was started and the highest density area, which contains the BGA (ball grid array) and processors, was hand routed first. I'm not a big fan of auto routers, my experience with them on other systems was less than satisfactory. Each of the boards in the BeBox is hand routed to keep the critical signals short and to allow for EMIreduction features, such as shielding of clock lines. The clocks are all series terminated to create clean transitions at the destinations.

The motherboard has a ground plane, a +5V plane, and one of the inner signal layers has a sub plane to supply 3.3V to the processors, memory controller, and PCI slots. For the motherboard, parts were placed on the top side only, to match the manufacturing flow at our assembly house. It's essential to learn the order and type of machines used to place and solder the parts on the board, so you predict the assembly order of the board.

The I/O card is a 4-layer board, with islands in the power and ground planes to provide EMI isolation. Of the two boards, the I/O card has a higher component density, especially in the GeekPort area. Parts are placed on both sides of the board, with all of the parts on the back capable of withstanding wave solder.

Since these boards are meant for high-volume production, test points must be added to allow an in-circuit tester to perform "opens and shorts" testing on each node. In addition to the through-hole connector pins, which may be probed, 235 test points were added to the I/O card, and 388 to the motherboard. Remember to keep 0.100" center-to-center spacing on the test points, so you can use larger (and therefore more reliable) test points in your fixture.

Somewhere along the way you've picked components for your design, which means you'll need an internal part number for each part, so that you can have a single reference to multiple vendors' part numbers. Come up with a numbering scheme that will be easy to use, both for you and for the stock room. I heard a story once that at a leading Southern California aircraft company, part numbers were assigned sequentially, with say a rivet having a number adjacent to an engine cowling. This made the stock room a real mess, with like parts scattered all over, and if you transposed a number on a requisition, you were never quite sure what you might get.

At this point the first 90 percent of the work is done. In a future article, I'll talk about the next 90 percent: bring-up, debug, and verification.

For Justin Tomich, the BeBox presents an opportunity "to create something that matters, that people will actually use, and you don't have to be a giant to do it." Tomich and his partners at Broadhead, Tomich and Associates in Kensington, California, have been doing contract programming jobs since they graduated from the University of California at Berkeley two years ago with degrees in computer science. Mostly, they've been doing projects related to their clients' use of the Internet and the world-wide web. Tomich says the BeBox's multiprocessing and multithreading capabilities make it an exciting machine. But that's not really his thing, "though I'm sure it has the graphics people drooling," he says.

What excites Tomich and his partners is that the BeBox has TCP/IP built in from the ground up. Tomich looks at the BeBox and sees great potential as an Internet server. "What the BeBox needs is a POP (Post Office Protocol) server and SMTP (Simple Mail Transport Protocol). That would get it a long way towards working as a mail server," Tomich says. He's also considering writing POP client software for the BeBox—something similar to the popular Eudora program for the Macintosh. Broadhead, Tomich and Associates has never done a product of its own for the market. All of its work has been as inside programmers for companies. On the surface it might not make a lot of business sense to try to enter the third-party products business on an installed base as small as Be's. On the other hand there are no giants to compete with and "we can get in there before it takes off," Tomich says. "Then we'd be the first people to come out with a key product that will be around forever, sort of like the Be equivalent of Word for the Macintosh. And there's the thrill of the BeBox." Tomich says he has no plans to be the Microsoft of the Be world.

A treacherous subject. I was once asked if we'd ever bundle a word processor with the BeBox. The question came from a developer understandably anxious to know if his port of an existing word processor would be met with a special kind of competition: A "free" product bundled with the BeBox. This is a good opportunity to state our position on the matter and to solicit feedback.

But first, a little history of bundling. It's tempting to assign the start of bundling to the Macintosh. Originally, it came with three applications, MacWrite, MacPaint, and MacDraw. The very visible Mac made the bundling rather visible too. Yet, the Lisa set an earlier example with its seven applications, and we can be sure there were others before.

The naysayers were having a field day: This toy—how could you call a Macintosh a computer—has no installed base. Therefore, no self-respecting developer will write software for it. Therefore, it will never grow an installed base. Sounds familiar. At the time, in order to break the vicious circle, the powers that were decided to include application software with the first Macs. The machine would be immediately useful and these applications would demonstrate what was so special about the new computer—the word "platform" wasn't used yet in this context. It did the job.

In the early days, when visiting from France, I remember recognizing the restaurant menus composed with a Mac. Graphics, fonts, MacWrite, and the ImageWriter were making their mark. The Macintosh could take off without waiting for Lotus Jazz to ship. Unfortunately, there were three perverse effects. First, the bundle was allowed to last for too long, thus discouraging efforts to develop similar applications, especially from the smaller, more innovative authors and publishers. Second, this form of protectionism, of monopoly, provided no incentive to the marketplace, no sense of urgency in improving the bundled products. As a result, MacDraw, MacPaint, and MacWrite, once they lost their protected 100 percent market share, never recovered a leadership position. Third, the bundling involved cushy deals for the authors. Some were Apple employees. Not a healthy situation. Its complications revisited Apple at the time of the HyperCard bundle, with the same results all around.

If by now you're beginning to think I'm not wholeheartedly committed to bundles... read on. We've been careful to represent the BeBox as an infant product, not ready yet for the mainstream, for C++ programmers only. Some program for themselves, for a project of their own. Some write code for others, they're software developers. And we've been careful to state there were no applications initially, thus avoiding the consequences of the third lie. Yet, with a few hundred machines in the hands of independent developers, applications are starting to emerge in early stages of their development. Does it mean we'll yield to the temptation and bundle a few exemplary programs in order to stimulate sales and give examples of our product's most attractive features? We won't need to. This time around, we have the web and, with it, instant dissemination of information, access to demo versions of new applications. And an inexpensive, worldwide distribution channel for the full product. In a slightly modified version of this structure, our agreement with Metrowerks provides we ship a CodeWarrior starter kit of the Be native version of their IDE.

"Starter kit" means you must buy the full product for industrial-strength development. As far as the applets we've developed are concerned, we intend to leave the better ones with the product—along with source code on our web site. Thus, if you don't like the way it behaves, have a go at it. Get the source and remind us of our limitations! Does it mean we'll never, never bundle an application? One should never say never, of course, but I seriously doubt you'll see us repeat a Write, Paint, Draw scenario. And we know how platforms evolve. From time to time, optional capabilities become part of the system, with varying degrees of success. Mail integration comes to mind, with PowerTalk, now abandoned, and Exchange, more successful. Yet Eudora Pro is so good I'm no more likely to abandon it on my Windows 95 system than on my Mac, recognizing other users will pick the base system offering, at least on Windows. In other words, no to Write, perhaps to Exchange—metaphorically speaking only. Your comments and suggestions are welcome, as always. We're small and hungry enough to actually use them.