[VINTAGE] Reviving an IBM WDI-325 (PS/2 30 hard drive)

[rasz_pl]

I notice that the IBM WD-325N HDD has a 4KB MCU. It's amazing what could be done with a tiny amount of ROM and RAM in those days.

not that amazing when you realize all this MCU does is most likely just handling 'buffered stepping' by counting pulses

I missed posts, replied on vogons, gonna repeat here - do NOT try formatting IDE (even xt ide) disks with MFM formatting tools.
all the low level tools had warnings about this back in the day.
there were briefly tools promising low level format of some specific early ID drives, like ISPFMT (cant find it anymore, dont have it on hdd to quote its readme) and SGATFMT
https://www.uselesssoftware.com/download/sgatfmt3-zip
sgatfmt4 https://www.vogons.org/viewtopic.php?p=1192929#p1192929

In the case of AT (IDE) drives:
AT (IDE) drives can be divided into three separate scenarios: Early,
Swift and ZBR.

1. EARLY: When AT interface drives (aka IDE - integrated drive
electronics, but so are SCSI's) were first introduced (ST157A family),
we strongly warned and cautioned against any attempt to lo-level
format the drives because 1) the factory written defect-mapping files
might be erased on reserved areas of the drive, and 2) the optimized
interleave and skewing values used would be forfeited giving slow
transfer rates. At this stage of development, SGATFMT3 lists these
drives only as a fall back option, in lieu of a factory repair format.
If the drive has somehow lost its original format, or the partition
structure been corrupted by a virus etc., SGATFMT3 could be used to
reformat _without_ the benefit of the defect mapping files. Any
defects will need to be "rediscovered" again; first, by the DOS high
level format and second, by a third-party disk scanning utility.
These utilities are quite likely to locate all of the hard errors, but
unlikely to find the soft errors. The only way to completely evaluate
a drive for both hard and soft error is by a factory repair with
extremely sophisticated diagnostic equipment. (See the glossary
section for HARD and SOFT ERRORS.)

2. SWIFT: As the AT interface products became more sophisticated
with new technology and the introduction of the Swift drives (models
like ST1239A, ST1201A etc), lo-level formatting became pretty much
"half" of a problem. When these drives are in translation mode
(non-physical geometry definitions), a lo-level format is harmless to
the factory defect-mapping files and optimized skewing (albeit
destructive to user data) since it doesn't re-sector the drive. If,
however, the Swift drive is in true physical mode, then the lo-level
format will re-sector the drive.

3. ZBR: Finally, today's AT interface drives (like the ST-1144A and
ST-3144A) are often Zone Bit Recorded (ZBR). ZBR drives, have variable
sectors per track, depending on the zone of the drive. The outside
tracks, being larger in circumference (i.e. track length is longer),
are able to hold more sectors than the innermost tracks. In this
scenario, it is IMPOSSIBLE to define the drive in CMOS setup with true
physical values. Cylinders and heads, yes.... but not the sectors per
track. Therefore, these drive are ALWAYS in translation mode and
immune to a re-sectoring lo-level format. On ZBR AT interface drives
(Seagate, at least... others UNK), the factory defect mapping files
are fully protected, and since the drive is always in translation, the
optimized skewing is also protected.

[elizabethtaylor]

Michele, the platter swap is impressively methodical, but I'd suspect the LLF trouble lies with the servo/index track rather than the donor surfaces. Stepper drives like the WDI-325 still depend on a fixed index pulse and the original sector geometry written at the factory. Since you moved platters between a 325 and a 387, the track-to-head alignment and the recorded index reference won't necessarily match the new stack. Check whether the drive sees a stable INDEX signal and whether the controller expects a specific head/sector map. The controller's low-level format routine may also be gated on a valid defect table or geometry table burned into ROM.

[mima85]

I missed posts, replied on vogons, gonna repeat here - do NOT try formatting IDE (even xt ide) disks with MFM formatting tools.

Well, as the drive is already toast a try was worth anyway. But now I'm going an alternative route and I have something cooking in the pan. I don't know if that's gonna be successful and there's a high probability it won't, but we'll see. More updates on this later.

I saw yesterday your post on Vogons, today I'll post some photos of the ST125N's circuit board. As I use a dumb phone and I don't have a smopho (smartphone), I made the previous photos with an old Microsoft Phone I had around, that's why they were so crappy. Today I'll use something better.

Michele, the platter swap is impressively methodical, but I'd suspect the LLF trouble lies with the servo/index track rather than the donor surfaces. Stepper drives like the WDI-325 still depend on a fixed index pulse and the original sector geometry written at the factory. Since you moved platters between a 325 and a 387, the track-to-head alignment and the recorded index reference won't necessarily match the new stack

