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.
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.
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.
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.
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.
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?
At least with ESDI the firmware was on the controller. I wonder if this would scale well to modern drives.
We kind of know it wouldn’t 🙂 There’s a reason why ESDI went out of fashion very quickly when SCSI and IDE became viable.
Some kind of documentation exists, if you can read Russian. AceLab (well known and oldest developers data recovery tools) used to have some tools for Conner drives
BTW, 7200-8-1 was default settings for long time (AFAIR Seagate 7200.7 still used 7200-8-1 settings)
Well, it’s not the default setting on four of the five old Conner drives I tried (9600,8,N,1 is). I don’t have enough drives to draw any real conclusions but in my sample, 9600 bps is the common speed for Conner drives.
Thanks! I’d seen this document before but forgot about it, and it didn’t come up in searches because there’s very little in English. This is helpful because it’s specific to Conner drives, even though it does not cover the oldest generations.
Almost makes me want to try and “repurpose” a failed HDD by trying to get it to run BASIC off ROM. :V
Sadly most Conner drives have the PROM soldered, not socketed. With a socketed PROM it would be quite doable. Conners with socketed PROMs do exist, but I’m not sure if it’s certain models or just some batches or what.
Better take a newer drive, with Flash and more performant (ARM9 or V850) CPU to run Linux 🙂
How about DooM?
Could be tough with the 8-bit 68HC11 🙂 On a newer hard disk I have no doubt the CPU is powerful enough (probably way more than a 486). Attaching a screen could be tricky though.
Attaching screen to PATA drive seems to be an easy task (it is just a 16-bit parallel bus). SATA is a different story.
Linux running on HDD firmware has been done: http://spritesmods.com/?art=hddhack&page=1
As for running Doom, recently it was ported to an Ikea smart lightbulb (where a screen had to be soldered on; unfortunately, the author had to take down his post, supposedly because he works for the company that manufactures the CPUs used in those lightbulbs).
DSSI (like SCSI but proprietary to DEC) seems to take this sort of stuff a few steps further. It has the “Diagnostics and Utility Protocol” (DUP) that lets you access the serial interface on your raid controller from the host computer over the DSSI cable. Handy if you need to change the config or something and you cant plug a serial terminal in in to the raid controller (system is remote).
Neat thing is DSSI hard disks implement DUP too. You can connect to the firmware running on the hard disk and run programs to adjust its configuration, perform tests, see statistics, etc. I think this is probably about as user-friendly as HDD firmware gets: http://www.mcmanis.com/chuck/computers/vaxen/dssi-plug.html
The primary reason for Conner/Seagate terminal is a production testing and certification. Although many HDD manufacturers used some kind of serial diagnostic port (Toshiba, Hitachi, Samsung are examples), usually it’s functionality very limited. Samsung, AFAIR, only implements basic MCU debugger (run, stop, single step, download, dump, modify memory, etc). Most of factory testing implemented as firmware binary blob, via ATA/SCSI interface.
Conner/Seagate is unique to implement full factory testing functionality as serial console (Seagate U5 is an interesting exception, as it have serial interface duplicated over ATA).
Newest date code on Conner CP-342 chips is from week 47 of 1987, November. Other ones are fairly close on the biggest/most expensive chips, week 37, 38, 41, 44, 46, those would be the ones with shortest time on the shelf. It sure looks like very early 1988 drive. Any plans on decompiling the firmware? 🙂
You’d think it’s from 1987/88, BUT: 1) the sticker on the firmware clearly says ‘(C) CP 1989’, and b) the date code (at least I think that’s what it is) on the chassis is 8949. The serial number on the chassis matches the S/N in the firmware.
Oh! Now that I’m looking at the drive again, it’s even weirder: I’m quite certain the firmware PROM was re-soldered. That’d at least explain why chips from 1987 go with 1989 firmware.
I have no explanation for this. The PCB sure looks like it’s from late 1987, but then someone put newer firmware on it and slapped it onto a chassis two years later. Warranty repairs? Something else?
As for decompiling the firmware, I’d first have to get it out. *I* have no desire to desolder the PROM, I don’t know how to read it out without desoldering, but it should be possible to suck it out using the serial diagnostic interface.
Another thing you can try is fiddling with the drivers, since some years Linux have a driver that works with SATA and ATA, “libata”, which is the default now, in the past it used drivers for different chips, for example “pata_via” for VIA chipsets, this drivers are marked deprecated but still in the kernel, you could try “ide” (generic PATA) module or a module for the chip of your PCI controller. Probably the old driver/module send the recalibrate command or could fix the problem.
Since CTRL+S results in a line with BRK and what looks like a prompt, that is probably some simple monitor. Try for example M and see what happens, either M alone or M with some parameters like one or two four digit hex addresses (separated by space or comma). It might be possible to dump the content of the drive firmware this way.
7200 is probably due to the CPU running at a frequency that matches SCSI bus timing.
As IDE/ATA is clocked by the host and the host can run the IDE bus at any speed within the wide spec of allowable timing there is no reason to run the CPU in the drive at a particular speed to match the IDE/ATA interface.