Can This Conner Talk?

As part of research into the IDENTIFY DRIVE command, the OS/2 Museum acquired two old Conner IDE drives, a CP-342 and a CP-341i. These drives look extremely similar at first glance, and they’re both 40 MB IDE drives, but on second look their PCBs are significantly different.

I believe the CP-342 is an older design and very similar to Conner’s original Compaq-specific model, the CP-341. The CP-341i is clearly newer and more capable. While the CP-342 is built around the Adaptec AIC-010 and AIC-270 chips, the CP-341i uses Cirrus Logic chips (in this case CL-SH260 and SH110), just like many other early 1990s Conner drives.

When I successfully unlocked a Seagate drive through a serial terminal attached to it, a reader commented that the ability to more or less directly attach a serial terminal to a production drive is something that Seagate inherited from Conner. That obviously got me wondering: Is it possible that the first Conner drives from 1987 or 1988 would already have this capability?

The CP-342 and CP-341i both have an undocumented connector on the side of the drive opposite the IDE/power connectors, on both drives labeled as J4 on the PCB. If there are any serial pins on the drive, they’d have to be there.

A handy thing about these old drives is that Conner was not yet big enough to get custom chips made. So we can clearly see the Motorola MC68HC11A1 microcontroller. It’s not hard to find its pinout and establish that if it’s in serial communications mode, the PD0/RxD and PD1/TxD pins are number 20 and 21 on the PLCC variant, right on the corner. Are these microcontroller pins linked to the mysterious connector?

A quick session with a multimeter confirmed that yes, the 68HC11 RxD/TxD pins most certainly do lead to the J4 connector. Which also meant that almost certainly, the pins are not directly RS-232 compatible but need a TTL to RS-232 adapter. Which is what I already used with the Seagate drive earlier.

Unfortunately I could not (and can not) find any information about anyone using the serial functionality on such old Conner drives. Therefore I had no idea what serial settings to use. 8 data bits, 1 stop bit, no parity at 9,600 bps would be the obvious guess, but only a guess.

At this point I wasted a lot of time because of my own carelessness. I connected the drive to my PC using a TTL to RS-232 adapter, but all I could get out of it was garbage. It was different garbage depending on the serial settings I used on the host, and at the same time the garbage was fairly consistent every time I power-cycled the drive (I had at that point disconnected the HDA to avoid pointless spin up/down cycles).

After I tried every possible halfway sensible serial port setting and still got nothing but garbage, I thought I’d better check if the TTL to RS-232 converter still worked with the same Seagate drive it worked with before.

It didn’t. I got nothing at all out of it, even after double and triple checking the connections (I’d taken photos of the working wiring so I was confident I’d wired it the same way again). Okay, so that one time when the converter heated up a lot, it must have gotten damaged. Time to get a new one.

A few days later, I retried the procedure with a new converter. And lo and behold, using entirely standard 9600,8,N,1 settings, I got this out of the CP-341i:

This drive with firmware from 1988 really does communicate over the serial port! And it calls itself “Inca”, which is a Conner code name that I could not find mentioned anywhere, even though the names of newer drive series tend to be known. The label on the firmware chip says “I2.11” which almost certainly means “Inca firmware version 2.11”. The “No current P 2” messages were presumably caused by the disconnected HDA. So let’s plug it back again and retry…

Whoops! There goes another TTL to RS-232 converter. Apparently attaching the converter’s GND pin to what I thought was the ground pin on the Conner drive’s J4 connector was a very bad idea.

Order more converters, attach the converter’s VCC/GND to only the USB IDE adapter rather than the drive, power up the drive… and this time, the converter survived:

The numbers after Ref/Xsition/Full spd are not always the same and presumably reflect some kind of a timestamp. The ‘Cyl 010’ should quickly go through a number of different cylinders as the drive verifies that it’s capable of seeking. This particular drive clearly is not. I was not able to access the drive from a host machine, so the fact that it’s not capable of seeking was not much of a surprise, there was clearly something very wrong with it.

For whatever reason, these old Conner drives have very quiet seek and the spin noise is on the louder side. So it’s very hard to tell what the drive is doing by listening, which is actually rather unusual. It could be a mechanical problem with the actuator arm being stuck or otherwise unable to move, or it could be an issue with the heads or the read channel electronics. At any rate, the drive never becomes ‘ready’ and the host cannot talk to it.

But the diagnostic interface functions just fine.

Connections

For reference, this is how to use the Conner mystery connector with a MAX3232 TTL to RS-232 converter.

Since the drive works with 5V logic levels, the VCC and GND pins on the MAX3232 need to be connected to provide it with 5V power. It might be possible to find GND and VCC on the Conner J4 connector, but I already destroyed two converters while trying to do that so I’m not going to try it anymore.

