Hello, All, I own a computer I bought a while back from an independent PC manufacturer. It has an Intel Pentium II MMX at 350MHz, 128MB RAM, an 8GB hard drive, a mixed ISA/PCI motherboard, and an extra PCI (ultra ATA) add-on card (for the newer CDRW drives). The operating system is Windows98 (pre-SE). When I purchased and installed a Creative Labs 4x2x24 CDRW drive onto the ultra ATA card (with Nero v4, bundled), the PC would sometimes freeze when any kind of CD was inserted, full, multisession, or blank. I've changed numerous settings in Control Panel (in the Device Manager section of the System portion), but to no avail. Oddly enough, with Nero running, I could burn CDs without a problem by inserting the blank CD after Nero asks for it, but if I insert it BEFORE Nero asks for it (even if Nero was already running) the PC freezes. As such, after having had enough of the numerous freezes and warm/cold reboots followed by the annoying Win98 blue "blame-screen," I went and installed a newer CDRW drive onto the ultra ATA card. This drive, a generic (BTC BCE2410IM) 24x10x40 drive, reads regular CDs without a hitch, and with it, I was able to install Roxio Easy CD Creator v5 onto the computer. (Since the Nero I was using was bundled with the Creative Labs CDRW drive, it literally refused to work with this new drive, so I had to uninstall the Nero program.) But now when I try to burn files onto a CDR or CDRW using Easy CD Creator, the PC freezes EVERY TIME I insert a blank CDR or CDRW (even if the blank CDRW was preformatted on a different computer). Even if all crucial programs have been disabled, inserting the blank CDR/CDRW at any point causes Windows98 to freeze. Which means that now I cannot burn ANY CDRs/CDRWs. Any help would be more than greatly appreciated. Thank you in advance.

Burners sometimes act weird when connected to an ATA card. I don't really know why. Anyway, try connecting it to one of the on-board IDE ports.

That's right! Most add-in PCI IDE controller cards do not support optical drives. The motherboard IDE ports 'should' support them. Do yourself a favor BACKUP! Sorry, I do not check for private messages

Thank you very much DAVEINCAPS and ham30 for your replies and suggestions. Per your suggestions, I reconnected the CDRW drive to the main PCI bus, where the hard drive sits (with the hard drive as the Master, and the CDRW drive as the Slave). I just finished a successful Read Test and several successful Write Tests on the CDRW drive. Again, thank you very much!

You're welcome. If you only have the burner and hard drive on the IDE ports you may want to connect the burner as master on the secondary. If you have other IDE drives connected, just leave it as primary slave since it's working OK there.

This raises an interesting point: from a technical perspective, optical drives are NOT IDE drives; though they use an IDE CONNECTOR, they are in fact ATAPI devices, and should ALWAYS be attached directly to the motherboard, NOT to an add-in PCI IDE controller card. The motherboard chipset is designed to recognize and control ATAPI devices, while the IDE controller card chipsets are made to interface with IDE drives ONLY. You'll get MUCH better performance by installing your optical drive on the Secondary IDE channel, as the Master device (even if it is the ONLY device), but make sure you attach it to the END of the IDE cable, not to the middle connector. The middle connector should only be used for SLAVE devices, if any are to be installed. You also should avoid making an IDE drive slave to an ATAPI drive; I've done extensive testing on this, and data throughput suffers greatly when a modern (ATA5 / ATA6) drive is set as slave to an ATAPI device. The ATAPI integrated controller will run at the speed of the slower device on the chain, which will be the ATAPI (optical) drive, NOT the IDE drive. SCSI drives and controller cards were developed years before ATAPI drives were introduced; as a result, operating systems have been hard-wired to work with SCSI drives and controllers (think: UNIX, early Apple computers, the first versions of MS-DOS...). That leads us to another point: instead of re-writing operating systems to work directly with ATAPI devices, a functional work-around was developed: the drivers for ATAPI devices identify the hardware (the optical drive) as a SCSI device to the operating system. Since the operating system is already coded to work with a SCSI device, it doesn't need to be rewritten; the device driver interfaces with both the OS and the hardware, so everything functions as expected. The OS doesn't "know" it ISN'T working with a SCSI device, and the ATAPI device doesn't "know" that the OS "sees" it as SCSI hardware... If you've read this far, you should now have a better understanding why this process is used; it is much easier to make an OS work with hardware it is already coded for, than to re-code the entire OS. In fact, the same trick is used for the add-in PCI IDE controller cards themselves: during POST, the controller card BIOS identifies itself to the motherboard BIOS as a SCSI device. The motherboard BIOS is coded to recognize SCSI devices, so the BIOS doesn't need to be re-coded. The motherboard BIOS waits for the "SCSI device" to return control of the POST process; while that happens, the IDE controller card BIOS spins up the IDE drives attached to the card, and when they are ready, the IDE controller card BIOS returns control of the POST process to the motherboard BIOS, which then polls the rest of the hardware until the POST is completed. The PCI IDE controller card might be used simply to increase storage space, to control a boot drive, or to manage a large (+137GB) harddrive that an older OS (Win9.x) isn't capable of working with; some are also RAID controllers, which is even more complex. The most important thing the PCI IDE controller cards have in common with their PCI RAID controller cousins is that their BIOS chips identify them to the motherboard BIOS as "SCSI" devices, all to keep from having to write new BIOS code, just as the device drivers identify the hardware to the OS as "SCSI" devices, to prevent having to re-write (or patch the HELL out of) the OS... To recap: For devices that interface with the BIOS during the POST process, the hardware BIOS chip is designed to mis-identify the hardware so that the motherboard BIOS doesn't have to be re-written. At the OS level, the device driver mis-identifies the hardware to the OS, so that the OS doesn't have to be re-written. I consider this method to be one of the more functional workarounds in the PC hardware environment; it beats installing new Service Packs and Critical Updates every time a new piece of hardware is introduced... I'm the first to admit that this is somewhat technical, and I've tried to present it in fairly basic terms; I don't want to confuse anyone, but I hope that those who read this will now have a better understanding of how these different types of hardware interface with an OS (or with a motherboard BIOS, whichever applies). I think this will make sense to the hardware geeks who read it, but if your eyeballs start dripping blood onto your keyboard, I hereby apologize in advance... I DO try to keep the ultra-geek posts to a minimum.

Thanks for the explanation. I'd add that most modern chipsets support independent device timing so different transfer rates are supposed to be less of a problem: http://www.storagereview.com/guide2000/ref/hdd/if/ide/confTiming.html