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.

• ROM: Read Only Memory. A chip that contains software routines and/or data which were stored in it during the manufacturing process. It's contents cannot be altered in any way except by unexpected failure.All hardware devices containing some kind of microprocessor need software to "boot" with. That software cannot be stored on a disk, since microprocessors do not know how to access disks. They need 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. The BIOS stored in ROM is usually a part of the Operation System.
• EPROM: Erasable Programmable Read Only Memory. EPROM's can be erased a number of times using UV (Ultra Violet) light. Afterwards they can be reprogrammed using an EPROM-programmer, a process sometimes called "burning".
• FLASH-ROM, FLASH-EEPROM, FLASH-RAM: just like a ROM, will have it's contents unchanged when power is switched off. However, it's contents can be altered by special software. Mostly it is partitioned into sections, where some sections can be write-protected by a switch or a jumper.
• Shadow RAM: A disadvantage of the various ROM types is that they have long access times compared to RAM, making them slow. Further, they typically are 8-bits wide. The fact that 486 processors access 32 bits, and Pentium chips even access 64 bits from RAM at a time, makes this comparison even worse. That is why typically ROM contents are copied to RAM during the boot process. The RAM used for that is mostly called "Shadow RAM" and is part of the normal memory (DRAM) in you PC. Mostly the BIOS/chipset will write-protect it after having copied the ROM contents into it.
• Harddrive Cache, Harddrive Buffer: most harddrives have RAM built in that stores often accessed sectors. The buffer is also used for read-ahead purposes. When software reads a sector from disk, it often will also want to read the next sector, but only after processing data from the first sector. If the software requests the next sector after the processing-delay, that next sector may have already rotated away under the drive's read/write head, and thus it will take an extra revolution of the disk to read that next sector. The read-ahead mechanism mostly reads in an entire track, or even tries to predict which sectors may be requested next. Pretty complicated algorithms may be in use for this. Among others, Quantum has some information about algorithms like these: http://www.quantum.com/products/whitepapers/perform1.html
• Cache RAM, Static RAM: a special type of RAM that often is much faster than normal RAM (like DRAM, SDRAM, EDO and BEDO: I won't go into those here). Often static RAM is used as cache between the CPU and main memory. This impoves execution speed of routines that are used often and of data that is read from/written to often. Static RAM is also used as built-in harddrive cache. The term static refers to the fact that no special tricks are required to have the RAM retain it's data (except for having the supply voltage available). Compare this to DRAM (Dynamic Random Access Memory) chips, they need a mechanism that "refreshes" bits in order to retain the data. Compared to DRAM, Static RAM usually has a lower access time, is more expensive, mostly has much less KBytes/chip and usually does not have multiplexed address lines.
• Chipset: mostly 2 to 5 microchips on your PC's motherboard. They form the interface between the CPU and other devices like DRAM, cache-RAM, I/O ports etc. Nowadays they usually include 2 fast IDE controllers. The complexity of these chips, also called ASIC's (Application Specific Integrated Circuit), starts getting pretty near that of other high-tech chips like CPU's. That is why they also can have some bugs in them, depending on manufacturer, type and revisison. For example, the RZ1000 chip (part of an Intel chipset) is known to cause data-corruption on EIDE drives under certain Operating Systems.
• Microcontroller, Firmware: A microcontoller is a special-purpose CPU (Central Processing Unit, or MicroProcessor), often with extra I/O ports built in. It runs on a program generally called the firmware, which is usually stored in ROM or FLASH-RAM (which may or may not be part of the microcontroller chip). Current harddives are complete computers of their own. The microcontroller inside is responsible for a lot of things, including positioning the heads over the right tracks, transferring data to and from the attached cable (to the HD controller on the motherboard), recalibrating the drive and for internal translation. Microcontrollers are also used in automobiles, washingmachines and microwave ovens (just to name a few). Like other software, firmware can have bugs, and sometimes a replacement or an update is necessary. For example, the firmware in Western Digital harddisks can be updated using a special program that runs on a PC. I expect harddrives from other manufacturers to have similar possibilities. While the drive's Serial Number is ususally printed on the top of the harddrive, the Firmware Revision (or version) number is not. However, you can obtain both (serial number and firmware rev.) numbers using a modern harddrive diagnostics program. These programs issue an "Identify Drive" command, and the harddrive will respond with a lot of details, including those numbers. Check my tools page for some harddrive diagnostics programs that reveal this information.

• ROM-BIOS: This is actually more or less a part of the Operating System's BIOS.
• WD1003, AT command set: the standardized interface for old IDE (non-EIDE) harddrives. Drivers and BIOS releases that conform to this standard use the drive in CHS mode, and thus limit the drive to 528MB (where M equals 1,000,000) or 504MB (where M equals 1024x1024). This is due to the fact that this standard command set has the following maximum values:
  • Cylinder range from 0..1023 (1024 cylinders in total)
  • Read/write head selection range from 0..15 (16 in total)
  • Sector selection (on the current track) range from 1..63 (63 in total, for historical reasons counting starts at 1 here)
• INT13: In Intel-based PC's, usually Operating System functions are called via software-interrupts (a software-interrupt is actually a "subroutine" called by software, not to be confused by a hardware interrupt, which get's called when a hardware event takes place which has caused the CPU's interrupt-input to change in potential). Somewhere at a low memory address there is a pointer table. The pointers in it point to Operating System functions. One of them is used for Int13, which happens to be the entry point for a number of low-level disk access routines in the BIOS, like functions to read and write "absolute" (specified in Cylinder/Head/Sector values) sectors. At entry of the basic Int13 routine, the contents of one of the CPU registers defines which sub-function to call. Most Int13 sub-functions use other CPU registers to pass the values for the cylinder, head, sector, number of sectors to transfer and a memory address. The fact that only 10 bits are used for specifying the cylinder value in these Int13 routines causes the infamous 1024 cylinder or 504/528MB limit, which can only be overcome by some translation tricks, or by no longer using this BIOS call. However, for compatibility reasons with DOS programs this routine cannot simply be discarded. A proper Windows 32BDA driver replaces all INT13 functionality..
• DMA, Direct Memory Access: a technique that allows other devices than the CPU to write to memory (RAM). In most computers this is the preferred technique to transfer lots of data fast. Basically, the CPU tells the DMA controller which device to access and where in RAM to read the data from, or write the data to. After these instructions, the DMA controller transfers the requested data and notifies the CPU when it is ready. However, in standard AT compatible PC's the built-in DMA controller has a number of serious limitations: it's speed and memory ranged are limited by the AT bus specifications which means that it runs at 8MHz (limiting actual speed at a few MB/second) and can only access 16MB RAM at max. Typically, the AT-DMA controller is no longer used for harddrive communication, but floppy-drives and soundcards often still use it. Both EISA en Intel-PCI based motherboards have a new DMA controller, that does not have the limitations of the AT-DMA controller. Some 32BDA drivers may be using fast DMA modes, but as far as I know most BIOS'es stick to fast PIO modes. A problem exists with DMA and Operating Systems that use Virtual Memory. One of the implictions of virtual memory is that a virtual address (the one used by software, for example the address where a database-record should be loaded) does not have to be the same as the physical address. Because older drivers may be unaware of this sitation, a technique called DOUBLE-BUFFER was introduced, which prevents the DMA controller form transferring data to a wrong address (physical address, since that's all controllers know about). The DOUBLE-BUFFER technique reserves a memory block that has the same virtual as physical address, which is where the DMA controller reads from and writes to. It is the job of the Operating Software to transfer the data from virtual memory to the buffer and back. Of course, some overhead is involved in this.
• Bus Master DMA: Usually this means that not the onboard DMA controller is used, but rather one on an expansion card. However, in my opinion that is not a good explanation. As far as I know, for "normal DMA", the DMA controller will request the CPU if it can take over address and data lines in order to access memory; the CPU may agree on this or not. A "Bus Master DMA" controller has the power to make the CPU shut-up regardless what the CPU thinks about this. You should realize that only one device at a time can access main memory (DRAM), either the CPU or the DMA controller. This means that each of them will have to wait for the other. Also see PIO vs DMA.
  Of course, cards mounted in AT-slots will have the same limitations as the onboard AT-DMA controller (i.e. 8MHz and 20 address lines limiting memory access to 16MB). Current motherboards equipped with modern chipsets and a PCI bus often have a 32-bit (accesses 32-bit wide RAM simultaneously) Bus Master DMA controller built-in. This PCI-DMA controller does not have the limitations of the old AT-DMA controller (which is still supported by the way) but requires special drivers to be activated. Only true multi-tasking operating systems like Windows NT, OS/2 and Linux will benefit from this, because these DMA controllers allow the CPU to spend most of it's time on a foreground process, while in the background a filetransfer can take place. Therefore there are no busmasterdrivers available for DOS/WfW (as far as I know, please let me know if I'm wrong!).
