NO ROM BASIC, SYSTEM HALTED
? This should get a prize for the PC compatible's most obscure error
message. It usually means you haven't made the primary partition
bootable or, in Microsoft-speak, 'Active'. Use
FDISK
to fix this. Don't fret, you won't have to repartition or
reformat anything unless you have no primary partition at all.
The earliest true-blue PCs had a BASIC interpreter built in, just like many other home computers those days. Even today, the Master Boot Record (MBR) code on your harddisk jumps to the BASIC ROM if it doesn't find any active partitions. Needless to say, there's no such thing as a BASIC ROM in today's compatibles, and this action ends in the above error message.
If your 4.50G BIOS is dated earlier than 12/13/1994, the address translation table is faulty. To access drives with more than 1024 cylinders, you cannot use address translation (Large) but must use LBA. In versions dated 12/13/1994 or later this has been fixed. Be warned that switching to LBA will probably force you to repartition and reformat your drive; do back up your data.
Many BIOSes dated before 1996 contain bugs making them incompatible with drives of more than 4096 cylinders, which works out to be about 2GB in size. Some BIOSes have similar problems at the 8192 cylinder boundary (4GB). The effects may range from not being able to use the full capacity to a crashing BIOS during bootup or upon detecting the drive.
Possible solutions include
Some BIOSes assign a drive of over 8192 cylinders a translated geometry with 256 heads. MSDOS 6.22 and below fail when they try to access the last head.
If your BIOS allows a user definable drive type, use a geometry with 15 heads and 16/15 times the original number of cylinders, rounded down. Thanks to universal translation you can always do this. Remember to write down the geometry somewhere so that you can reproduce it if necessary! If no user definable drive type is possible, there's little you can do about this except upgrade to Win95.
OnTrack has a web site: http://www.ontrack.com/ . Most importantly, you can find their Disk Manager FAQ at http://www.ontrack.com/ontrack/faqhome.html . There's also a bit about DM in section 13.1 . If all of that doesn't help, contact OnTrack tech support at tech@ontrack.com .
Beware that some licensed versions are supported by the OEM rather than by OnTrack. In such cases the OEM usually offers help, FAQs etc. on their web site.
Try using a slower mode or disable fast modes altogether. Mode 3 and especially mode 4 are very sensitive to timing problems, and not all adapters follow the ATA-2 specification really closely. Don't dismiss the possibility too easily: if you changed anything on your system, it is very well possible that a drive which marginally worked so far now starts to corrupt data.
Some controllers seem to configure themselves according to the capabilities of the master drive. This can mean trouble if the slave handles only slower modes.
Moreover, check your cables, and ensure they aren't too long (see Q 5.4 ). Removable drive brackets may also cause problems with fast PIO modes for roughly the same reasons.
No. All modern drives support error management, which completely hides any bad sectors that may be on the disk before leaving the factory. Even a single bad sector is sufficient grounds to return the drive under warranty. If you want to continue using it, the drive should be viewed with the utmost suspicion.
Western Digital's wdat_ide.exe
utility can hide grown bad
sectors on many Caviar disks.
There is one exception. Under rare circumstances, use of bad (too fast) timing by the disk adapter can cause bad sectors on a disk. This type of error can be fixed simply by writing fresh data to these sectors, as there is no actual media defect.
Often, this is caused by the use of block mode (see Q 10.6 for an explanation). Large blocks can take a long time to transfer; during the transfer, interrupts are disabled and the serial ports are not serviced by the CPU. Eventually, the buffer for incoming data may overflow, leading to overruns and CRC errors.
The solution is to reduce the number of sectors per block, if possible, or disabling block mode altogether. 16550 compatible serial ports have a larger buffer, but with excessively large block sizes this problem may still occur.
There appears to be an awful lot of confusion about this subject, partly due to some unhappy terminology.
In the most literal sense, no ATA(-2,-PI) drive will allow 32-bit access. Data is transferred to and from the drive over a 16 bit bus. However, many local bus interfaces are capable of combining two 16-bit words into a 32-bit doubleword when reading data from the disk, and the reverse when writing. This way, data transfer between the CPU and the interface can be done in 32-bit chunks. This is often called '32-bit access', although '32-bit host bus transfers' would be a better name.
With 32-bit host bus transfers, more efficient use is made of the computer's bus and CPU. On the other hand, these are seldom the bottleneck, so don't expect miracles from this feature. Windows' 32-bit disk and file access are completely unrelated issues and the subject of question 8.10 and 8.11 .
There are numerous reasons why this can fail; you will more easily be able to do something about it (or decide if you want to fix it in the first place) once you know some background.
Windows' 32-bit disk access (32BDA) is a bit of a misnomer, actually, since it has nothing to do with 32-bit data transfers. A slightly better name for it is 'FastDisk'. It is a feature of Windows in 386 Enhanced mode that allows one to replace the BIOS' disk routines by Windows' own routines that work in protected mode. A much better name, then, would be "protected mode controller access". For some reason Microsoft decided not to use the latter.
Anyway, the main advantage of this feature is that it allows Windows to use virtual memory for its DOS sessions. Without 32-bit disk access, DOS sessions cannot be swapped out and every DOS box takes 640k of real memory. Because it also reduces the number of switches between virtual and protected mode Windows has to make, it gives a slight performance improvement as well, but usually nothing dramatic. Only if 32BDA is used together with Windows for Workgroups' 32-bit file access feature, it will eliminate these mode switches altogether (at least for most disk operations), which gives a far more interesting performance boost.
Unfortunately, the standard FastDisk routines that are internal to windows,
called *wdctrl
, are severely limited in their capabilities. The
*wdctrl
software understands nothing of non-IDE hardware (e.g. SCSI),
more than two harddrives, drives with more than 1024 cylinders, 32-bit host
bus transfers, block transfers, or ATAPI CD-ROM drives on the primary
channel. If you use any of these things, 32-bit disk access won't work
unless you have a *wdctrl
replacement.
Today, that means that 32-bit disk access won't work 'out of the box' for most of us.
Most interfaces that are incompatible with *wdctrl
come with their own
FastDisk routines (usually with a .386
extension). For the rest of
you, many drive manufacturers offer replacement FastDisk software. Many
drive manufacturers have such drivers on their WWW sites these days; take a
look in the net.resource guide below. You can also contact your vendor to
find out what is available. Last but not least, the ontrackw.386
driver in
ftp://ftp.ontrack.com/pub/software/dmpatch.zip
is
reported to work fine on all drives even if you don't use Disk Manager.
Most of these drivers won't give you 32-bit disk access if you have an ATAPI CD-ROM on the same cable as the harddisk. Only a few CD-ROMs come with a special VxD driver which does the job.
Note: these drivers are incompatible with the Stealth feature of some versions of Quarterdeck's QEMM. Quarterdeck's fix can be found on ftp://ftp.wdc.com/drivers/hdutil/32bda.com .
The idiosyncrasies of the 32-bit disk access feature with respect to disk
hardware has led to the popular myth that 32-bit file access has similar
problems. However, that's all it is: a myth. If 32-bit file access fails,
you should first check your filesystem and the programs that use it. As
little as a single open file, e.g. from a printer spooler, will cause 32BFA
to fail. Oh, and put DEVICE=C:\WINDOWS\IFSHLP.SYS
in
your CONFIG.SYS
, and make sure your SYSTEM.INI
contains the
correct magic incantations (vfat.386
, vcache.386
). If this
doesn't help, there's a first rate FAQ on this topic (see the net.resource
guide for details).
The culprit usually is a virus. Do get a recent virus scanner.
If that turns out negative, it may also be DOS (real-mode) driver that loads
in the CONFIG.SYS
or AUTOEXEC.BAT
, or an old version of EZDrive/Disk
Manager loading from the MBR.
See the next question.
If you've used Win95's fdisk
utility to partition your drive, you may
run across a nasty bug.
Win95 supports extended int13 calls to break the 8GB barrier. To avoid
problems with old versions of DOS, partitions extending beyond 8GB must be
made invisible. Unfortunately, the Win95 FDISK
sometimes hides
partitions this way even if your drive is much smaller than 8GB.
Incidentally, this also hides them from all other operating systems,
including old versions of DOS, and can cause all kinds of problems.
Under circumstances, these new partition types can completely mess up things when going from the Win95 graphical shell to MS-DOS mode. Drive contents may appear to be corrupted or be replaced by the contents of C:. Don't try anything fancy when this happens; it is really easy to corrupt your data. Don't use the "Restart in MS-DOS mode" option and don't run programs configured to run in MS-DOS mode. MS-DOS windows are still fine.
The most comfortable way to fix this is to change the partition types using Partition Magic , but ONLY version 2.03 or later. You can get an update patch for older versions.
The alternative is to back up your data and repartition using FDISK
/X
, which disables the use of the new partition types, or DOS 6
FDISK
. Also be sure to apply the Win95 ios
bugfix and other fixes
available from
Microsoft's web site
.
If you have a Triton II or Natoma based board, the retail version of Win95 may not recognize the PIIX3 interface. This will trigger an entertaining bit of Plug'n'Pray magic which eventually causes the BIOS to disable the secondary IDE channel on the next reboot.
To determine if this is really your problem, go into the device manager and
click on Hard Disk Controllers
. If you see the following devices listed:
Primary IDE Controller (single FIFO)
Standard Dual PCI IDE Controller
Standard IDE
ESDI Hard Disk Controller/mshdc.inf
needs a little update. You can download this from
ftp://ftp.intel.com/pub/patch/ideinfup.exe
.
The Win95 busmastering drivers sometimes have trouble co-operating with older harddisks and ATAPI CD-ROMs. Try installing the latest drivers.
If that doesn't help, you could try this registry hack. Move all
old devices to the secondary port. Back up the registry
(system.dat
and user.dat
in the Win95 directory). Start
regedit
and look for
HKEY_LOCAL_MACHINE/System/CurrentControlSet/control/Services/hdcHere is where the entries for both ports should be located. In the second entry, change the key
PortDriver
from "ideatapi.mpd"
to "esdi_506.pdr"
. This will cause the secondary channel to be
handled by the default driver.
If the CD-ROM is connected to the secondary channel, make sure this channel is enabled. Some BIOSes will enable the channel only if one or more harddisks using this channel are defined in the setup; in that case, you can't avoid putting the CD on the same cable as a harddisk until you manage to get your BIOS updated.
You may also get trouble if the CD-ROM is jumpered as slave and there's no master on its channel.
Finally, the PIO mode (speed) used by the interface may be too high,
especially if the CD-ROM shares its cable with a harddisk. Many
interface drivers and BIOSes are not ATAPI-aware and don't take the
CD-ROM into account when determining the maximum possible speed. The
best fix is to move the CD-ROM to a different channel. Manually
lowering the mode a notch or two should also help; this is usually
done either through the BIOS setup or by passing options to a device
driver in the CONFIG.SYS
.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter