17 Apr
2000
17 Apr
'00
8:07 p.m.
But if you want an IDE interface for the S100 bus that
will work with
just about any IDE drive that you throw at it, then you should only
depend on whatever features are required for the drive to work in a
normal PC. Because you can bet that some drive (or most drives!) won't
implement anything else.
I'd agree from my experience. I'd add the 2.5" drive are less likely too.
> willing to believe that the interface will not
assert IOCS16- if the
drive's
> interface is programmed to operate in 8-bit mode.
I would expect that if
I
The term 'interface' is ambiguous here. IOCS16/ is asserted by the drive,
not by the bus adapter card.
True! I built the interface on the assumption it would be asserted to
save logic.
The bus adapter simply buffers the signal (most of the
time) and sends it
to the ISA slot. In particular, note that the address decoder logic on
the bus adapter is not what asserts IOCS16/
Correct, those assert CS lines.
AFAIK, a standard IDE drive only asserts IOCS16/ for
accesses to the data
register. Not for accesses to any of the control/status registers. Which
means all of those are seen as 8-bit registers.
Yep. That mas a 8<>16 adaptor simpler as it's only reads and writes to one
address that need folding.
> MSI-implemented IDE channels don't have the
means to operate in that
mode.
See above. The bus adapter should do the right thing provided the drive
asserts IOCS16/ at the right time. The TTL bus adapter cards are just a
couple of buffers and an address decoder (normally a PAL, but it doesn't
have to be).
Actually this is only important to obscure hardware as the software knows
a data register read/write is 16bit (word) and that all other registers are
byte.
I think the idea was that IOCS16 was to notify byte oriented logic to handle
the 16bit transfer (ISA-8).
Allison
-tony