Message-ID: <67BAFB085CD7D21190B80090273F74A45B7D10@emwatent02.meters.com.au> From: "Da Silva, Joe" To: "'opendos AT delorie DOT com'" Subject: RE: 1024 cylinder limit; anti-bloat (was DRDOS FDISK) Date: Tue, 31 Oct 2000 16:55:19 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: opendos AT delorie DOT com See below ... Joe. > -----Original Message----- > From: Patrick Moran [SMTP:pmoran22 AT yahoo DOT com] > Sent: Tuesday, 31 October 2000 10:45 > To: opendos AT delorie DOT com > Subject: Re: 1024 cylinder limit; anti-bloat (was DRDOS FDISK) > ---- snip ---- > I don't remember the exact details and would have to dig out those old IBM > manuals that has all the BIOS info, but the BIOS is where the 1024 cylider > limit is. When IBM wrote the BIOS they only allowed 10 bits for the number > of cylinders. They only had so many bits for the number of sectors and > only > had so many for the number of heads. nerwer BIOSes have a work around for > ---- snip ---- [da Silva, Joe] Well, yes and no. The limit is in the Int 13 interface defined between the BIOS and the O/S. Many BIOSes from the mid 90's would happily accept cylinder counts > 1024 but this was totally useless because they still used an untranslated Int 13 interface. Later, they realized that providing translation would be a "good idea" ... The real mistake IBM made was to define the Int 13 CHS parameters with different limits to those of the MFM hardware interface (which was later transformed into the ATA interface). Now, the ATA interface CHS parameters (also the LBA ones) define up to 128G, while the Int 13 interface defines up to 8G. But, because IBM mismatched the two, the net effect was a 504M limit. BIOSes today get around this mismatch by translating the CHS parameters, thereby allowing the Int 13 interface to address the full 8G (with only 1024 cylinders), beyond which the standard Int 13 interface (as used by DR-DOS, etc.) cannot take us (for that, a newer, Extended Int 13 interface was defined). As for the 1024 limit itself, yes in retrospect, it could have easily been avoided, however, nobody would ever dream that drives would exceed 8G, so this is really not something to blame IBM for - just the silly mismatch ... > > As for using M$DOS 3.3 to avoid bloat, I would recommend instead, > > DR-DOS 6. This gives you partitions of up to 2G (instead of just > > 32M), > > has reasonable memory support (note - it's EMM386 has very *good* > > compatibility with app's :-), yet has nice, compact executables. > > I would highly recommend it for small systems with limited resources. > DRDOS > 5.0 would be well suited for 286 and 8088/86 systems. Some 286 systems > could > use expanded memory and 5.0 had a memory manger for them as well. > [da Silva, Joe] Don't know ... never used DR-DOS 5 ... however, I suspect the DR-DOS 6 executables would be of similar size (there may be more of them perhaps, but you could always delete anything you never use). DR-DOS 6 ran very nicely on 8088 machines, with the exception of DOSBOOK, which "ran like a dog" on anything less than a 286 ...