18 Apr
2000
18 Apr
'00
9:30 p.m.
Boggles the mind, doesn't it? I remember that I
paid $1250 for the first
ST506 I bought. It even said Shugart Technology rather than Seagate
Technology . That was 5 MB.
Managed to get my St506 in mid 81 for much less than half that.
connections.
Well, if you're willing to believe that what's
in the timing diagrams,
after
you see they clearly violate other spec's, you can
do that. I prefer to
latch the data to ensure that I have it. Likewise, whether I have to write
two locations or the same one twice, the data has to be latched. You also
Didnt' say you didn't need the latch only you didnt need an extra FF to
track
the silo status.
'646..'654 type device, which won't work
the way that's needed because
they're edge-triggered, you'll run up the parts count. After all, you have
to latch the low byte on writes and the high byte on reads. I think saving
What about 573s? Thats what I used. though the proto used ls373s.
parts by leaving out functionality is risky here. If
you write the high
byte to the latch first, then write the low byte AND high byte, in a single
unlatched write for the low byte, it may work, but now you can't use those
handy instructions that make the Z-80 handier than the 8080/8085.
Well true, but then I don't always use z80. one version happens to use a
8749 with a 8155 and 8251 to serialize the data for a low speed net.
I only said I didnt' require the FF to track the data, not that it would
allow INIR.
IMHO, once you have more than two components you have
to look at
programmable logic. I'm convinced that a CPLD, a small one, in fact, is
the
correct solution here, except in the case of an 8-bit
capable drive, in
which case no logic at all is needed, beyond what's already there.
I have 2064s and 3030s but those packages are a real pain to wirewrap.
Then I ahve to balast a erpm with the pattern and wire that too. No savings
in wiring. For a PC card, yep, the only way.
Yes, it's been done, and if I'm going to do the
16-bit interface, I'm going
to do it with what's essentially their code. That means a pretty similar
interface, which, by the way, is pretty minimal. It does latch both bytes
of the data at the port.
Still no need to do that. you only latch the data you cant transfer
immediately.
Saves one latch though you could use it for a gated buffer if you wanted to.
What matters to me more than making the extended
versions of CP/M work, is
making the REAL CP/M work.
Been there done that. It's easy enough, I have working examples. the
problem is with 8mb logical disks I tend to fill them and ploughing through
1000+ files
is a real pita to look at on the tube and slower than sludge cpu time wise.
Keep in mind I've been running CP/M since 1.4 was new. I have over
12 systems in the room that are running CP/M now. maybe another 5
that would run save for they are on the shelf (run but, are in storage).
Running systems CP/M more than half of which are running BIOS of my
design and ZCPR3. Some have mods to CPM like banked BIOS:
* means it's anything but stock and is a production use machine.
* hurikon MLZ92 Multibus CPM 2.2, banked.
* ISC8010 (modded) with NEC BP575 and BP2190 (two of them) running
banked with 3.5" floppies. (another multibus crate)
NS* horizon (restored, dual MDS-A) running Lifeboat CP/M 1.4
* NS* horizon with expansions and my own controllers runnign banked
ZCPR/SUPRBDOS/bios (CP/M2.2 compatable with extensions).
Current controller has 71mb (RD53). Controller is WD1002WXS with
Z80 frontend to the bus. this crate is 22years old and nothing near
stock.
NS* Advantage (restoring), 15mb CCS and floppy CP/M2.2 in 128k
Has a unique bios that attaches the NS hard disk DOS tot he cpm file
system allowing definable partitions.
* CCS runing their version and also a version of 2.2 I assembled for
Compupro
Controller (disk 1A)..
DEC vt180 (in Vt100) stock
* DEC VT180 (standalone, modded) running CP/M 2.2 from romdisk.
used as testbed for IDE, bubble memory. Runs at 6mhz (z80).
* AmproLB (scsi fujitsu 45mb) no mods other than cmos and it's production.
* Kaypro with Advent TURBOrom, 1 360k 5.25 and two 781k 3.5" floppies plus
2mb ramdisk.
Visual 1050 ( restored 128k CP/M 3) with dual 5.25 96tpi 781k, 20mb
Xebec
controller.
* Visual 1050 (modded, IDE 120mb). Banked bios CP/M2.2
* Compupro crate, NS* z80 cpu with MMU added 256k ram, Disk -1a controller
and IDE (85mb).
* Epson PX-8, with 120mb wedge CPM2.2 from rom. My laptop.
Allison
19 Apr
19 Apr
12:27 a.m.
Please see itemized comments below.
Dick
----- Original Message -----
From: allisonp <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, April 18, 2000 8:30 PM
Subject: Re: 8-bit IDE
write
savings
to.
through
Boggles the
mind, doesn't it? I remember that I paid $1250 for the first
ST506 I bought. It even said Shugart Technology rather than Seagate
Technology . That was 5 MB.
Managed to get my St506 in mid 81 for much less than half that.
connections.
Well, if you're willing to believe that
what's in the timing diagrams,
after
>you see they clearly violate other spec's, you can do that. I prefer to
>latch the data to ensure that I have it. Likewise, whether I have to >two locations or the same one twice, the data has
to be latched. You
also
Didnt' say you didn't need the latch only you didnt need an extra FF to
track
the silo status.
it's just one D-flip-flop, which, for the writes, is implemented as a shift
register that shifts out the write strobe a clock tick after the high byte
is written to the IDE. It also generates the OE* to both registers. For
reads, the negative-going read strobe enables the buffers' outputs and the
inverted read strobe clocks the registers.
>'646..'654 type device, which won't work the way that's needed
because
>they're edge-triggered, you'll run up the parts count. After all, you
have
>to latch the low byte on writes and the high byte
on reads. I think
saving
What about 573s? Thats what I used. though the proto used ls373s.
Those parts run up the parts count too much. The '646 family devices have
registers in each direction as well as a '245-style buffer bypassing them in
each direction.
>parts by leaving out functionality is risky here. If you write the high
>byte to the latch first, then write the low byte AND high byte, in a
single
>unlatched write for the low byte, it may work, but
now you can't use
those
handy
instructions that make the Z-80 handier than the 8080/8085.
Well true, but then I don't always use z80. one version happens to use a
8749 with a 8155 and 8251 to serialize the data for a low speed net.
I only said I didnt' require the FF to track the data, not that it would
allow INIR.
IMHO, once you have more than two components you
have to look at
programmable logic. I'm convinced that a CPLD, a small one, in fact, is
the
correct solution here, except in the case of an
8-bit capable drive, in
which case no logic at all is needed, beyond what's already there.
I have 2064s and 3030s but those packages are a real pain to wirewrap.
Then I ahve to balast a erpm with the pattern and wire that too. No in wiring. For a PC card, yep, the only way.
>Yes, it's been done, and if I'm going to do the 16-bit interface, I'm
going
>to do it with what's essentially their code.
That means a pretty similar
>interface, which, by the way, is pretty minimal. It does latch both
bytes
of the data at
the port.
Still no need to do that. you only latch the data you cant transfer
immediately.
Saves one latch though you could use it for a gated buffer if you wanted
>What matters to me more than making the extended versions of CP/M work,
is
making the REAL
CP/M work.
Been there done that. It's easy enough, I have working examples. the
problem is with 8mb logical disks I tend to fill them and ploughing 1000+ files
is a real pita to look at on the tube and slower than sludge cpu time
wise.
<snip>
Allison
7:42 a.m.
On Tue, 18 Apr 2000, Richard Erlacher wrote:
You do not have to explain it to me, I've done it, have working examples!
Allison
Please see itemized comments below.
PLEASE EDIT YOUR MESSAGES, IF I CAN ON A SLOW TELNET LINK YOU CAN!
Didnt' say
you didn't need the latch only you didnt need an extra FF to
track the silo status.
it's just one D-flip-flop, which, for the writes, is implemented as a shift
register that shifts out the write strobe a clock tick after the high byte
is written to the IDE. It also generates the OE* to both registers. For
reads, the negative-going read strobe enables the buffers' outputs and the
inverted read strobe clocks the registers.
9:59 a.m.
Gee! I thought I had trimmed the excess from the message I sent. I get a
couple of hundred emails every day, including this mailing list, and,
frankly, I need all the help I can get in associating the current level
message with the context. Message subjects certainly don't help much since
the fractional portions that warrant my interest aren't always entirely
central to the initial thread title.
The reason I like the '646 and friends is because it essentially provides
the register that is needed to hold the high data on a read and the buffer
to steer the high data on a write That's one part instead of two. With the
proto-space limitation I have that's an important consideration. All the
while, I've been harping on this notion that there must be SOME drives that
provided this 8-bit option, else it wouldn't have been in the standard at
all. The fact that it was not popular at all is grounds for its removal in
the 1996 standard, but as I say, I want to consider it a possibility until
I'm sure it won't work out. That would make my board a channel board rather
than a device-specific board. I like that notion as well. I won't have to
add any extra parts to those already in the artwork, thereby saving space
that can be used for connectors, and I won't have to put parts on an
external board, because the target devices use the channel as their
interface. It's a goal which I'm exploring. If I come up completely empty
in my search for IDE drives that actually support the 8-bit mode, I can
still use "normal" 16-bit IDE by putting in the circuit that works with
Tilmann Reh's GIDE hardware. I'd leave out the RTC/calendar function,
though, since I use an MSM5832 from OKI for that, having built a board back
in the '80-'81 timeframe for that.
I consider the "correct" parts count to be either 0 or 1. In the case of
the WD100x channel, it's 0, and in the case of the 8-bit IDE it's 0. If it
becomes 1, it has to be a CPLD because I can put all thenecessary registers
and buffers in there without increasing the space that's used.
Now, you've listed a couple of FPGA's. Those inherenly imply a parts count
of 2, unless you load them from your processor. I suppose it's splitting
hairs, but the parts count is really not the issue, it's the space, in my
case, because the board has only those two teensy proto-areas, one at 20 x
12 holes, and the other at 24 x 11. That's barely enough for a 68-pin
PGA/PLCC socket. Few parts come in those packages any more, so the 44-pin
PLCC might be what's left. I do have bigger wirewrap areas on other WW
boards, but this one is so close ...
Frankly, I wish the current generation XILINX software would support the
2000 and 3000 series parts, but the former was end-of-lifed some 10 years
ago and the 3000 has been replaced with the 3000-A series and 3100 series.
The 3030 would make my job MUCH simpler, but I just can't use one due to
software incompatibility.
That's how they get us to buy more parts and throw out the old ones, doncha
know!
----- Original Message -----
From: <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, April 19, 2000 6:42 AM
Subject: Re: 8-bit IDE
On Tue, 18 Apr 2000, Richard Erlacher wrote:
to
<snip>
Please see itemized comments below.
PLEASE EDIT YOUR MESSAGES, IF I CAN ON A SLOW TELNET LINK YOU CAN!
> > Didnt' say you didn't need the latch only you didnt need an extra FF
You do not have to explain it to me, I've done it, have working examples!
Allison
3:45 p.m.
The reason I like the '646 and friends is because
it essentially provides
the register that is needed to hold the high data on a read and the buffer
If you have a unified bus it's a good part. S100 (raw) is not unified so
it's less than helpful.
The compromise is to make the board a channel (like mine) and use a
interface adaptor between it and the drive (IDE-16).
Frankly, I wish the current generation XILINX software
would support the
2000 and 3000 series parts, but the former was end-of-lifed some 10 years
ago and the 3000 has been replaced with the 3000-A series and 3100 series.
The 3030 would make my job MUCH simpler, but I just can't use one due to
software incompatibility.
Blame w96 for that. I have the old generation stuff and run W3.1 (though
I'm trying it under NT4).
That's how they get us to buy more parts and throw
out the old ones, doncha
know!
I just don't bend to that.
Allison
5:18 p.m.
On Wed, Apr 19, 2000 at 08:59:40AM -0600, Richard Erlacher wrote:
Gee! I thought I had trimmed the excess from the
message I sent.
And yet, even in *this* message, you included 100% of Allison's message
to which you were replying. PLEASE just trim it to the paragraphs you're
actually addressing in your reply, some people are paying per packet to
receive this list and anyway it's a real pain to have to page through
many screens of text trying to find the parts that are new.
All the
while, I've been harping on this notion that there must be SOME drives that
provided this 8-bit option, else it wouldn't have been in the standard at
all.
Well, for that matter, the SCSI-2 standard tells us that wide drives have
the signals spread across *both* a 50- *and* a 68-pin cable. But good luck
finding an actual drive like that. Some standards are obviously the result
of bickering in the committee and are too silly to implement for real.
Similarly, the 8-bit ISA market had shriveled up by the late 80s so it's
certainly understandable that manufacturers building new drives (especially
the really fancy 2.5" portable ones) wouldn't bother with an 8-bit mode.
Who would need it?
Frankly, I wish the current generation XILINX software
would support the
2000 and 3000 series parts, but the former was end-of-lifed some 10 years
ago and the 3000 has been replaced with the 3000-A series and 3100 series.
The 3030 would make my job MUCH simpler, but I just can't use one due to
software incompatibility.
All the more reason to use MSI TTL when it's a good fit (and appropriate to
computers from that era).
John Wilson
D Bit
6:41 p.m.
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, April 19, 2000 4:18 PM
Subject: Re: 8-bit IDE
<snip a bit of stuff that's true enough>
to
On Wed, Apr 19, 2000 at 08:59:40AM -0600, Richard
Erlacher wrote:
that
Gee! I thought I had trimmed the excess from the
message I sent.
And yet, even in *this* message, you included 100% of Allison's message
to which you were replying. PLEASE just trim it to the paragraphs you're
actually addressing in your reply, some people are paying per packet to
receive this list and anyway it's a real pain to have to page through
many screens of text trying to find the parts that are new.
> All the
> while, I've been harping on this notion that there must be SOME drives
> provided this 8-bit option, else it wouldn't
have been in the standard
at
all.
Well, for that matter, the SCSI-2 standard tells us that wide drives have the really fancy 2.5" portable ones) wouldn't
bother with an 8-bit mode.
Who would need it?
> Frankly, I wish the current generation XILINX software would support the
> 2000 and 3000 series parts, but the former was end-of-lifed some 10
years
> ago and the 3000 has been replaced with the
3000-A series and 3100
series.
The 3030 would
make my job MUCH simpler, but I just can't use one due to
software incompatibility.
All the more reason to use MSI TTL when it's a good fit (and appropriate computers from that era).
Well, not if it means more work, particularly drilling holes for IC's. This
is a purely Xilinx problem. They switch software and obsolete parts more
than their competitors. I really prefer devices I can program by
themselves. They do make some nice and cheap CPLD's, though. The choices
in deciding between integrated vs. programmable logic is not so simple. I
do like to keep mod's in the same generation as the original, so it could
have been done at the time.
I find the choice depends on several factors. (1) if I'm building a tool,
all other priorities are off in favor of speed and ease, (2) not everybody
wants to maintain the level of technology of other hardware in the
environment. If, for example, the generational mix is already quite
diverse, I have no reservations whatsoever about using a better part than
was available when the various system components were designed. (3) If
there's a limitation on space or if using new technology, e.g. programmable
logic, will reduce the number of parts involved, particularly if using
denser programmable logic will make the work involved in making an upgrade
or fix happen amount to less, particularly if it's less irreversible effort,
e.g. drilling holes, I prefer the more modern components.
In this case, there's a limitation on space, so I'm inclined to use what's
dense and handy. but only if I can't find a simpler solution. Today's
devices drive as hard, and symmetrically rather than what the old TTL used
to do, as any TTL device. Consequently, it's easy to use one programmable
device in place of a quantity of hardware that wouldn't even fit on several
boards. That's generally not necessary, though I'm tempted simply to remove
all the datapath and glue logic from my various S-100 boards and replace it
with a single CPLD. That way, if something breaks, I just stick in a new
CPLD and it's likely to work. No fiddling around with one component or
another. It's also a cheaper way to do the "shotgun" repair, since
there's
only one "logic" component.
BTW, I'm not particularly fond of FPGA's for a number of reasons. One of
these reasons is that the parts that I now find I can't use are the ones I
bought ten years ago for several hundred dollars each.
John Wilson
D Bit
9026
days inactive
9027
days old
6 comments
3 participants
participants (3)
-
allisonp＠world.std.com -
edick＠idcomm.com -
wilson＠dbit.dbit.com