The last time I wrote (issue 9, February 7, 1996 ), I discussed the first part of the design process—the part that gets you 90% of the way there. Now let's finish the job and build some systems.

We built only three prototypes of our first board (Rev 01). This was, in essence, a "learning board," so it was good to start small. We learned several things about overlapped transfers on the processor bus, and found mistakes in the placement and pinouts of the board's components. But these boards served us well as we tested the CPU and RAM, the disk systems, and the devices on the PCI and ISA busses. To arbitrate communication between these different appendages, you need a controller; luckily, we received our first controller chips (the MPC105 "Eagle") the same day that we got the Rev 01 prototypes back from the fabricator.

I designed the PCB of the I/O card while the software team started using the Rev 01 boards. The I/O card was a difficult design: It fit on 4 layers with lots of EMI features on the inner planes. The component density was higher than the motherboard, especially around the GeekPort™.

Rev 02 of the motherboard saw about 10 prototypes. We used these boards to really shake down the I/O cards and the chip sets, and ended up adding some glue logic in the form of two GALs to solve some problems.

Rev 03 was a build of about 45 boards that went to the engineering team and a few guinea pigs outside the company. These systems incorporated the glue logic and are quite similar to what you are seeing now. The one major difference is the ISA I/O chip set: With Rev 03, we experienced a problem with the mouse port, so we replaced the part that contained the keyboard/mouse, floppy, parallel port, RTC, and serial port with separate chips. Later, it turned out that the problem probably wasn't in the part we replaced—but in a bit of perverse luck, that part went on severe allocation and the price jumped dramatically. Thus, by swapping parts, we indeed solved a problem—we just didn't realize, at the time, that it was an economic and not a technological one.

Rev 04 was another short build to test the new I/O solution. To save time and set-up costs, these boards were hand-built, with the exception of the BGA, which was soldered to the board in the standard reflow process. A couple of nits were found and fixed with rework wires. Rev 04 was the first board to see the new chassis, so new mounting slots and holes were added, as was the new front panel.

Rev 05 was our first big build—more than 400—and our first general shipment to developers. If you have a system now it's probably a Rev 05. The machines were built in-house: Half of our floor space was given over to a make-shift factory, complete with an ad hoc assembly line. These systems were shipped in a preproduction chassis without the front panel.

Rev 06 is a build of 450 units that is hitting the streets as we speak. For the first time we have in-circuit tests in place at the board factory to locate problems before the boards leave the production line; so far we've had a 91% first pass yield, the remaining units requiring minor touch-up to pass. Rev 06 is being shipped in a production chassis with an LED board and an untextured front panel. This build is (finally!) being handled by an outside service that's experienced in the business of assembling, testing, and shipping PC clones.

Enough for this time, except to say that Be is seeking a hardware engineer to join our team. If you would like to join us, read the job posting on our web site.

Eric Berdahl, Mitch Adler, and John Townsend could write a "how-to" book on new, object-oriented operating systems. That's because they're all former Taligent employees who jumped ship in January 1996 to form Shooting Star Systems, a company that develops OEM solutions for professional video production.

What sort of solutions? Take an evening news broadcast as an example. The opportunities Shooting Star is looking at include: Editing and sequencing raw video footage into broadcast-ready clips complete with titles and graphics; compositing and wiping between a live video feed and a studio feed within the same news segment; and compositing a weather person on top of a computer-generated map, so the presenter can appear to manipulate the map on-screen.

As Eric Berdahl puts it, “One of the advantages of taking an OEM approach to these problems is that the customer often doesn't know—and usually doesn't care—about the name of the computer that's at the heart of the system. They just want the best solution.” And that's exactly what the BeBox will help Shooting Star deliver.

Given their pedigree, it isn't surprising that the folks at Shooting Star are quite familiar with the problems inherent in OS and application models. Eric observes that “Be appears to have skirted most of the tar pits.”

“While other developers are worrying about obeying standards and maintaining market share, Be is one of the few companies that's adopting a don't-swallow-the-elephant attitude. Be has simple solutions to difficult problems and isn't trying to solve world hunger with its offering.”

On the business side, Eric believes the BeBox is an ideal platform for OEM models. “With the Be OS™, we can develop solutions with a minimum of interference from the underlying OS and a maximum of support for general programming problems, such as multitasking and memory management.”

“We have some very interesting PCI boards available to us for building video production systems,” says Eric. “We plan to use these in conjunction with a PCI chassis and our own custom software.”

Shooting Star is writing BeBox drivers for some of its PCI cards now, and plans to begin development of its first BeBox product in a month or two. They expect their product to be available by the end of 1996, but aren't quite ready to reveal the details yet—so stay tuned.

For more information on Shooting Star Systems, send e-mail to Eric at berdahl@serendipity.org.

We get the question on-line, by fax, by phone, and even in person sometimes when people see the T-shirt. We're very grateful for the interest and we'd like to respond in the most appropriate and most durable fashion. Which is to say we'd like to build happy relationships, create positive word of mouth, not just expedite locally profitable transactions. There are a number of obstacles on the road to this blissful state of affairs. Some are regulatory, some are connected to the status of product development, the availability of applications and more generally, the resources and learning process involved in building a new platform.

On the regulatory side, we're in line for FCC approval and expect it early July. In the meantime, the units coming out of the manufacturing pipe will continue to be allocated to developers. Even with healthy caution applied to the size of our backlog of unfilled developer requests, we'll need the next two months to catch up. Then, FCC approval in hand, we turn to customers.

