Excerpt: Data Translations and Devices

Data Translations

As described elsewhere in this book, BeOS is "object-oriented" through-and-through. While that term is typically only of interest to programmers, there are a few places where the concept bubbles up to the user level, and the concept of Translators is one of them. Any time an application has a Save As... option, you're being given the option to translate the data format of the current file into another format. For example, an imaging program might let you save TARGA images as TIFFs. In other operating systems, the code that handles this translation has to be built into each and every application, which means several things: The developer has more work to do, the program becomes more bloated, and if you need access to a file format that isn't built into the application, you're out of luck. Know what Be has to say to that? Hooey.

In BeOS, data translation engines are "objects" called Translators that live in a central location in the operating system. Any application can take advantage of format translation services by simply taking a look at the list of installed translation objects. Programs stay smaller, developers don't waste time duplicating each other's work, and you can extend the capabilities of many applications at once by adding a single file to your system. Just the way it should be.

Translators can exist in one of two places:

/boot/beos/system/add-ons/Translators

or

/boot/home/config/add-ons/Translators

As always, the first location contains files provided by Be with your BeOS installation, and the second location is the one you should use to add new Translators to your system. If you add Translators to the user-level folder that have the same names as files in the system-level folder, they will be used instead of the system-provided versions.

As you know, some file formats also have optional settings. For example, the JPEG file format in imaging applications always gives you the option to specify the degree of "lossiness" with which images should be compressed. Specifying those kinds of preferences is the purpose of this panel.

Not all Translators have configurable settings, though. When you select non-configurable Translators in this panel, you'll just see a few details about it in the right-hand pane. Clicking the Info... button may give you additional information, if it's been provided by the developer.

As of R4, the majority of Translators that come with BeOS deal with image formats. However, you'll eventually begin to see a larger number of filetypes with applicable Translators as well. For example, if a developer creates an appropriate Translator, all of your word processing applications could suddenly gain the ability to read and/or write common word processing formats popular on other operating systems. As of R4, the only non-image format available was the StyledEdit Text translator, which gives plain text editors the ability to use fonts and colors and still retain the plain text file format, just as StyledEdit does now.

In order for an application to take advantage of translation services, the developer must program it to do so. Most do, but you can't assume that all applications automatically use the translations system. If your favorite application doesn't, write a polite note to the developer requesting the feature.

Devices

	Figure 9.08 The Device preferences panel is broken down into four categories. Devices are assigned to a category depending on how the system allocates resources to them.

Present only in x86 machines, the Devices panel provides an interface onto every piece of hardware built into or attached to your motherboard. For the most part, this panel is purely informational in nature; it's not going to let you just jump in and start reconfiguring your hardware with wild abandon. However, there are a few editable components here that may, in certain specific cases, help you to get supported hardware working with BeOS. Note the word "supported" there. If a driver for a specific piece of hardware is not present on your system, no amount of twiddling with Devices will get it working.

If it ain't broke, don't fix it. If everything attached to your system (for which you have drivers installed) is working fine, there's no reason to fiddle with settings in this panel. Injudicious tampering with resource settings can yield unpredictable results. Change only the settings you understand, and change only one thing at a time, testing after each change.

What This Panel Isn't If you've used Windows's Device Manager before, this panel may look somewhat familiar. On closer inspection, however, you'll notice some important differences. For one thing, Windows's Device Manager is aware of devices beyond your motherboard. It knows not only that you have a video card installed, but what brand of monitor is on the other end of the video cable. It's able to do this because Windows's Device Manager is also an interface onto the drivers installed in your system, not just the physical hardware. In contrast, the Devices preferences panel in BeOS works at a very low level, and does not tell you anything about drivers that are available or in use. Second, Windows's Device Manager lets you configure--or even remove--just about anything in your system. Users can get pretty tangled up in Windows's Device Manager, and can end up spending hours reinstalling drivers and juggling resources to make everything right. BeOS takes a different approach. It says, "Look. This is a list of all of the hardware that has been clearly and unambiguously identified by the operating system. If you have a driver for it, or if it's supported by the kernel, it will work."

The vast majority of the time, everything does work. However, there are variables out there in hardware land that can make things very difficult for BeOS. It all boils down to resources: IRQs (interrupt request queues), DMAs (direct memory addresses), and IO Port Ranges. We don't need to get in too deep with those terms (and they're covered in more depth in Chapter 16, Troubleshooting and Maintenance), but it's useful to understand the difference between the major categories of devices listed in this panel.

x86 History In the past, most x86 hardware was incapable of sharing most resources with other hardware in the same machine. This limitation was built into the ISA bus, which once prevailed in x86 computers. Since the early 90s, however, several other pieces have been added to the puzzle: First, Microsoft's Plug-and-Play specification was designed to manage resource conflicts at the operating system level. As you've no doubt heard (and possibly experienced for yourself), PnP is not always successful in its mission. Next, the

PCI bus was introduced, improving the situation greatly by simply allowing many resources to be shared between devices without complaint. Plug-and-Play devices exist for both ISA and PCI buses, but the nature of the PCI bus actually makes the PnP mechanism unnecessary in a well-designed operating system. Finally, the USB and FireWire buses were introduced to put an end to this nonsense for good. You can read about those buses online in the online-only chapter The Future.

At this point in history, most x86 machines include both ISA and PCI buses, and many users out there own both ISA and PCI devices. That means we have to mix shareable and non-shareable resources in the same machine, and to make them all behave under a single operating system. The most important consideration for the operating system is this fact: Most modern devices can have resources assigned to them by the operating system at boot time, while most older devices cannot. Therefore, the OS needs to accommodate the inflexible devices first, and give them the resources they demand. After those devices have been satisfied, whatever resources are left over can be divvied up among the rest of the devices. The moral of the story is this: The fewer legacy ISA devices you have in your machine, the better off you'll be, and the smaller your prospects of experiencing resource conflicts.

