10 Aug
2011
10 Aug
'11
12:40 p.m.
> > > They did NOT make provision for
multiple FDC, although they also
> > > didn't take steps to block it.
> > The buffer to drive the DMA requrst line on the IBM FDC card is a
> > 3-state drvice, whit the eneable software-controllaable. Thus you can
> > disable it and allow some other device (like a second FDC) to use that
> > DMA channel.
> The IBM FDC was made perfectly capable of sharing the bus with
> another FDC; all that is needed is a separate range of I/O ports.
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.
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,
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.
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
responsibility to move the buffer, or at least correctly identify what
went wrong. (just as it was SMARTDSK's responsibility to recover from a
sector error in delayed writes, rather than locking up on an an
unterminatable R[etry]? condition) Whether the buffer straddled the
boundary could often be easily changed by adding or removing a TSR or two.
Since the "experts" had no clue what was really happening, that led to
much stupid incorrect journalism that concluded that certain TSRs were
incompatible with FORMAT, or even in at least one case, reports that a
certain TSR was NEEDED for FORMAT to work!
--
Grumpy Ol' Fred cisin at xenosoft.com