Well, of course that's the case, anything that's left on those platters is not actually usable by the WDI-325. And as the drive was already partially demagnetizing with age, a lof is for sure just garbled mess. That's why I want the drive to blindly treat these platters like blank one fitted during the production process.

[hannahmiller]

Michel, the transplanted platters raise the layout question you already flagged: servo and low-level format info differ between a 325 and 387 even if the coating looks identical, so the controller may not find valid track data and refuse to format. On stepper drives the LLF usually needs the right cylinder/head count and interleave set in the controller, plus a valid defect map. Does the PS/2 setup utility expose those parameters, or does it assume the original drive geometry? That would explain why it stops short. Keep the original platters labeled so you can backtrack.

[mima85]

Does the PS/2 setup utility expose those parameters, or does it assume the original drive geometry?

It doesn't expose any parameter, but I don't know if it just assumes that the drive is a 20 MB 615/4/17 CHS or if it asks the integrated drive's controller for that. I think that it asks the controller, because for the PS/2-30 there are the options for 20 (WDI-325) or 30 (WD-336) megabytes hard drive. But it could well just ask the drive for its model and then select the appropriate geometry between the two variants. There is no information on how the Advanced Diagnostic utility works internally.

That would explain why it stops short. Keep the original platters labeled so you can backtrack.

Of course the geometry is entirely inappropriate for the drive. But the original platters, as it can be seen in the photos, are in a totally rough and unusable state. The plastic powder chemically embedded itself to the platters' surface and it can't be removed. And rotating at high speed those rotten and contaminated platters under the heads would mean grinding them to death. I have no other option than transplanted platters here. By the way, in the meantime I demagnetized the "new" platters because I want the drive treating it like totally blank ones that still have to be initialized. Anything that was on those platters was useful anyway.

And in this regard, unless some other information about an hypotetical "factory mode", where the drive can initialize totally blank platters from scratch, would pop up, the only option I see here is to come up with a custom firmware that can be put in place of the original one to blindly low-level format the disk without any sanity check in place. In the last days, with the help of Google's AI (sorry folks, I don't know i8031 assembly so I had to rely on big brother's tools, even if I'm not actually fond of AI and the whole vibe coding thing) I, naively I admit, made the robots slopify me some assembly source code to put together a sort of "factory restore" firmware, of which I thoroughly outlined the specifications. I gave to the AI the hex dump of the original IBM's firmware to make it extract from the IBM's code all that's needed to handle all the hardware and the low-level format routine itself, which appears to be actually present into the original code, and to build over it the custom firmware. But of course, it doesn't yet work, not that I expected different results anyway. Today I spent all the afternoon at it but I got no results, mostly because of my lack of skills with 8031's assembly and in general low-level, close to the metal programming. That was the stuff "cooking in the pan" that I talked about in my last post but at this point I even couldn't had got the recipe itself right. I still have a lot of learn in this regard.

If you want I can share the code, my specifications and some other stuff that came out during the conversations with Terminator... ehmm I mean, Google's AI. Of course, for all of you that know 8031's assembly, don't expect good code here.

[rasz_pl]

Stepper drives like the WDI-325 still depend on a fixed index pulse and the original sector geometry written at the factory

afaik in soft sectored early stepper drives index was generated by optical/hall sensor or motor driver
here for example chip doing it for Seagate 125 https://github.com/schlae/HardDriveInfo ... 647-502.md
and on a diagram https://github.com/schlae/HardDriveInfo ... _20629.pdf

The controller's low-level format routine may also be gated on a valid defect table or geometry table burned into ROM.

afaik also too early for defect tables handled by disk

now index track is another matter and I agree disk fails to get ready because it most likely cant find its index track. Seagate uses special track -1 (or -2?) for this purpose, no idea how WD handled it.

In the last days, with the help of Google's AI (sorry folks, I don't know i8031 assembly so I had to rely on big brother's tools, even if I'm not actually fond of AI and the whole vibe coding thing) I, naively I admit, made the robots slopify me some assembly source code to put together a sort of "factory restore" firmware, of which I thoroughly outlined the specifications. I gave to the AI the hex dump of the original IBM's firmware to make it extract from the IBM's code all that's needed to handle all the hardware and the low-level format routine itself, which appears to be actually present into the original code, and to build over it the custom firmware.

Google's toasters arent the best for this. I havent seen anyones RE success stories using google crap. Claude toaster on the other hand sometimes pulls rabbits out of its ass one-shotting exotic firmwares. What Im trying to say is you are going to need a bigger boat.

