I used to run all SCSI, but as the drives have gradually died I've
replaced them with SATA, so that I now have one mixed system with the
remaining SCSI drives attached to an LVD 160 card. Boot times are
about the same for this as SATA, both noticeably faster than IDE.
This particular mixed PC kept giving me sudden freezes and the like,
and when I examined the System Event log for those events that had
managed to create one, SCSI was clearly implicated. Finally, almost
in despair as being the only thing I hadn't tried, I swapped the tidy
comparatively modern cable for an older one, the plastic wrapping of
which has deteriorated to the point the individual strands were
separating from each other! Despite the state of the old cable, the
problems vanished, and as conviction grew in time the shiny newer one
was consigned to the metals recycling box. I hate to tempt fate, but
(touch wood), the PC's still working like that now, some years later.
I don't know if there's anything else I can suggest in your
circumstances, as you claim to have tried a lot already, but for the
benefit of others if not yourself, I have two pages on my website that
might helpin such situations, one specifically about SCSI and other
about diagnosing PC hardware faults ...
Similar here really. I used to run lots of Amiga kit and hence using
SCSI meant I could share stuff with the PC. But the list of SCSI kit I
need to keep running is dwindling. The machine I am typing this on has a
8GB SCSI LVD boot drive on a AHA-2940U2W (plus a couple of DVD/CD
devices), plus IDE and SATA additional drives. This one has always been
The problem one (my games / video editing box) has a AHA-29160N with
just a couple of scanners on it now. Its also got a striped set on a
paradise PATA RAID controller.
One of Pournelle's laws IIRC - always suspect the cable.
Its a few years since I gave up fiddling with the problem drive, but I
am fairly sure I tried alternate cables.
I have no particular need to get that drive working - although I suppose
it is a shame having a high spec drive sit there doing nothing. Next
time I rebuild this machine I may try swapping it in for the 8GB unit.
It may be it will be happier running on the slower host adaptor.
Nice set of notes BTW. (you may want to have a go a rewording that 8 bit
on a 16 bit bus section though - I had to read it three times!)
Yup, pretty sure I tried all of those, which is why I took it out in the
end. It was only the second SCSI device to ever cause me a problem. The
first was a Conner CFP1060S 1GB SCSI drive (back in the days where 200MB
was a big drive!) That turned out to have a firmware error that showed
up on Linux, and as it also transpired Amigas. Fortunately they did a
patch for it that fixed it.
That's still considerably less times than I have reworded it! :-)
Seriously though, it is a very complicated situation which I admit is
not easy to explain, so it always was unlikely that I did a perfect
job. If you wish, feel free to suggest a rewording of your own
(bearing in mind the need to preserve sensible pagination if the
content is printed), and if I think it's better, I'll amend the page
Yes. I had a quick look at the booting section, and it's good.
A couple of comments -- There's about 440 bytes for the MBR
code nowadays (more than half a sector). It used to be a few
bytes more, but Vista decided to steal some space before the
partition table for its own purposes, so you can't boot Vista
if you go over 440 bytes of MBR code.
For the BIOS disk ids, 0 and 1 are the floppies, and 0x80 and
0x81 are the hard drives, which came along later ;-).
[email address is not usable -- followup in the newsgroup]
On 04 Apr 2009 11:07:35 GMT, email@example.com (Andrew
Yes, I should update or amend that - the actual amount used by the
boot loader seems to depend on the make and era of the operating
system that installed it.
But my point is that the disk designation depends on what of many
programs you happen to be running. BIOS has one way of designating
them, Diskprobe which you might use to troubleshoot the disk another,
Ghost which you might use to back it and restore it another, and so
on, so Disk 0 in one is something else in another.
I had two - the original which I reflashed, and a second I bought a
about year later (which had fixed firmware by then). The first one went
on forever (10+ years in a fairly poorly ventilated box with constant
use. I expect it still works!), the later one died after about four
How about something like:
"While it is possible to connect a 'narrow' (8-bit) device to a 'wide'
(16-bit) bus using a suitable 68 to 50 way adaptor, this should be
avoided if possible, since it can introduce complications with bus
termination. If your 16-bit card has a dedicated 8-bit connector, it is
better to use that for 8-bit devices. Note however that with some cards
(e.g. Adaptec's AHA-2940UW), even this does not necessarily solve the
problems, since the 8-bit connector is still on the same physical 16 bit
bus as the 16 bit connector, but connected only to the control bits and
lower half of the 16 bit bus. This may mean that to get correct
termination of the bus, you may need to apply it to the high and low
sections of the bus in completely different places
For an explanation of this along with diagrams illustrating the various
permitted layouts, the is FAQ from Adaptec."
Thanks, and sorry for not replying sooner, been concentrating on
The following seems to me an improvement taking the best bits of each
and is still concise enough to maintain pagination ... Any advances?
If possible, avoid connecting to the same bus both 'wide' 16-bit and
'narrow' 8-bit devices (the latter using 68 to 50 way adaptors), as
this can lead to performance and termination issues. Where 16-bit
cards have an 8-bit connector, use that for 8-bit connections, but
note that with some such cards, for example Adaptec's AHA-2940UW,
these separate connectors may nevertheless actually be on one bus -
the bus can be regarded as entering the controller via the 16-bit
connector, the high 8 data bits end on the controller, while the low 8
data bits and the control bits continue out through the 8-bit
connector. Additionally connecting external devices to the backplane
complicates this situation still further. For an explanation of such
complexities with diagrams illustrating the various permitted layouts,
see Adaptec's FAQ.
And later under Termination:
The controller may also be at one end of an internal cable on another
connector. On some controllers, this might be an entirely separate
secondary bus needing normal termination, but with Adaptec's
AHA-2940UW we have also seen that this controller can be at the end of
the high 8-bits of the main bus, and so should terminate them, while
at the same time being in the middle of the low 8-bits and the control
bits, and so should not!
Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
On Sat, 04 Apr 2009 03:44:19 +0100, John Rumm wrote:
I've always thought of it as two separate 8-bit buses, and wide devices
just happen to straddle the two at once. Terminate the end of each bus,
avoid stubs, avoid automatic termination, use good-quality cables, ensure
a good power supply, and things always seem to just work out.
Things only get really murky when connecting two SCSI controllers to the
same bus (perfectly legal to do, but tends to involve some interesting
Around that sort of era Conner seemed to be total junk, regardless of the
drive technology. They truly were awful, with firmware that was generally
riddled with bugs and a healthy dislike for sharing a bus with anything
from a different vendor...
Indeed. Technically speaking the controllers are actually present on
each SCSI device - the thing that interfaces to the computer is a host
adaptor rather than a controller in the normal sense.
That particular drive (once fixed) seemed to play ball quite nicely with
quite a full SCSI bus including CD ROMS, a tape streamer, Jaz drive,
scanner, and some other hard drives. Had an Amiga at one end and a PC at
the other as well.
I think some of it must just be a hang-over from the early days when SASI
was morphing into SCSI; there was an awful lot of pre-CCS stuff around
which didn't support various commands that were later standard, and
all sorts of devices that didn't cooperate well on the bus with each other
because they misinterpreted the spec.
To be fair, it did seem to get better - so I suspect there were
things going on in the early IDE days as I speculate about above with
SCSI. But I still always found that SCSI storage out-performed IDE, plus
it was useful being able to house the devices separate from the main
machine (I so wish that SCSI supported hot-plugging as a fundamental
part of the original spec!)
As others mentioned,
a) The drive mechanisms aren't always the same,
b) Vendors can do well by over-inflating prices for SCSI and selling to
corporates whilst peddling lesser IDE solutions to the 'home' market.
In a way it's a pity IDE ever happened, but it was a logical progression
from the ST506/412 drives which used to dominate the cheap end of the
Absolutely, even on more recent boards it is always good practice to put
slow drives (CD/DVD etc) on the second IDE socket to help with performance
and especially against drop-outs if copying/writing from a HDD to CD-/RW.
To the OP = have you ensured the jumpers are correctly set? I once had a
hard drive (Seagate I think) and the diagram on the drive seemed to suggest
that the slave was the second jumper from the left, but was in fact the
second from the right i.e. the diagram didn't explain your viewpoint! All
that is superfluous if you set both as master and use the IDE1 & 2 sockets.
you are right harry, by the sound of this mobo.it's too old to recognise
these devices as atapi and they should be connected as you say, hdd as
and cd rom as secondary master.
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.