• Fast PIO modes, Programmed I/O: To overcome the slow transfer modes from the AT-DMA controller in PC's with fast CPU's and fast harddrives, PIO was invented. Instead of using the AT-DMA-controller to transfer data, now the CPU takes care of transferring 16-bit words to and from the harddrive. This involves a lot of CPU overhead, which is not so bad on more-or-less single-tasking operating systems like WfW (see also PIO vs DMA). Currently PIO modes 0 through 4 are common, where 0 is slowest. For the slower PIO modes 0, 1, and 2, data is simply "put" on the cable (either by the drive or the CPU, depending on the operation being a read or write) while the sender assumes the receiver reads the data within a specified amount of time, depending on the PIO mode used. For PIO modes 3 and 4 a "handshake-line" called IORDY (I/O Ready) is used to synchronize this communication, which takes place at really high speed. Some older and cheaper motherboards have problems with PIO 4: data corruption without a warning may occur, causing programs to fail or compressed files to show CRC-errors if you unpack them. Data-corruption may also be caused by too long datacables. PIO works as follows: when a sector mus be read from the drive, the CPU will issue a command to the drive to do so, and then the CPU can do other things. The drive will find the requested sector and read it into it's internal harddrive-cache. When the full sector has been read, it will issue a hardware interrupt signalling the CPU that the data is available. Then the CPU will read the data (2 bytes at a time) with high speed from the harddrive and write it to main memory in one burst. See also HDD BlockMode for a longer explanation.
• PIO vs DMA: A lot of people argue that DMA is much better than PIO, since PIO transfers involve a lot of CPU overhead (the CPU is actually reading bytes from the harddrive interface and writing them into main memory, or in the other direction for diskwrites). However, during DMA transfers the CPU cannot access main memory. Some smart chipsets may allow the CPU to continue reading from/writing to cache-RAM, but this is rather tricky. Imagine what happens when the CPU is reading data from a cache-area, that is supposed to be a representation of main memory, which was just overwritten by the DMA controller! The trick to prevent these mismatches is called bus-snooping (the chipset keeps an eye on the address lines, and if it sees that data at an adrdress which is also in the cache is modified, then 2 things can happen: 1) either that cache-entry is invalidated, effectively causing the CPU and chipset to need access to RAM causing a block until the DMA transfer is done, or 2) the chipset ALSO reads the DATA that is transfered to main memory and updates the cache accordingly. Of course this trick will not work if the CPU writes to the cache, since it is possible that the data, from the address the CPU really ment to write to, is currently being transferred to disk, causing an inconsistency.
  Alternatively, the simple solution is to stop the CPU during DMA transfers. However, even in case the CPU is put on hold during DMA transfers, the CPU overhead is less since no instructions have to be read from memory to do the PIO transfers (a DMA controller is based on hardware, it does not read "program instructions" to do it's job). Further, moderate DMA data-transfers will occupy the buses for only a few percent of time. So DMA may indeed allow the CPU to do more things than PIO would (depending on the chipset), but it typically does not result in a 100% CPU availability during data transfers!
• HDD BlockMode, MultiSector Setting, Blocks per Interrupt, Sectors/IRQ: This fast PIO-mode option allows the CPU to transfer multiple sectors in one burst, instead of just one sector. Because DOS stores files in clusters, accessing a file means that DOS will request the BIOS to read bunches of (for example) 16 sectors (see Partition Efficiency). If the BIOS (actually the CPU reading instructions from the BIOS) would read 1 sector at a time, then this means that the following things happen:
  • A read-request is sent to the drive
  • The drive finds the sector and reads it into it's harddrive-cache, meanwhile the CPU can do other things
  • The drive issues a hardware interrupt
  • The CPU transfers the data
  • A read-request for the next sector is sent to the drive
  • However, the harddrive didn't stop rotating after the previous sector. It may take a full revolution before the next sector is read (assumed it is on the same track, and no head seek is involved, which is often the case). For a 5000RPM drive this means a delay of 12 milliseconds! By the way, that is why old drives used to have "Interleaving": an imaginary disk with 4 sectors/track would have sectors numbered as 1,3,2,4 (or even 1,4,3,2). After reading sector 1, the transfer to memory takes place (while sector 3 spins under the head), and when sector 2 is requested, it will be there. Possibly modern drives are interleaved as well, but this is not "visible" from the outside, and may depend on the manufacturer. This is yet another reason why you should never low-level format IDE drives.

  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.

• 32BDA, 32-Bits Disk Access, FastDisk: a means for windows to bypass the BIOS to directly access the harddisk using a protected mode driver. It's job, like the BIOS INT13 routines, is to actually transfers sector contents to/from memory. W31 and WfW come with a built-in driver called WDCTRL which only supports WD1003 compatible drives (smaller than 528MB), and as such is useless for current drives. It is loaded from SYSTEM.INI in section [386Enh] in a as device=*wdctrl. If you do not have such a line in SYSTEM.INI, then you're not running it, if you do however, this doesn't necessarily mean it matches your drive(s)! See my 32BDA warning below. 32BDA was introduced in MS-Windows V3.10. Although the name "32-Bit" seems to suggest that data is transferred 32-bit at a time, this is not true for IDE (and EIDE) drives, since they have a 16-bit AT interface with 16 (electrical) data-lines. As such, this is a physical limitation. Theoretically the combination of an appropriate 32BDA driver, controller and a Wide-SCSI drive could result in actual 32-bit transfers (I don't know if something like this really exists). The name 32-Bit only has to do with the fact that this is a Virtual Device Driver which uses 32-bit instructions and CPU-registers , and runs in "protected mode".
  Some commonly used 32BDA drivers for Windows are, to name a few:
  • Device=*WDCTRL: the W31 and WfW built-in 32BDA driver which only supports WD1003 compatible drives. Therefore typically useless.
  • ONTRACKW.386: a 32BDA driver made by Ontrack and licensed to Quantum. I found the latest version, V1.06 in the complete Ontrack DiskManager driver-set V7.12 (licenced to Quantum). See my tools page. This driver is known to also work on non-Quantum drives (without having any Quantum drives installed) but using it that way is a violation of the copyright on it.
  • WDCDRV.386: a 32BDA driver written by Western Digital. Version 2.6 has some extra options for tuning, I once tried fiddling with them but didn't notice any performance differences. Version 2.6 is the version that came with Ontrack Diskmanager V6.03 for WD drives. It only works if you have at least one WD drive connected. Apart from the problems reported in this artcile it worked flawlessly with a Quantum Fireball TM2100A and a WDAC31600, regardless which was slave and which was the master drive. However, I saw recently that WD no longer supports Ontrack software and has switched to Ontrack's competitor, Microhouse. I'd like to note here that I never had any problems with either Ontrack Diskmanager V6.03 or WDCDRV.386 V2.6. I have them running on at least 10 PC's.
  • MH32BIT.386: a 32BDA driver written by Microhouse. Note that older versions of this driver will only run when EZ-Drive is installed on the drive.
  • SGAT.386, SEG32BIT.386: 32BDA drivers for Seagate drives.

  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 helps.
  

