Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!harrier.ukc.ac.uk!zodiac.ukc.ac.uk!cur022
From: cur022@zodiac.ukc.ac.uk (Bob Eager)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Formatting 3.5" Diskette
Message-ID: <11902@zodiac.ukc.ac.uk>
Date: 11 Jan 90 11:59:20 GMT
References: <20972@kuhub.cc.ukans.edu> <7509@pt.cs.cmu.edu>
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 26

In article <7509@pt.cs.cmu.edu>, ralf@b.gp.cs.cmu.edu (Ralf Brown) writes:
> I believe that you have encountered a bug in all known versions of DOS
> FORMAT.  It doesn't check whether its buffers cross over a DMA boundary, and
> blindly uses them;...

Actually, the bug is in the PC BIOS, and no doubt faithfully replicated in
compatibles. The BIOS call to format a track checks that the buffer provided
DOESN'T cross a 64K boundary, and fails if it does. However, it uses this
code not only for reads and writes (which is correct) but for formats (which
is incorrect, since the buffer is much shorter because it only contains
sector headers, gap bytes etc). If the format buffer is NEAR a 64K boundary,
then the BIOS thinks it overlaps it because it thinks the buffer is 512 bytes
long although it isn't really.

No version of FORMAT has contained a workround, but then it doesn't contain
a bug either.

The easiest way to fix the problem is to add/subtract one from the BUFFERS=
value in CONFIG.SYS; you don't have to mess about with TSRs every time you
want to format then.
---------------------+-----------------------------------------------------
Bob Eager            | University of Kent at Canterbury
rde@ukc.ac.uk        | +44 227 764000 ext 7589
---------------------+-----------------------------------------------------
*** NB *** Do NOT use the return path in the article header ***************
---------------------------------------------------------------------------