The picture above shows what I believe is the pinout of the diagnostic connector, but take it with a grain of salt; the Rx and Tx pins are the only ones I’m certain about. There are two pins with unknown purpose. The pins labeled Rx and Tx are connected to the 68HC11 MCU’s RxD and TxD pins, respectively.

The connector appears to be designed such that when the drive is installed inside a desktop chassis, it would be possible to remove the drive slot cover and plug in a custom connector for the diagnostic terminal while the drive is installed and operational.

I simply connected the MAX3232 converter’s GND and VCC to the USB adapter that I used to power the drive. The adapter has a 44-pin IDE connector for laptop drives which conveniently supplies 5V and ground.

The converter’s RX and TX pins were connected to RX and TX pins on the drive (that is, RX to RX, not swapped). Most Conner drives appear to communicate at 9600 baud with 8 data bits, one stop bit, and no parity. There is obviously no hardware flow control either.

Conner CP30174E

To probe the diagnostic interface further, I grabbed a 170 MB Conner CP30174E drive made in early 1993.

The drive has a slightly different connector (labeled J7) with two additional pins. However, the larger section of the connector closer to the side of the drive appears to be the same.

This is what the drive shows after powering up and going through the initial seek sequence:

The drive clearly calls itself Jaguar and 4HT2.35 must be the firmware version. There is a PROM chip on the PCB which has the same 4HT2.35 identifier printed on it. The firmware was presumably completed on May 8, 1992.

Now this firmware does lots of interesting things. For example, sending Ctrl+X produces output similar to this:

I believe these are the ATA task file registers. Sending Ctrl+S shows something like the following:

This is a ‘snapshot’ of the microcontroller’s registers, showing what the Motorola 68HC11 is up to. Not particularly useful without firmware source code or at least a firmware dump.

Here’s Ctrl+L:

This is kind of boring because the command just repeats the sign-on message. But Ctrl+F is more interesting:

This functionality is obviously only available in drives that have some sort of a cache, i.e. not the oldest models. And because the drive is not actually attached to a host, the data shown won’t change, but would allow tracing how the cache behaves.

Let’s see what Ctrl+E does:

This clearly shows the current ATA interface state: ‘Max’ is the maximum cylinder/head/sector (in hex) with current translation, and ‘mlt’ likely reflects the current SET MULTIPLE MODE state.

However, the above does not even begin to scratch the surface of what the Conner diagnostic interface can do. I stopped randomly pressing keys when I ascertained that a document called Seagate Diagnostic Commands is highly applicable to this Conner drive. The drive is old and therefore has much less functionality than circa 2005-2010 Seagate drives, but the diagnostic interface is unquestionably the same, just more restricted.

It is also pretty clear that a careless use of the diagnostic interface could cripple a drive; it is highly advisable to exercise caution.

Conner CP-341/CP-342

Naturally I had to check what the CP-342 drive does. Note that although the label on the drive very clearly says CP-342, the firmware says CP-341, both in its sign-on message and in the IDENTIFY DRIVE data. I take this to mean that there is very little difference between CP-341 and CP-342. The CP-342 drive works, even though it has some bad sectors, and this is what it shows after powering up (again using 9600,8,N,1 serial settings):

‘Cp 341’ is clearly the model and 0585 is the firmware version (sticker on the PROM chip says 5.85). There is no code name.

I could not do much with this drive’s diagnostic interface. All I can say is that it is significantly different from the CP-341i and later Conner drives. However, the diagnostic serial console did exist even in what was probably Conner’s first generation of drives, and the pin-out was the same as the early 1990s Conner drives.

Conner CP3040A

Do Conner’s SCSI drives support the same diagnostic interface? Unsurprisingly, they do… but! All I could get out of a Conner CP3040A (a 1990 drive with 40 MB capacity designed for Apple machines) was garbage. As it turns out, this drive runs the diagnostic interface at 7200,8,N,1 — or something close enough that those settings work. I don’t know why since Conner’s older IDE drives ran at 9600 baud. Maybe something to do with old Macs? Who knows.

At any rate, here’s what the drive shows at 7200 baud:

The sticker on the PROM chip says ‘SN2.31’, which very likely stands for ‘Stallion firmware version 2.31’.

Here’s what it shows upon pressing ‘Ctrl+X’, ‘.’ (dot), and ‘;’ (semicolon). The task file interface seems to be there, but it’s a dummy. The drive serial number is correctly shown.

I have not been able to do much with the diagnostic interface on this drive because it seems to be different enough from ATA drives to make things difficult. It is clearly the same sort of interface, but just different enough to be tricky.

Who Knows More?

Anyone? Anyone? Bueller? The Seagate diagnostic interface is fairly well known, but the Conner interface which is quite clearly its direct predecessor does not appear to be, and I could especially not find any evidence that it was publicly known to exist in the 1980s. Yet someone must have known about how the Conner diagnostic interface works and what to do with it, although this would have been potentially known only to a relatively small number of people. Has any of that information survived?