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
17 Apr
17 Apr
11:56 p.m.
please see embedded comments below.
Dick
----- Original Message -----
From: allisonp <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 7:07 PM
Subject: Re: 8-bit IDE
<SNIP>
I'd agree from my experience. I'd add the 2.5" drive are less likely too.
if
> 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 I
What it is is an I/O channel controlled by the
host. The host provides an
address and a select, in addition to which it provides a read or write
strobe, and the interface, which is implemented at the target device,
interprets the signals on the channel and responds accordingly. The signal
name is inherited from the 1003-WAH, since it had to assert that signal to
force the ISA bus to transfer a whole word at once. But for that signal,
the AT bus would have steered the bytes separately from two byte transfers.
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.
... and that's EXACTLY why
I'd expect the thing to decline to assert IOCS16-
when it's conditioned for 8-bit operation as the standard suggests. I am
beginning to see that there's a lot of doubt that drive manufacturers
actually implemented this mode, and I certainly see the logic behind that
belief.
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.
one
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
address that need folding.
are
> 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 byte.
I think the idea was that IOCS16 was to notify byte oriented logic to
handle
the 16bit transfer (ISA-8).
Allison
-tony
18 Apr
18 Apr
8:08 a.m.
What it is is an I/O channel controlled by the host.
The host provides an
address and a select, in addition to which it provides a read or write
strobe, and the interface, which is implemented at the target device,
I know that.
... and that's EXACTLY why I'd expect the
thing to decline to assert IOCS16-
when it's conditioned for 8-bit operation as the standard suggests. I am
beginning to see that there's a lot of doubt that drive manufacturers
actually implemented this mode, and I certainly see the logic behind that
belief.
When I tried to use set-8bit IO_16 did respond as it did for 16bit
default. Tha and I was loosing every oher byte.
Please edit messages, I'm running at work over a really turkey telnet link
and editing is painful, even wholesale deletion can be slow.
Allison
9027
days inactive
9028
days old
2 comments
2 participants
participants (2)
-
allisonp＠world.std.com -
edick＠idcomm.com