• LBA, CHS, XCHS, Translation: terms used mainly in BIOS setup screens. LBA means Logical Block Addressing, often incorrectly referred to as a scheme to overcome the 504/528MB limit in BIOSes caused by the INT13 interface (when a harddrive is marked for LBA access in the BIOS, then the BIOS will ALSO take care of the necessary translation). CHS refers to the old Cylinder/Head/Sector addressing (WD1003); which limits drives to 504/528MB. From a DOS point of view, XCHS is a the same as LBA, since the BIOS will apply a translation for both modes (the difference is only in how the BIOS communicates with the harddrive). Since all modern drives support LBA it is best to avoid XCHS if possible. The following table shows the various standards involved as limiting factors:
  

  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).

• Ontrack Diskmanager (DDO, Dynamic Drive Overlay), Microhouse EZ-Drive: Drivers that allow the use of harddrives larger than 504/528MB in older PC's. BIOS routines need not reside in ROM or even in shadow-RAM. The addresses in RAM where most BIOS routines are located, are stored in a "pointertable" (this incomplete explanation is just for sake of simplicity, don't flame me please). This means that DOS doesn't have to know where the routines are in memory. Instead, it knows which entry in the pointertable stores the address of the (for example) ReadSector routine, and if it wants to call that routine, it reads it's address from the pointertable and then makes the CPU continue execution of instructions at that address. This setup allows for easy replacement of BIOS routines, and that is where drivers like Ontrack Diskmanager and Microhouse EZ-Drive fit in.
  These drivers simply replace BIOS routines by their own, translation-capable equivalents. There are a number of problems involved however:
  • One problem is that these drivers are stored on disk, and are read from that disk before the translation is active, since they're not running yet! This means that the drivercode must be stored in the first cylinder of the disk, and therefore cannot be placed in a normal file (except when you boot from another disk that does not need translation, like a harddrive smaller than 504/528MB, or a floppy).
  • Secondly, not really a problem but a must. If you boot from a floppy, there should be NO way by which you can access the harddrive, since translation is not active. Therefore, if you only have 1 harddisk and 1 floppy drive in your PC, and you do a full boot from floppy you will only have drive letter A: (and no C:). However, this affects the following problem.
  • Once the driver is loaded, you should not be able to overwrite it's code on the harddrive by programs like FDISK, which overwrites the first sector of the drive! Therefore a "cloaking" mechanism is used by these drivers.
    • Apart from the translation-factor, Ontrack Diskmanager also introduce an offset or shift. This means that after it's loaded, they will fake DOS in such a way that DOS thinks it is accessing cylinder 0/side 0, while it actually is accessing cylinder 0/side 1 etcetera! This prevents programs like FDISK from overwriting the driver code, provided that the driver is loaded! If you add an Operating System to your drive, and boot from the OS-setup floppy (either at the start of the installation or reboot halfway the process) then the translationdriver will not be loaded, and the Operating System will probably think you have a brandnew disk (because it is inaccessible) and starts partitioning it. Of course, this causes all files on your drive to be lost.
    • EzDrive uses a different approach. It only "cloaks" the real MBR when it is loaded; the EzDrive code is in the first track (63 sectors) of the drive. When you read or write the MBR (CHS 0,0,1), EzDrive will actually pass you or let you write to the next sector (CHS 0,0,2) When you read/write CHS 0,0,2, you'll end up there as well. This method has two implications: the driver code can be overwritten more easily, but on the other hand, an uninstall of EzDrive is much easier than Ontrack Diskmanager, since all partitions point to the right locations (while Ontrack partitions point to locations with a 63 sector offset).
  • Another problem is where to put the replacing routines in RAM; you don't want them to reduce your conventional DOS memory with a couple of KB's, since then that superduper game might not run anymore...Therefore they use a number of tricks to finally get loaded in UMB's (memory between 640K and 1MB). Ontrack Diskmanager needs only 64 bytes of conventional memory when properly installed (I haven't examined how Microhouse EzDrive handles this).

  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, primary partition, extended partition, logical partition or logical drives: A partition is a subsection of the disk which starts right after the preceding partition table sector, and ends at the end of the drive or with the last sector preceding the next partition table sector. For DOS, only a primary partition can be bootable, and always get "lower" drive letters assigned than other partitions do. This explains why people have C: and E: on their primary and D: and F: on their secondary drive. An Extended Partition is used to store Logical Partitions or Logical Drives in. Generally DOS/Windows-compatible partitions are referred to as FAT-partitions.
  
