How do you know your EPROM eraser actually works?

Part 1 of 2. This one is the borrowed cabinet and the method. Part 2 is my own eraser, and whether the predictions at the end of this post survive contact with it.

Also part of an occasional series on not trusting your tools—see When Two EPROM Programmers Disagree and its bit-flip companion.

I bought a used UV eraser off eBay. Nothing special—a small two-tube unit, cheap, cosmetically rough. When it turned up in conversation I mentioned I'd be testing it before it went on the bench, because I wasn't about to trust thirty-year-old lamps on somebody's cartridge ROMs.

That remark cost me a Saturday.

A local collector heard it and handed me his—a Spectroline PC-2000, cabinet-sized, considerably nicer than mine—and asked whether I'd test that one too while I was at it.

So instead of one machine with a receipt and a return window, I suddenly had two: one I'd bought and hadn't earned any confidence in, and one with no history at all. And standing there holding somebody else's equipment, it occurred to me that I had no real idea how you would check.

There is a rule of thumb. Everyone knows it. Stick the chip in for ten minutes, or twenty, and then blank-check it. If it reads blank, it's erased.

I've been doing that for years. This is the story of finding out what it's worth.

So I did what everybody does

No tray came with it, so the shelf is three stacked foam pads against the cabinet's own runners. That 14.8 mm is now baked into every number in this post.

The borrowed cabinet arrived with no tray, so I improvised a shelf out of three stacked anti-static foam pads—14.8 mm, which put the chip windows at roughly the height the original platform would have. More on that later; it turns out to matter.

Then I took a freshly programmed M27C512, set the dial to ten minutes, and walked away.

It came back blank. First read on the Needham's EMP-20, clean. I moved it to the GQ-4x4 to be sure, and that agreed.

Two independent programmers, both saying the chip was erased. The rule of thumb worked.

And I sat there feeling entirely unsatisfied, because the chip reading blank and the erase being any good are not the same claim, and I had no way to tell them apart.

Where did ten minutes come from, anyway?

Nobody knows. It's inherited—a number handed from forum post to forum post, detached from any particular machine. And once you ask the question properly, you can see why it can't possibly be right for everyone.

Erasure is a dose, not a time. The STMicroelectronics datasheet for the M27C512 asks for a minimum integrated dose of 15 W-sec/cm² at 254 nm. Dose is intensity multiplied by time. So "ten minutes" only means something if you also know how much ultraviolet your lamp is putting out—and a thirty-year-old lamp with darkened tube ends is not obliged to tell you.

That reframing is the whole thing. Not how long, but how much.

Which raised the question of how much this particular cabinet was actually delivering. And the only instrument I had for measuring that was a chip.

Making a chip that tells you something

The test articles. Programmed to all zeros, numbered with orange dots, and about to be spent.

Here's the trick, and it's the useful part of this post if you skip the rest.

An erased EPROM cell reads as a 1. Programming drives cells to 0, and it only ever goes that direction—you can add zeros to a chip all day, but the only way back to 1 is ultraviolet light.

So I programmed a chip to all zeros. Every cell in the array charged. 524,288 of them on a 64 KB M27C512, every single one in its programmed state. That is the hardest possible thing to erase, and it means a blank check doesn't just tell me pass or fail—the number of failing bytes tells me how far through the erase I am.

I burned twelve of them, numbered O1 through O12 with orange dots, and kept one aside that never went near the cabinet as a control. That one read 65,536 errors on a blank check. Every byte. Which is what you want a control to say.

The borrowed cabinet starts asking questions

Before any of that, though, there were the unknowns—and the machine set the agenda.

Does it stop when you open it? Interlock first, before anything goes inside. Shortwave UV burns eyes and skin and gives no warning while it's doing it. Start a cycle, open the drawer, watch the lamps die. This one does, immediately. Ten seconds to check, and it's the only test on this list you must not skip.

How long is a minute? I set the dial to fifteen and timed it against a phone stopwatch. It ran twelve minutes and eighteen seconds—about eighteen percent fast. That's not a fault exactly; the timer works, it dings, it cuts the lamps. It's just optimistic. Every load gets 82% of the dose you thought you set.

