Be Newsletters - Volume 1: 1995–1996
One of the integral parts of the BEOS—perhaps its cleverest element— is the application server. The server is designed to take full advantage of the multi-threaded kernel; the glory of the design is manifest as a superbly efficient and responsive user interface. But even more than by its exploitation of threads, the server gains speed and efficiency by communicating directly with the driver that controls the graphics card. The application server links with the graphics card driver in its own address space, thus allowing direct access to the driver without the overhead imposed by system calls.
In the next release of the Be OS (release 1.1d7), we will publish an API through which you can create your own graphics drivers to support the card of your choice. By using the new driver API (which was described by Robert Herold in Issue 1-14 of this newsletter), you will be able to load your driver into the application server, thus allowing the same direct server/driver communication that Be provides with its own drivers.
This first version of the graphics driver API supports all the main accelerated functions needed by our 2D application interface system. The resolutions that we will (ultimately) support are
The depths are:
As even the minimal resolution/depth uses almost 300K of bandwidth, we chose to support only those cards that provide linear addressing and a good bus bandwidth. Consequently, we only support PCI graphic cards—ISA cards are definitely too slow.
We decided to integrate high-precision refresh rate and synchronization settings to allow the best possible use of your monitor's capabilities. With a few minutes of real-time, interactive tests (using the new Screen preferences), you can get your monitor to display an unexpectedly high resolution. There's no trick here—when you approach the maximum refresh rate supported by a monitor, it becomes incredibly sensitive to any synchronization problems. Since you can adjust the settings in real time, you can quickly see what works and what doesn't. For example, we got 800x600 out of an old fourteen inch monitor in two minutes. By comparison, the complete version of Windows 95 failed after a half hour of automatic testing and another half hour with the help of the user.
Be will also provide, in release 1.1d7, some of our own new graphics drivers (look at the Web Site for an up-to-date list). If the number of drivers that we provide seems a bit skimpy, remember the following:
The Be Machine isn't Intel
This obvious remark might seem unrelated to graphics drivers—but actually, it's the key to everything. The incestuous relationship between card manufacturers and Microsoft engenders a deceptively simple view of the graphics world. Why do you think PC cards areas "easy" to install as they are today? Because tens (more probably hundreds) of engineers from graphics card companies are working closely with Microsoft to provide "seamless" cooperation. Have you ever noticed that every SuperVGA card comes with a ROM (and not a small one)? That ROM represents the brain trust, the collective hard-wired wisdom of those hundreds of engineers. But just try porting to the thing.
The BeBox doesn't execute Intel 386 code (we're still studying emulation solution, especially to get a minimal mode for the boot, but it's not easy, and really not efficient). And we don't have access to their source code—but, admittedly, we haven't asked. So we need to redo everything from scratch.
I've asked a few friends, all software engineers, “What do you think do we have to do to initialize a graphic card ?” Most of them replied: “You put the resolution in a first register, the depth in a second, the refresh rate in a third, something like that...”
It's a reasonable answer—but in the reality, there's something like 60 to 100 registers involved in the initialization of superVGA mode. Every time you turn on your TV, consider what it would be like if, instead of an on/off switch, channel selector, and volume dial, you had to set the parameters that control the light beam, the synchronization signals, the frequency of the channel, the vertical blanking, and tens of other parameters that are meaningless—except to the engineer who designed it. You'd probably watch less TV.
The task of designing a graphics driver depends, largely, on the quality of the information provided by the manufacturers of the chips used on the card. In a few cases, they provide examples of complete settings (God bless them !). Most of the time, however, you have only a description of each register. In the worst cases, there are mistakes in the databook that takes hours, days, or weeks to uncover. Some manufacturers don't provide databooks at all (Matrox, example Matrox).
Not to be discouraged, things get better; the initial, lost-in-the-forest part of designing a driver for a graphics card is by far the worst part of playing around with graphics. After that comes the fun stuff: Multiple monitor support, game architecture, 3D strategies. But we'll save all that for the next versions of the drivers and another newsletter.
“Simple, clean, fast...”
“Getting in on the ground floor.”
“An opportunity to change the world like the Macintosh did a decade ago.”
Phrases like these pop up regularly when we ask Be developers why they're developing for the BeBox, and what their future hopes are for the platform. Michele Fuortes of Leuca Software says, “I hope the BeBox becomes the Macintosh of the next millennium.” Nicely put. We can almost see the tag line on a full-page Wall Street Journal ad...
Fuortes' current product, Macjordomo (not related to the famous UNIX program Majordomo), is a freeware Macintosh list server, which he expects to make available on the BeBox by late 1996. Macjordomo is used primarily in the education market, which isn't surprising, given that Fuortes is an assistant professor of Anatomy and Cell Biology at Cornell University Medical College. But Macjordomo isn't just a tool for research students. Michele reports that many “regular folks” are using Macjordomo, from fiction writers, to Northwest plant lovers, to church groups.
He writes his software in his spare time and distributes it free-of-charge because he wants to help people take advantage of the Internet, and “for the pure pleasure of seeing the programs run well and seeing people use them.”
For communications programs like his, Fuortes sees the clear advantages the BeBox provides. “With an integrated, object-oriented OS; real multitasking, multithreading, and memory protection—it's a powerful box.” If he had five seconds to describe the BeBox? “The power of UNIX with a Macintosh interface.”
Fuortes' BeBox development plans include an email client program that is currently in the design phase. Also on the drawing board: a reference manager for scientists that can tap the speed and processing power of the BeBox. The program will make it easy for a scientists and science students to search for specific topics in journals, articles, and books.
As a freeware developer, Fuortes isn't overly concerned with a platform's installed base. Still, when the topic of low-volume platforms comes up, he likes to remind people, “Bill Gates started small.”
For more information on Leuca's products, visit their web site: http://leuca.med.cornell.edu/Macjordomo.
Why do we keep targeting the PC clone organ bank? Because that's where the goodies are. The hardware goodies, that is. As luck and Bill Gates would have it, fairly soon there will be better building blocks in it for us.
Last week, at WINHEC 96 (Windows Hardware Engineering Conference), in San Jose, Microsoft announced its support for a number of industry initiatives, some of which are of great interest to us. Specifically USB and IEEE 1394—a.k.a. FireWire for the Apple connected.
But first, let's marvel at the juxtaposition of Windows and Hardware Engineering. Years ago, IBM lost control of the PC platform. The efforts to regain proprietary command of the PC standard with PS/2 and OS/2 were not met with great success. The IBM PC/AT, instead, became the de facto standard and grew almost organically without anyone formally at the helm. Buses came and went: We had EISA (too expensive), VESA or VLB (too specific), and finally settled for PCI and the old PC/AT bus, renamed ISA in honor of the industry taking it away from IBM. Creative Labs surprised everyone, including themselves, I hear, by creating the SoundBlaster standard. Today, you can buy an Intel motherboard with a Creative Labs chip on it. (Sound remains one of the messier areas of the organ bank, one we rely on the least)
Speaking of Intel, by building more than microprocessors and chipsets, but also motherboards and even complete systems, the company put itself in a very nice position to control the hardware part of the PC platform. In the process, they coopted firms like Creative and S3 (for SVGA graphics). But imagine a new processor or motherboard that doesn't run Windows. Who would blink first? Hence WINHEC 96.
Of course, Microsoft doesn't have to bless USB and IEEE 1394. One can and will write drivers for devices using these standards, but it helps to know that the support will be there.
Both new standards are borne out of a frustration with the current methods of connecting peripherals. There is also the recognition of a market limit. For personal computers to become more pervasive, especially in homes, the task of connecting peripherals—be they classical ones such as printers and modems, or new ones such as DVD players or digital video cameras—must be made less complex. Otherwise, opportunities are lost for everyone.
Today, Plug and Play works ... almost. On my Fall 1995 Intel motherboard P&P finds two mice, including a non-existent PS/2 mouse, and needs to be goaded into binding the sound hardware to the OS. To be fair, many other instances, such as connecting communications hardware, work very nicely.
But P&P is just a good hack, while USB and 1394 are designed solutions. The Universal Serial Bus will connect the lower speed devices such as modems, printers, and scanners, while IEEE 1394, with speeds up to 400 Mb/s, will do nicely for hard disks, DVD players, and video cameras. More than speed, these connectivity standards offer self-configuration and hot connect and disconnect. The system will recognize that you've plugged in an ISDN adapter (a sore point these days), or your video camera, and will configure itself accordingly. True plug and play. Thus at last offering consumers an experience as simple as the proverbial toaster: A computer you never have to open. (Well, maybe for a little memory to run the latest software upgrade.)
To us, it means the industry will produce chips that support USB and IEEE 1394, and peripherals that use these standards. Anything that helps connectivity and lowers prices because of wider market acceptance is a boon to us. Especially for high-speed digital media and communications applications where the BeOS shines.
When? Not a great deal will happen this year. Intel is already offering USB parts and Comdex will see many vendors showing off new hardware supporting both new standards. Digital video cameras are still expensive and only two offer Firewire connectivity; DVD players are not yet available. As always, the brochures look sharp while the reality of the implementation is more gradual. A book published by Microsoft in 1985 -- "The New Papyrus," if memory serves—described the future as belonging to the CD-ROM. But eight years later, only half of all personal computers included a CD-ROM player
This time, I believe the change will be more rapid because, contrary to the CD-ROM, the industry doesn't need to generate a new genre of content for these connectivity standards to take hold. On our side, we're happily readying ourselves for another raid on the bank.