• Partitioning: this refers to the proces that writes only a few sectors to the drive containing partition tables, and in case of the MBR, the bootcode if the partition is "active" (bootable). It does NOT assign drive letters or anything alike! However, drive letters assigned later by DOS/Windows may be affected by the partition layout and types you choose. Make sure that you have correctly setup your drive in the BIOS setup. You cannot change modes from XCHS to LBA (or backwards) after partitioning without the risk of trashing your drive (see also Translation). The table below shows some maximum values for partitions with optimal clustersize for FAT16 partitions. Note that FDISK uses 1024x1024 bytes for a MegaByte, while some other programs including Ontrack Diskmanager (and harddrive manufacturers in general) usually use 1,000,000 bytes for a MegaByte:
  

  Partition Size in MB (M=1,000,000)	Partition Size in MB (M=1024x1024)	Partition Size in Cylinders (at 16 heads and 63 sectors/track)	Cluster Size in sectors/cluster	Cluster Size in KB (K=1024)
  268	256	520	8	4
  536	512	1040	16	8
  1072	1024	2080	32	16
  2144	2048	4160	64	32

  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).

• Partition Efficiency: With a large clustersize, a lot of diskspace may be wasted (see the table above). This is typically the case when you have a large number of small files. For example, I have installed Borland C++ V5.0 Developer Suite on a single 256MB partition, and added some other small files. When I run chkdsk on it, it reports "4,096 bytes in each allocation unit" and "65,444 total allocation units on disk" which is an optimal situation for a disk with "268,066,816 bytes total disk space". Chkdsk also reports that there are "20,344,832 bytes available on disk". If I add up the total number of bytes in files (4,595,712 bytes in 7 hidden files, 2,609,152 bytes in 629 directories and 240,517,120 bytes in 3,887 user files) then I end up with 247,721,984 in total. Somehow I have lost 20,344,832 bytes (20MB) of diskspace! You can imagine that I would have lost much more if I would have installed BC5 on a bigger partition... Anyway, since each file (and subdirectory) uses at least one cluster, a rough estimation is that you will loose half a cluster of diskspace per file and subdirectory. This means that if you have 1900 files and 100 subdirectories, you'll typically loose at least 8MB on a 512MB partition, 16MB on a 1GB partition and 32MB on a 2GB partition. However, the numbers typically get even worse for larger partitions, since then more files will even be smaller than half a cluster. For example, your AUTOEXEC.BAT may fit in 512 bytes but will use 32KB on a 2GB partition!
  NOTE: under some conditions FDISK may round up instead of down, i.e. sometimes when you enter 512MB as a partitionsize it will end up being 513MB, which is just a little too high! However, FDISK immediately shows what value is going to use, so if you see the number 512 you typed being changed into 513, simply re-enter it as 511.
