You're right in both of the points you raise, Tony, but I'm not interested
so much in verifying that standards are often ignored as I am in making the
interface work in a very specific way if it is at all possible. The
difference between the way in which the WD100x-05 boards worked, for
example, as compared/contrasted with the WD1003-WAH, is quite minimal.
Likewise, the difference between the WD1003-WAH and the IDE is quite
minimal. The only REAL difference between the IDE and the 100x-05 in its
operating mode (in general terms) is quite minimal as well. That's only
true if the IDE will, as the standard states, work in 8-bit mode.
>From the standpoint of my S-100 application, the difference between the two
40-conductor cable interfaces is a little more crucial. If the IDE can be
muscled into its purported 8-bit mode, it is strictly software. The board I
want to use has an address comparator, a low-byte address buffer/latch, and
a latch (373) for the DATA OUT bus and one for the DATA IN bus, though it's
used strictly as a buffer, i.e. the gate is tied high. The Data OUT bus is
always enabled, but latched at the end of the OUT strobe developed on the
board so it remains stabile until the next local OUT. If I have to
propagate data in words, it still takes two bytes, but because of the nature
of the available adequate latches, I have to provide a sequencer to write
the data to the IDE after, not during, the OUT cycle. This has to enable
both output bytes on an OUT. It has to snag both bytes in the other
direction, and then has to sequence the enables to the two bytes in the
appropriate order AFTER the write from the IDE is complete. This, again, is
because of the nature of the best suited registers, i.e. '646's, which,
sadly. don't seem to come in a latched version. They are edge triggered,
hence you don't dare look at the data until the entire transaction on the
IDE side is over. I had the notion that the '652 or one of the other
members of that family would be a transparent latch, but apparently not . .
. <sigh>.
Doing all that is pretty simple, but it would be so much simpler in 8-bit
mode, where the card-local bidirectional data bus can serve with no latches
or buffers at all.
What that accomplishes is it makes the interface more general. For the IDE
or for the WD100x-05, I need only a connector, as all the required signals
are available on the card already. For SCSI, using either an NCR 5380 or a
WD 33C93, either of which will fit easily on the available 12x20 wirewrap
area at the top of the board. For the case in which I want to attach a
notebook drive to the board I need simply attach the fraction of a notebook
drive adapter to the IDE channel, and that's done. The only cut-n-paste I
have to do is to replace the address comparator with a GAL16V8A or faster,
and we're on our way. If I have to build the word-wide interface and the
support logic, it takes more cuts and wires, and requires a second GAL. For
that reason, I'd prefer a 68-pin CPLD and then leave the TTL component sites
vacant, using only their pads for connection points.
I find the latter approach somewhat uglier in view of the age of the S-100
and the age of these boards I want to use.
Making an S-100 interface, even making a relatively sophisitcated one, is
actually quite simple. What I would prefer is to use the TTL for which
sites are provided on the board already and make it work with hardware from
the period when the system was designed. The fact that the board is using a
disk drive fully twenty years younger is excusible only because it's to be
use mainly as a develpment tool.
Dick
----- Original Message -----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 17, 2000 5:33 PM
Subject: Re: 8-bit IDE
> >
> > Tony, your bracketed heading says it all! I'm NOT trying to "fake"
8-bit
> > I/O on the IDE interface. The published standards specify a valid 8-bit
>
> This, IMHO, depends on what you're trying to do.
>
> If you're trying to get a drive to work in 8-bit mode as an interlectual
> exercise, fine. You'll learn something about the IDE interface, and how
> PC parts rarely adhere to published standards.
>
> 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.
>
> > data transfer mode for the data port (the other ports are already
8-bit).
> > This is described rather minimally in chapter 6 wherein the registers
are
> > defined. There's an 8-bit enable bit which, when properly conditioned,
will
> > cause the data port interface to transfer 512 bytes as bytes rather than
as
> > 256 words. There are LOTS of ways to "fake" it, but I'm trying to
determine
> > whether anyone has actually operated an IDE interface normally used in
> > 16-bit mode in this obscure and, possibly, scantily supported mode.
>
> My guess is that most drives do _NOT_ implement this bit, at least not
now.
>
> One thing I've learnt over the years is that a lot of 'PC hardware' will
> work in a PC when used with the standard OSes and programs but it as sure
> as heck doesn't meet any published specs. I've had printer port cards
> that don't use open-collector drivers on the control lines (even though
> IBM specified that somewhere). I've had floppy drives that don't
> implement any parts of the SA400-like interface other than those needed
> for the PC (some of them don't even have drive select jumpers). Keyboards
> that don't implement all the modes that IBM described in the TechRef.
> Floppy controller chips that won't do single density properly. Etc, Etc,
Etc
>
> > You seem to have a good grasp of what some of the IDE signals do. I'd
be
>
> Well, I had to modify the IDE card in this PC....
>
> > 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.
>
> 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/
>
> 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.
>
> > initialize that interface in a 16-bit-capable interface, I'll see the
> > IOCS16- go away. Unfortunately, the vast majority of the old TTL
>
> Well, for an 8-bit interface, IOCS16/ doens't have much meaning...
>
> > 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).
>
> -tony
>
Received on Mon Apr 17 2000 - 20:13:44 BST