|
Be Newsletter
Issue 40, September 11, 1996
Table of Contents
BE ENGINEERING INSIGHTS: The Devil in the Board
By Pierre Raynaud-Richard
[This is a fiction based on real events. Any similarity to
actual people or machines will be... perhaps intentional.]
- Friday, 9:23 pm
An anonymous Be geek, alone with his computers, is reading
comp.sys.be:
"The BeBox is a great machine... except for graphics card
support which is really miserable."
"Why is Be supporting only the 964 (which is no longer
available), and not the 968 (which is). I *know* they're
almost identical..."
"Is Be so lazy that they can't even support the Matrox
Millenium?"
Dagnabbit, these guys are right. What was Be thinking when
they decided to do such a bad job with graphics card
support? I need to help them... At least they had the
intelligence to release the sources for the few graphic
drivers that they do provide. Let's see... here I have a
Diamond card based on a Vision S3 968, using VRAM. A pretty
good card. Too bad they don't support it. I never did a
graphics driver before, but it's probably no more difficult
than any other piece of software.
I'll plug the card into my BeBox and turn the machine on. Uh
oh, the screen is black. No Be logo, nothing. That's
strange. When I plugged this card into my Wintel machine,
everything just worked -- I didn't even have to copy a new
driver onto my disk. Why can't I do the same thing here?
Wait... Of course! God, I'm stupid! The Wintel uses an 80x86
processor which can execute the BIOS code of the ROM. The
BeBox would need an emulator to do the same thing, and
that's not such an easy job.
But it's not a big deal. I have the source from Be for a
964-based board. I just need the databook of the 968... Here
it is.
[Be geeks are extremely resourceful.]
Great, they explain the differences between the 968 and the
964 -- just what I need. This should be an easy job.
- Friday, 10:28 pm
Tarnation! Still nothing! All the settings look good, but
the screen is still completely black. What could be wrong?
I'm using the TVP 3026 RAMDAC/clock generator; the Be driver
uses the TVP 3025. That's probably close enough -- but maybe
I should check to see if they're really compatible. I should
have those databooks somewhere... Here. OK, let's compare
everything...
- Friday, 10:51 pm
Fuor la spada! These guys are completely crazy! They rename
or move half of the registers, and half of the others were
completely modified. No wonder nothing worked. Probably I
can try to patch the code used to program the TVP 3025...
- Saturday, 12:04 am
Okay, now I'm making progress. There are still huge bugs in
the graphic settings, but at least the screen isn't black
anymore, and the monitor was able to synchronize correctly.
- Saturday, 3:11 am
O Entsetzen! These are nasty bugs...
- Saturday, 5:43 am
It's too late now, I'm getting nowhere. Time to sleep.
- Saturday, 1:32 pm
Let's see if those wretched bugs can evade me now that I'm
fully awake!
- Saturday, 8:58 pm
Okay. Maybe I'm not going about this the right way. These
chips probably have bugs that aren't documented. I need more
information. I should be able to get driver sources from
somewhere else. Let's try Linux and Windows NT... Here they
are! First Linux... hum, the source is 1 MB... and a bit
confusing. What are they doing ? Oh... it looks like they're
still using the old bank-switching mode. What about Windows
NT? Oops! The source is even bigger (1.3 MB) and it's even
more confusing. Huge macros everywhere... links to their
global graphic system... and more source code.
Linux, Windows NT... in both cases it looks like it will
take days or weeks to understand what they're doing and
reproduce it. And they're not even supporting some of the
advanced features used by the Be drivers. Probably the best
is just to look for specific comments about the 968.
- Saturday, 9:17 pm
I'm going nowhere again. Too big, too complex, too
different. My driver is probably almost working, except for
a few bugs. Stupid to begin everything again from scratch...
Okay, let's try disassembling the Windows driver.
- Sunday, 6:02 am
Looks like another big failure. They're doing strange things
in a strange order. And the API is so complex! I hope I
never have to write a driver for that OS. Off to sleep.
Maybe I'll have another idea tomorrow...
- Sunday, 2:16 pm
I was doing things the wrong way. What I need to do is just
put the card on my Wintel machine in a mode that's as close
as possible to the one used on my BeBox and then dump the
values of the registers. Then all I have to do is check what
my BeOS(TM) driver is doing. Pretty simple. I should have
done that in the beginning.
- Sunday, 3:57 pm
Criminidly! I've set the registers to be as identical as
possible, given the differences in the settings between the
machines. But it's still not working! Svenami! There are
probably bugs in the program order too! I remember that
there's a case in which you have to first set register A to
0 before you set register B to a specific value, and only
*then* could you set A to its real value... Dumping the
registers won't help here.
But I have one more solution: Where's my logic analyzer?
[We told you the geek was resourceful.]
I'll plug the analyzer into my Wintel machine and spy on the
transactions between the CPU and the graphics card. I can
only store one set of 1024 samples, and I need 2 samples per
transaction. But 500 transactions should be more than
enough. Lets see what it's doing when it turns on the
graphics card in default mode during the boot...
- Sunday, 4:04 pm
Uh oh, it looks like there are going to be more than 500
transactions. Why so many? Strange. Bah, there are probably
just a few more. Let's keep tracking...
- Monday, 12:19 am
I can't believe it! I can't believe it! I've already looked
at 40,000 transactions, and there are still more... Just to
boot the card! What's going on? Is there a devil in the
board? What's it doing? Can a virus have reprogrammed the
BIOS ROM? My God! The guys who wrote these pazzo drivers are
completely crazy! Wait... I know one of them! Perhaps I can
get a few hints out of him. It's not too late to call...
"Hi John, it's Paul. How are you?... Me too, me too... No, I
called because I was just trying to adapt a driver for your
968-based graphics card... Yes, that one... How long!?... It
took two engineers an entire year to get the Wintel driver
working?!... I understand better now... A lot of bugs? I can
believe it... So thanks John, see you soon."
Perhaps I chose the wrong card. Better to try another one.
Oh, here's my Matrox Millenium. Where's the databook? How
could I not have the databook?
[Remember, the geek always has everything he needs.]
Oh, I remember, I tried to get it two months ago, but John
said even they couldn't get it. Matrox just doesn't give it
out. Pretty annoying... Looks like I'll have to wait for Be
or a third party to give me new drivers. They said they're
working on it...
BE DEVELOPER TALK: StarCode, Hard at Work
By Carlin Wiegner (cew@starcode.com) and Michael Klingbeil
(mkk@starcode.com)
Like many other Be developers, StarCode Software jumped at
the chance to develop for this new and exciting platform.
The BeOS represents an intriguing mix of old and new. The Be
interface is a strange blend of Windows, Macintosh, and even
some UNIX interface ideas which seem to work well together.
The stability and performance of preemptive multitasking and
memory protection are a welcome change on the personal
computer frontier. The small, flexible Be API is much less
intimidating than the numerous "Inside Macintosh" volumes.
The database and multimedia support are full of tremendous
potential.
As many people were quick to point out, Be was crazy to try
to build another OS when the world seems to embrace only a
small handful of OSes. What Be had going for them, whether
they knew it or not, was an OS that would appeal to a wide
range of users, from geeks and hobbyists to multimedia
designers. And with the introduction of the PowerMac port,
Be has an opportunity to reach the mainstream.
Even though there's a lot of work left to be done on the OS
and certain aspects of development are still frustrating, we
should start seeing a change on the applications front over
the next six months. Be is in a perfect position to
aggressively track down great products from other platforms.
Some areas where we see wonderful opportunities for small
shops are: A hybrid resource/database editor, some
memory/heap tracking tools, a news reader, and a graphical
FTP client.
Located in Menlo Park, California, StarCode Software
specializes in writing software management tools for the Be
platform. We will be releasing the first version of our
software installer, the Package Builder, during the second
half of September. This is a critical step for developers to
have a better tool than tar to distribute their software.
Preliminary versions of the Package Builder will be free
while we close in on a commercial quality product. (Feel
free to suggest features and report bugs.)
Following the Package Builder, we will begin developing a
second product, the Software Valet, which will help users
spend less time managing their software and more time using
it. Early versions will keep track of a user's installed
applications (and concomitant software "packages"), thus
allowing the user to easily and cleanly uninstall particular
programs (for example). Later versions will track software
compatibility, offer software upgrade assistance, and
automate registration.
We're excited to bring these tools to the Be platform. For
more information, send us e-mail at info@StarCode.com or
check out our web site at http://www.StarCode.com. By the
way, we're looking for another engineer. If you're
interested, see the job announcement on our web site.
BE MARKETING MUTTERINGS: Premature Announcement Syndrome
By Alex Osadzinski
I well recall, in a reminiscence that will date me as a
startup ancient, my painful technolust for the portable Z80-
based CP/M machine called the Osborne 1. I saved up my L, s,
and d in anticipation of purchasing my own Osborne 1 --
until Adam Osborne, the company's eponymous founder,
announced the second-generation machine somewhat ahead of
its shipment date, with the unfortunate effect that sales of
the first product ground to a halt as everyone (myself
included) waited for the newer, far superior, Osborne 2. The
company failed and bequeathed its legacy to the computer
industry:
Os-borne (Awz'born) vi. to cause a decrease in or
elimination of sales of a product by announcing its
replacement prematurely.
Despite this, companies continue to announce -- or leak --
information about new products before they are available.
Sometimes this is simple misadventure, but there are other
motives for early announcement, some pure, some not so pure.
- A company wishing to wage war on competitors with superior
products may pre-announce its even more superior product to
encourage customers to wait and not buy from the
competition. Sometimes the even more superior product exists
or is being developed. But not always.
- Companies with suboptimal products (a computer industry
term for products that don't actually work very well, if at
all) may announce a long-term future product that, of
course, fixes all the deficiencies of the current one.
- A company wishing to gauge reactions to a product idea may
announce the idea as an actual product in development. If
enough orders arrive, maybe they'll build the product.
Sometimes they even succeed.
- Some companies make the 16th century Tudor Courts seem
calm, loyal, and altruistic by comparison: A rancorous
faction within a company may make a premature announce-
ment -- and an implied commitment to customers -- simply to
lock the company into a particular direction.
- And, finally, some companies pre-announce products to keep
their customers informed about future directions.
I'm prompted to write about Premature Announcement Syndrome
because we may have unintentionally been unclear about the
nature of two recent announcements: Our licensing of OpenGL®
from Silicon Graphics and our agreement with Metrowerks to
develop Java tools for the BeOS. Our intent was to inform
about our future direction.
In both cases, our announcements met two important criteria:
They were news and they were factual. We had indeed
concluded a license agreement with Silicon Graphics and had
indeed agreed with Metrowerks that they would develop Java
tools for the BeOS. Neither was a product announcement, but
both have been interpreted as such by some people. We
apologize for the confusion. Our intent was, and still is,
to indicate two important directions for the BeOS: That it
will support the OpenGL® API, making the porting and
development of OpenGL®-based applications much easier; and
that we are planning to support Java, an important emerging
language.
We'll announce both products when they ship, with a target
for both of them late this year or early next year.
Samuel Adams, Again...
By Jean-Louis Gassée
There are a number of reasons why I like Samuel Adams, or
Boston Beer, the brewery. It makes excellent beers and, for
Be, an excellent metaphor -- a little outside my usual range
perhaps, but an example of a well-run company that succeeds
in a market dominated by giants. Recent events have
rekindled my interest in the metaphor and also provided an
answer to observers who kindly teased me by pointing to a
flaw in the imagery.
The first event is a very nice story written by Steve
Kaufman, a staff writer at the San Jose "Mercury News." The
piece appeared September 9 and, thanks to the net, was
brought to my attention by friends over in France. Titled
"Companies Putting the 'Public' Back into IPOs," the column
describes how companies such as Boston Beer or Starbuck
Coffee make sure small individual investors do not get shut
out of "public" offerings. Boston Beer allocated 20 percent
of the 4.5-million-share offering to customers who called
for a prospectus and the opportunity to buy shares at $15
each. What's remarkable isn't that shares still trade above
the IPO price (quote symbol SAM: $21 today), it's that Jim
Koch, Boston Beer's CEO, took the extra pain and money
required to include consumers in the IPO. It took an extra
shot of pain in dealing with the SEC, getting their
approval, writing a special consumers-only prospectus, and
spending over a million dollars in the process. Apparently,
this was money wisely invested. The consumer/shareholders
turned out to be Boston Beer's best promoters, they got
cards identifying them as Boston Beer co-owners and
everywhere they went, demanded to know why the store or the
restaurant they were in wasn't carrying Samuel Adams beer.
This isn't the way most companies do IPOs. In order to get
stock in a hot IPO, you need friends in high places. Either
at the company or in one of the firms handling the new
issue. The little guy stands outside that cozy network and
only gets to buy after the insiders and their cronies made
their profits on the initial rise. Too bad if the stock
falls back not only from the early apex, but also below the
offering price, as it did often in recent hyped-up
offerings.
This is not a new phenomenon. In 1980, I got a call from
Aaron Orlhansky, a financial analyst from a US brokerage
house located in Paris. We used to meet for lunch, he
brought press releases and prospectuses, I interpreted the
technical jargon, and he picked up the tab. One day, by way
of thanking me for pointing Tandem to him, he offered to get
me stock in the upcoming IPO of Apple Computer. I declined,
preferring to stick with my small Tandem position. He also
mentioned that Tom Lawrence, then Apple's VP of European
Operations, was looking for someone to start Apple France.
This time, I bit.
Back to Boston Beer, I used to like the company because it
made an excellent case for both contrarian wisdom and plain
old good execution. Back in the seventies, the Boston
Consulting Group and their brethren sold concepts such as
"forward pricing" and "size is everything". As a result, we
witnessed ugly copulations of large corporate bodies,
megaconcentrations in the food, tobacco, and beverage
businesses. Anheuser Busch bought competitors, Philip Morris
bought Miller breweries, and we got corporate beer, beer
designed by committee, indifferent beer. Less taste, more
filling. On the consumers' taste buds, this left room for
more interesting beers. Microbreweries, an old pioneer
tradition, started to rise, so to speak. We got mediocre
beer, so-so beer, and great beer. Boston Beer rose from
nowhere, initially with little support from the financial
community, with no manufacturing plant. But their beer
consistently won taste contests. They contracted capacity
from other breweries, stayed in control of the taste, the
quality, and the cost, and initially marketed the hell out
of their product at beer festivals and other connoisseur
venues. Samuel Adams and the other fine microbrews became so
successful the giants woke up irritated and confused. Their
response? Imitation. By carefully reading the label of one
such ersatz, you'll find it's made under a license from a
French industrial brewery. The same attention to a Plank
Road label will reveal it comes from the makers of Miller
Lite.
I was introduced to Boston Beer by one of our founders,
Steve Sakoman, home brewer himself, who felt Samuel Adams
was one of the few commercial brews worthy of real beer
makers and drinkers. So, after metabolizing a few pints, I
started metaphorizing. Boston Beer and Jim Koch became one
of the examples that inspired our work. That was long before
they went public. Not only did Boston Beer execute well
against conventional wisdom, but when the time came for a
hot IPO, they also treated their consumer/shareholders
warmly and creatively. Reading Steve Kaufman's column made
me feel we had indeed picked a good model.
What about the flaw in the imagery, then? Astute observers
remarked this microbrewery metaphor bucking contrarian
thought was well and good, but all beers are compatible with
the installed base of refrigerators and bottle openers. Our
beer needed not just taste buds tired of legacy brews, but
also different refrigerators and bottle openers. It just
occurred to me that with the PowerMac port of the BeOS we
might have found nice standard fridges and church keys.
BeDevTalk Summary
BeDevTalk is an unmonitored discussion group in which
technical information is shared by Be developers and
interested parties. In this column, we summarize some of the
active threads, listed by their subject lines as they
appear, verbatim, in the mail.
To subscribe to BeDevTalk, visit the mailing list page on
our web site: http://www.be.com/aboutbe/mailinglists.html.
- ---- WEEK 2 -------------
Subject: Sound card discussion (or why my BeBox sounds
better than my PC)
Subject: Be Audio Stats
AKA: AES/EBU
More discussion of sound cards vs in-box audio. This week we
had comparisons with Gravis Ultrasound and Soundblaster AWE-
32. In a related thread, a call was made for AES/EBU
connectors on the BeBox. Also, there was some speculation on
Be's GM synthesizer.
THE BE LINE: We will be releasing the General MIDI
synthesizer through our Web site in a few weeks. Stay tuned.
- --- NEW -----------------
Subject: Single and double clicking
AKA: Clicks, doubles n' drags
AKA: Multiple Clicking
(and so on)
A number of mouse issues:
- When the user double-clicks the mouse, what messages
should be sent to the target application: Two single clicks?
A single click followed by a double-click? One double-click?
Should the application be able to specify which of these it
wants?
- Should a double-click always do something "constructive"
(such as open a document), or can it be destructive -- can
it be defined to quit an application, for example?
- What's a "click": Is it a mouse-down, or a mouse-
down/mouse-up?
- How should a three-button mouse be emulated by a mouse
with only two buttons? Should the user be allowed to choose
the form of emulation?
- When a dragged item is dropped, how should the source
(window) be informed of the item's new location?
- ---- NEW ----------------
Subject: RunFilePanel and RunSavePanel
It was suggested that the open and save panels allow broader
file filtering and format conversion. Currently, the
BApplication class lets you filter files based on their
types (only).
- ---- NEW ----------------
Subject: Floating point performance
The clarion has sounded: Use floating point. It's fast,
it's easy, and it's (sometimes) free. Not much controversy
here -- but some cautions: Division is slow, as is int<=>fp
conversion. Pierre Raynaud-Richard offered a handy rundown
on the comparative speeds of various operations in various
contexts.
- ---- NEW ----------------
Subject: Bug Errata for BeOS would be wonderful.
Many developers wrote in to cast their vote for publicly
disclosed bug reports (from Be). Many of these developers
have been asking for this sort of support for quite awhile.
Speculation is that Be doesn't have the necessary
technology...
THE BE LINE: The hang-up hasn't been technology as much as
manpower stretched thin. But you're right -- you deserve to
see bug reports and we will give them to you soon (honest).
Look for an announcement within a couple of weeks.
|
