LINKS | LINUX | MAIN MENU | PS2 | REFERENCE | USENET
Copyright (C) 1997 by Erik van Straten. All (registered) trademarks
TIP: having problems with hypertext jumps in frames? Then mark the following string: http://www.computercraft.com/docs/evsterms.shtml and copy it to the clipboard, paste into your browser's URL line and press Enter.Contents:
All hardware devices containing some kind of microprocessor need software to start-up, get running, or "boot" with. That software cannot be stored on a disk, since microprocessors do not know how to access them.. They need other chips and a program to tell them how to do that, in order to read the actual operating system from the disk. That program is usualy stored in ROM, EPROM or FLASH-ROM, and the other chips are usually in the chipset on your motherboard.
Further, there is some overhead involved in each hardware interrupt: the CPU must save all it's registers in some safe place (the stack) because it needs those registers during the data transfer, and afterwards, restore the register contents and continue with what it was doing before. For both reasons BlockMode was invented. With BlockMode enabled, the CPU will request a range of sectors, which the harddrive will read into it's internal cache, and issue only 1 interrupt to initiate the data-transfer to memory in 1 big burst. Of course, both the harddrive (firmware and cache-size) and the Int13 routine must support this. However, having the BIOS Int13 routine using BlockMode, does not necessarily mean that BlockMode is used by Windows. That depends on the 32BDA driver used. The number of sectors per interrupt is also called the "blocking factor" and is typically 8 or 16 for recent harddrives. Most BIOSes will determine and use this number on a per-drive bases. This allows the concurrent use of old and new drives, and not have the old drive limiting the preformance of the new drive. The software will only benefit from BlockMode if it asks the BIOS (or driver, like the 32BDA driver) to read multiple sectors; only in that case indeed multiple sectors will be read from disk. Therefore, especially FAT filesystems with large clustersizes will benefit most from BlockMode (unless compressed with DoubleSpace or DriveSpace, but I wouldn't use those performance-killers anyway, considering the current harddrive prices). However, without BlockMode, things aren't as bad as it seems. This is due to the fact that most harddrives will do read-ahead's when 1 sector is requested: the drive will be loading followup sectors in the harddrive-cache without having been asked for it, yet, which typically happens next. This reduces much of the problem to the extra CPU overhead involved in multiple interrupts.
Note that when you install Windows95 over your current Windows 3.x files,
Win95 may refuse to run in 32-bit mode and will use DOS-compatibility mode
instead (which really slows down your system). Removing the line
device=xxxx.386 (where xxxx is one of the drivers above) usually
|Limiting factor||Cylinders||Heads||Sectors/track||Max. Size|
|EIDE controller CHS||65536||16||256||128GB|
|EIDE controller LBA||16 bits||4 bits||8 bits||128GB|
|BIOS INT13 call||1024||256||63||7.8GB|
|CHS via INT13||1024||16||63||504MB|
|LBA/XCHS via INT13||1024||256||63||7.8GB|
In the table above, M equals 1024x1024 and G equals 1024x1024x1024. The
upper two data rows show which commands are sent to the drive by the BIOS; the
lower three rows show how "DOS" (the Disk Operating System, i.e. on the level
of files and directories) communicates with the BIOS. When the EIDE drive is
used in LBA mode, then all bits are grouped together to form one "word" of 28
bits, allowing 2^28 combinations, which provides for the ability to address
approx. 268 million sectors of 512 bytes each, yielding 128GB.
The BIOS takes care of the actual transfer of sectors from the harddisk to RAM and backwards. DOS calls the BIOS through standardized routines, that is, with standardized parameters. And that's where the problem is. Simply said, the BIOS routine "ReadSector" takes parameters with maximum values displayed in the "BIOS INT13 call" row in the table above. However, the hardrive, which contains the EIDE controller, also has maximum values in the commands that are passed to it. The unfortunate combination of both worlds (BIOS and EIDE) results in the restricted maximum values shown in the "CHS via INT13" row (note that EIDE can handle a max. of 16 heads, while INT13 can handle a max. 1024 cylinders).
Because the maximum values of both BIOS and EIDE are standardized, not much can be done about this, except by a trick called translation, used by the BIOS modes LBA and XCHS. DOS can call the BIOS Read-Sector routine while specifying 1 out of 256 heads and 1 out of 1024 cylinders, but the harddrive can only handle 1 out of 16 heads, but on the other hand, upto 65636 cylinders. Translation solves this IN the ReadSector routine (in the BIOS): it devides the head value it got from DOS by 16 and at the same time multiplies the cylinder value it got from DOS by 16. For a 7.8GB drive, the translationfactor 16 is the only posibillity. For smaller drives, often smaller translationfactors (i.e. 2, 4 or 8) are used. Device-drivers like Ontrack Diskmanager use a similar translation. In the case of LBA, the passed CHS values are converted into a logical block number which addresses the harddrive as one large array of sectors (counting starts with 0 here).
Note: since real 32-bit Operating Systems have their own 32-bit BIOS built-in (they fully bypass the 16-bit ROM-BIOS) and directly access the EIDE controller, they can handle drives upto 128GB (note that LBA is not limited to 7.8GB, but only LBA via INT13 is). Of course, if any INT13 functionality is supplied in such an OS, access via that call will be limited to the first 7.8GB of the drive. A nasty problem here is the boot process: files involved in that boot process must be stored within the first 7.8GB (1024 cylinders at 256 heads and 63 sectors/track) of the drive, because the ROM-BIOS has to take care of loading them. However, I expect a "smarter" BIOS standard soon.
Translation also takes place within the harddrive. Modern drives typically have more cylinders, 2-6 read/write heads, a variable number of sectors/track (more on the outer tracks than on the inner, to keep the Bits-Per-Inch value as high as possible over the disks). However, the BIOS and operating system are unaware of this since the microcontroller in the harddrive fully takes care of it.
Because of the fact that drives do internal translation anyway, they do NOT mind how you address them: for an imaginary drive of 63MB (with 512 bytes/sector) it makes no difference if you specify it as 2048/1/63 (C/H/S) or 512/4/63, as long as the total number of sectors you can access does not exceed the total number of sectors actually on the drive. Note that you cannot exceed any of the maximum INT13 values here: max. 1024 cylinders, 16 heads and 63 sectors/track. Also note that if you change settings like this in your BIOS, or switch from XCHS to LBA, then you will have to repartition your drive, and reformat the partitions on it! One more remark: changing PIO- or BlockMode has nothing to do with how your drive is partitioned, and as such, can be done without repartitioning. However, make a backup first, since other problems may cause data corruption (i.e. too fast PIO-mode or a to high blocking-factor not properly supported by the drive, cabling and BIOS).
If you're careful when installing new operating systems (first boot from
the harddisk to load the driver, and when it prompts you to press a key to
continue the boot process from floppy, do so) you shouldn't have any problems
with these drivers. In fact, where I work we have a number of 486 PC's with
Western Digital drives ranging from 540MB upto 1.6GB, all with Ontrack
Diskmanger V6.03 (licensed to Western Digital) installed, and never had a
single problem related to DiskManager. I have only experimented a bit with
Microhouse's Ez-Drive, but now of others who use it without problems.
Some people fear performance degradation because of drivers like these. I did not test it but that seems very unlikely. The translation scheme used only involves a small number of CPU instructions, while the competition, a translating BIOS, would have to perform similar operations! What IS likely to cause performance degradation is not software, but hardware. Typical PC's that require these drivers have VLB or ISA only (no PCI) buses and slower CPU's. Theoretically VLB-EIDE controllers are okay, but in practice they can hardly be compared with a decent PCI-based EIDE interface. By the way, if you have an ISA card with a translation-ROM, make sure it is "shadowed" to RAM (check your BIOS setup). If not, HD performance will be ssslllooowww.
|Partition Size in MB
|Partition Size in MB
|Partition Size in Cylinders (at
16 heads and 63 sectors/track)
|Cluster Size in
|Cluster Size in|
I have read that 4GB FAT16 partitions with 64KB clusters are possible as well. However, FDISK cannot create them, and I wouldn't be surprised if low-level programs like Norton Utilities would not know how to handle these. Further, if you're a video freak, this won't help. The max. filesize in DOS, Windows and Windows95 is 2GB, and in practice you won't be able to access files much larger than 1GB. I suggest that you stick with max 2GB partitions, or use NT with NTFS partition(s).
WARNING: Do NOT enable 32BDA if you
are not absolutely sure that you have installed the proper driver. In contrary
to what most people think, NOT having the entry "Use 32-Bits Disk Access" grayed
is NOT a guarrantee that you are allowed to enable it! This "graylevel" depends
on a line in SYSTEM.INI in section [386Enh] being there or not:
|32BitDiskAccess=Off||it's Off, but NOT grayed, thus can be enabled|
|32BitDiskAccess=On||it's already On|
|-no such line-||the entry in the Virtual Memory Settings will be grayed and thus cannot be enabled.|
Only Windows SETUP determines whether your drive(s) conform to the
WD1003 specification, the only spec. supported by the windows built-in driver
WDCTRL. If any of them (including ATAPI CDROM drives and SCSI drives) does not,
it will not add the line with the "32BitDiskAccess" parameter. Otherwise it will
add the parameter, but set it's value to "Off". You'll have to switch it on
manually through the Virtual Memory Settings dialogbox.
Therefore, if you copy your Windows setup from an old drive to a new and bigger drive (or just ADD an ATAPI CDROM or bigger harddrive) without adding an appropriate driver, then you WILL be able to check the entry "Use 32-Bit Disk Access" in the Virtual Memory Settings dialogbox, if you did not already. Windows will not automatically uncheck this for you if you change your hardware configuration, but usually it will detect the change, and refuse to load 32BDA while issuing an error message. But under some circumstances it will not detect the change, which typically causes you to corrupt data on your drive(s), including trashing the partition table, FAT's and rootdirectory sectors, rendering the entire drive inaccessible!
This page is NOT intended to be a replacement for the excelent information in
the various FAQ (Frequently Asked Questions) files and webpages around the world
(see my tools page
for some pointers). I only wanted to explain a number of terms related to the
document that describes the problems with Quantum
Fireball TM drives I experienced (although I admit it got longer than
planned). I did my best to supply reliable and correct information here, but,
since I'm only human, I may be wrong. Please let me know if you disagree or have any other
remarks about this page. If I consider them relevant I may update this
If you have general questions about harddrives, diskmanagers, formatting, possible bugs and fixes etc., please ask those questions in one of the Usenet Newsgroups; for PC related storage devices this would be comp.sys.ibm.pc.hardware.storage. If you don't have a newsreader, most wwwbrowsers will accept the following URL: news://your.news.server/comp.sys.ibm.pc.hardware.storage where you must of course replace your.news.server by your favourite host. Before posting messages (asking questions) in any newsgroup, please read the newsgroup's FAQ to make sure that you are not asking a Frequently Asked Question; see my tools page for some pointers to FAQ's. When I have time, I will be reading some of the postings in the PC storage group, but lots of other, often much more experienced people do as well, and they often come up with answers I am not aware of. So check it out!
I cannot and will not take any responsibility if you experience damage or loss of data or any other inconvenience caused by anything written here by me. In other words, anything you do is your own responsibility, don't blame me!
Copyright (C) 1997 by Erik van Straten. I grant Computercraft the non-exclusive right to publish this page. All (registered) trademarks are recognized.
Erik van Straten.
Return to my Quantum Data Loss page, to my tools page or to the COMPUTERCRAFT main menu