WD1772 16MHz Myth
This page is preliminary. Testing is ongoing and this page will be updated as more batches are worked through over the coming days.
Read this before anything else on this page. This has been tested more thoroughly than anything published on the subject before it, with a control chip re-verified between every swap and every 16MHz failure re-checked at 8MHz. But it is still a bench test of a few dozen chips over a few days, not hundreds of chips over hundreds of hours, which simply is not realistic for one person to do. Treat this as the best indication available, not as gospel. Some questions below are genuinely still open, and are marked as such rather than glossed over.
WD1772 at 16MHz: the 00-02 and 02-02 myth, tested
For as long as anyone can remember, the accepted wisdom around the Atari scene has been that only the WD1772 "02-02" revision will run at 16MHz for 1.44MB high density support, and that the earlier "00-02" revision simply won't. This page traces where that claim actually came from, what Western Digital's own datasheets say, and the results of a proper bench test of real chips, run to try and settle it.
Test setup
Hardware: an H5 Phoenix motherboard fitted with a built-on 1.44MB floppy addon, using an external 16MHz oscillator rather than a Shifter-derived clock (see the clock quality note further down). Software: a custom written 68000 test program that formats the disk, verifies the format, then loops continuously – writing pseudo-random data to every sector on every track and side, reading it back, and comparing – until stopped. It shows elapsed time live and records the time of the first error. Testing was carried out in near-UK-summer conditions, ambient roughly 27°C on generally overcast days – not deliberately hot, but on the warm side for a UK workshop.
Where the "only the 02-02 does 16MHz" claim came from
The earliest identifiable source is a text called "Introduction and Notes for adding High density disk drives to the Atari ST", written by someone using the callsign GW6HVA and circulated on UK packet radio via the BBS GB7OSP. It states plainly that the WD1772 "carries a suffix (usually) of 00-02 or 02-02", that the chip is "designed to run at 10MHz" and that "only the 02-02 chip will handle the higher clock speed of 16MHz" – with no mention of heat, duty cycle, or any chip-to-chip variation, and critically, no stated sample size. Nowhere in this text, or in anything that repeats its claim since, does anyone say how many chips were actually tried. For all that is known, it could have been exactly one 00-02 that didn't work and one 02-02 that did, on a single evening thirty-odd years ago, which then simply became accepted fact through repetition. That gap is worth naming plainly, since it is precisely the kind of omission this page is trying not to repeat. It circulated bundled with a formatter utility dated September 1989, so the claim itself predates the web entirely. The oldest surviving online copy is a 1998 Usenet repost, now archived at the Cleveland Free-Net Atari SIG.
The softened version sometimes quoted, that "ST Format said only about 5% of 02-02 don't work", has no located source at all – it is a 2012 forum recollection of an uncited magazine article. No issue number, date or scan has ever been produced for it. Wikipedia's claim that the "WD1772PH02-02" officially supports 500kbit/s HD carries a citation-needed tag on the article itself. And the account given by Best Electronics, a long-standing Atari parts dealer, says the opposite of a purpose-built chip: that Western Digital never designed the 1772 for 16MHz at all, and that Atari simply hand-selected and tested chips that happened to survive the overclock for the TT.
What Western Digital's own datasheets actually say
Both the WD177X-00 and the WD1772-02 datasheets, from the 1986 WD Storage Management Products Handbook, carry an identical Miscellaneous Timing table for the clock input: a duty cycle of 50 to 67 nanoseconds each phase. A 50ns minimum half-period works out at 10MHz, which is very likely where the "designed for 10MHz" line in the original packet radio text actually comes from – traceable to WD's own numbers, not invented, even though both datasheets separately specify the clock as 8MHz ±0.1%. What matters most: those timing figures are the same on both revisions, and 16MHz needs a 31.25ns half-period, nowhere near either chip's 50ns minimum. Neither revision of the WD1772 was ever specified anywhere near 16MHz. That is the strongest documentary evidence against the myth, and it applies equally to both.
Chip markings: closed, none of it predicts anything
A fair amount of effort went into whether the markings on a chip's package could predict the outcome. Every angle tried has come back negative.
- A second line sometimes seen on the package, such as C026028, is Atari's own part number, applied to chips that went through Atari's own production – not a sign of special testing or vetting. In 1986 the FDC ran at 8MHz exactly as specified, so there was nothing to screen for at the time.
- Date code does not predict the outcome. Two chips sharing the exact same production week gave opposite results at 16MHz.
- Country of assembly does not predict it either, and in this sample is confounded with revision anyway.
- Lot code, the most specific marking available, does not predict it either. A working chip and a failing chip, same date code, were checked right down to the lot code stamped on the underside of the package. Identical, top and bottom. Same lot, opposite result.
- One date code (8618) briefly looked like a genuine exception – the first 3 units tried all failed, and all 3 shared an identical lot code, which on a small sample looked like real evidence of a single bad production lot. A much larger follow-up batch of the same lot overturned that. See the results below.
So every single thing that can be read off the outside of the package has now been checked, and none of it tells you anything reliable.
Results
| Marking | Date code | Units tested | Result at 16MHz |
|---|---|---|---|
| 02-02 | 9427/9431* | 2 | 2 pass |
| 02-02 | 9522 | 1 | 1 pass |
| 00-02 | 8614 | 1 | 1 pass |
| 00-02 | 8618 | 13 | 9 pass, 4 fail |
| 00-02 | 8622 | 17 | 11 pass, 6 fail |
| 00-02 | 8627 | 12 | 12 pass |
*the underside lot code on these two reads 9431, not 9427 – top and bottom carry different codes on this pair, not yet resolved which the top actually reads.
"Pass" runs are 10 to 15 minutes of continuous 16MHz operation with no errors, grouped together as "10 minutes" for simplicity. Every failure was re-run at 8MHz afterwards and loaded and ran perfectly, confirming these are working parts that simply won't take the overclock rather than dead chips. One of the 8618 passes had a single data mismatch error about 5 minutes in, otherwise clean; heating that specific chip afterwards produced no further failures, so this looks more like a worn floppy or a one-off glitch than a genuine chip issue, and it has not been counted as a fail. 8622's failures include one that ran for about 2 minutes before failing, rather than failing immediately on boot like the rest – noted as a slightly different symptom, though still counted as a fail.
Separately, one 00-02 (8622) that passed a short run went on to accumulate roughly four hours of near-continuous 16MHz operation across several restarts. Deliberately heating that chip with a soldering iron reliably induced failure, and it recovered fully once cooled. In a further test, a chip that had already failed at 16MHz was treated with freezer spray and started working, then ran for about three minutes before failing again. Both point the same way: this looks like a thermal or voltage margin effect, not a fixed pass or fail property of the chip.
Why chips fail is not actually understood yet
It's important not to overstate the conclusion here. A chip failing at 16MHz on this rig is not the same claim as that chip being incapable of 16MHz as a matter of fact. The heat and freezer spray results both point at some kind of margin, possibly something as simple as a borderline clock voltage or signal level that some individual chips tolerate less well than others, but that is a hypothesis for future investigation, not a proven mechanism. The chips that failed here will also be re-verified on a different machine, to rule out something specific to this particular test setup rather than the chips themselves.
What this means for real kits
One important scope note before anything else in this section: a chip passing here says it survived 16MHz on this specific rig, with a clean external oscillator and a healthy power supply. It should not be read as a guarantee that the same chip will behave identically in someone else's hardware. The variation between individual machines, clock sources, and power rails across nearly forty years of ageing Atari hardware is far too wide to assume otherwise – a noisy or borderline clock, or a power rail that's drifted out of spec, can easily tip a marginal chip over on one machine while it runs fine on another. What follows is specifically about the kit design used for this testing.
Kits that switch the FDC clock to 16MHz only while a drive is actually being accessed, reverting to 8MHz the rest of the time, put a chip under a far lighter load than any of the testing on this page. Every chip that passes even a short continuous run here is comfortably proven adequate for that kind of use. This specific kit design has been in production for close to 30 years and has proven reliable across that time, which is separate, longer-running evidence for the design itself, on top of the bench results above.
A lot of older, period floppy upgrade kits worked differently: some switched to 16MHz on disc or drive change and simply stayed there for as long as a disk was present, rather than reverting between individual accesses. That is a much heavier, closer-to-continuous load, and would plausibly fail more often than an access-only design. Because this distinction was never documented or tested at the time, an old report of a kit working or failing can't be sorted after the fact into which switching design was actually behind it – such reports may well still be perfectly valid, they just aren't directly comparable to each other, or to the results on this page, without knowing which kind of kit produced them.
The working standard used to call a chip "good" for the results above is a clean 10 minutes of continuous 16MHz with no errors. That is considered adequate confidence for a chip destined for an access-only kit design specifically. It is not proposed as a general safety threshold, and it says nothing about sustained or continuous operation.
It's worth being honest about what that 10 minutes does and doesn't prove. The chips that ran for hours did so because they were deliberately chosen for an extended run after already passing a short one, not because every chip that passes 10 minutes has been shown to do the same. Assuming the rest of the "pass" chips in the table above would also run for hours is a reasonable extrapolation, not a tested fact. Actually running every chip for hours individually would take months of continuous testing, which isn't realistic for one person to do alongside everything else. Where that gap matters is exactly the access-only kit use case: for that, 10 minutes of continuous 16MHz is already a far harder test than the kit itself will ever apply, so it remains good enough confidence for that purpose even without an hours-long run on every chip.
Still open
- Whether the 02-02 is genuinely more reliable than the 00-02 at 16MHz has not been shown either way. It is the assumption almost everyone makes, on the strength of the original myth, but that is exactly the myth this page exists to test. Meaningfully more 02-02 testing is needed before any claim about relative reliability could be made.
- Why some individual chips of an identical lot pass and others fail is not understood – see above.
- Sustained, continuous 16MHz operation over many hours or days has not been tested by anyone, including this project. Roughly four hours is the longest clean run achieved so far.
To do
There are several hundred new old stock WD1772 chips behind this project, both 00-02 and 02-02, and testing every single one, even for just 10 minutes each, isn't realistic. The list below is what's practical to chip away at over time, not an exhaustive plan.
- Re-verify the failing chips on a different machine, to rule out the test rig itself.
- Investigate why some chips fail and others of the same lot don't – borderline clock voltage is the leading guess, unconfirmed.
- More units needed to bring every batch up to a reasonable sample size (roughly 10 each): 00-02 8614, 02-02 9427/9431, and 02-02 9522 are all still short of that. 00-02 8618 (13 units), 00-02 8622 (17 units) and 00-02 8627 (12 units, all pass so far) are now well sampled.
- 02-02 testing generally, at the same scale as the 00-02 testing above.
- Sustained/continuous operation testing beyond a few hours.
Have more information? Or want a chip verified?
If you have a genuine Western Digital document that specifies 16MHz for either revision, a WD1772 you've tested that adds to the picture above, or anything else that would make this page more accurate, please get in touch via the exxos forum. This page will be updated as better information comes in.
Happy to run a chip through the same test rig if you want one verified and send it in, on one condition: it needs to have come out of, or have a solid paper trail back to, original equipment. Chips bought in from China are not usable for this, since so many of them turn out to be re-stamped, and at that point there's no way to know what the original part underneath actually was. A chip pulled from a real ST, or genuine new old stock with a traceable source, is what's needed for a result here to mean anything.
Sources and credit
Datasheet research, myth sourcing and bench testing by exxos (Chris Swinson), 2026. Primary datasheet source: the 1986 Western Digital Storage Management Products Handbook. Best Electronics' account of the Ajax history is on their custom chips page. See also the WD1772 Floppy Disk Controller reference page for the full register and command-level datasheet corrections this project also produced.