If you want I can share the code, my specifications and some other stuff that came out during the conversations

I havent seen a firmware for an IDE drive so I dont know how it looks like internally and how much is handled by controller chip (chip directly connected to IDE port) and how much still goes thru micro. If its anything like old SCSI drives then micro is the brains of everything - selects heads, controls head assembly arm movement, sends commands to actual controller Asic, even controls rotation speed. Here micro is at least directly controlling head stepper.

For WD drive start with making robot produce annotated disassembly to the point it can name functions. Im you will need:

Trace which 8031 IO connect to two TEA3717 pins 7 8 9. Thats between 3 and 6 IO taken care of.
Trace which 8031 IO go to big IBM chip - this one incorporates

Capture all 8031 IOs, if you dont have 40 IO LA capable of storing couple seconds at >12mhz you will need to kludge = https://sigrok.org/wiki/Lcsoft_Mini_Board would be barely fast enough at 12MHz considering cycle times of 8031. Capture all 8031 IOs in groups of P0, P1, P2, P3. In 16 channel mode at least grabbing one of the ports + pin 9 reset (and trigger on that) / 16 wr / 17 rd / 29 psen + P0.0-P0-4 for syncing. Lets say 5 seconds from reset. AI will be able to cobble python script gluing all the captures into one correlated log.

give that to AI + as much pinout as you can gather. Dont mix two boards you have Pick just one and stick to it, AIs are stupid and easily confuse when given too much choice.

The questions that interest us most are
- How and when does it know its on track 0? waiting for some IO port or maybe reading something from controller? waiting for specific pattern decoded by ENDEC? this one is crucial and should be easy as its somewhere at the beginning of initialization. - - does it sync with Index pulses? Which IO it uses to do it? logic capture should show it as one of the pins will steadily pulse at ~50Hz.

Finally in separate session you can try https://github.com/yyzkevin/COMrade https://github.com/jdredd87/DOSBridge one of those to let Toaster control PS/2 with drive connected and ask it to determine whats the status of connected XT-IDE drive. Try it with Seagate first since its almost working. Ask it to low level format it too, knowing how AIs operate it will cobble together custom made programs to attempt this. It will find IO ports on its own, determine command structure etc.

[HaQue]

hannahmiller and elizabethtaylor and a few others are AI bots, so ignore their output

[mima85]

My fault, I didn't pay attention to their join date. Thank god they're banned now.

[mima85]

What Im trying to say is you are going to need a bigger boat.

Yep, I experienced that. Code from the Google's AI is utter slop, at least for the free version that's reachable directly from the search engine. By making Google re-analyze for each session the source it spitted out the first time, it kept finding errors, telling me how to correct them. Every time I corrected them as per detailed explanation of the AI, iterated the check/correct cycles until it told me the code was OK, closed the session, opened a new session the day after and it still found errors. And sometimes it told me to do corrections that actually in some sections brought the code back as it was initially. I know that the free Google's AI doesn't hold the context between the sessions, so I always told it to make me a context file of the discussion for the next session to come, in order to bring it back to where I left it. But that was useless anyway. Not that I expected something different to be honest, but I wanted to give it a try anyways.

For WD drive start with making robot produce annotated disassembly to the point it can name functions. Im you will need:

Trace which 8031 IO connect to two TEA3717 pins 7 8 9. Thats between 3 and 6 IO taken care of.
Trace which 8031 IO go to big IBM chip - this one incorporates

Capture all 8031 IOs, [...] give that to AI + as much pinout as you can gather. Dont mix two boards you have Pick just one and stick to it, AIs are stupid and easily confuse when given too much choice.

Wouldn't be the disassembled original source code be enough? Unfortunately I don't have any logic analyzer, just an analog oscilloscope and an old lab multimeter (the stuff I mainly need to occasionally fix my old analog synthesizers).

In the meantime I started to disassemble the original IBM code using Ghidra. As I said I don't know anything of Assembly, the thing that I understood today is that if I make Ghidra start the disassembly from the reset and interrupt vectors, by sequentially following the code and all the jumps it can get out most if not all of the actual code. And all the sections of bytes between any type of jump or return instruction and the next block of actual code are data and padding. Am I right with my understanding? Sorry for the silly question, as said I'm a total novice with this type of stuff.

Of course I'm working strictly with one board, I'm aware of the different layout between the two versions.

[HaQue]

for Ida and Ghidra it is usually essential, or at least preferable to make sure you have the configuration of the target processors setup properly. Otherwise the disassembly can look kind of reasonable, but will be way off, or a jumbled mess. Also depending on processor, memory map is also important. Ive never done any 8031, but maybe the simulator in SDCC might be of use? discussed: https://electronics.stackexchange.com/questions/139762/editing-hacking-8031-eprom-code

