Send us the full top-side marking on your Zilog part plus a photo of both sides of the board, and we’ll tell you within a working day or so whether a Zilog IC unlock is feasible, roughly how long it takes, and what it costs. Feasibility on Zilog parts swings hard by family — an OTP Z86 masked-ROM-era device behaves nothing like a Z8 Encore! XP with its flash protection bytes set. The marking is what decides it.
Which Zilog parts actually come across the bench
Zilog silicon has a long service life, which is exactly why we see it. The parts still living inside working equipment tend to cluster into a few groups.
- Z8 classic (Z86xxx, Z86E series) — 8-bit OTP and masked-ROM devices in vending, HVAC controls, motor drives and older consumer gear. Frequently in DIP or PLCC.
- Z8 Encore! and Z8 Encore! XP (Z8Fxxxx) — flash-based, with a flash option byte region and a debug interface that can be disabled. This is the largest group we get asked about today.
- Z8 Encore! MC (Z8FMCxx) — motor control variants, common in fans, pumps and compressor drives.
- Z80, Z180, Z8S180, eZ80 / eZ80Acclaim! — the CPU-plus-external-memory world. Here the code usually lives in an external EPROM, flash or EEPROM, not in the CPU at all, which changes the whole job.
- ZNEO (Z16F) — 16-bit, flash, with its own protection scheme.
- Z8 Encore! with on-chip EEPROM / NVDS — calibration and serial data often sits separately from program flash and has to be pulled separately.
If your marking is worn or the top is laser-blurred, send a photo anyway. Package, pin count, date code style and the board context often narrow it down enough for us to name the family, and a die shot after opening will confirm the rest.
Why Zilog feasibility depends so much on family and era
Three things drive the answer, and none of them are about how “advanced” a lab is.
Memory technology
Masked ROM, OTP EPROM and embedded flash all store bits differently, and each behaves differently once protection is asserted. A masked-ROM Z86 has the program fixed in the metal and diffusion layers — reading it is an imaging problem, not a protocol problem. An OTP part with the protect bit blown is a different problem again. Flash-based Z8 Encore! parts route everything through the on-chip debug and flash controller logic, so the question becomes what state the flash option bytes are in.
Protection state
Zilog flash parts use option/configuration bytes to gate the on-chip debugger and to lock flash regions. Whether a part was shipped with the debugger fully disabled, partly restricted, or simply left readable makes an enormous difference. Plenty of legacy production boards were programmed without protection ever being enabled — we’ve had jobs finish in an afternoon because the previous engineer never set the byte. Others were locked down properly and become a much longer, lower-certainty exercise.
Where the code physically lives
On a Z80, Z180 or eZ80 design, the interesting bytes are usually in an external device on the same board. That means the job may not be a chip unlock at all — it may be an external flash or EPROM read, sometimes with an address or data bus scramble to work out, sometimes with a companion PLD or GAL doing the decode. Those cases are usually faster and more predictable than an on-chip flash unlock. Send board photos and we’ll tell you which situation you’re in before you pay for anything.
What Zilog IC unlock costs and how long it takes
We don’t publish a number, because a fixed price for “Zilog” would be dishonest. Here’s what moves it.
| Case | Typical difficulty | What drives the effort |
|---|---|---|
| Z80/Z180/eZ80 with external EPROM or flash | Usually the easiest | Desoldering, correct reader socket, mapping bus scrambling if present |
| Z8 Encore! / Encore! XP with protection not fully asserted | Low to moderate | Correct debug interface setup, verifying the dump is complete |
| Z8 Encore! with debug disabled and flash locked | Moderate to hard | Individual evaluation; may need sample sacrifice |
| Z86 OTP with protect bit set | Hard, case by case | Package opening, die-level work, older process helps |
| Masked-ROM Z8 (Z86Cxx and similar) | Specialist, long | Decapsulation and imaging; array size and layer count dominate |
| Z16F ZNEO with protection set | Case by case | Less common part, more characterization time |
Turnaround follows the same shape. An external memory read on a Z180 board can be a couple of days including shipping-in. A locked flash Z8 Encore! is meaningfully longer, and a masked-ROM imaging job is measured in weeks, not days, because every stage — opening, delayering, imaging, bit extraction, sanity-checking the decoded array against known code patterns — takes real bench time. Rush handling is possible on the simpler cases; we’ll say so in the quote rather than promising it up front. If you’re weighing vendors on more than price, our notes on how to evaluate an unlock lab cover the questions worth asking.
What to send us, and what comes back
Getting a useful answer takes about five minutes of your time. Send this:
- The complete chip marking, every line of it. “Z8F6423” is not enough — the suffix and package code matter. A macro photo beats retyping it.
- Photos of both sides of the board, on a dark, non-reflective background, whole board in frame, in focus, with the lighting angled so silkscreen and part markings are legible.
- Board dimensions and how many identical units you have. Spares matter — see the honesty section below.
- What the equipment does and why you need the code. Motor controller? Instrument front panel? That context tells us what kind of data structures to expect in the dump.
- One line on deliverables: raw binary only, binary plus programmed replacement parts, or binary plus a disassembly-ready map of the memory regions.
What comes back from us: a plain feasibility verdict (yes, probably, or no — we say no when it’s no), a lead time, a price, and a note on what would change the answer. On completion you get the extracted binary or hex, a report on which memory regions were read and verified, and, if you asked for it, blank parts programmed and checked against the original. Where on-chip EEPROM or NVDS holds calibration data, that gets dumped and delivered as a separate file so you don’t mix it with program code.
The honest limits on Zilog work
Nobody should quote a Zilog job without saying this out loud.
- We don’t guarantee any specific part. Not a percentage, not a success rate. Two boards with the same Z8F marking can behave differently depending on how the original firmware engineer configured protection.
- Some work is destructive. Package opening and die-level imaging consume the sample. If you have one board and one chip and the equipment must keep running, tell us first — sometimes the right recommendation is to leave the chip alone and pursue a different route.
- Old, hot-running parts can be marginal. Twenty-year-old flash cells sitting in a 70 °C enclosure drift. We may get a dump that reads inconsistently across passes, in which case we do repeated reads and majority comparison and tell you honestly how confident we are.
- An extracted binary is not source code. You get bytes that run. Turning those into maintainable C is a separate, much larger job, and we’ll say so instead of implying otherwise.
- Rare Zilog derivatives and customer-specific mask variants sometimes have no established path. If we haven’t characterized a part, we say “unknown, needs evaluation” rather than quoting blind.
Zilog work sits in the same category as other long-lived industrial silicon. If your board also carries an 8051 derivative, a Silicon Labs part like a C8051F340 mixed-signal MCU, or a serial EEPROM such as a 24C256 device holding setup data, mention it — legacy controllers usually hide their real configuration outside the main CPU, and we’d rather pull everything in one pass than have you ship the board twice.
Legitimate reasons this work happens
Almost every Zilog job we take is a maintenance problem. A machine built in 1998 still earns money, the original firmware author retired, the hex file lived on a machine that got scrapped, and now a failed controller means the line stops. Or the Z8 variant went end-of-life and you need the code so you can migrate to a current MCU without re-deriving fifteen years of tuning constants. Or a unit failed in the field and you need the code and the NVDS contents to understand why.
Those are all normal engineering. You’re responsible for holding the rights to the firmware you ask us to recover and for complying with applicable IP law; we work under NDA on every project and don’t retain client code after delivery. That’s the whole of it — we’re not going to lecture you, and we’re not going to help anyone lift a competitor’s product.
FAQ
Can you unlock a Z8 Encore! with the debug interface disabled?
Sometimes, but it needs evaluation rather than a yes over email. Once the on-chip debugger is gated by the flash option bytes, the straightforward route is closed and the job moves toward physical-access tech
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote