14 Aug
2008
14 Aug
'08
10:55 a.m.
Date: Wed, 13 Aug 2008 13:49:22 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Upgrading early BIOS
On 13 Aug 2008 at 15:36, M H Stein wrote:
> AFAIK cable select has always been an option with
Parallel ATA drives,
> although it was rarely used in pre-UDMA days; the cable was obviously
> different (40 conductors with standard connectors vs. 80 conductors and
> unique special connectors) and the order of the drives was usually reversed
> (i.e. the slave on the end of the cable).
Nope--I've got a couple of very early Conner and
Maxtor drives (less
than 100 MB)--CS isn't an option on the jumpers.
If you'd read more carefully, you'd have seen that I *did* say that "not all
drives
supported the CS option;" in fact, quite a few of the older drives did not.
I was responding to the posted statement that CS "had not been invented" in
the 486 days, when AFAIK, it was part of the early ATA specs (although
rarely implemented in practice).
It's the motherboard that determines the cable
type and mode from pin 34,
which is grounded at the mobo end in a UDMA cable, so if the mobo isn't
UDMA-aware I don't think the drives would be, and the cable wouldn't matter.
Also, not all drives supported CS.
Read the Wiki article you cited:
"Pin 34:
Pin 34 is connected to ground inside the blue connector
of an 80
conductor cable but not attached to any conductor of the cable. It is
attached normally on the gray and black connectors".
On UDMA-66 capable drives, it's the cable, not the
mobo that dictates
speed. Put an ordinary 40 conductor cable on a UDMA-capable drive
and mobo, and the configuration won't take advantage of it. When the
changeover was in progress, we used to get support calls quite often
on the subject of UDMA cables and drives on non-UDMA mobos.
Well, I never knew that just replacing the cable in my 386 and 486 systems
would speed things up; live and learn. I always thought that if the mobo
wasn't pin 34 aware and UDMA capable then the cable wouldn't have much
effect on the transfer mode. AFAIK in order to use UDMA all three items
have to be UDMA capable, the mobo, the cable and the drives, although
I'd say that, assuming it's UDMA aware, the mobo controls the speed
depending on what kind of cable and drives it sees. Semantics?
You said that with a UDMA cable, any UDMA capable drive will operate in
UDMA mode (presumably regardless of the mobo); how does a drive know
what kind of cable is connected? I always assumed that only the mobo can
tell from pin 34.
BTW, a UDMA cable certainly works with non-UDMA drives and/or mobos,
although you have to remember that it is also a CS cable, but I don't think
it'll be any faster.
Similarly:
"With the 40-wire cable it was very common to
implement cable select
by simply cutting the pin 28 wire between the two device connectors;
putting the slave device at the end of the cable, and the master on
the "middle" connector. This arrangement eventually was standardized
in later versions. If there is just one device on the cable, this
results in an unused "stub" of cable, which is undesirable for
physical convenience and electrical reasons. The stub causes signal
reflections, particularly at higher transfer rates."
Bottom line is that if you use a non-CS-capable (i.e.
40 conductor
"straight through") cable, it won't work. Depending on what the
mobo/controller end does with pin 28, you'll have either two masters
or two slaves on the same cable.
Agreed; I took it for granted, but with our detour into UDMA the most
important point to be made relevant to the OP is that Cable Select needs
a special cable and with pre-UDMA drives & mobos you're probably
better off using Master/Slave and a standard cable.
Cheers,
Chuck
m
14 Aug
14 Aug
12:24 p.m.
On 14 Aug 2008 at 10:55, M H Stein wrote:
Well, I never knew that just replacing the cable in my
386 and 486 systems
would speed things up; live and learn. I always thought that if the mobo
wasn't pin 34 aware and UDMA capable then the cable wouldn't have much
effect on the transfer mode. AFAIK in order to use UDMA all three items
have to be UDMA capable, the mobo, the cable and the drives, although
I'd say that, assuming it's UDMA aware, the mobo controls the speed
depending on what kind of cable and drives it sees. Semantics?
Partly, I suppose. I can speak only from (a pile of) experience.
Using a UDMA cable can create some real problems with older systems.
And some early supposedly-UDMA-capable systems can't handle the full
transfer rate of UDMA-133.
IDE's pretty much been a mess from Day One. For example, I've got an
early IDE drive that flips the endian-sense on the word pair returned
for the total number of sectors on the drive. It was not uncommon
for drives from two different manufacturers not to work as master-
slave on the same cable.
At any rate, for the OP my advice stands. Use a 40-conductor cable
and forget about cable select--jumper for master and slave. And
cross your fingers and offer up a chicken or two to whatever deity is
in charge of IDE operation.
Cheers,
Chuck
1:36 p.m.
Chuck Guzis wrote:
Using a UDMA cable can create some real problems with
older systems.
Indeed - or newer ones... (I've got a DVD-RW drive here which randomly
disappears from the bus when used with a UDMA cable)
IDE's pretty much been a mess from Day One. For
example, I've got an
early IDE drive that flips the endian-sense on the word pair returned
for the total number of sectors on the drive.
I had one of those, too - I think it was a Maxtor, but could be wrong (drive
long since tossed). Circa 1994 I was writing an IDE driver for a fledgling OS,
and it was amazing how many quirks there were out there with drives of that
period. Funny how SCSI seemed to get a bad name for that kind of thing, yet
IDE's reputation stood intact despite all the inconsistencies.
It was not uncommon
for drives from two different manufacturers not to work as master-
slave on the same cable.
... and yet sometimes such a pair would work the other way around.
(and don't get me started on the manufacturers who used microscopic jumpers
which had a habit of falling off at random moments... Quantum were bad for
this, I recall)
cheers
Jules
2:08 p.m.
On 14 Aug 2008 at 12:36, Jules Richardson wrote:
Funny how SCSI seemed to get a bad name for that kind
of thing, yet
IDE's reputation stood intact despite all the inconsistencies.
One of the answers that I wanted to convey to the OP was "If you want
to (fairly) painlessly increase hard disk storage on an older system,
get a SCSI controller and drive." But ISA SCSI controllers are
getting harder to find, so that's probably a no-go.
IDE is cheap in comparison to SCSI, so that was probably one very
good reason why it found wide adoption.
If disks were bad, tapes were far worse. There was all manner of
mutually-incompatible cheap tape backup out there. We insisted as
SCSI being the only tape interface that we would support--there was
an ANSI-defined common command set and most of the later units were
read-after-write verification. I wonder how many of those old DC2000
carts written on floppytape drives are still readable? And who can
still read their Datasonix Pereos tapes? (I've got some Irwin-
recorded DC1000s that I really should check for readability one of
these days).
For us, 4mm DAT was most popular based on media cost, followed
closely by Exabyte 8mm. DLT was third, mostly because of very high
media cost. Bernoulli and other removable media drives were also
very popular.
Cheers,
Chuck
3:12 p.m.
Chuck Guzis wrote:
On 14 Aug 2008 at 12:36, Jules Richardson wrote:
For sure - but SCSI seemed to have a reputation for being picky about cabling,
host adapter settings, device ordering etc. - all the exact same things which
have plagued IDE over the years. Given that IDE was more accessible due to it
being cheaper technology, I'm surprised that it too didn't gain a reputation
for requiring goat sacrifices and the like that SCSI did. I suppose cost wins
out over common sense at times...
Funny how SCSI seemed to get a bad name for that
kind of thing, yet
IDE's reputation stood intact despite all the inconsistencies.
One of the answers that I wanted to convey to the OP was "If you want
to (fairly) painlessly increase hard disk storage on an older system,
get a SCSI controller and drive." But ISA SCSI controllers are
getting harder to find, so that's probably a no-go.
IDE is cheap in comparison to SCSI, so that was probably one very
good reason why it found wide adoption. If disks were bad, tapes were far worse. There was
all manner of
mutually-incompatible cheap tape backup out there. We insisted as
SCSI being the only tape interface that we would support--there was
an ANSI-defined common command set and most of the later units were
read-after-write verification.
Yep - there was an awful lot of proprietary stuff out there. Personally I'm a
DLT fan - like you say, it's expensive, but it's worth it for the reliability.
I used to really like DAT (mainly for compactness) until I started seeing tape
and drive reliability problems all over the place.
cheers
Jules
3:42 p.m.
Jules Richardson wrote:
For sure - but SCSI seemed to have a reputation for
being picky about
cabling, host adapter settings, device ordering etc. - all the exact
same things which have plagued IDE over the years. Given that IDE was
more accessible due to it being cheaper technology, I'm surprised
that it too didn't gain a reputation for requiring goat sacrifices
and the like that SCSI did. I suppose cost wins out over common sense
at times...
I got the impression that SCSI was used (in those days) in higher
end systems. If you stuck with one vendor, you probably only played
with well tested configs but if you tried to save money because "it's
all SCSI, it must all play together" then you could run into issues.
I know one of the reasons that DEC was late to the SCSI game was that
they felt it didn't meet their reliablity requirements.
If you used IDE in the PC space you would almost certainly be fine
unless you shoved two disks on one cable - and I guess that most
people (and corporations) didn't do that.
These days you would expect everything to work everywhere.
Antonio
4:11 p.m.
On 14 Aug 2008 at 20:42, Antonio Carlini wrote:
I got the impression that SCSI was used (in those
days) in higher
end systems. If you stuck with one vendor, you probably only played
with well tested configs but if you tried to save money because "it's
all SCSI, it must all play together" then you could run into issues.
I know one of the reasons that DEC was late to the SCSI game was that
they felt it didn't meet their reliablity requirements.
Early SCSI was pretty awful, largely the province of users with Macs,
but by the time that the Adaptec 1540 series hit the market, things
had gotten a lot better. Drivers were always an issue (e.g., does
anyone have a NetBSD driver for an Ultrastor 14N?).
If you wanted a bunch of storage on a PC-type machine, SCSI was
pretty much the only way to get it. 7 devices (or 56 if you could
unit-address them) on a SCSI bus was pretty cool--particularly if you
had an interest in RAID. I have a couple of Adaptec 3985 PCI cards
that appear to the system as 3 2940 controllers. Intended for
Netware RAID setups.
I believe that SCSI was used extensively for external devices, where
that was rare for IDE. External means confusion with cabling,
termination, etc. The multiple SCSI electrical varieties (8-bit,
wide, ultra-wide, ultra2-wide, differential, etc.) didn't help un-
muddy the waters either.
Cheers,
Chuck
15 Aug
15 Aug
2:42 p.m.
On Thu, Aug 14, 2008 at 12:12 PM, Jules Richardson
<jules.richardson99 at gmail.com> wrote:
Given that IDE was more
accessible due to it being cheaper technology, I'm surprised that it too
didn't gain a reputation for requiring goat sacrifices and the like that
SCSI did. I suppose cost wins out over common sense at times...
I'll give some additional reasons...
0. Most people never actually did backups and still don't.
1. SCSI supported daisy chaining with too many devices on one chain.
With two devices and one host on one cable there is less likelihood of
a problem than there is with with two devices and one host on two
chained cables with a terminator. And far less likelihood of a
problem than there is with 7 devices and one host on 7 cables and a
terminator. One incompatible or uncooperative device on the chain and
they all stop working.
2. DB-25 implementations of SCSI allowed the use of cheap printer
cables that really weren't up to the task of handling SCSI data rates.
3. Termination options could also be a pain... Terminator on the
device (meaning you need to open the box to see if it's terminated).
Autotermination (which sometimes put termination at the wrong spot in
the chain. Passive terminators. Active terminators. The Mac IIfx
special black terminator. SCSI printer interfaces that didn't even
have a second connector on them. And later when wide SCSI showed up,
narrow devices would only terminate half the lines.
4. For disks IDE was (and still is) half the price for the same
drive with a different controller.
Yep - there was an awful lot of proprietary stuff out
there. Personally I'm
a DLT fan - like you say, it's expensive, but it's worth it for the
reliability.
I'm totally off tape. Our experience with DLT is that the drives
don't last, transfer rates are too slow, and the media are too
unreliable and too expensive. Haven't tried LTO Ultrium, but for
$1700 for a drive and $40 for a 400GB (uncompressed) tape it's too
expensive when you can get 750GB SATA drives for $150. (The crossover
point is 17TB).
Eric
3:13 p.m.
On Friday 15 August 2008, Eric J Korpela wrote:
On Thu, Aug 14, 2008 at 12:12 PM, Jules Richardson
If you think that DLT was unreliable, you must have had bad (Imation)
tapes, tried to use DLT8000 or cheap-o DLT-1 drives. We had very few
problems with Fujifilm tapes, and DLT7000 drives... not that we didn't
have any problems, but it was in a high-usage environment (HSM) that I
wouldn't have wanted to think about trying to power enough disks to
store that much data.
Our compression rate is at least 1.5:1 on average, we've found too.
FWIW, you can get LTO-2 drives for under $500 (I paid $500 for a
top-o-the-line used IBM LTO-2 drive about a year and a half ago), and
tapes for quite cheap these days, around $20-$25 for good quality
Fujifilm LTO-2 tapes.
I also think that comparing the cheapest possible SATA drives to
high-end LTO tapes is a bit like apples to oranges; you might as well
compare LTO drives to $1/GB FC/SAS disks, which have a similar market,
reliability, and speed.
Also, if you want to complain about speed, it's hard to find a single
disk that can keep up with the streaming speed of a new LTO-4 tape
drive.. Tape is keeping up with disk technology just fine. LTO-3 is
over 100MB/sec itself, and I've seen at least 50MB/sec off of my U160
SCSI LTO-2 drive.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Yep - there was an awful lot of proprietary stuff
out there.
Personally I'm a DLT fan - like you say, it's expensive, but it's
worth it for the reliability.
I'm totally off tape. Our experience with DLT is that the drives
don't last, transfer rates are too slow, and the media are too
unreliable and too expensive. Haven't tried LTO Ultrium, but for
$1700 for a drive and $40 for a 400GB (uncompressed) tape it's too
expensive when you can get 750GB SATA drives for $150. (The
crossover point is 17TB). 
3:27 p.m.
>>>> "Patrick" == Patrick
Finnegan <pat at computer-refuge.org> writes:
Patrick> .... We had very few problems with Fujifilm tapes, ...
Really? That's surprising.
Every Fuji audio tape I have (several dozen) has gone bad over the
years (loud squeaking audible both from the tape transport and over
the playback audio). Every last one. No other name brand has failed,
not even one tape.
For this reason, I no longer buy any Fuji product of any kind.
paul
16 Aug
16 Aug
12:08 a.m.
On Friday 15 August 2008, Paul Koning wrote:
Lots of manufacturer's products quality vary over the life of the
company... and I would never equate audio tape to data tape quality
anyways, especially considering the difference in cost (and I'm
guessing also the difference in age).
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
>>>> "Patrick" == Patrick Finnegan <pat at
computer-refuge.org> writes:
Patrick> .... We had very few problems with Fujifilm tapes, ...
Really? That's surprising.
Every Fuji audio tape I have (several dozen) has gone bad over the
years (loud squeaking audible both from the tape transport and over
the playback audio). Every last one. No other name brand has
failed, not even one tape.
For this reason, I no longer buy any Fuji product of any kind. 
12:55 a.m.
Patrick Finnegan wrote:
Lots of manufacturer's products quality vary over
the life of the
company... and I would never equate audio tape to data tape quality
anyways, especially considering the difference in cost (and I'm
guessing also the difference in age).
I am guessing the *real* audio stuff is way more expensive as
we are talking studio production equipment here. None the
less you get what you pay for.
Pat
PS: "The tape project" is project to put music on reel to reel tape
with as high quality as possible - I think they quoted about $50
for a reel of 1/4" tape. 2400 feet?
4:31 p.m.
On Fri, Aug 15, 2008 at 12:13 PM, Patrick Finnegan
<pat at computer-refuge.org> wrote:
On Friday 15 August 2008, Eric J Korpela wrote:
We got most of our tapes and drives donated from Fujifilm, and at
times Quantum and Compaq.
The vast majority of the tapes were Fujifilm. But even then, we had
brand new Fujifilm tapes occasionally kill a drive and few percent of
our tapes were "write only". Average lifetime of a drive was about a
year (of nearly continuous operation.)
On Thu, Aug 14, 2008 at 12:12 PM, Jules
Richardson
If you think that DLT was unreliable, you must have had bad (Imation)
tapes, tried to use DLT8000 or cheap-o DLT-1 drives. We had very few
problems with Fujifilm tapes, and DLT7000 drives... Yep - there was an awful lot of proprietary stuff
out there.
Personally I'm a DLT fan - like you say, it's expensive, but it's
worth it for the reliability.
I'm totally off tape. Our experience with DLT is that the drives
don't last, transfer rates are too slow, and the media are too
unreliable and too expensive. Haven't tried LTO Ultrium, but for
$1700 for a drive and $40 for a 400GB (uncompressed) tape it's too
expensive when you can get 750GB SATA drives for $150. (The
crossover point is 17TB). Our compression rate is at least 1.5:1 on average,
we've found too.
Unsurprisingly, the compression you'll get will be almost exactly the
same that gzip will give you if you're streaming to disk. Compression
is a software function.
I also think that comparing the cheapest possible SATA
drives to
high-end LTO tapes is a bit like apples to oranges; you might as well
compare LTO drives to $1/GB FC/SAS disks, which have a similar market,
reliability, and speed.
You're buying into somebody's marketing. In actual use FC, SCSI and
SAS disks have failure rates that are nearly identical to SATA and ATA
drives for 7500 RPM drives. In our experience failure rates go up
with the drive rotation rate, although I have not seen a study of
that. The only reason you would choose to pay extra for SCSI/FC/SAS
is to get the faster rotation rate. The reason that manufacturers
don't offer 10K and 15K RPM drives in SATA and ATA is that people
probably won't pay as high a premium as they will with SCSI and FC.
In terms of failures of communication between the controllers and the
drives, FC over fiber is the wost ever. We multipath all fiberchannel
devices because controllers have a tendency to freeze on any error.
SCSI is getting worse as time goes on because the connectors keep
getting smaller and weaker. We also multipath anything with VHDCI
connectors.
Also, if you want to complain about speed, it's
hard to find a single
disk that can keep up with the streaming speed of a new LTO-4 tape
drive..
If you buy one of those who can afford a disk? Anyway if you're
backing to 800GB tapes it's pretty unlikely it's coming off a single
disk.
Eric
15 Aug
15 Aug
4:58 p.m.
Eric J Korpela wrote:
On Thu, Aug 14, 2008 at 12:12 PM, Jules Richardson
<jules.richardson99 at gmail.com> wrote:
Hmm, good points... I suppose I never really thought of the DB-25 Apple SCSI
(or those bloody SCSI Iomega drives) as being "real SCSI", but maybe that was
a lot of peoples' first exposure to the technology.
The termination issue's always puzzled me, because the rules for how and when
to terminate have seemed so clear. I agree that auto-termination was one of
those features that never should have happened, though - it does seem prone to
screwing things up.
Given that IDE was more
accessible due to it being cheaper technology, I'm surprised that it too
didn't gain a reputation for requiring goat sacrifices and the like that
SCSI did. I suppose cost wins out over common sense at times...
I'll give some additional reasons...
[snip] I'm totally off tape. Our experience with DLT is
that the drives
don't last, transfer rates are too slow, and the media are too
unreliable and too expensive.
I've never had any issues to be honest. I've heard lots of bad things about
the DLT-8000 technology, though.
it's too expensive when you can get 750GB SATA
drives for $150.
I keep waiting for a hard disk vendor to come out with a 'backup drive' which
has an unloadable head assembly and the platter stack in a removable pack,
accessible through the front of the machine - just like the olden days :-)
cheers
Jules
16 Aug
16 Aug
4:47 p.m.
Eric J Korpela wrote:
4. For disks IDE was (and still is) half the price
for the same
drive with a different controller.
This is only partly true. Although the drives are substantially the
same, I'm told (by people who used to work for disk manufacturers)
that they effectively "sail closer to the wind" with the IDE drives.
Every penny saved there really makes a difference to what is (in
essence) a cost conscious audience. If you are buying SCSI you
are more likely to be an enterprise so if your disk dies prematurely
that's more than just one lost sale. (The same is true of FC, only
even more so).
My main buying criterion these days (once I've decided on capacity
and perhaps approximate speed) is the length of the guarantee
period!
Antonio
17 Aug
17 Aug
6:09 p.m.
At 03:47 PM 8/16/2008, Antonio Carlini wrote:
My main buying criterion these days (once I've
decided on capacity
and perhaps approximate speed) is the length of the guarantee
period!
1 terabyte Seagate 7200.11 drives, 5-year warranty, SATA-300, NCQ, 32M,
were on sale for $110 at Dell a few days ago.
- John
14 Aug
14 Aug
4:06 p.m.
>>>> "Chuck" == Chuck Guzis
<cclist at sydex.com> writes:
Chuck> On 14 Aug 2008 at 12:36, Jules Richardson wrote:
> Funny how SCSI seemed to get a bad name for that
kind of thing,
> yet IDE's reputation stood intact despite all the inconsistencies.
Chuck> ...
Chuck> If disks were bad, tapes were far worse. There was all manner
Chuck> of mutually-incompatible cheap tape backup out there. We
Chuck> insisted as SCSI being the only tape interface that we would
Chuck> support--there was an ANSI-defined common command set and most
Chuck> of the later units were read-after-write verification. I
Chuck> wonder how many of those old DC2000 carts written on
Chuck> floppytape drives are still readable? And who can still read
Chuck> their Datasonix Pereos tapes? (I've got some Irwin- recorded
Chuck> DC1000s that I really should check for readability one of
Chuck> these days).
Sure, but SCSI didn't necessarily cure these issues. I still have a
4mm DAT drive from Colorado Memories (or some name like that --
acquired by HP years ago). If I remember right it comes with a SCSI
controller, and it works with that controller -- but not with any
other SCSI controller. And it requires proprietary software that was
promptly discontinued by HP.
I can still use that drive but only because I still have the Win95
system that can support the software, and the floppies it came on.
Even the mainframe world isn't that painful -- at least not where 1/2
inch tapes are concerned. 7 track is more difficult, and I wouldn't
want to imagine the pain involved in reading 1 inch 14 track tapes
(CDC early 1960s) never mind even more ancient stuff like Uniservo
tapes...
paul
4:35 p.m.
On 14 Aug 2008 at 16:06, Paul Koning wrote:
Sure, but SCSI didn't necessarily cure these
issues. I still have a
4mm DAT drive from Colorado Memories (or some name like that --
acquired by HP years ago). If I remember right it comes with a SCSI
controller, and it works with that controller -- but not with any
other SCSI controller. And it requires proprietary software that was
promptly discontinued by HP.
I can still use that drive but only because I still have the Win95
system that can support the software, and the floppies it came on.
I wonder which drive you have (T3000 maybe?). I've got at least one
Colorado, several Archive and a few drives with the HP logo, all 4mm
DAT and they all obey the standard command set and pretty much work
on any mainline SCSI controller. In particular, the Archive is a
magazine loader and obeys the SCSI command set for autoloader
"robots".
OTOH, the Colorado floppy tape drives were pretty awful.
We tended to advise customers to stick with the more established
controllers. Adaptec 154x, 2840, 294x. There was a lot of
variability among controllers, but we found the common Adaptec models
to be the most consistent in their support. The 2920 (really a
rebranded Future Domain model) was less dependable.
Cheers,
Chuck
15 Aug
15 Aug
10:41 a.m.
Chuck Guzis wrote:
I wonder which drive you have (T3000 maybe?).
I've got at least one
Colorado, several Archive and a few drives with the HP logo, all 4mm
DAT and they all obey the standard command set and pretty much work
on any mainline SCSI controller. In particular, the Archive is a
magazine loader and obeys the SCSI command set for autoloader
"robots".
There was an HP-branded ISA adapter, an Adaptec chip if I recall,
that was sold with one of the ScanJet flatbed scanners. It was of
course non-bootable, but the couple I've run into were also completely
unreliable with storage devices.
Doc Shipley
14 Aug
14 Aug
2:16 p.m.
On 14 Aug 2008 at 12:36, Jules Richardson wrote:
I had one of those, too - I think it was a Maxtor, but
could be wrong (drive
long since tossed).
I just checked some old code. It was indeed Maxtor:
// DetermineGeometry - Get a solid reading on drive geometry.
// ----------------------------------------------------------
//
// We compute logical CHS if we're in LBA mode and we also
// work out the problem with some Maxtor drives that have the
// LBA capacity words swapped!
//
Cheers,
Chuck
4:28 p.m.
Jules Richardson wrote:
(and don't get me started on the manufacturers who
used microscopic
jumpers which had a habit of falling off at random moments... Quantum
were bad for this, I recall)
Don't forget the good old Maxtor 7850AV... 2mm pitch jumpers on pin headers
that were just slightly too short for the jumper caps.
I lost the master-slave jumper from one of mine. Wire-wrap wire is a good
replacement. Well, it hasn't fallen off yet... :)
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
4:37 p.m.
Philip Pemberton wrote:
Jules Richardson wrote:
Oooh, SHINY!
That puts 12 or 15 1GB and 2GB Seagates back in biz. Thanks!
Doc
(and don't get me started on the
manufacturers who used microscopic
jumpers which had a habit of falling off at random moments... Quantum
were bad for this, I recall)
Don't forget the good old Maxtor 7850AV... 2mm pitch jumpers on pin
headers that were just slightly too short for the jumper caps.
I lost the master-slave jumper from one of mine. Wire-wrap wire is a
good replacement. Well, it hasn't fallen off yet... :)
5825
days inactive
5828
days old
22 comments
12 participants
participants (12)
-
arcarlini＠iee.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
classiccmp＠philpem.me.uk -
dm561＠torfree.net -
doc＠mdrconsult.com -
jfoust＠threedee.com -
jules.richardson99＠gmail.com -
korpela＠ssl.berkeley.edu -
pat＠computer-refuge.org -
Paul_Koning＠Dell.com