Direct DOS 5.0 support for disks with more than 1024 cylinders -------------------------------------------------------------- This document describes my experience with adding support to DOS 5.0 for drives with more than 1024 cylinders. I used NO third-party partitioning software to accomplish this. Instead, I patched DOS 5.0 to directly support large drives. An actual step-by-step procedure and the DEBUG patches used are contained in the GT1024.ZIP file. A WARNING first: Unless you are experienced with patching and testing software, you should not try the process I will describe! Even experienced programmers may shy away from the modifications I have made due to their sensitive nature. In any case, you should read and understand this process. The drive limitations imposed on MS-DOS users are vestiges of the original IBM AT BIOS. Microsoft should have completely eliminated them when support for drives with more then 64K sectors was added to DOS. - - - - - - - - - - - - - I have recently purchased an additional hard drive which has 1700+ cylinders. In the past, I have experienced compatability problems with third-party partitioning schemes. Also, I have two large (>300M) hard drives on my system and don't like to define multiple partitions. In fact, I voluntarily gave up using the last 200 cylinders of my first hard drive to stay within the DOS limit of 1024 cylinders. Rather than give up additional disk space or add unusual disk access software to my system, I chose the examine the possibility of having DOS directly access the entire hard disk. After all, DOS no longer has a 64K limit on the number of disk sectors. Most disk controllers support up to 4096 cylinders, not the 1024 cylinder maximum which was coded into the original (and poorly written) IBM AT BIOS. Futhermore, many BIOS manufacturers have added support for INT 13 access to drives with more than 1024 cylinders. The original INT 13 specification uses a 10-bit cylinder number for a maximum value of 1023 (hex 3FF). An additional 2 bits of the cylinder number may be placed in the DH register on an INT 13 call, for example, resulting in a maximum value of 4095 (hex FFF). This is the case on my primary system, which uses a Hauppauge Computer Works 4860 motherboard with Award BIOS. (My second system is an original IBM AT; On this system, I found it fairly easy to modify the BIOS to support a 12-bit cylinder number for INT 13 calls.) Since DOS is so very close to supporting really large disks anyway, I found it possible to patch the DOS disk device driver and eliminate the 1024-cylinder maximum. Until an INT 13 is performed, DOS identifies a sector on the disk by its 32-bit sector number. Prior to issuing the INT 13 request, the sector number is converted to a physical sector address on the disk. By slightly modifying this calculation, up to 4096 cylinders can be accessed. During DOS startup, the disk driver reads the disk partition table to identify the DOS partition(s) it should access. If there is a single DOS partition which starts at a cylinder number less than 1024, the 32-bit sector count in the partition table is the only value used to determine the end of the partition. The ending cylinder and head values in the parition table are ignored. Therefore, setting a large sector count is all that is needed for DOS to access more then 1024 cylinders. The FDISK.EXE program builds the partition table using the values returned from INT 13 function 08 ("get drive parameters"). Unfortunately, for compatibility reasons, this function returns a maximum cylinder value of 1022 (cylinder 1023 is a "diagnostic" cylinder). To modify FDISK, I chose to examine the drive parameter tables pointed to by INT 41 and INT 46 directly. These contain the actual number of usable cylinders on the drive. After modifying the disk driver in IO.SYS and the FDISK.EXE program, I was able to successfully FORMAT and use both of my entire drives as single large partitions. Next, I began to test this setup for compatibility with various applications. Since well-behaved applications access the hard disk via DOS calls, I expected few problems. However, I was unsure of how MS-Windows would work; accessing its 386-mode swap file in particular. I have been running for almost two months now, and have encountered only a few difficulties: 1. Disk caching programs do not usually recognize drives with more than 1024 cylinders and unusual values in DH on an INT 13 call can make them fail. Initially, I tried SMARTDRV, which ignores INT 13 calls for which the high bits of DH are nonzero. Everything operates properly, but the area of the drive beyond cylinder 1023 is not cached. This is not too serious, but I was uncomfortable with the thought of slow access to that part of my drives. I had previously purchased a commercial cache program (I hesitate to mention names here), but gave it up for SMARTDRV after experiencing problems under DOS 5.0 and Windows. I realized that SMARTDRV is a very poor performer, but I was willing to trade performance for a working system. Several shareware cache programs are available on COMPUSERV. I tried some of these, even one which claimed to support more than 1024 cylinders directly. I gave that one up after getting "General Failure" errors on my C: drive. Finally, unwilling to compromise, I wrote my own disk caching program which supports most of the advanced features available in commercial program. I would be willing to make this available as "freeware" or "shareware" to interested parties. 2. I use SPINRITE to regularly low-level format my hard drive. I love this program, but can no longer use it. For now, SPINRITE only formats cylinders 0-1022 and uses cylinder 1023 as a diagnostic cylinder, overwritting any data contained there. Actually, SPINRITE is very close to having the support which I need. Perhaps a future version will work. As a general precaution, I have written a utility called MARKCYL to mark cylinder 1023 as "bad" in the DOS FAT. This prevents it from being used by DOS programs and so safe for use as a diagnostic cylinder. This utility is included in GT1024.ZIP 3. Most PARK utilities use the cylinder value returned from INT 13 function 08. I have written a PARK.COM program which uses the cylinder counts from INT 41 and INT 46 instead. This utility is included in GT1024.ZIP. 4. I use a temporary swap file for Windows. When a permanent swap file is allocated, Windows uses INT 13 for read and write it. A temporary swap file is accessed through DOS. In the future, I may modify Windows' PAGESWAP and VHD drivers to allow direct support for cylinders > 1024. Windows 3.1 is reported to directly support drives with more than 1024 cylinders, so this may not be needed. - - - - - - - - - - - - - Uploaded 10/13/91 by: Jerry Metcoff ID 70540,566