(c) 2007-2008 Cyan
Recently, I went through the process of upgrading my PC. Since I use BeOS R5 full-time, it was paramount that the system was entirely compatible with R5, and also powerful enough to justify upgrading my old Athlon 1.33GHz system (which also had a few annoying hardware bugs relating to the PCI bus).
While the last PC upgrade I did -- 6 years ago -- was easy, thanks to the Frizbe Hardware Matrix and other community resources, I found practically no information this time. It seems that very few people have even bothered trying R5 on modern hardware, assuming that it won't work, and those few that have tried it often dismiss it as incompatible when they hit some of the common problems.
By publishing this document, my hope is that some BeOS R5 users can be saved from migrating to other platforms. As I discovered, there's seldom any reason BeOS should be relegated to ancient hardware or ditched completely because it "won't boot".
For those of you wanting to build a fast, modern system that's compatible with R5, scroll towards the end of this document for a description of the system that I'm using. I recommend building something very similar to ensure complete support, because with so few reports of success on modern hardware (mostly due to lack of applying the correct workarounds), it's quite hard to find any recommendations at all.
Note that this document is NOT intended for laptop or small-form-factor computer users. While the principles discussed in this document also apply to these systems, you may not have much luck. This is because these machines are almost totally unexpandable -- if the manufacturer has stuck a pile of proprietary unsupported devices inside, then you're stuck. If you're building from scratch, I strongly recommend using a full ATX motherboard, to make sure you've got plenty of expansion slots.
Many of the solutions listed here will already be familiar to experienced BeOS users. The purpose of this article is to collect everything together in one place to provide a reference for anyone having trouble booting BeOS on a new system, or planning to build a new system that's compatible with BeOS.
While Haiku is clearly the future, and is making very significant progress, it isn't quite ready for day-to-day use yet. BeOS R5 is what we have right now, so it's still very valid to keep it running.
For those of you who might complain about having to buy extra hardware (e.g., cards) to run BeOS, remember this: £30 spent on extra hardware to run your favourite OS is nothing, compared to Mac users who spend £1,000 or more to run their favourite OS.
Thanks to everyone in the BeOS community for the various bits of information which helped create this document, and special thanks to those developers who created the essential patches and drivers mentioned here.
- Cyan
While there might be some systems out there which can never boot R5 (at least, without extensive patches that don't exist yet), I haven't come across one yet. However, that doesn't mean you can just plug in your BeOS hard disk and expect it to boot right away.
There are basically six problems with getting BeOS to work on modern machines:
Thankfully, there are fixes for all of these problems, which work in almost all situations.
Once it's booted, there's more to contend with:
Fixes for these will be addressed later in the document.
As many of the problems listed above can actually stop the system from booting, the patches and workarounds cannot be applied from within BeOS.
There are several workarounds to this -- the following methods come to mind immediately:
I recommend using BeOS 5 Personal Edition. This is because the image file can be easily moved between machines (physical and virtual), without any special tools required. It can be installed onto its own partition later, and can be upgraded to Professional Edition status by copying the relevant files from the Professional Edition CD.
There are some more recent BeOS distributions released by third parties which contain a number of patches already. You're free to try these first, but I haven't tested them personally. Bear in mind that some patches fix some machines, but break others, so a modern distribution is no guarantee of a fix. For this reason I still strongly recommend the use of plain BeOS R5 to begin with.
Do NOT install BONE to start with -- it only complicates matters. Also do not install any extra drivers above what's included with R5.
Generally, on almost all R5 installations, it's a good idea to change the disk cache settings. Failure to do this can lead to some very strange issues, including boot problems, on all systems.
To change it, move the file /boot/home/config/settings/kernel/drivers/sample/kernel to /boot/home/config/settings/kernel/drivers/ and open it in StyledEdit.
Change the line:
# disk_cache_size 2048
to:
disk_cache_size 16384
(yes, remove the # character as well)
Save the file, and it's done. Everything from here onwards will assume you've done this.
Also note that if you're installing onto a new partition, pick a block size of 2048 for the new partition. Otherwise you may run into various bugs.
While I don't recall the specifics of the problem, some kind of memory space collision occurs in BeOS when the system RAM plus the video card's RAM exceeds a certain threshold.
Generally speaking, it's possible to install up to 1GB of RAM on a plain BeOS R5 (net_server) system, or up to 768MB of RAM on a BONE system. However, most modern video cards have a substantial amount of RAM. As a result, you need to lower these figures.
512MB usually works fine for both net_server and BONE, with practically all video cards (except maybe some of the very largest ones, e.g. 512MB, but that's untested). Here are the configurations I've tested on various machines:
As you can see from the above, 512MB is a pretty safe bet. If you go above 512MB, all bets are off. I don't think the number of DIMMs affects whether BeOS will boot (but if you're having trouble, try removing some anyway). It might affect whether or not BeOS can see all the RAM though -- for this reason I suggest avoiding "unusual" configurations; stick with single DIMMs or matching pairs.
If you're building a new system primarily for BeOS, I recommend putting only 512MB of RAM in the system at this stage (it can be upgraded post-Haiku of course). If you buy today, you can still get hold of fast 256MB DDR2 DIMMs, so you can even run dual-channel (although I've benchmarked both single-channel and dual-channel configs, and haven't found any real measurable difference). 512MB is still plenty enough for BeOS unless you're doing something really unusual, and it's cheap too.
If you want to have more RAM installed in the system, you run the risk of BeOS freezing during boot. However, thanks to Euan's RAM Limiting Bootloader, you can usually limit your RAM to 512MB, thus fixing the problem.
A word of caution though -- from reading around, it seems that there may be some compatibility problems with the RAM limiting bootloader and some PCs. So the safest approach is still to only install 512MB of RAM. If you need to dual boot between BeOS and something that requires more RAM, consider using a pair (or four) 512MB DIMMs. This way, if you have any trouble with the RAM limiting bootloader on your hardware, you can always resort to physically adding/removing RAM when required.
If you have 512MB RAM or less, I recommend that you don't install the RAM limiting bootloader to avoid any unexpected compatibility trouble.
Ever since AMD added support for Intel's SSE instruction set to their processors (with the Athlon XP), there has been trouble booting BeOS in some situations. This occurs due to a quirk of AMD's SSE implementation, that BeOS does not have a workaround for.
If your system suddenly reboots during the bootscreen, and you have an AMD processor, this is probably the cause. However, not all AMD-based systems suffer this problem, so try booting it anyway.
Thankfully the fix is now well-understood, and available in many forms. If you're using Personal Edition, I recommend using The Magnetic BePatch-O-Matic, although this requires the ability to run a DOS program (a boot floppy or CD is sufficient, as is the Windows command prompt).
Another option is to use a BeOS boot floppy image which includes the Athlon patch. Search on Bebits for "Athlon XP" and you should be able to find quite a few solutions to the problem.
Some of these patches work by disabling SSE completely, so you won't be able to take advantage of the extra performance SSE can deliver in some situations (mainly multimedia). Other patches work by enabling SSE in an AMD-compatible way. If one type of patch doesn't work, try another.
Some BIOSes allow you to disable the SSE instructions. It may be worth checking for this feature first, before you start applying patches.
Caution: Only apply the Athlon patch if your system definitely needs it. Otherwise the patch may actually be causing the boot problem.
Today we take on-board hard disk controllers for granted, but not too long ago, you needed a separate card to plug your hard disk into.
Whether it's on-board or a separate card, you need drivers to support the hard disk controller, just as you need drivers to support a particular sound card, video card, etc.
For a long time, hard disk controllers have all followed a standard. This has allowed operating systems to "just boot" on any system, with just one driver supporting all controllers.
However, recently, with the introduction of SATA, and more modern chipsets like the Intel P965, P35, etc., there have been some changes. As a result, when you try to boot BeOS on such a machine, it will stop on the boot screen, with a message along the lines of "no boot device found".
There are a few solutions to this problem:
Safe mode and BIOS options
Some chipsets support the old standards well enough to be able to
boot BeOS -- under some conditions.
If you're using a SATA hard disk,
check in the BIOS for an option called "SATA mode" or "IDE emulation",
and set it to "IDE" or "Enabled".
If you're using an IDE or SCSI hard disk, set it to "AHCI" or
"Disabled" (even if no SATA devices are connected).
If this alone doesn't fix it, try pressing space when the BeOS boot
screen first appears, and select "Disable IDE DMA" in the safe mode
options. Also try with and without "Don't call the BIOS" selected in
the safe mode options.
Third-party drivers
If the above technique doesn't work, or is too slow, the next thing
is to try installing third party drivers. Start with the
IDE Replacement Driver.
If that doesn't work, you might want to try the driver mentioned
over at
http://www.bebits.com/talkback/4517
(7th post up from the bottom), but bear in mind that this hasn't
seen the same level of testing that the standard IDE Replacement
Driver has, due to being less well-known.
IMPORTANT NOTE: Don't install either of these drivers unless
you actually need them! Some systems will fail to boot with them
installed, while they work okay with the standard BeOS drivers.
Using a different IDE port on your motherboard
Some motherboards have an extra set of IDE/SATA ports, controlled by
a different controller chip to the main set. If the above software
solutions can't make BeOS boot, try connecting your hard disk to
a different port. You may find that either the standard BeOS driver,
or the IDE Replacement Driver supports the different controller chip
used for the other set.
Using a different IDE hard disk controller
You don't have to use the hard disk controller built into your
motherboard -- and if the above options don't work for you, then you
can't.
The simplest and cheapest fix is to pick up a Promise Ultra100 TX2
on eBay or similar. This is a dual-port IDE hard disk controller card,
that's well-supported with the
IDE Replacement Driver
(it isn't supported with the standard BeOS driver, so make sure the
IDE Replacement Driver is installed first).
There are multiple variants of this card with slightly different model
names -- your success with these may vary.
Using a SCSI controller card with a SCSI hard disk
Similar to the above option, you can use a supported SCSI controller
card connected to a SCSI hard disk. The documentation supplied with
BeOS tells you which SCSI adaptors are supported -- the Adaptec
2940W and 2940UW are among those. The Adaptec 29160 is also supported
but only if you copy the driver file ("aic78xx") from Dano.
Since real SCSI drives are either hideously expensive, or small,
I recommend converting an IDE drive to a SCSI drive using a bridge
board. This is described in the following section.
If you only need 120GB of storage space or less, I recommend using
a Promise IDE controller card instead, because it'll work out cheaper.
As you're probably already aware, IDE hard disks have had a history of various capacity limitations over the years. Most of these have had BIOS fixes, so if you've recently upgraded your hard disk, make sure you're using the latest BIOS for your motherboard.
The most recent, and most fundamental capacity limitation is the 136GB barrier. This came about because IDE hard disks use 28 bits to specify which sector number to read. This sets the maximum size of an IDE hard disk to 136GB.
To work around this problem, hard disk manufacturers developed a new protocol, carried over the existing IDE interface, called 48-bit LBA. This uses 48 bits instead of 28, raising the maximum capacity to about 140,000 terabytes, so we should be okay for the next 20 years before the same problem begins to appear again.
Unfortunately, because this change to the protocol happened after BeOS R5 was released, it isn't supported in BeOS. It also post-dates the IDE Replacement Driver, so that doesn't support it either.
As a result, when you try to use such a drive in BeOS, you may find that only the first 120GB of the drive is visible -- or you may even find that the drive can't be accessed at all.
Because SATA drives (when used in IDE emulation mode) behave the same as an IDE drive, the same limitation applies there.
Alternative drivers
One approach to fix this problem is to install the drivers mentioned over at http://www.bebits.com/talkback/4517 (7th post up from the bottom), but bear in mind that this hasn't seen the same level of testing that the standard IDE Replacement Driver has, due to being less well-known.
This driver is said to support 48-bit LBA, although whether or not it supports SATA hard disks is unknown -- the original IDE Replacement Driver seems to have trouble with this.
USB solution
Another solution is to put the large hard disk in an external USB enclosure, and use a small (4 - 120GB) IDE hard disk to boot BeOS from. With the USB Storage Module installed, you may be able to access the USB drive. USB uses the SCSI protocol, not IDE, so has a much higher limitation of 2TB.
Note that you often need to install the "USB patches" for R5 before the USB Storage Module will work correctly -- search on Beshare for "USB-patches.zip". Also, read the supplied documentation with the USB Storage Module -- there's an option you need to select in order to avoid a KDL at boot on most machines.
If you can't get access to the drive even after installing both of these drivers, you may need to try a different USB enclosure -- they do differ in terms of how well supported they are.
The above configuration only supports USB 1.1. This limits transfer rates to about 1MB/sec. While this may be okay for casual use, it's definitely a bottleneck when working with large files.
The solution here is to install the USB stack from Haiku onto R5. Michael Lotz explains how to do this at his weblog.
Note that because it's still under development, your success may vary. After installing this you may lose support for some of your existing USB devices. It includes its own USB mass storage drivers, so you shouldn't need to install the USB Storage Module (indeed, uninstall it first). However, if you can't get it to work, try removing the mass storage driver that comes with the Haiku USB stack, and then install the USB Storage Module in replacement for it.
Also note that installing BONE seems to occasionally cause USB trouble, as can installing the 48-bit LBA IDE driver mentioned in the "Alternative drivers" section above. As with all new configurations, always test with a plain unmodified R5 installation first.
SCSI solution
SCSI uses its own protocol, so it has never suffered the capacity limitations that IDE has. This protocol supports hard disks up to 2TB in size, so it's currently fine for all modern hard disks, but will become a problem in the next 2 years (along with USB).
As mentioned in the "Unsupported hard disk controller" section, there are many BeOS-supported SCSI cards. Combining one of these with a sufficiently large SCSI hard disk works around the problem completely.
Unfortunately, real SCSI hard disks are extremely expensive. So instead of using a SCSI hard disk, I recommend using an IDE hard disk, and connecting a bridge board to it. The bridge board is basically a SCSI-to-IDE adaptor that sits between the IDE hard disk and the SCSI card, and translates the SCSI commands to IDE. All modern bridge boards support 48-bit LBA on the IDE side, so you can use hard disks up to 2TB in size.
You can also get SCSI-to-SATA bridges, allowing you to use a SATA hard disk instead of IDE. These are generally a little more expensive though.
If you choose to do this, make sure you get a bridge board that's sufficiently fast for what you want to do. Ideally look for at least "Ultra-wide" (40MBytes/sec) or "Ultra160" (160MBytes/sec) support to ensure a transfer rate close to the speed of most hard drives. Also avoid "ATAPI" bridges -- these are designed for CD-ROM drives only.
These boards are made primarily by Acard and Addonics (the latter appear to be re-branded Acard boards). They're not particularly cheap -- expect to pay about as much as a 400GB hard disk (as of late 2007) for a fast one -- but on the other hand I've found this to be a very reliable, fast solution.
60GB "limitation"
If you're having trouble making partitions greater than ~60GB, you've hit a bug in the "mkbfs" tool that comes with R5. The fix is described here. This particular problem has nothing to do with hard disks, hard disk controllers or protocols -- it's a simple software bug.
BACKUP
Whatever solution you use -- a reminder: MAKE SURE YOU HAVE A WAY OF BACKING THE DRIVE UP REGULARLY! If you have small amounts of data, the cheapest way to do this is using CD-Rs/CD-RWs. If you have large amounts of data, use another identical hard drive. There's little sense in tape drives, DVD or HD DVD, etc. -- the capacity is just too small. Whatever approach you use, make sure it's easy to do, otherwise it'll be forgotten, the drive will fail and you'll lose everything.
If you're using another hard drive, you don't need to arrange for access to this hard drive in BeOS -- you can attach the other hard drive to one of your motherboard's IDE or SATA ports, and use another OS (booting from a Live CD if required) to do the mirroring.
Make sure you keep an eye on your data to make sure it's not getting corrupted unexpectedly. While this isn't usually a problem if you're using the standard BeOS drivers (SCSI or IDE) or the IDE Replacement Driver, it could be a concern if you're using mostly-untested drivers.
Don't keep your backup drive attached to the system -- remove it when not in use. This way, it should have a much longer lifetime, and is less likely to be killed simultaneously with your main drive due to a power supply failure (a very common cause of PC component destruction).
Although USB keyboards and mice work okay on many machines, you may encounter a problem on some machines, especially if you have a non-Intel, non-Via chipset.
While this is unlikely to make the system unbootable, if both your mouse and keyboard are USB, then the system is essentially useless.
There are three types of USB controller -- UHCI, OHCI and EHCI. Prior to USB 2.0, Intel and Via made chipsets using the UHCI standard, and everyone else (nVidia, ATi, SiS, etc.) made chipsets supporting the OHCI standard. Later, when USB 2.0 came along, EHCI was introduced to support the new high-speed devices, but when a low-speed device (such as a mouse) is plugged in, it falls back to either UHCI or OHCI depending on who made the chipset.
BeOS R5 only supports UHCI as standard. So if you have a chipset made by a company other than Intel or Via, the USB will be unsupported.
The solution to this problem could be to install the USB patches (mentioned in the "USB solution" section under "IDE or SATA hard disks greater than 120GB"). These seem to include support for OHCI controllers.
The Haiku USB stack as of 2007 has an incomplete OHCI implementation, so that isn't recommended if you're using a USB mouse/keyboard.
If this doesn't fix the problem, check in the BIOS for an option called something similar to "Legacy USB emulation", "USB mouse/keyboard emulation", etc. Try with this option both enabled and disabled -- sometimes it conflicts if enabled, while on other machines, it may need to be enabled in order for the mouse/keyboard to work.
As a final solution, you may need to use a PS/2 mouse and keyboard. If your system lacks a PS/2 mouse port, you can use an old serial mouse (assuming you have a serial port), but if it lacks a PS/2 keyboard port, you're stuck.
Note: Before assuming your mouse/keyboard are unsupported, make sure the operating system is actually running, as opposed to frozen. If one of the devices (mouse only / keyboard only) is working, this is easy to check. If neither work, keep an eye on the time displayed in the Deskbar for a few minutes to see if it changes.
Tracker and Deskbar have been known to occasionally freeze at boot-time on some systems, depending on the version of Tracker used. This can give the appearance of a partly-frozen system. Press ctrl+alt+del to see if it responds -- if it does, select "Restart the Desktop". Tracker is most likely to freeze if the hard disk controller isn't properly supported, but there are other causes too, such as the very high bug count in Tracker. Remember: Always test with the bare-minimum set of drivers installed.
If none of the above workarounds fix it, in different combinations, there are still a few more things left to try.
Reset the BIOS by selecting "Load optimized defaults" or similar. This is necessary on all new machines to make sure you're getting optimal performance (motherboards often ship from the factory with fail-safe settings). Something may have been changed which is causing some kind of conflict.
Try BeOS in safe mode. Also try the options "Don't call the BIOS", and "Disable IDE DMA".
Remove all cards (apart from video and the hard disk controller) from the system and try booting. Also try moving the cards into different slots -- this generally causes the BIOS to assign new resources to devices, which can clear up certain conflicts. This is actually very common.
A variant of the above suggestion, if you're using a PCIe x1 video card (e.g., Matrox G550), try installing it in a PCIe x16 slot (yes, this is perfectly valid). I have found this clears up some freeze-on-boot issues.
If your BIOS has a setting for "PnP OS", try setting it to both Yes and No.
Try disabling USB in the BIOS. Sometimes it can conflict with the video card, causing a crash or freeze on boot.
If there's a setting in the BIOS for "MPS Version", try with both 1.1 and 1.4 -- 1.4 is preferred though. This is a cause of freezes and hardware problems particularly if it's set to 1.1.
As already mentioned, disabling/enabling legacy USB support, and disabling/enabling IDE emulation for SATA can significantly affect stability.
Try disabling all on-board devices, such as the sound, network, and even the hard disk controllers if you're using a separate card for that.
If the BIOS has an option for "Assign IRQ to VGA", try changing it. Also try disabling S.M.A.R.T. for hard disks in the BIOS.
If there's an option to select between PIC and APIC modes, try changing this. Generally it should be set to APIC for a multi-core system, but change it if you need to.
In the CPU features section of the BIOS, try disabling Hyperthreading, enabling "Limit CPUID Max Val", and try various other options in there. Also, play around with any "Memory hole" settings (be sure to put them back the way they were if it doesn't help).
If none of those fix it, then you have a pretty obscure issue. At this point, I recommend installing alternative versions of BeOS, such as R5+BONE, Dano, Zeta, or the recently-posted "R5.05 BONE".
Okay, so it's booting, and running relatively stable (if it isn't, then keep trying everything mentioned already until it is).
However, there are probably some issues to resolve...
At boot-time, BeOS measures the speed of the CPU and stores it in a 64-bit integer. It uses this for various timing purposes, which are particularly critical for multimedia playback.
Unfortunately, the way the calculation is done is incorrect, and an internal variable overflows if the CPU speed is above ~2GHz. This problem shows up in BeOS as the CPU speed being reported incorrectly, and multimedia playback (and other timing functions) don't work correctly.
Thankfully the solution has been around for some time, and is very stable. Installing Michael Lotz' cpu_fix clears this problem up. It has even been reported by users to help on systems where the CPU is slower than 2GHz, due to the accuracy being improved.
I've never seen or heard of any problems that could be traced to cpu_fix being installed, so as a result, I recommend installing this under almost all conditions, even when the CPU is significantly slower than 2GHz.
Unusual slowdowns can usually be traced to driver problems. Assuming you've eliminated all unnecessary drivers as a cause (e.g., video card, sound card, network card) by not installing them, the most likely driver to be causing trouble is the hard disk controller driver.
To fix this, follow the suggestions mentioned in the previous sections regarding the hard disk.
Some of Intel's older processors (Pentium 4, possibly Pentium D) and their soon-to-be-released 45nm processors feature Hyperthreading. While Hyperthreading is generally okay under BeOS when used with a single-core processor (it'll either show up as a single or pair of processors), it can cause a performance problem when there are multiple cores.
This is because BeOS does not know the difference between a "virtual" CPU (implemented with Hyperthreading), and a real CPU core, so it will schedule threads to run on different "virtual" CPUs, when in fact they're competing for shared resources in that configuration.
If you run into this problem, one workaround is to disable Hyperthreading in the BIOS, although some BIOSes lack this option, and some other BIOSes have it, but it doesn't do anything.
Alternatively, you could perform a test to find out which processor numbers correspond to which physical processors in Pulse. To do this on a dual-core Hyperthreading CPU, launch two instances of Teapot (you'll need to modify the preferences in FileTypes to allow multiple-launch for this application). Open pulse, and you should see two processors at maximum load, and the other two near-idle. Disable each possible pair of processors in turn (e.g., #0 and #1, #1 and #2, #2 and #3, #0 and #2, #1 and #3, #0 and #3) and write down the framerate for each combination. When you find the highest framerate, you've successfully disabled the two "virtual" processors -- do this each time the system boots to avoid any performance problems.
If you have a multi-core or multi-processor system, and only one processor is showing up in pulse, check the following things:
If you can't resolve the problem by following the above steps, then the chances are, your BIOS does not support MPS (MultiProcessor Specification).
This is an older standard (now replaced by ACPI) which operating systems use to detect and enable the extra processors in the system. Unfortunately, because it's in the process of being phased out, many modern BIOSes lack this feature, and therefore you'll be stuck with only a single processor in BeOS.
If you're buying a new multi-core system specifically for BeOS, you need to make sure it has MPS (otherwise you may as well get a single-core processor and save money). The most certain way of doing this is to actually test BeOS on it, but the second best way is to check in the BIOS for an option labelled "MPS version". If the option isn't there, the chances are it doesn't support it. Do NOT rely on the motherboard manual to find this option, because they often just cut+paste the BIOS description from an older manual.
As a result of much research, I have managed to find out the following two absolutes:
One trend I have noticed is that MPS seems to be more likely to be present on boards which have the "Phoenix-Award BIOS". Boards with just the "Award BIOS" tend to be less likely to have MPS. Both BIOSes look almost identical in their setup utilities, so you need to have a close look.
If you're specifically having trouble making BFS partitions greater than 60GB, you've hit a bug in the 'mkbfs' tool that comes with R5.
The solution is to either make the partition in Dano / Zeta (R5 can read the partition -- the problem is with actually creating it), or copy the 'mkbfs' file from Dano onto R5.
Note that this specifically fixes a problem with making BFS partitions
larger than 60GB.
If you're having trouble going above 120GB, or are having problems
making any partitions at all, you're experiencing a problem with the
hard disk controller or drivers. Refer to the two sections earlier
dealing with these.
If your video card isn't working properly, even after trying all the appropriate driver versions for it, you may need to check in the BIOS for an option labelled "Assign IRQ to VGA" or similar, and enable it. You may also need to try the video card in different slots.
If you're experiencing crackling sound, you could have any number of problems. Putting the sound card in a different slot is quite likely to clear the problem up. Also try enabling/disabling real-time audio in Media Preferences. You may also want to try installing the leaked Beta Media Kit, and select "Tri-linear resampling" in the pop-up list in the audio mixer (higher resampling settings are broken in this particular leaked beta and have poor quality, while lower resampling settings are inherently poor).
Playing with the "PnP OS", "PIC/APIC" and "MPS version" options in the BIOS are also likely to have an effect on devices which aren't working correctly.
If you're experiencing crackling sound only when you do certain things (e.g., scroll in a web browser -- this would be a video card driver issue -- or connect a certain USB device), write a bug report to whoever wrote the driver that's causing the interference. Politely remind them that interrupts must be disabled for absolutely no more than 10 microseconds -- this is a hard limit. However, some devices are simply designed in such a way that they'll cause interference no matter how you write the driver, and these devices must not be used. The problem might not show up in Windows or Linux, but those are not real-time systems.
This particular problem deserves a special mention.
Assuming you've tried all possible versions of drivers for your graphics card, and the relevant BIOS options, and still can't get it to work, your card may simply be unsupported.
For some devices, a simple PCI ID patch is all that's required to make them work. Ask around on one of the relevant BeOS forums for more info.
However, some cards are simply unsupported. Most noteworthy are the nVidia Geforce 8000-series cards. These cards use a different internal design to previous cards, and nVidia are extremely tight-lipped regarding specifications. Basically, they're not interested in having their cards supported in alternative operating systems.
If you're buying new hardware, I urge you to choose hardware which has programming specifications available. By doing this, you stand a much higher chance of having the device properly supported in Haiku, regardless of whether or not there are currently drivers available.
This pretty much limits you to a choice of just two ranges of cards:
If you thought the problem was bad today (with only 2D acceleration being required for BeOS), just imagine how bad it's going to get if Haiku one day uses the 3D hardware for its desktop. So make sure whatever you buy at least has some programming specs available!
There are also drivers for nVidia 7000-series and older video cards, although due to lack of official specs, certain features are unsupported on the higher-end cards -- e.g., there's no video overlay acceleration available on 7000-series cards, which makes video playback CPU-intensive and relatively slow. These types of issues could potentially exist for a long time with nVidia's current policy, so I can't personally recommend buying nVidia cards at the moment.
Personal experiences with video cards
So far I've tried three PCIe video cards. Below I detail my experiences with each of them:
Here's the complete hardware specification for the machine I use on a day-to-day basis. This machine sees many hours of heavy use in BeOS every day, sometimes running overnight, and hardly ever booting other operating systems (although I do use QEMU in BeOS sometimes, with the kqemu accelerator, which is stable and extremely fast). So I can say with confidence that this particular configuration is absolutely stable:
What works:
What doesn't work:
What's needed to get BeOS to work on this system?
Surprisingly little, actually:
As you can see, apart from the hard disk controller, this system is pretty much as easy to get working in BeOS as any other, despite being a very modern machine.
Given the ease of making the P965 work under BeOS, and the small changes between the two chipsets, I would imagine that the new Intel P35 chipset should pose no new problems, and since the P35 chipset supports the new bug-free dual-core processors (Exx50 series), it could potentially make for a very attractive low-cost BeOS system (anything with a quad-core processor can't really be called low-cost). Unfortunately the P965 chipset does not support these new Exx50 processors (but it does support the Q6600 and Q6700 quad-core processors).
I wouldn't recommend the older Core 2 Duo processors due to the presence of bugs which may trip BeOS up (or just about anything). The Q6700 is bug-free (but ridiculously expensive). The more affordable Q6600 G0 stepping is also bug-free (but not the older, non-G0 stepping which has bugs), and all Exx50 dual-core processors are also fine. Anything else is a potential concern as of 2007 (although the situation will improve throughout 2008 as the buggy processors are discontinued and replaced with more bug-free ones).
I would also advise using an Intel chipset system, which means that you need to use an Intel CPU. Support for non-Intel chipsets under BeOS may vary: many non-Intel chipsets have a long history of very serious bugs
If you want to use all cores of a multi-core processor in BeOS, don't forget to make sure the motherboard has MPS -- DFI boards do, Gigabyte boards do not. Also when choosing a motherboard, make sure there are at least 3 PCI slots available, plus a graphics slot.
Here are some example system configurations which stand a chance of working in BeOS. Bear in mind that only one of these has actually been tested -- the one I detailed above when I described my system. If you can't afford BeOS not to boot, then build this one. I take no responsibility for any mistakes!
System 1: Low-budget configuration (COMPLETELY UNTESTED)
System 2: Medium-budget configuration (COMPLETELY UNTESTED)
System 3: High-budget configuration (completely tested, 100% stable)
See above for the complete specs.System 4: Fun-budget configuration (untested, but almost certainly R5-compatible)
Hopefully this document has been of some use to you. If you have any corrections, questions, or reports of compatibility with particular hardware, please get in touch! See towards the bottom of this page for an e-mail address.
- Cyan