For the rest of the day I ignored the dial and used the stopwatch.

Where do the chips sit? With no tray, the chips sit wherever you put them, and rated intensity is quoted at the tray plane. Move them down and they get less. My foam stack was a guess at the original geometry, and I wrote it down and never touched it again, because it's now baked into every number below.

The foam is worth a short detour, because I nearly talked myself out of it. Common sense says keep plastics away from shortwave ultraviolet—it embrittles them, yellows them, and some outgas. So a foam pad under a 254 nm lamp sounds like a bad idea.

Except that Spectroline's own chip platform for these cabinets, part number I-2200, is specified with a high-density anti-static foam pad. The foam isn't tolerated; it's the design. And the reasoning I'd been applying was backwards—conductive foam is carbon-loaded, and carbon black is what you add to plastics to make them resist ultraviolet. The black pad holds up better under 254 nm than a clear one would.

Which is a small thing, and a good reminder that the sensible-sounding argument and the correct answer are different animals. The manufacturer had already solved it forty years ago.

The working geometry: chips window-up on black anti-static foam, at the height the original platform would have put them.

The ladder, and the cliff

The method is simple: expose a chip, blank check it, record the error count, expose it longer.

I started with thirty seconds. Then a minute.

Nothing. 65,536 errors both times, identical to the untouched control. Not one cell had released.

At a minute in a single continuous run: 65,534. Two bytes.

Then things got strange, so let me put the numbers where you can see them.

Between one minute and one minute fifteen, essentially the entire array crossed over. Not a gentle slope. A cliff, about fifteen seconds wide.

That is why the folklore is useless. People argue about ten minutes versus twenty for something that flips in the time it takes to read this paragraph—and where the flip happens depends entirely on the machine.

Two photographs

The interesting part isn't the pass and fail. It's the shape of the failures on the way through, and I got two pictures I haven't seen anywhere else.

Early in the transition, a chip reads like this:

Device data:  00  39  C5  29  2F  A9  B9  9D  AD  EF

Every byte different. Cells releasing at random across the array. Look at the last value—EF, seven of its eight cells already gone—nine addresses from a byte that's still 00 and hasn't started a thing. Cells in the same neighborhood at completely different stages of the same exposure.

Early in the erase. Every byte a different value as individual cells release at their own pace.

At the other end, with 38 bytes left failing:

Device data:  F7   7F   BF   FD   FB

Those five values are the whole vocabulary—every one of the 38 failing bytes read as one of them, and not one is 00. Every one is a single bit short of FF. Seven cells erased, one holding on. Those aren't 38 unerased bytes—they're 38 individual cells, each the last holdout in its byte, out of half a million.

Thirty-eight failing bytes out of 65,536, and not one of them reads 00. Every value is a single bit short of FF—thirty-eight individual cells, each the last holdout in its byte.

Which is the point, made visible: an EPROM doesn't erase as a unit. It erases as half a million independent cells with a spread of speeds, and the blank check passes at the moment the slowest one finally crosses. If that hex means nothing to you yet, the bit-flip primer walks through how to read it.

Bit 7 is a straggler

Here's something I didn't expect.

Go back and count the bits in that second block. 7F is bit 7 low. F7 is bit 3. BF is bit 6. In the 38-error sample they're mixed, but when I caught a chip with 72 bytes still failing, almost every single one read 7F.

Same bit. Across the whole array. That isn't random—it points at physical layout, one column of cells consistently slower than its neighbors, presumably by geometry or position on the die.

I've only seen it on one lamp and one batch of chips, so treat it as an observation rather than a law. But it's the kind of thing that only shows up if you count the failures instead of just reading pass or fail, and I'd be curious whether anyone else sees it.

Three ways the obvious method lies to you

Along the way, three procedures that seem completely reasonable turned out to measure something other than what I thought.

Short exposures don't add up. The tidy way to find a threshold is a ladder—expose a chip a little, check it, expose it a little more, check again—and it quietly assumes that dose accumulates across the interruptions. It doesn't. Two separate thirty-second runs erased nothing, while a single continuous sixty-second run had already started—though the chunked pair ran on a cold lamp and the continuous one on a warm one, so this is really the warm-up finding wearing a different hat.