As we advertised earlier using various metaphors, this isn't a mainstream machine. This time, to make the point I'll use the following four qualifying questions for a prospective customer: Do you own two or more personal computers already, do you use or love C++, do you have Internet access, and do you have two thousand dollars on your credit card?

The first question addresses the lack or paucity of applications at the time we start selling customer units. You must already have personal computers (we're brand agnostic) to take care of the daily bread and butter needs the BeBox cannot fulfill. Also, good working knowledge of the pluses and minuses of existing platforms will add realism to expectations and enjoyment to ownership of a well-balanced stable of computers.

Then, the C++ question. I've been advised it's impossible to use AND love C++. More to the point, for some time, CodeWarrior will be the only—or one of the very few—applications available on the BeBox. We expect Java tools to be available from Metrowerks and other sources at a later date, but in the meantime, our customers have to be interested in C++ programming. CodeWarrior's award-winning IDE and the speed of the BeBox will add to the enjoyment of C++ programming.

The Internet access shouldn't be a problem. It's almost a self-selecting mechanism. The Web constitutes our best marketing and support channel. Be developers will use the Web to promote and distribute their applications as well. Just as important, even at this very early stage of our life, there are many active Web sites and substantial traffic on comp.sys.be. These will grow and provide useful information and technical support to BeBox users—and Be engineers and marketers. It bears repeating that without the Internet and the Web, this company probably wouldn't exist. When I started Be, in October 1990, I thought we'd begin with a small BBS to interconnect our developers, our users, and ourselves in order to exchange information, arguments, and software. I even watched with glee as I saw FirstClass (from SoftArc, a Canadian company), one of the nicest BBS systems ever, take off and gain worldwide respect for the quality of their product. I even hoped we could bundle a Be version of FirstClass with our product, a nice and useful communication tool for early adopters. The Web has fulfilled that dream and much more, without asking us to become a BBS operator in order to do business from Australia to Finland.

As to the credit card question, this is the payment mechanism we've used thus far. But we'll take any reasonably current and reliable instrument. And we'll refund your money, as indicated in the small print to come on the Web site, if you're not happy. Yes, we need money. Happy money, good word of mouth that brings new customers and repeat business. If we do a good job processing your images, or serving your web site, we hope you'll buy more BeBoxes and recommend us to your envious friends.

Initially, we'll offer our products on the Web and run a small number of experiments with the geekiest of retailers. Even if some of us have prior experience marketing computers (or because of it), we know this is new territory. We don't like it when bystanders label us quixotic, when they are polite, or crazy, when they are honest, for launching a new platform. We explained and we'll keep explaining how this isn't so lunatic in view of the state of aging platforms and the emergence of undominated digital media and communications applications. But they have a point. There's the expectation that launching a new platform requires almost infinite Procter & Gamble financial resources. We, in the microbrewery school of business, plan to deploy the BeBox in the market as we developed it, patiently. Premature marketing expenditures kill many a start-up. We'll step up spending only when we have traction, when we have proven where the BeBox works and where it needs more development. That's what we'll do in the next few months and we hope you'll lend us a hand by developing software, buying our product, or just sharing your observations.

A last anecdote. Last week I mentioned selling T-shirts. It looks like the price just went up. This morning our housekeeper walked in ten feet tall and handed me a VHS tape. On it there was a segment of David Letterman's show, prominently featuring Robin Williams, and less prominently, two glimpses of said housekeeper in the first row proudly displaying a Be T-shirt. Expect the customary "As Seen on National TV" label real soon now.

Last week, three Beings (Mark Gonzales, Dominic Giampaolo and Alex Osadzinski) spent three days in New York City taking the BeBox and Be OS on the road. We did press interviews, radio and TV shows, and three user group meetings. At every event we demonstrated the BeBox and Be OS and then had discussions about our company, its strategy, and products.

The press interviews were with The New York Times, Business Week, and Unigram. The Times and Business Week seemed to really like the demo and asked a lot of technical as well as business-related questions. This type of interview will build good relationships with these important journals for the future and, who knows, may even generate short-term coverage. The folks from Unigram, an open systems industry weekly newsletter, were interested to hear about a new system platform, even if it doesn't run UNIX! Of course, they were most interested in our POSIX compliance, and seemed pleased that Linux is running on the BeBox.

After the print interviews, we moved on to TV and radio. "High-Tech Shower" (!), a Japanese-language technology show that can be seen in Manhattan, asked us to their studios to video tape Mr. Gonzales' demo performance (he'll be translated into Japanese for the broadcast). Then we rushed over to WBAI (99.5 FM) for an interview that included a live phone-in segment. We fielded a lot of very good Be questions—there are more Be people out there than we'd guessed.

The most important part of the trip was attending and speaking at three user group meetings: The New York Mac User's Group (NYMUG) and two meetings sponsored by the Amiga Users' Group (AMUSE). Because of a tight agenda, we only had time for a quick demo at the NYMUG, although even that generated a lot of interest. At the two AMUSE meetings we had more time and enjoyed lively Q&A sessions. After the second meeting, we just made it out of the building before they locked the doors, and could easily have spent a couple more hours talking with the Amiga folks.

Altogether, about 400 people saw the BeBox and Be OS during three very hectic days. Many, many thanks to Bhima Hogan, Livingston Hinckley, Linus Lys, Eugene Pisman, Chris Bastian and many others in the New York area who helped us set things up and who hosted us most graciously.