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™).

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.

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™ 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).

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 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.