Gregory's Serverthe 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*.
|
101 comments
 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. so from the ST-225 to the ST-251, this function got swallowed up in the drive interface chip. but at least now i know how it works. 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. let's see what happens when i throw the switch. it's putting 10V bursts on the reset pin, so i hope nothing gets damaged. 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)  i'm not giving up. maybe it needs more clocks before bringing reset high. the datasheet says "at least 8" oh that's interesting, the port C output is pulsing sometimes (and the data line doesn't get contention). 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... OH! it has a clock divider on the input. so it's actually 5 CPU cycles. i think this exploit actually is running, but not consistently. looks like the key finding is that i needed 2 more sets of clock cycles before bringing RESET up to 10V. finished the disassembly process, more or less. you can read the commented source code here: https://github.com/schlae/HardDriveInfo/blob/main/st225/firmware/80007-001_commented.txt 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. 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.  @tubetime you got impressive knowledge from analysing these drives. It's unheard of. This will be so useful for anyone wanting to fix these drives, thank you so much for the full #retrocomputing community. time to reverse engineer the platters themselves. what secrets can we find? 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. 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. now it gets a little strange. there seems to be a secret set of 17 hidden sectors on track -1. @tubetime Dynamic CHS parameters for a programmable hard disk controller like the WDXT-GEN? @tubetime I have a stalled project to RE the WDXT-GEN BIOS, because I got tired of it's shitty/uninformative error messages. If you don't use one of the 4 hardcoded drive types, the BIOS will write your drive type (CHS, Write Precomp, Reduced WC, etc) to somewhere on the drive that's _not_ the data area. It's not actually clear to me where the data is actually written, but IIRC, the "magic" value to provide to the controller is "write to track 0 with an out-of-bounds sector". 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.  @tubetime I have loved this thread. While I've got into bit-level understanding of floppies before, hard disks have always been mysterious black boxes to me, and while at a logical level I understood they'd be something like this, this actual reversing has been a great way to remind myself they're not magic! Thanks. @sgf thanks! yes, it's easier to understand the older drives, but there's a steady, linear progression from then to modern drives. trying to digitize the entire drive using the Saleae. one drawback is exporting as a CSV takes f o r e v e r  @tubetime CSV is a horrible interchange format (other than being supported by literally everything). Bulky, slow to parse, slow to generate, difficult to do random access in, etc. But it's not going anywhere. @tubetime is that an Android Arduino? No way this runs android (?) @nichtjonas it is a Mega 2560 that was custom made by Android back in 2011. it has a USB host interface that can connect to phones of that era. they were giving them away...  @tubetime Have you figured out yet how it syncs up the divider chain? @developing_agent yes it pulses a GPIO pin and that clears the divider flip flop. @tubetime I mean more like knowing when to do that (which 2F region should be the index pulse), or is that arbitrary and doesn't matter? @developing_agent the 2F region is once per revolution, so i think it doesn't matter as long as it is consistent. my guess is the edge between the 2F and 1.75MHz regions. @tubetime If there's only one 2F region, what do you get multiple pulses of per revolution? (and need a divider chain for?) @developing_agent you get multiple pulses per revolution off the spindle motor's hall effect sensor. you need a way to divide this down (usually with a chain of T flip flops) to get a pulse that occurs once per revolution. the disk controller uses this to place the sectors in their correct locations. it needs to be in the same spot every time otherwise the controller will get confused. @tubetime Ah, so the divider chain is driven from the spindle hall effect sensor, and the single 2F region sets which hall pulse is the zero index. |
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.