• Suggested Partition layout: I am used to store the operating system(s) and applications on the C: drive. If a harddisk is large enough, I would create a 1GB C: partition (not bigger)! This may not be optimal, but often 512MB is simply not enough. Then I'd create a smaller D: drive, either 256 or 512MB, depending on the total size of the harddisk(s). The D: drive is usually used to store smaller files on, like letters etc. Typical 1.6GB harddrives will have room for one 1GB and one 512MB partition. What remains is typically less than 15MB which I'll keep unused (these are the inner and thus slowest tracks of the drive anyway). On larger harddrives I'd add some partitions, possibly a large one to store big files on (ZIP files, AVI etc.) and, if required, another smaller partition to store additional small files on (for example, letters from 1995 and before, in case I like to have them available online).
• MBR, Master Boot Record: the first sector on a drive (i.e. cylinder 0, head 0 and sector 1). It contains BOTH the primary partition table AND code that is loaded to a standardized address in RAM by the ROM-BIOS of your PC (which starts the boot process from your harddrive). Usually that code will read the bootsector from the primary partition and pass control to the code in there. Nowadays the partition table ONLY describes the size and layout of the primary partition, and optionally has a pointer (i.e. CHS value) to a followup partition table sector. Note that a drive may not have a primary partition. If mounted as a slave drive, most partitioning programs will create a primary partition table without a primary partition; however, the program will create an extended partition (which is pointed to by an entry in the primary partition table). The extended partition typically holds 1 or more "logical drives", which are sub-partitions within the extended partition. This sounds complicated, and it is. Most partioning programs try to hide this complexity from the user but only get this job done partially in my opinion.
  Also note that the MBR is not really stored in cylinder 0, head 0 and sector 1 when a program like Ontrack Diskmanager is installed.
