|
Be Newsletter
Issue 33, July 24, 1996
Table of Contents
BE ENGINEERING INSIGHTS:
Infrared
By Guillaume Desmarets
The happy campers among you who, day after day, enjoy the
presence of a BeBox may have already removed the chassis
cover to see if we really shipped two PowerPCs per BeBox
("...yup, there they are..."). The most courageous may then
have decided to take a further look at the motherboard;
eight SIMM slots (check), ISA slots (check), PCI (check)
third processor socket (che...what??? sorry, it's just the
logic analyzer port).
And over here we have the U30...
The U30 is an 8-bit microcontroller located between the
logic analyzer port and the ISA slots. More congenially, the
U30 is the infrared (IR) chip. This article describes the
history and features of this chip.
The goal of the BeBox IR port is to enable the BeBox to
interact with consumer IR devices. Not only can the IR port
receive commands from a regular IR remote control, it can
send control signals to an external device -- in other
words, you can turn your BeBox into a big blue remote
control. The goal for now isn't to support standards like
IrDa, we just want a cool feature (almost as cool as the
GeekPort(TM)).
In implementing the port, we needed to find an IR format
that we could support. The original idea was to sample a few
specific remote controls and then try to understand all the
messages that they could send. We planned on choosing
generic, programmable models that had large numbers of keys.
On the out-going side, we needed to be able to sample an IR
sequence and reconstitute it later. Finally, we wanted the
transceiver (the box that receives and sends the IR signals)
that's plugged into the IR port to be as simple as
possible... ideally, as simple as an IR LED (for the
emitting side). Consumer IR signals are time modulated, so
in addition to broadcasting data, the IR port needs to
deliver a time-modulated signal.
Unfortunately, after gathering information about IR and
sampling all the IR remote controls that were lying around
at Be, we concluded that no two protocols were exactly
alike. (Some conclusion!) For example, each time you press a
key, you send a data field and an identification field
related to the device. Hmm.... Timings, data and
identification fields, synchronization fields, modulation
frequency, repeat patterns -- all different!
It was time to resort to the old science fiction standby:
The "universal translator." You have a room filled with
people from Earth, Venus, and outer space colonies -- yet
everyone is speaking English! (How convenient.) What does it
mean? In order to ease communication, you accept that you
will lose part of the data that you receive when someone is
talking to you, particularly language-specific nuances. In
fact, you don't even know what language the other person is
using. The only problem is that your universal translator
has to recognize every language that it hears; if the range
of languages is too broad to *teach* it each one (or if new
languages are created), then the translator has to have the
ability to *learn* new languages on its own. Back on Earth,
California, Menlo Park, that's what our IR chip tries to do.
First of all, the tasks of listening to a remote control
(so you can control the BeBox by using a remote), and
emitting IR signals (so you can control an external device
from the BeBox) are clearly divided into two modes: The
first we call "analysis" mode; the second is "sampling"
mode.
To use the BeBox to receive IR signals, you put the chip
in analysis mode and then teach it what to listen for by
punching the set of keys (on the remote control) that you
want to use. During analysis, the chip looks for a set of
(eight or fewer) bits that remain constant; it assumes that
this is the identification field for your remote control. It
then assumes that the changing bits (again, as many as
eight) make up the data field.
Once a remote control has been analyzed, the data can be
stored in a library of remote control settings. By choosing
a remote from the library, the user tells the chip to begin
listening for signals that match the analysis data. The chip
then only processes incoming messages that contain the
proper ID bits. The chip can listen to three different
remote controls at the same time: There are three IR
channels, and each channel can be set up to recognize a
different ID.
Sending IR signals to an external device also requires a
learning phase. You put the chip in sampling mode and then
(once again) step through the remote control keys that
you're interested in. In sampling mode, however, there's no
analysis -- the chip is simply recording the signals that it
receives. Later, when the user is using the BeBox to control
an external device, the chip simply plays back the signal
that corresponds to a particular requested function. Thus,
for example, when you want to use your BeBox to tell your
television to change to channel 65, the IR chip simply
replays the "change to channel 65" signal.
This raises a question: Why doesn't the IR chip use the
analyzed data for output as well as input? Why does it have
to play back a recorded signal when it's talking to an
external device, rather than synthesizing the signal from
the analysis data? It's a valid request -- but,
unfortunately, it can't be done (at least not yet). During
analysis, a lot of important information is lost; only the
ID and data field information is retained, everything else -
- timing information in particular -- is thrown away.
Although a few remote controls won't work with the BeBox,
a very large number of brands are supported. Still to come
is the software that will use the IR chip.
BE DEVELOPER TALK: Robert
Poole, Leonid Software
E-mail:
lionlad@dancris.com
After a somewhat mediocre career in undergraduate
physics, I decided that a different course of action was in
order. So I became a hacker.
I've done a variety of things with computers. My great
love is graphics -- especially algorithms for generating
really cool images, or for transforming existing images. I
played extensively with ray tracing and image manipulation
(sharpening, enhancing, posterizing, and so on) -- I know, I
know, most of these tools are readily available for many
different platforms, but I wanted to write my own. Besides,
being an Amiga fan, I have little choice in the matter.
After a couple of jobs in the industry (including writing
PDF conversion software at MasterSoft), I decided to start
writing software for myself again. As the sole employee of
Leonid Software, I consult by day and write the software
that I really want to write in the evenings. I've got
several software ideas kicking around:
- A PNG graphic toolchest, to convert images to and
from PNG (a relatively new graphic file format), to view
them, to apply transformations to them, and to edit the
various chunks that comprise a PNG file, as well as to
append new chunks.
- A PDF viewing application, useful to developers since
much on-line documentation is now written in the PDF file
format.
- I'm negotiating with a game development company to
port a sound toolkit to the BeBox.
The BeBox for me is like the Amiga -- full of promise and
capable of doing more with less. To me, the idea of an
inexpensive multiprocessing personal computer is a logical
next step in PC evolution, and I'm amazed nobody has pushed
such a design previously. The BeOS(TM) is clean,
object-oriented, and logical. The GUI is simple, yet slick.
The BeBox has let me recapture the euphoria I had lost
when I sold my Amiga 3000 to pay for a Pentium box. On the
down side, there are plenty of bugs and shortcomings to work
out. I'm particularly annoyed at the lack of support for
foreign file systems in the BeOS -- one simply expects to be
able to read an ISO 9660 CD-ROM volume without effort! But
the hardware is good (thank you, Be, for including SCSI as a
standard bus!), and the OS is constantly being improved. So
the immediate shortcomings can be overlooked.
I plan on making my BeBox products available as shareware
over the Internet. That's really the best distribution
method for a one-man show like myself. In the long run, I'd
like to create a whole suite of document and graphic
processing applications for the BeBox, and I think it's not
unrealistic for a company starting small to do this. That's
how others have started. As for my target audience, it's
clearly graphics and DTP enthusiasts (with a heavy leaning
toward graphics initially, because for me that's less
difficult).
Fun and Games
By Jean-Louis Gassée
In coming weeks we'll be featuring a column by Pierre
Raynaud-Richard that will address two components of the
upcoming Developer Release 8 of the BeOS: The Game Kit and
the 3-D Kit. This marks an important step in the evolution
of the BeOS and, as such, deserves some clarification and
expanding upon the philosophy behind our moves.
First, the Game Kit. As Pierre points out, he wrote a
fairly basic first installment with enough functionality to
encourage use and feedback -- feedback we'll use for the
"fully functional" revision. After that we'll be in
"continuous improvement" mode, until technology or market
changes call for a major release. That's the theory, a
little too tidy perhaps when compared to implementation, but
a usable framework when describing our approach. On
occasion, we'll depart from that model if and when we decide
to take out a part of the system and rebuild it from
scratch. From painful experience, we'd rather suffer (and
cause others to suffer with us) a temporary inconvenience
than to live with our sins forever. In a way, this sort of
effort is a fleeting luxury, one we can afford in the early
days of the system when the concrete hasn't set and we can
still move the foundation walls.
Back to the Game Kit... The second point about the Game
Kit concerns facilitating what programmers will do anyway --
with or without our support or approval. In this case, game
developers want and will write directly to the screen. This
epiphany was easier for Pierre than for most systems
programmers: He wrote games that were his calling card when
we hired him. Only later did he also reveal he writes
science fiction. Doom and other best-selling games
contravene programming guidelines on systems such as
DOS/Windows that make the breach relatively easy.
Frequently, these games aren't available at all (and
therefore don't help sales) on systems such as the
Macintosh, because these systems make such invasions too
difficult. Picking our challenge was easy: We'll take the
problems and the sales. If we do a good job with the Game
Kit, we might even minimize the problems associated with
high-speed writing to the screen without hurting game
quality -- and sales -- too much. In the BeOS, we're
cognizant of the realities of office life: Games take over
the screen in one of the system's workspaces. This helps
users avoid the misunderstandings and lengthy explanations
about the relaxing and reflection-enhancing virtues of
games: Switching to a more mundane workspace is one keypress
away. We're of the school that thinks there's no serious
computer without a serious inventory of games. The Game Kit
reflects this philosophy.
The 3-D question calls for more complex answers, and
Pierre points to the difficulty of a "one size fits all"
API. Many have suggested we license OpenGL®, so we're doing
that now. I've just executed the licensing agreement, and we
can expect the port to be completed in the near future (not
for DR8, but soon thereafter). The good news is that OpenGL®
is a liked and respected industry standard. Silicon Graphics
has done a great job of promoting it, and as the smoothness
of the licensing process attests, the "Open"in OpenGL® is not
there in vain. It will be attractive for high-end
applications, and it represents yet another installment in
our effort to make it easy, or easier at least, for some
UNIX applications to migrate to the BeBox. This effort
started when we realized we could progressively implement a
fairly complete Posix API in the BeOS. We also decided to
build a separate 3-D Kit in the BeOS. Simpler or more
interactive 3-D applications are not best served by an API
originally designed for high-end CAD work. The full 3-D Kit
isn't implemented yet, even if the project is fully scoped
in Pierre's papers. Just as many hardware and software
developers found color wasn't merely more bits per pixel, we
know 3-D isn't the visual space we know, with just one more
dimension. Success will stem in great part from our fine
tuning of the architectural choices we've made and, for
this, developer feedback is even more important than usual.
The first public demonstrations will take place at the
Boston MacWorld Expo in August. We hope to see you there or
soon thereafter.
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. To subscribe to BeDevTalk, visit the mailing
list page on our web site:
http://www.be.com/about_be/mailinglists.html.
- ---- WEEK 2 ----------
Subject: First Experiences
More opinions on the shutdown mechanism, plus a new
proposal: The interface (probably some designated portion
of the Browser) should indicate whether it's safe to turn
the computer off. This was countered with the position
that the computer can't really know for sure if it's safe
-- you have to perform an explicit sync between the file
system and the database.
- ---- WEEK 2 ----------
Subject: File Format
In this thread (which finally separated itself from
"Speaking of PostScript...") the previously proposed
system-level data translation mechanism was critiqued. As
an alternative, EAIFF 85 (Electronic Arts Interchange
File Format) was suggested. And rebutted.
- ---- WEEK 2 ----------
Subject: Speaking of PostScript...
AKA: Content Negotiation Protocol
This has turned into a mail filter/type discussion.
Should Be create a mail filter daemon that lets you
describe the sort (and amount) of mail you're willing to
accept? Should Be invent a new mail data format? (This
evoked mutterings of "NeXTMail.")
- ---- NEW ----------
Subject: Root Directories
AKA: Root Dir Proposal
AKA: Remembering Mounted Volumes
In the hottest thread of the week, the philosophy of
what goes into the root directory was discussed. Should
"/" contain the expected UNIX-like directories (/dev,
/tmp, etc.)? Should a CLI view of the file system be any
different from that presented by the Browser;
specifically, what should the Browser present as "/"?
Woven into the thread was a debate on how
partitions/volumes should be handled: Should mount point
locations be restricted? How should the BeOS handle a
request to eject a mounted (removable) disk?
Also: Will Be do links? Multi-user? Automount?
THE BE LINE: Remember, the file system rewrite is
coming. As far as the design details go, we'll keep you
posted. Until then, this thread is being closely watched
-- your suggestions and observations aren't wasted.
- ---- NEW ----------
Subject: Converting Pathname to Fileref
How do you get the ref for the current working
directory? The doc for get_ref_for_path()
claims that it doesn't accept relative paths; some have
experienced otherwise.
THE BE LINE: The doc is (philosophically, at least)
correct: You shouldn't pass a relative pathname to
get_ref_for_path(). This is because the
meaning of cwd in the ref/database world is undefined
(note, however, that this issue is in the file system
rewrite hopper). If you want to pass args, use
BApplication's ArgvReceived().
- ---- NEW ----------
Subject: Standard Shared Libs
A call was made for folks to volunteer to implement
common freeware (and the like) as shared libraries. It
was suggested that add-ons might be a better approach.
|
