track -2 contains the same 32 sectors on all heads. it seems to be 8051 code (02 is the LJMP instruction). i'm guessing this is the main drive operating code.
i've got another ST-225N to try and extract firmware from. the board was apparently dead, but eventually i might try it out with my other ST-225N logic board (i hope it still works)
it spins up and i've captured the negative tracks! (the Marker bit is a signal pulsed by the Arduino when it changes tracks or heads. it just cycles through all the heads in order, then goes to the next track)
i'm trying to correlate the drive's data output (valid on the rising edge, each pulse has a fixed width) with the analog data. it seems to have a delay of about 180ns caused by the analog filter and the propagation through the comparator.
going to dump the drive firmware for the ST-225N's 8051 microcontroller. this has never been dumped before. this firmware reads additional firmware off the platter, but i've already dumped that data.
i decided to try and get a better read of the firmware tracks (-1 and -2 on all the heads). this time i'm capturing analog data from the drive's test points.
anyway this analog signal comes off the drive's analog test points (circled). this signal comes after the differentiator (IC 9E1) and the first stage analog filter, but before the second stage filter.
so even though this disk image is probably irrecoverable, i want to learn as much as a can. this drive was from the Amiga Comspec, and i want to see if i can figure out how to replicate the disk layout. this segment here is from the Kickstart disk.
there are a few sectors with the drive firmware (negative cylinders) but then there appears to be real data. "DOS" might be part of some partition table scheme.
the design of the ST225N is essentially an ST225 but with the data separator and controller built in. they changed the microcontroller to an 8051, and stored a bunch of the firmware on some hidden tracks.
wrote a crappy python program to interpret MFM data, and it seems we have some sectors. they are using a different sector header format and there seems to be a lot of corrupted data.
the real reason for all this is that there's data on this ST225N (SCSI version of the drive) on the right. I want this data.
I already tried a board swap but the SCSI version stores its firmware on track -1 and -2 instead of an index signal. my hacked board should be able to handle it, though.
oops didn't mean to leave you hanging. turns out my track numbering is off by one. this is actually track 0 and it has regular MFM data on it. i wrote a quick-and-dirty routine to convert it and it just has regular WD1010-style headers for 17 sectors.
i made a table showing the layout on the platters themselves. only head 0 has the index marker tracks. there are 2 of them, one at track -1 and the other at track 617.
to allow your computer's HDD controller to park the heads, it lets you step past the user data area end track of 614 to go all the way in to track 670. theoretically, if you mistype the BIOS # of cyls, you could try to store data here and even overwrite the inner index track!
this will confuse the drive when it powers up. it'll eventually go find the index track on the outside edge, but only after an extended search sequence. you can't command the drive to step to track -1, so you can't overwrite that track.
here is a closeup. the raw MFM data shows a square wave of 5MHz for most of it, but there is a short section (4ms long) of 1.8MHz. the one-shot acts as a primitive data separator and the MCU can then detect this index marker and reset the hall effect divider flip flop.
with this setup I can control the stepper from the Arduino without the drive's microcontroller interfering. then I can use the Saleae to digitize the data.
confirmed that there are two index tracks, one at track -2 (relative to user data starting on track 0) and another on track 616 (user data ending on track 614). the D2 square wave is directly from the hall effect sensor, 2 cycles per revolution. the D1 pulses are this signal divided by 2. MCU read data is the index signal as seen by the MCU after being processed with a one-shot.
another fun one is the empty space for an EPROM and a latch chip. these weren't used to store drive firmware (as i thought before) but they store a giant lookup table of microstep values *for each individual track* so you could presumably trim individual drives to avoid bad areas on a platter.
of course it controls the head position regardless of the physical platter, so it wouldn't really be helpful unless the drive only had a single platter in it. i've never seen an actual chip soldered in here and it was completely removed in later board revisions, so i guess they never fully implemented it.
and i learned some interesting things along the way. the drives have this weird set of resistors and driver chips tied to the stepper motor phases. it's for microstepping while in recovery mode!
the idea is that you assert a control pin that puts the drive in recovery mode, and it will try to read a track 15 times while shifting the head side to side very slightly. this is apparently only implemented in the ST-01 disk controller.
essentially all of the drives i've inspected do not actually have these components soldered down, so it must have been an uncommonly used feature that was removed to save cost.
so the code that the exploit loads into RAM pulses the port C (all pins) with an LDA #$FF ; STA $82; KDA #$00; STA $82. the LDA is 2 cycles and the STA is 3 cycles. but the pin is high for 10 clock cycles...
no luck, sadly. it's supposed to be clocking in a program over PORTC, but there appears to be output contention (see how the voltage levels on ch4 don't always make it to a logic high)
someone's dumped the MOS version of this microcontroller using a clever circuit and a test mode. i don't know if it will work with the NCR version of the chip, however.
why is this useful? it turns out that these drives have a 1.75MHz signal recorded onto specific tracks, letting the MCU (which controls the stepper motor) know if it has gone outside of the data area.
so basically, you step around, and if you see this pin go high (and stay high) then you know you're out of bounds.
there is a special signal recorded at track -2. it is the same 1.75MHz but it has short bursts of twice the frequency (2F). this lets the MCU know that (1) it is at track -2, and (2) it lets it synchronize the hall effect sensors.
you get multiple pulses per revolution, so you need a way to sync up the divider chain so you get an index signal that is repeatable.
OK, this one is done! amazingly, it also helped me solve a mystery on the ST-251. on this later drive, the board has a custom chip that captures data from the current track and outputs a "processed" version of it to the MCU through the PA2 GPIO pin. how does it process it? i didn't know until today.
so the 20527 board in the ST-225 uses a discrete circuit for doing the same task. it has two 74123 one-shot pulse generators connected in series with each other and going out to the MCU (on PA7 because this board uses a variant).
the key observation is that the pin state depends on the frequency of the signal coming in. for DC, it is normally low. for frequencies *higher* than about 2.6MHz, it also stays low. but for a particular window of frequencies (1.4 to 2.6MHz) the pin goes *high*.
this is the control board for the ST-225 hard drive. it's an earlier revision. so far it's not too dissimilar from the ST-251 but the stepper motor driver circuit is quite different.
this one has minor electrical changes from the previous one, mainly adding control over the spindle motor *power level* from the microcontroller. that way they were able to lower the average power consumption.
this later revision of the st-251 uses a mask-ROM microcontroller. it's very similar to the R6518, at least in the pinout. it also latches its internal address bus on a bunch of the pins during the rising edge of phi2! this means i can spy on the program counter and any other memory addresses being accessed.
unfortunately we don't have a dump of the protected mask ROM, but it seems to be somewhat similar, and the 6502 puts *every* address it accesses on the bus, so you can see it accessing special function registers and the stack, allowing you to infer quite a bit about what is going on.
the "ring lsi" is interesting. it provides an adjustable linear regulator to set the stepper motor supply voltage (set through SPI bus) and it monitors the "ringing" on a winding after it has been driven and is settling.
i've moved on to the read/write LSI. the read channel is somewhat tricky because it uses four (!) one-shot timers to turn the raw analog signal coming from the read preamplifiers into an output pulse that represents a flux transition.
the ST-225 drive uses a similar circuit but it is an older design and less integrated. the ST-251's SSI257.2 chip drives the center taps of the head windings. they just "garbage collected" the transistors, head select decoder, and resistors driving it along with the transistors that set the write current.
by looking at the ST-412 schematic, i figured out that the ST-251's SSI257 chip contains a bunch of steering diodes as well as an op amp (an NE592 equivalent).
so one of these drives blew a tantalum capacitor. i think i will take this board apart for reverse engineering purposes. there are multiple revisions but this will be a good starting point.
with a combination of hot air and a desoldering gun, i've taken it down to just a few surface mount parts. i'm going to leave those in place for now since many of them are not marked. there is also no silkscreen.
they scanned well. i've taken the top and bottom images and lined them up precisely. these reference images are 600dpi but i may go for a lower res version for KiCad since it stores the images in the pcb file, which slows it down a lot.
hmm, looks like there are a few instructions that aren't 6502. apparently Rockwell defined a few new ones. it would be nice if Ghidra could handle those.
oh yeah. i've mapped it starting at address 0x3000 but the hardware maps the ROM chip in starting at 0x0100, where it just gets aliased all the way up to 0xFFFF. the absolute jump addresses located in the vectors at the top of the ROM refer to addresses starting at 0x3000, so i'm just using that.
another version of the board has the EPROM footprint populated, and the chip is marked R6518AJ, which is definitely a Rockwell microcontroller. the firmware has already been dumped.