• Formatting, Low-Level Formatting: this is very confusing to most people. Formatting a floppy generally means that BOTH a low-level and a high-level format take place. The low-level format overwrites full tracks consisting of multiple sectors, headers and trailers. Each sector is preceded by a header and gets a trailer written behind it. Only the sectors and trailers are updated when you copy a file to the floppy (effectively writing sectors), the headers are used for finding the start of each sector on the track and are only read from (except during a format operation). The low-level format calculates a CRC-checksum (CRC = Cyclic Redundancy Check, a special algorithm that is very sensitive to even the slightest change in data) from each sector it writes, and writes that calculated checksum to the trailer. After low-level-formatting each track, the format program simply reads all sectors and trailers in it, recalculates the checksum from each sector and compares it to the checksum in the trailer. If they don't match, the sector is considered "bad". It stores all bad sector locations in RAM for later use. After finishing ALL tracks on both sides, the format program will do a high-level format of the floppy. That means that it will write a proper bootsector, clear both FAT's and the rootdirectory of the drive. Then it will recall the bad sectors found and adjust the FAT's accordingly. If you run FORMAT with the /S option, it will also copy IO.SYS, MSDOS.SYS, COMMAND.COM (and if it can find one of them, DBLSPACE.SYS or DRVSPACE.SYS) to the floppy. Finally format it will prompt you for a volume label.
  However, the DOS FORMAT program only knows how to low-level format floppies, not harddrives, due to the fact that sector header/trailer information varies widely between harddrive manufacturers and models. Further, the number of sectors on a track is fixed for floppies (DOS, not for some Mac floppy formats) but varies on most harddrives. And finally, EIDE harddrives are preformatted by the manufacturer typically with dedicated programs that leave some space on the drive to "remap" bad sectors to, should they show up over time. This means that if the microcontroller in the drive detects a bad sector, it will try to reread a number of times until the checksum matches. Then it will mark that sector as bad, and store the information in another sector. All this is invisible from DOS. However, for fast AV (Audio Video) or multi-speed CDROM writers this may mean a hickup in the datastream coming from the drive, not only when the bad sector is detected, but also afterwards because the drive will have to fetch sector data from another physical location on the drive (possibly involving extra head-seeks). Therefore, instead of low-level formatting your EIDE drive when it was trashed somehow, first make sure that there are no other problems involved (i.e. too fast PIO mode, *wdctrl in use for a large incompatible drives, buggy CDROM drivers, too long datacables (ribbons) between your controller and drives, bad RAM or bad cache RAM etc).
  I strongly advise you NOT to use the "format" option in most BIOS'es (reachable from the BIOS setup screen). This FORMAT option was useful for old MFM and RLL drives, and usually DESTROYS EIDE drives! If you need to "repair" an EIDE drive (bad sectors, or "undestructible" viruses etc.) it is best to use a tool that simply overwrites all sectors. This will force the drive to "remap" bad sectors itself. Nearly all bad sectors that are not remapped can be detected by either FORMAT or SCANDISK (surface scan option) and they will mark the clusters containing bad sectors as bad in the FAT. See my tools page for programs that can "clear" an EIDE drive. However, if your drive is still under warranty I suggest you try to have it replaced by your supplier or the manufacturer if you keep getting more bad sectors. If these are really due to the drive itself then often the number of bad sectors will keep growing each time you use the drive. And modern operating systems using write-caching are extremely intolerant for bad sectors!