The lamp needs time to reach full output, so a short burst spends most of itself warming up. I'd always treated erasing as a one-shot dose rather than something you creep up on, and it turns out there's a reason for that instinct even if I'd never articulated it. Put the chip in once and leave it.

The lamp remembers. The same 1:15 exposure gave me 38 errors when the lamp had been running all morning, and 65,535 when it had been sitting cold. Almost the full range of the curve from the same duration—though I have to flag that the cold run also carried five chips rather than one, so lamp state and load are tangled together and I can't hand you that pair as a single-variable result. Part 2 has the clean version. Either way, any comparison has to standardize thermal state, and I now pre-warm deliberately before timing anything.

Uniformity looks terrible if you measure it at the threshold. I mapped five positions at an exposure right at the knee, and one position came back dramatically better than the others. It looked like a real hot spot. It wasn't. Repeat the map at a working dose and all five are identical—because at the foot of the curve, a tiny difference in delivered UV turns into an enormous difference in error count. Map at twice the threshold, not at it.

The test that didn't work

Now the part I'd rather report than bury.

I noticed something promising. A chip caught mid-transition read inconsistently—38 errors, then 41 on a re-read with no additional ultraviolet in between. Nothing physical had changed; those cells were sitting right at the sense threshold and flipping depending on temperature or noise or read timing.

That looked like a free margin test. Read the chip three times, and if the number wanders, it's marginal. No special equipment, works on any programmer. Regular readers will recognize the shape of it from the intermittent fault that refused to come back across five programmers.

So I tested it properly. I took a chip and crept up in ten-second steps until it just passed—72 errors at 1:10, clean at 1:15. Five seconds of exposure between failing badly and passing. That is as marginal as a passing chip can be.

Then I read it five times.

Five clean passes. Rock steady. And chips erased well past threshold were equally steady.

So the instability is real, but it lives in chips that are still mid-transition—not in one that has just crossed. A barely-passing chip passes repeatably, and my free margin test doesn't do what I hoped.

I'm including this because a clean negative result is worth more than a claim I'd have to walk back, and because the honest version is still useful: you cannot see margin from a blank check, and no amount of re-reading will show it to you.

What I'd tell someone with one eraser

You need a programmer and one chip you're willing to spend. That's it.

1. Program a chip to all zeros. Not a ROM image—all zeros, so every cell is charged and the failure count means something.
2. Expose it, blank check it, write down the number of failing bytes. Not pass or fail. The number.
3. Repeat with longer exposures until it passes. Where it first passes is your machine's threshold, at your geometry, with your lamp as it is today.
4. Run production at twice that, and never chase the threshold.

That last point is the whole reason to do any of this. The threshold is a measurement, not an operating point. At the moment a chip first reads blank, its slowest cells have cleared by nothing at all—and a cell that barely cleared today is the one that gives somebody a strange fault in two years. Erasing well past threshold is free insurance against a problem you cannot otherwise detect.

On the borrowed cabinet, "well past" is three minutes. It clears a worst-case chip in ninety seconds.

The machine, for the record

The business end of the PC-2000—a serpentine quartz tube on a specular reflector. Most people who have owned an eraser have never seen one of these.

The PC-2000 came out well. Interlock correct, shelf uniform across the five positions I mapped—with a caveat I did not know to add at the time, and which Part 2 supplies—and much faster than I expected: ninety seconds for a chip with every cell programmed. The timer runs 18% fast and there's no tray, but neither is a fault in the erasing, and both are cheap to sort. It went back to its owner with a written report and my thanks, because testing one eraser tells you what that eraser does. Testing two tells you whether the method is any good.

Which brings me to the one still in its box.

Three predictions, written down before I know

Mine arrives this week. Small, two 6 W tubes, nothing like the borrowed cabinet—and I've already ordered replacement tubes for it, sight unseen, on the assumption that thirty-year-old lamps in a garage-stored machine must be worn out. That assumption is not a measurement either, and I notice I made it in a checkout page rather than at the bench.

