Notices by Tube🌞Time (tubetime@mastodon.social), page 5

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).

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 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.

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.

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.

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.

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.

https://e4aws.silverdr.com/hacks/6500_1/

i think i'll try to dump the microcontroller on the ST-225.

i'm not giving up. maybe it needs more clocks before bringing reset high. the datasheet says "at least 8"

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)

holy crap it is working, it's dumping real 6502 code

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.

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 that's interesting, the port C output is pulsing sometimes (and the data line doesn't get contention).

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

starting the disassembly process.

looks like the key finding is that i needed 2 more sets of clock cycles before bringing RESET up to 10V.

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.

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.

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!