• BootSector: the first sector in each partition. It stores information like the number of sectors/cluster, the partitionsize, the number of sectors/FAT and the number of sectors in the partition. Also it has code to load IO.SYS and MSDOS.SYS which are used by the boot process which is of course only used in the active, primary partition that is used to boot.
• FAT, File Allocation Table: a number of consecutive sectors in between the partition table and the rootdirectory on each partition, used to determine which clusters are used to store file-contents in, which clusters are free, and which clusters are invalid due to one or more bad sectors. For historical reasons the FAT table has a duplicate FAT table stored right after it. NOTE: The following section applies to FAT16 only! The bootsector, FAT's and rootdirectory are not stored using clusters, and are fixed in size (i.e. number of sectors). That is why you can have a full rootdirectory, while subdirectories can grow unlimited (until you have no more free clusters). Each cluster in a partition is assigned a 2-byte entry in the FAT (i.e. 16 bits, a typical value for large harddrive partitions; floppies and small partitions may use 12 bit FAT entries). This limits a partition to a little less than 65536 clusters. That is, BTW, the reason for the huge clusters found on large partitions. A better name for FAT would, in my opinion, have been CAT for Cluster Allocation Table. Since each cluster has a FAT entry, the opposite is true as well: each FAT entry is related to a cluster. That means that for example FAT entry number 1234 is related to cluster number 1234! Now here is how DOS exploits this: if the FAT entry contains a 0 (i.e. the two bytes are both zero) then the cluster is unused (there is no cluster 0, in fact, both cluster numbers 0 and 1 are reserved, and so is a short range just below 65535; the first real cluster on a partition is cluster number 2). Any nonzero FAT entry value means that the cluster is NOT free. If the cluster involved contains part of a file, then the corresponding FAT entry will contain the number of the next cluster (and FAT-entry) of that file! If it has the value 65535 (the largest number you can store in 2 bytes) then that indicates that the corresponding cluster is the last cluster of the file. Another FAT-value is reserved for indicating that a cluster is bad. Those are the reasons for having somewhat less than 65536 possible clusters.
• FAT32: Windows95 OSR2 has the possibillity to create so-called FAT32 partitions. Windows95 OSR2 is NOT available in the shops, it can only be legally obtained by buying a new PC (OEM PC-manufacturers can sell you a PC with this Win95 release), or you will receive it when you are a MSDN level 2 (or higher) member. The "FAT" part of FAT32 works the same as previous FAT implementations (i.e. FAT16 and FAT12). However, since each FAT entry now consists of 4 bytes, upto 4,294,967,296 clusters (minus a few reserved values) can be addressed. At first, that seems to solve the partition efficiency problems. But in fact it introduces another problem, especially when using large partitions. For example, consider a 2GB drive with 1 partition; when formatted using FAT32 it will have 4KB clusters (8 sectors/cluster). Because of that, it will have approx. 500,000 clusters. Since each FAT32 entry uses 4 bytes, each FAT will use 2MB of diskspace! As with FAT12 and FAT16, each FAT is stored twice (note that the max. size of one FAT16 table is 128KB). This means that the first 4MB of your 2GB disk will be used for administrative purposes. That is not so bad for a 2GB drive. What is a problem however, is that this may slow down your PC considerably if you do not have much free RAM and your applications do a lot of diskaccesses. Things get a lot worse when the disk becomes fragmented. The reason for this is, that it is not likely that the full 2MB FAT will be cached in RAM (unless you have for example 64MB of RAM installed). If your application accesses files (or file contents) randomly on the disk, the chance will be small that the required FAT entry is in the cache. Therefore it must be read from disk, which requires a time-consuming head-seek to the outer tracks of the disk (where the FAT is located) and back to the area where the file is located. Therefore I would not advise people who are developing large, multi-source file, C++ programs or randomly accessing a large database, to use FAT32. A small FAT16 partition (i.e. 256MB, 512MB) will do fine for the case where you have a large number of small files, and you won't be wasting much space on a 2GB FAT16 partition if you only have large files on it.
  Apart from the fact that a FAT32 partition uses 4 bytes/FAT entry, there are some more differences. I had a look with a diskeditor, and I'll describe what I found for the 2GB FAT32 partition. Note that all this is just experimental, and may be plain wrong:
  • The partition "type" field of a FAT32 partition has value 0Bhex (11 decimal), and is stored in the MBR as expected. The MBR layout has not changed as far as I could see. This means that OSR2 should be able to coexist with other partition types (for example NTFS and Linux). Florian Painke reported (thank you, Floh!) that OSR2 can use the following partition types (all values in hexadecimal):
    • 0x05 Extended partition using standard INT13 (limits drive to 7.8GB)
    • 0x06 Normal FAT16 partition using standard INT13 (7.8GB max)
    • 0x0B FAT32 partition
    • 0x0C FAT32 partition using INT13 Extensions
    • 0x0E FAT16 partition using INT13 Extensions (otherwise the same as good-old 0x06)
    • 0x0F Extended Partition using INT13 Extensions (otherwise the same as good-old 0x05)
      NOTE: to prevent OSR2 from using any of the new partition formats 0x0B..0x0F use FDISK /X to partition the drive. This is a necessity if you need to access the partitions from DOS.
      The INT13 Extensions handle LBA addresses using 64 bits (note that an LBA address points to a sector of 512 byes). We won't be running into this limit for some time I guess.
  • The "bootsector" now consists of multiple sectors, 6 in my case, of which the first 3 contain non-zero data and are terminated with 55AA (hex). I'll refer to this set of 6 sectors as the boot-block. It contains a "dirty-flag" which is cleared when the PC is properly shut-down; if the PC crashes this flag will not be cleared. When Win95 boots and finds that this flag is not cleared, it will run SCANDISK first.

• A copy of this bootblock is stored right after the original (i.e. another 6 sectors).
• Next you'll find the original and the copy of the FAT (2MB each!)
• After the second FAT, the first cluster starts. In contrary to FAT12 and FAT16, an OSR2/FAT32 rootdirectory does not have a fixed size, but uses clusters like subdirectories already did. This is a good thing, because you may run out of rootdir entries sooner then expected. The "old" Win95 uses DOS format, which be default creates 512-entries rootdirectories. 512 sounds a lot, but a long filename is stored in multiple entries. Each entry is 32 bytes long, the long filename is stored in UniCode (2 bytes per character) and some of the 32 bytes cannot be used in order for DOS not to treat long filename entry as a 8.3 entry. The result is that you'll rapidly run out of rootdirectory space when you use a lot of long, long filenames in FAT16, but not in FAT32.
• The function "ReadSector" (C function absread() or INT 26) will return an error 511. This function is used by many diskutilities in "normal mode". Probably Microsoft has disabled the use of the function to prevent people from completely messing up their disk when running them. However, for example Norton Utilities will run in "physical mode". It then uses INT13 diskaccess, and has no "understanding" of partition structures etc. and will only read and display "raw" sectors.
• Long Filenames are still stored in the "clumsy" manner, a 8.3 equivalent and multiple (32-bytes) directory entries to store the long filename.
• Windows95 OSR2 will not install if it can find any WIN.COM on your harddrive(s), because it is not intended as an update.