I'm going to run exactly the same protocol with exactly the same chips. And since the entire point of this exercise is that I stopped trusting things I hadn't measured, it seems only fair to put my guesses on the record first, where I can't quietly adjust them afterwards.

One: it'll clear a chip in three to eight minutes.

On paper it should be about twenty-six minutes—that's the datasheet dose divided by the published lamp intensity, and it's the number I'd have quoted before Saturday. The borrowed cabinet did the job in ninety seconds. The arithmetic was out by more than a factor of fifteen, because that 15 W-sec/cm² is a guaranteed-worst-case figure and not a physical threshold, and nothing on the datasheet says so. Three to eight is the revised guess. It may also be wrong.

Two: bit 7 will lag again.

If those stragglers are down to how the array is laid out on the die, the same bit should trail on a different lamp, in a different cabinet, on a different day. If it's something peculiar to the borrowed machine's light, it won't. I genuinely don't know which, and it's the question I most want the answer to.

Three: the specimens will hold.

There are two chips in a bag on the shelf—one erased comfortably, one that passed by five seconds. I'll re-read both at a day, a week, and a month. If the marginal one drifts while the well-erased one doesn't, that's the retention argument demonstrated rather than asserted, and it's the last piece of evidence for erasing well past threshold.

I'd put money on all three. I'd have put money on twenty-six minutes, too.

Part 2 is here, and two of the three did not survive.

Frequently asked

How long should you leave an EPROM in a UV eraser?
It depends entirely on the machine, and the common "ten to twenty minutes" advice is not tied to any particular one. The borrowed Spectroline PC-2000 in this post cleared a fully programmed M27C512 in about seventy-five seconds. Measure your own eraser with a test chip, then run production at twice the measured threshold.

How do you test whether a UV EPROM eraser is actually working?
Program a chip to all zeros, expose it for a fixed time, blank check it, and record the number of failing bytes rather than just pass or fail. Repeat with longer exposures until it passes. The exposure where it first passes is that machine's threshold at your geometry with your lamps as they are today.

Why program a test chip to all zeros instead of using a ROM image?
An erased EPROM cell reads as 1 and programming drives it to 0, so an all-zeros chip has every cell in its programmed state—524,288 of them on a 64 KB M27C512. That is the hardest possible case to erase, and the count of still-failing bytes becomes a measure of how far through the erase you are.

Does a blank check tell you whether an EPROM was erased well?
No. It tells you every cell has crossed the read threshold, not by how much. A chip that passed by five seconds of exposure reads exactly like one erased well past threshold, and re-reading it will not reveal the difference—which is why you erase at twice the threshold rather than at it.

Further reading

• Part 2 of this pair—my own eraser, and the two predictions above that didn't survive: https://chicagolandretrotech.com/blogs/news/why-my-eprom-eraser-wasnt-erasing
• When Two EPROM Programmers Disagree—the cross-validation workflow this series grew out of: https://chicagolandretrotech.com/blogs/news/when-two-eprom-programmers-disagree-a-cross-validation-workflow
• Reading an EPROM verify error—the bit-flip primer, if the hex above needs decoding: https://chicagolandretrotech.com/blogs/news/reading-an-eprom-verify-error-a-bit-flip-primer
• Chasing an intermittent EPROM fault across five programmers—the read-instability gremlin's previous appearance: https://chicagolandretrotech.com/blogs/news/intermittent-eprom-read-fault-cross-validation-part-2
• GQ-4x4 vs XGECU T48—the second programmer used to cross-check every read in this post: https://chicagolandretrotech.com/blogs/news/gq-4x4-vs-xgecu-t48-tl866-comparison
• Spectronics Corporation (Spectroline), who made the borrowed cabinet and its lamps: https://spectroline.com/

I'm Jeffrey Mays. Bench Notes is where I write up the actual workshop work—burns, builds, repairs, and the occasional afternoon spent proving that something I'd done for years was never measured once. Chip data captured on a Needham's Electronics EMP-20 with cross-checks on a GQ-4x4; erase-dose figures from the STMicroelectronics M27C512 datasheet; cabinet specifications from Spectronics Corporation. The PC-2000 was lent by a local collector, who tested my patience by owning a nicer eraser than mine. Subscribe to catch the next one.