A4000T not working

  • Thread starter Thread starter JHanna
  • Start date Start date
  • Replies Replies 119
  • Views Views 4139
No. The hard drive is 68 pin. The cable is 50 pin. Therefore the upper 8 bits aren't being terminated.
If you use an 8-pin cable, then only 8 pins carry data and the drive's other data lines,not carrying data, can't "ring" or be interfered with.

SCSI has forward and reverse compatibility: an 8-pin controller works on, or talks to, an 80 or 68 pin drive, and a 68-pin controller can talk to an 8-pin drive.

In this case, a 6 Oz sparrow can carry a 1 pound coconut.
 
Last edited:
Apparently these IBM drives won't even initialise unless the unused bits are terminated. Bit of a nightmare.
 
It is not possible to terminate lines that are not present, although you could use a 68-pin terminator on a 68-pin cable, such as a pass-through terminator:



SAM_6157.JPG


As an alternative, your 50-pin to 68-pin adapter could connect to a 68-pin cable that has at least 2 connectors, one for a drive and the second for end termination.
The 10K Atlas Maxtor SCSI drives, I used in the past, had no need for this arrangement; on my CSPPC SCSI-3 they gave up to 40 MB/s throughput.
 
Last edited:
The device I'm talking about is just like a regular 68-pin to 50-pin adapter except it has a bit of circuitry to terminate the unused lines on the 68-pin SCSI interface on the hard drive, and still leaves the other lines on the SCSI bus.
 
Apparently these IBM drives won't even initialise unless the unused bits are terminated. Bit of a nightmare.
The device I'm talking about is just like a regular 68-pin to 50-pin adapter except it has a bit of circuitry to terminate the unused lines on the 68-pin SCSI interface on the hard drive, and still leaves the other lines on the SCSI bus.

I have several 68- pin to 50-pin adapters (the data lines used are bidirectional) and they all work. The only lines that matter are the ones carrying data. I do not see unused lines as needing termination, they do not carry data and can't have excessive noise that is reduced with a resistor (passively or actively) to prevent data errors.
 
I'm just telling you what other people with experience of these particular drives have said.

If it's not a termination issue then I'm out of ideas. Can you think of anything else it could be?
 
Swear I'm nearing the end of my tether with this machine. Here's where I'm at:

SCSI just doesn't work - Hard drive not recognised. CDRW crashes a few seconds into copying data, hangs the bus, crashes the machine.

IDE is sloooooow - I had an A4000/040 at 25MHz 20 years ago and it was MUCH faster than this machine with an 060 at 100MHz. What's going on?!

Whole thing seems VERY unstable - I know Amigas are quite flaky, but 3.9 seemed much more stable and sorted than this 3.2.

I had hoped that in the 20 years since I was last a power user, things would have advanced a lot. It honestly doesn't seem that way, unless I'm missing something here.

At least 3.9 came with everything needed on one disc. 3.2 is barren. Had to buy P96 and AmiTCP. I believe P96 was actually on the 3.9 CD along with Miami DX or equivalent, and a token browser.

Dunno what to do now. Honestly thinking of selling the whole thing.

Anybody got an old yet big capacity SCSI disk they'd part with?
 
Anybody got an old yet big capacity SCSI disk they'd part with?

I've got one you could try as I'm not using SCSI HDs any more
 
Thank you!!

Not the best of news.

I've got 2 68pin drives, 4GB and 17GB.

Although the 4GB works it is a little noisy and I can't get my system to see the 17GB.

If you want them for testing purposes you're welcome to them otherwise they'll be going in the bin lol
 
As I was saying, the CDRW is working fine now. HDToolbox is set to scan on 2nd.scsi.device. All Dip switches are set to OFF, A4000T is unit 7, HD is unit 0, DAT drive is unit 1, CDRW is unit 2, going into the terminator built in to the A4000T.

I wonder if the fact that the upper 8 bits aren't being terminated is an issue?

I've had an A4000T for years, but never used the IDE. So I mixed up the scsi.device naming. (I specifically remember adding ncrsci.device to my old 3.9 ROM but I guess that's just the kickstart module file name.)

So indeed both the IDE and SCSI are named scsi.device, and hdtoolbox adds the 1st, 2nd, and so on automatically.
And if you put '2nd.scsi.device' in the hdtoolbox icon tooltype, it will not even find the second scsi.device (It won't search all the different scsi.devices, it will only look for one actually named 2nd.scsi.device. (I just tried on my 4000T with 3.2.2.1)

So you should put just 'scsi.device' in the icon tooltype.

(And double check the various jumpers on your drive as mentioned in the other thread.)
 
On the A4000T both the IDE and SCSI use the same scsi.device. All the dip switches should be left in the default. screwing with them is never needed

I agree about the dips, just wanted to check his were in the default positions.
(And I forgot about them being named the same, see previous post)

... In the A4000T, the end termination, being on the I/O Board, forms a big loop. With it free, the cable can be left out of the way at the lower end of the case. I have attached pictures of my A4000T opened up to illustrate...

Ok. I've just used drives with termination on the end, never had that issue :)
 
I agree about the dips, just wanted to check his were in the default positions.
(And I forgot about them being named the same, see previous post)



Ok. I've just used drives with termination on the end, never had that issue :)
The original cable that came with the A4000T was in the range of 6 feet long (~2 meters) and connected from the SCSI card through one's drives and ended in the termination board on the I/O board. Electronically, the two are separate, and the terminator is easily Dremeled away to be placed on the end of either a shorter cable, or out of the way at the end of the long cable allowing easier access to the drive cages, CPU board and such.
 
I've had an A4000T for years, but never used the IDE. So I mixed up the scsi.device naming. (I specifically remember adding ncrsci.device to my old 3.9 ROM but I guess that's just the kickstart module file name.)

So indeed both the IDE and SCSI are named scsi.device, and hdtoolbox adds the 1st, 2nd, and so on automatically.
And if you put '2nd.scsi.device' in the hdtoolbox icon tooltype, it will not even find the second scsi.device (It won't search all the different scsi.devices, it will only look for one actually named 2nd.scsi.device. (I just tried on my 4000T with 3.2.2.1)

So you should put just 'scsi.device' in the icon tooltype.

(And double check the various jumpers on your drive as mentioned in the other thread.)

When I was trying it, scsi.device found my IDE hard disk (as unit 0) and also my CDRW on SCSI as unit 2. Changing tooltype to 2nd.scsi.device then showed just the CDRW by itself.

Such an annoying naming scheme. Can't believe they haven't found a better solution after 20 years since 3.9.
 
Ok, if the hdd is not shown with just ‘scsi.device’ in tooltypes either, that’s not the issue then.

Did you check the hdd jumper settings, as I mentioned in your zuluscsi thread?

(Force SE mode, Disable Parity, Disable Motor start signal)
 
Back
Top Bottom