• BIOS: Basic Input Output System. The BIOS is a set of software routines which are mostly called via an operating system layer, but sometimes directly from applications. Hardware components are hardly standardized. The job of the BIOS is to form a standardized, relatively device independant interface to the rest of the Operating System. For example, you can call a BIOS routine to put a character on the screen, without knowing what graphics card is installed. Much the same, you can tell it to read a sector from disk by specifying the drive, cylinder, head and sector-on-a-track value while also supplying a memory address where you want the sector contents to end up at. You won't have to worry about DMA channels, PIO modes and whatever, the BIOS takes care of this. A standard part of the BIOS is in the ROM-BIOS of your PC, other parts are in stored in ROM on your graphics or VGA controller, some parts are loaded from disk during boot (IO.SYS) and other parts can be found on optional controllers like SCSI adapters etc. Also, most operating systems will replace some or all of the BIOS functionality stored in the BIOS ROM. For example, Windows NT only requires the ROM-BIOS to be able to boot. As soon as replacement BIOS routines have been loaded from disk, the ROM-BIOS will no longer be used (since it consists of 16-bits code).
• DOS, DOS622: Microsoft's MS-DOS V6.22
• WfW, WfW311, WfWG311: Microsoft's MS Windows for Workgroups V3.11. WfW is a major improvement over all other 16-bit windows versions, since it offers 32BFA. Especially when combined with 32BDA, all file and drive accesses (to drives that support 32BFA) will be done by 32-bit, protected-mode code, which improves reliability and performance a lot.
• W310, W31, Windows 3.1: Microsoft's MS-Windows V3.10
• W311: Microsoft's Windows V3.11. This basically is an updated W31. It cannot be compared to WfW311 since it lacks peer-to-peer network connectivity and 32BFA.
• Windows: either W31, W311 or WfW311, depending on context (but not X-Windows, Windows 95 or Windows NT etc.)
• Windows95: the version released in August 1995. It uses DOS to store files but uses multiple directory entries in order to store long filenames.
• Windows95 OSR2: see FAT32 for some information. Here is a site that has more info on Windows95 OSR2: http://www.users.cts.com/king/s/serwin/osr2.html
• Cluster: DOS/Windows have all file contents stored in clusters. Each cluster consists of at least one sector, but typically clusters on a harddrive consist of 16, 32 or even 64 sectors (see Partioning). Each file, no matter how small, uses at least 1 cluster of diskspace (see Partition Efficiency). Both DOS and Windows will read and write entire clusters when accessing files, not individual sectors.
• DiskCache: A cache either implemented in software (like smartdrv.exe) or in hardware (a caching controller).
• SMARTDRV.EXE, SmartDrive: a DOS program (16-bits) that caches disk information. The program uses extended memory to store information read from disks, not only harddrives but also removable media like floppy- and CDROM drives. Often requested information, like the rootfirectories and FAT tables will be accessible much faster after smartdrv has loaded them into memory. If WfW311 is properly installed and optimized, it will not use smartdrv for caching the harddrives on the primary IDE controller, because it uses 32BFA for that. However, performance of harddrives connected to the secondary IDE contolller and of removable media may improve a lot if smartdrv is used as well. However, while both 32BFA and smartdrv serve a similar purposes, 32BFA allocates it's memory dynamically, while smartdrv does not. Therefore smartdrv has options to determine how much memory it should allocate in a plain DOS session, and how much it should during a Windows session, which is important if you do not have much RAM in your PC.. Therefore most people will have smartdrv loaded from their autoexec.bat as follows:
  LH C:\DOS\SMARTDRV.EXE /X 2048 128
  The "LH" command tries to load the program "high" (in Upper Memory Blocks or UMB's, between 640K and 1MB RAM) if possible. The /X parameter disables write-caching, the 2048 value specifies that smartdrv should allocate 2048KB in a plain DOS session, while the 128 specifies that the memory allocated by smartdrv for the cache should be reduced to 128KB when Windows is started. Note that Windows 32BFA/VFAT uses write-caching by default. Note: in this documents I will refer to smartdrv as V4.0, which comes with DOS6 and up. The version of smartdrv V3.x that comes with Windows 3.0 (you shouldn't be using that anymore!) is actually very different from V4.0, because it operates at the INT13 level (making it suitable for IDE drives only, not for floppy drives and CDROM players etc.) while smartdrv V4.0 operates at the "cluster" (i.e. DOS) level.
• 32BFA, 32-Bit File Access, VFAT: a means for WfW311 to bypass DOS 16-bits code to manage file I/O at the partition-level. This is a relatively high-level Operating System layer that does NOT access the disk directly, but rather leaves that to BIOS-level routines, either implemented by the ROM-BIOS or dedicated drivers, including 32BDA drivers. It is used to access (sub-) directories, FAT's and files and does this by specifying logical sector numbers. It simply treats all sectors in a partition (i.e. drive-letter) as an array of sectors, and doesn't know about the actual disk-geometry. This is comparable to LBA (which treats the full drive as an array of sectors) while here the partition is treated as an array of sectors. As with LBA, logical sector numbering starts with 0 (note that sectors on a track start with 1). By default, 32BFA also caches disk information, and uses write-caching by default. 32BFA will not function if the program IFSHELP.SYS is not loaded from CONFIG.SYS, and if there are any open files when Windows is started. As far as I know, 32BFA does not support (E)IDE harddrives connected to the secondary IDE controller! Further, it does not support floppy-drives and CDROM players. Also, some networkdrivers are known to cause 32BFA not to function properly. To check if 32BFA is in use for your drives, execute the "386 Enhanced" program in Control panel, and then click on the "Viirtual Memory" button. "File Access: 16-Bits" for a drive means that for that drive, 32BFA is NOT in use. If 32BFA does not support a drive, smartdrv may take over (unless you have instructed smartdrv not to do so with "smartdrv x-" where x is your drive). There is a special FAQ dedicated to 32BFA problems, see my tools page.

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:

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 page.
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