11 Aug
2011
11 Aug
'11
11:16 a.m.
[Second disk controller in an IBM PC]
Right. I rememebr when I was directly accessing the disk controller, I
would allocate a 512byte buffer (I ws handling 256 byte sectors), thus
ensuring that at leat one half of the allocated area didn't cross a page
boundary. I'd use the thrst half if it was OK, the scond half otherwise.
I've never been bitten by this, but it sounds ridiculous.
Tony: Absolutely, that's waht I said.
Fred: Likewise. They didn't take steps to prevent it, but unlike the LPT
and COM boards, they did not provide an "official" alternate address, BIOS
support (could have been an INT1Eh parameter), nor solder pads for
jumpering.
True.
Talking of solder pads, I assume _everyone_ spotted the unneceessary vias
on the original parallel (printer) card. If you cut the track between
them and jumper one of the vias to another nearby via, you control th OE/
line of the data latch by the othewise unused bit of the control port,
thus making it a bidirectional port. This is not docuemted, not even in
th TechRef. Alas the same traces were not present on the MDA card (which
has a built-in parallel port, of course).
That;s the polite way of putting it!. IBM was
even worse than some othr
8088 machines in that they only had page registers (to provide the top 4
bits of the address), one of which served for 2 channels.
From a BEGINNING programmer perspective: If your
buffer for INT13h I/O
(even single sector), happens to straddle one of the 64K
"boundaries",
then your INT13H call will fail with an error code. That was not a BUG, just one more poorly documented caveat before using
INT13h. It is up to
your code to find whether the memory location assigned to your program
puts your buffer at risk (or just TRY IT), find another buffer location,
The linux fdrawcmd ioctl() allocates its own buffer which will not cross
a page bondary, and transfers the data to/from the array you pass to it
(which can be anywhere). In other words th OS handles the details fro
you, as it should do.
and redo the I/O. Many commercial programs failed to
do that test, often
resulting in code that "tested" fine, but failed at the customer's
location, depending on where in memory the program happened to get loaded.
Ouch!
From a USER's perspective: FORMAT was one such
program! IF its buffer
happened to straddle one of the boundary lines, it would
FAIL, and FORMAT
would proceed to report a COMPLETY TOTALLY incorrect error message,
blaming the diskette. THAT is a bug. The cause might be the fault of the original design (Microsoft called it a hardware bug!),
but it was FORMAT's
Well, I woill happily agree that the hardware design is a right kludge
(the language I would like to use to describe it is not suitable for a
public list :-)), but it is surely the program writer's responsibility to
ensre the program runs on said hardare under all conditions.
-tony