[rasz_pl]

What Im trying to say is you are going to need a bigger boat.

Yep, I experienced that. Code from the Google's AI is utter slop

Imo its all slop, its just that some engines make better slop than others

By making Google re-analyze for each session the source it spitted out the first time, it kept finding errors, telling me how to correct them. Every time I corrected them as per detailed explanation of the AI, iterated the check/correct cycles until it told me the code was OK, closed the session, opened a new session the day after and it still found errors. And sometimes it told me to do corrections that actually in some sections brought the code back as it was initially.

good old Google I find Gemini good enough for people skilled in particular subject because they can recognize sloppy slop on the spot and keep herding cats in general direction of the answer. If you dont know what you dont know Gemini will always sounds plausible even when it contradicts itself.

For WD drive start with making robot produce annotated disassembly to the point it can name functions. Im you will need:

Trace which 8031 IO connect to two TEA3717 pins 7 8 9. Thats between 3 and 6 IO taken care of.
Trace which 8031 IO go to big IBM chip - this one incorporates

Capture all 8031 IOs, [...] give that to AI + as much pinout as you can gather. Dont mix two boards you have Pick just one and stick to it, AIs are stupid and easily confuse when given too much choice.

Wouldn't be the disassembled original source code be enough?

LLMs arent superhuman, its more helpful to think of it as autistic phd student on ADHD drugs with way too much time. Human will find all this info super helpful for broader context, and LLM will use it to disregard most of its hallucinations.

Unfortunately I don't have any logic analyzer, just an analog oscilloscope and an old lab multimeter (the stuff I mainly need to occasionally fix my old analog synthesizers).

$5 pico, together with software from https://github.com/gusmanb/logicanalyzer you get 24 channel LA (with small buffer so have to do repeated captures). Buffer board might not be needed since pico is 5V tolerant.

In the meantime I started to disassemble the original IBM code using Ghidra. As I said I don't know anything of Assembly, the thing that I understood today is that if I make Ghidra start the disassembly from the reset and interrupt vectors, by sequentially following the code and all the jumps it can get out most if not all of the actual code. And all the sections of bytes between any type of jump or return instruction and the next block of actual code are data and padding. Am I right with my understanding? Sorry for the silly question, as said I'm a total novice with this type of stuff.

yes, but what you really want is annotated disassembly like this https://github.com/raszpl/Zenith_ZBIOS or https://github.com/raszpl/Sanyo_BIOS (no toasters were harmed making it)

The more details like pinout and LA captures you feed the beast the better. Absolute best would be this setup:
PS/2 + WD plugged in a way you can still tap into pcb
2 picos connected to all the important pins on the pcb
a relay allowing for remote reset or PS/2
bonus points for running https://github.com/yyzkevin/COMrade bridge so LLM can issue commands to disk from PS/2
super bonus points for https://onerom.org instead of actual ROM
Claude running on computer where those 2 picos and remote reset (relay on lpt, arduino over serial, third pico, whatever, LLM will take care of it) are plugged

Dave/EEVBlog recently demonstrated how even a complete hmm lets say amateur can do RE with those tools
EEVblog 1783 - Can AI Reverse Engineer the 121GW Multimeter Firmware? https://www.youtube.com/watch?v=BEKRoZj6otc
EEVblog 1784 - Claude Code Reverse Engineer 121GW Firmware SUCCESS! https://www.youtube.com/watch?v=2tUC0DuPjaM

Old schoolers will scream about committing crimes and calling Internet Police on me for this AI tutorial. How dare someone with no 8031 assembly knowledge attempt to do anything!!1 Reality of 2026 is the setup above has a _very_ high chance of one-shotting this firmware and assisting with modifying it to your needs with minimal interventions.

[mima85]

Old schoolers will scream about committing crimes and calling Internet Police on me for this AI tutorial. How dare someone with no 8031 assembly knowledge attempt to do anything!!1 Reality of 2026 is the setup above has a _very_ high chance of one-shotting this firmware and assisting with modifying it to your needs with minimal interventions.

Well, as I said me too I'm not too fond of AI and as a person that since 25 years can actually write code and develop software on his own, enjoying the process of creating something with his brain and hands, I hate the term "vibe coding". I can understand someone experienced with this stuff throwing s**t at me for what I was doing, that's why I kept a low profile . But I also want to learn in the meantime, so the next time I won't need the assistance of robots.

It's going to require me some time with the stuff you suggested me, in the meantime thank you.