When to Use Device Preferences Despite all of this, you may very well own perfectly good legacy devices such as modems, network cards, or sound cards. These devices' resources are set in one of two ways: by moving physical jumpers around on the card itself or through a software-based configuration utility provided by the manufacturer. In either case, the resources are "locked in" as far as the OS is concerned, and cannot be set by the system at boot time. Thus, the primary purpose of the Device preferences panel is to let you tell BeOS that a certain collection of resources is reserved for a specific device at a specific address, and must not be offered to other devices.

If you have such a device, you know it is supported by BeOS with appropriate drivers, and yet you cannot get it to work, then the Devices panel is for you. Let's take a look at the panel's layout, then talk about what you can do with it.

Meet the Panel The Devices panel breaks down your hardware into four categories, each of which can be expanded or collapsed to show the devices in that category. The four categories are:

• System Devices: These devices are embedded in the circuit logic of your machine's motherboard. You'll find entries such as serial controllers, RAM, system timer, and keyboard and mouse ports.
• ISA/Plug-and-Play Devices: These devices live on the ISA bus, but are Plug-and-Play enabled. The most common devices you'll find in this category are the less expensive sound and network cards.
• PCI Devices: This category hosts a mixture of I/O cards and motherboard components, all living on the PCI bus. In newer motherboards, you're likely to find your hard drive controllers, bridge devices that let the two buses cooperate in the same system, newer SCSI adapters, video cards, TV tuners, and the like. Your system may differ.
• Jumpered Devices: This category is reserved for any device that cannot have its resources set by the operating system, such as legacy ISA modems, network cards, and sound cards. This is the only category to which you can manually add entries.

Double-click any device entry to see its Info panel, which has two tabs. The Info tab offers a few low-level stats of interest mainly to developers writing drivers. It also includes an "Enabled" checkbox, which is probably grayed out. Very few devices can be disabled by the user. The Editor tab includes checkboxes and fields reporting on the device's IRQ, DMA, IO port address, and memory range. In most cases, every entry in the Editor panel will be grayed out and uneditable.

As of R4, it was not possible to see a listing of all IRQ assignments at once. This feature will be added to the Devices panel in a future release.

Disabling Devices In contrast to Windows's Device Manager, you cannot arbitrarily tell BeOS to stop "seeing" devices. You can't physically remove your hard drive controller if it's built into your motherboard, so BeOS doesn't let you remove it from the preferences panel either. The exception to this rule is with Plug-and-Play devices. Because the PnP mechanism can cause headaches for users of alternative operating systems, you'll find that the "Enabled" checkbox in a device's Info panel is not grayed out, and can be deselected, thus disabling that device. The only reason to do this is if you suspect a resource conflict between two devices that BeOS was not able to resolve. If this is happening, you should see an entry in the main device list reading "Disabled by system."

Let's say you find that neither your network card nor your sound card works, and they're both ISA/PnP devices. You may be able to get one of them working by disabling the other. Not much of a solution, I know, but better than nothing. The real solution, of course, is to replace one or both of these cards with equivalent PCI cards. A PCI NE2000 network card can be had for $35 or less, and is virtually guaranteed to work perfectly.

Disable Plug-and-Play OS The first thing you should always try when experiencing hardware conflicts in BeOS is to enter your system's BIOS (usually by pressing F1 or Del immediately upon boot) and look for an option reading "Plug-and-Play OS." Disable this option and BeOS should be much happier, though you may have to manually reconfigure some resources in Windows later on.

Adding Jumpered Devices Finally, we come to the real power of the Devices preferences panel. If you have a legacy modem, network card, or other device that is not Plug-and-Play and not PCI, and that is supported by BeOS, but that you can't get working, there's hope yet. Pull down File | New Jumpered Device and you'll find an empty template similar to the Editor tab for existing devices. Give the device a name, choose its type from the picklist, and enter as many relevant details as you have on hand. At the very least, you must enter an IRQ and in most cases, a DMA as well. It's not usually necessary to enter a memory range, since the chances of these causing conflicts is slim. If you're working with a network card, do enter an IO port address. You should be able to determine these settings by studying the card's documentation, the arrangement of jumpers on the card, or by using a software configuration utility that came with the card. Close the template to save your changes, and reboot to see if your changes enabled the device.

Figure 9.09 To reserve a collection of resources for a legacy device, use the New Jumpered Device template. You'll usually want to choose Communications Device | Serial Controller as the device type.

Unfortunately, this technique will not help you to get jumpered sound cards working in BeOS. Jumpered sound cards are simply unsupported, period.

What you have done is to "rope off" a set of resources, telling the system to leave them alone at boot time. The device that demands dedicated resources will get what it needs. Interestingly, this type of resource blocking can be useful even if you're not trying to add an older device to your system. For example, some PS/2 mouse ports have been known to prevent PnP modems from using a valid IRQ (modems should be on IRQ 3 or 4). By creating a new template that reserves IRQ12 for the mouse, you can force the modem back to a valid IRQ. Isn't Plug-and-Play wonderful?

Modem Notes Probably the most common use of the New Jumpered Device template will be to reserve resources for older modems. When adding a modem, use the Device Type picklist in the template to scroll to Communications Device | Serial Controller.

If your modem is on COM3, use IRQ4 and set the I/O range to 3E8-3EF.

If your modem is on COM4, use IRQ3 and set the I/O range to 2E8-2EF.