|
Be Newsletter
Issue 9, February 7, 1996
Table of Contents
Be Electronic Newsletter
This is the first electronic edition of the Be
Newsletter. Welcome to all of you who are reading our
newsletter for the first time. We really thank you for your
enthusiasm and continued interest. This is the ninth issue.
You can
read
previous issues on our web site. We hope you'll enjoy
reading our Newsletter. If you have comments, please don't
hesitate to e-mail us at
newsletter@be.com.
BE ENGINEERING INSIGHTS:
Do It Yourself BeBox
By Joseph Palmer, Director of Hardware
Engineering
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
EMI reduction 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.
BE DEVELOPER PROFILE:
Broadhead, Tomich and Associates
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.
Bungling Bundling
By Jean-Louis Gassée
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.
BE Europe: IT FORUM
From February 6 to February 10, Be will be at the IT
Forum in Paris (Porte de Versailles, booth PPC20). We'll be
in the PowerPC Village, along with IBM, Motorola, Apple, and
Power Computing. We'll be glad to see you all there. (Sorry,
we can't provide plane tickets yet.)
|
