Restoring "The Chip": rebuilding a 1983 Atari 810 modification

Part 1 of a series on a 1983 Atari 810 disk drive modification called The Chip, the copy protection it was built to examine, and a stack of Happy-modified 1050s that took a different run at the same problem. This one is the rebuild: three cut traces, three jumper wires, and a modification I had exactly one chance to get right.

There is a particular kind of dread that comes with a soldering iron and a working disk drive.

I had a modified Atari 810—modified with something called The Chip, a 1983 product that turns an ordinary 810 into an instrument capable of reading and writing floppy disks in ways Atari never intended. The modification lived on a sideboard that had stopped working. I had tried to repair it several times. It was dead.

I also had a working 810, unmodified, in service.

The obvious move—cut and solder the working board—was the one that could leave me with no working drive at all. This is the story of not doing that, of the three numbers I nearly got wrong, and of the thing I found sitting in the first two bytes of the ROM, which turned out to be the best part.

What The Chip is

The Archiver/Editor V1.0 reading track 4. The parameter line along the top is the one this post ends up defending—note the minus sign on A6. The monitor is a Commodore 1701; composite is composite.

The Chip was made by Spartan Software of Minnesota, Inc., of Crystal, Minnesota, copyright 1983. It is a 4K ultraviolet-erasable EPROM that replaces the drive's firmware, plus three cuts in the circuit board and three jumper wires.

Atari's 810 speaks a small, fixed vocabulary over the SIO bus: read a sector, write a sector, format, status. The Chip adds eleven commands to that vocabulary—commands for reading and writing entire tracks, for mapping what is physically on a track rather than what the disk claims is there, and for writing custom formats no ordinary drive can produce.

The companion software is called The Archiver/Editor, written by Mike Gustafson. Mine is version 1.0, labeled 810 ONLY.

Three years later, George Morrison reviewed it in Advanced Atari Protection Techniques (Alpha Systems, 1986), and his assessment is the honest one:

"The real power of Archiver lies in its ability to show what the disk contains, and thus makes it easier to understand what the protection is doing."

By 1986 The Chip was no longer especially good at copying things. It remained unmatched at seeing them. That distinction turns out to be the whole point of this series, and I did not appreciate it when I started.

Rule one: dump it before you desolder anything

Both halves of rule one in one frame: the code goes on the label, and the label goes over the window. Ambient light is a slow erase, but it is still an erase.

The single most important thing I did happened before any soldering.

The EPROM was read and its contents saved to a file, with checksums recorded—read twice, for the reasons set out in the cross-validation workflow. It is a forty-year-old ceramic chip with a quartz window. Ambient light degrades one of those over decades, which is why they were meant to live under an opaque label—and having recently spent two posts measuring what ultraviolet actually does to an EPROM, I was in no mood to find out how much daylight this one had already had. If it had died on the bench, the modification would have been unrecoverable, and these are not being manufactured any more.

Two rules follow, and they are cheap:

1. Dump it first. Before anything else touches it.
2. Cover the window. An opaque label, removed only when the chip is on display.

Once the dump exists, the chip becomes replaceable, and that changes the risk calculation of everything that follows. I would not have cut a trace without it. The two labeled chips in the photograph above are that promise cashed—both burned from the file, because everything that makes the original work is in the file. Including, it turns out, the code.

What is actually in the ROM

The dump is 4,096 bytes. From offset $002 it announces itself in plain ATASCII—$9B is the end-of-line character, which is why it shows as a dot:

$002  2A 20 54 48 45 20 43 48 49 50 20 2D 20 56 45 52  |* THE CHIP - VER|
$012  53 49 4F 4E 20 31 2E 30 20 2A 9B 28 43 29 20 31  |SION 1.0 *.(C) 1|
$022  39 38 33 20 53 50 41 52 54 41 4E 20 53 4F 46 54  |983 SPARTAN SOFT|
$032  57 41 52 45 20 4F 46 20 4D 49 4E 4E 2E 20 49 4E  |WARE OF MINN. IN|
$042  43 2E 9B                                         |C..             |

If those hex values need decoding, the bit-flip primer covers how to read them.

The SIO command dispatch table sits at file offset $1A7:

50 52 53 57 21 42 43 44 46 47 4C 4D 4E 4F 54 5A
 P  R  S  W  !  B  C  D  F  G  L  M  N  O  T  Z

The first five are the standard 810 commands. The remaining eleven—B C D F G L M N O T Z—exist only because of this chip.

The dispatcher uses the classic 6502 RTS trick, pushing a return address onto the stack and letting RTS jump there. The table is at file offset $1B7 but is read from $09B7, which tells you the ROM maps at $0800 in the drive's address space. 725 bytes of the image—17.7 per cent of it—are $1A, clustered into four pages, one of which is nothing else. $1A is an undocumented single-byte no-op on the NMOS 6502, and filling unused ROM with no-ops is deliberate defensive practice: a runaway program counter slides harmlessly down to the vectors instead of executing garbage.

I will come back to the first two bytes, which I have skipped over in that listing. They are the most interesting thing in the file and I walked straight past them for a fortnight.

Rule two: the dead board is the map

The template and the copy. Black wire above is the 1983 installation, on the board that died; blue below is the same three jumpers re-created this month. Same revision, same trace routing, forty-three years apart—which is the only reason I was willing to put a knife to the second one.

Both sideboards turned out to be the same revision—SIDE 810, part CO14024 REV A, © 1979 Innovative Leisure. Identical layout, identical trace routing.

That made the dead board a one-to-one template. Every cut and every jumper could be located on the working board by comparing it directly against a board where somebody had already done the job correctly in 1983.

This matters more than it sounds. The installation manual describes cuts as distances—"1/8 inch to the right of pin 18." A distance is measured on one specific board layout by one person looking at one photograph. Work by electrical net, not by distance. Establish what the trace connects, confirm it against the template, meter it, and only then reach for the knife.

Rule three: read the whole manual, not the chapter you need

I nearly got this badly wrong.

I had begun from an OCR'd excerpt of the installation chapter—the part that tells you what to cut. When I finally obtained a scan of the complete seventeen-page CHIP installation manual, three of the numbers I had been working from were wrong.

I had also missed two procedural steps entirely. The manual requires booting a DOS disk before the Archiver disk during the verification test, and the motor-off timing to watch for is five to six seconds, not the ten to fifteen I had assumed.

Any one of those could have cost me the drive. The excerpt was not wrong so much as incomplete in ways that looked complete, which is the most dangerous kind of document—it answers the question you asked and gives you no reason to suspect there was a better one.

The modification itself

This voids any warranty and can destroy a working drive. The 810s are all long out of warranty; the second half of that sentence still applies.

The cuts

All three are on the foil side. Cut about a sixteenth of an inch wide and remove all the copper—a scratch is not a cut. Meter each one before moving on.

The jumpers

Trim the wire ends to an eighth of an inch. Foil side.

Not every board has that hole. If yours doesn't, go to C107's own ground lead—and meter it to be certain it is circuit ground before you commit.

Orientation, which is where this goes wrong quietly

The notch on the chip faces the top edge of the board—the opposite direction to most of the other integrated circuits on it. This is exactly the sort of detail that gets skimmed. Check it twice. Installing a 2732 backwards is an efficient way to destroy one.

Working from the foil side, everything is mirrored and it is very easy to count pins the wrong way. For A102: pin 24 top left, pin 13 bottom left, pin 1 top right, pin 12 bottom right.

Iron: 25 to 30 watts, 30 absolute maximum. Sixty-forty rosin core only. Fifteen seconds maximum per joint—the pads on these boards lift if you dwell on them.

The verification that isn't obvious

Here is the part that catches people, and it is worth understanding before you conclude you have failed.

"As a safety feature to the user, the CHIP modification functions identically to a standard (unmodified) 810 Disk Drive when not opened."

A drive with The Chip correctly installed behaves exactly like a drive without it—until the chip is opened. There is no status command that reports whether it is present. You cannot ask it.

There are two ways to open it.

The boot ritual. Power the drive on first, disk in, wait for the busy light to go out, then power the computer. Booting in that order executes sector $2D0, which opens The Chip automatically.

The O command. O [4-digit code] [drive]. A wrong code—or pressing RETURN alone—closes the chip and returns the drive to standard behavior.

Mine came on a hand-written note that arrived with the drive: 3626, beside the words "810 Archiver / Chip #." Where that number actually lives turns out to be the best thing in this post, and I will come back to it.

When the software accepted that code, the installation was proven. O is a Chip-only SIO command; a standard 810 has no idea what it means. Acceptance is not "probably working." It is proof that the ROM is alive, the cuts are right and the jumpers are right, all at once.

It worked, and then it threw an error I misdiagnosed

The drive boots. The Archiver/Editor loads. The code is accepted. Disks copy.

Then I tried a whole-disk read with verification on, and got READ FORMAT ERROR.

My working parameter line is now this, and the important character in it is the minus sign:

S:1 D:1 R:00,27 V+ L+ C+ A6- F+ S+ B+     N 01

A6+ adds a second read pass and compares the two. I spent a while suspecting my drive speed, because I had recently recalibrated the mechanism from 290 RPM down to 288 and it was the most recent thing I had changed. That is exactly the sort of reasoning that feels rigorous and isn't—I picked the suspect because it was nearest, not because the evidence pointed at it.

The manual had the answer all along, in a chapter I had not read yet:

"…the tracks are badly garbled and the second pass does not return the same results as the first pass. This will only happen on unformatted tracks, in which case random numbers appear as the sector numbers. To solve this problem, simply switch to a A6- read format mode."

With verification off, the full forty-track read completes.

Blank tracks. Not speed. And my own evidence had said so from the beginning—the read had consumed only about 14.5K of a 39K buffer with compaction switched on, which is consistent with a largely empty disk. I had the number in front of me and drew the wrong conclusion from it.

The drive stays at 288, incidentally. Both period sources I trust—this manual and the Alpha Systems book—give 288 as normal; Atari's own field service manual says 290 with a one per cent tolerance, which 288 satisfies. Two out of three, and the two that agree are the ones written by people copying disks for a living.

The password was printed on the lock

The card that shipped with the drive, held against the file it was already written into. Offset zero reads 26 36. The card reads 3626. Two bytes, byte-swapped, and a fortnight of not noticing.

Now the good part, which I walked past a dozen times.

Every hex listing above starts at $002. Here is what sits in front of it:

$000  26 36 2A 20 54 48 45 20 43 48 49 50 20 2D 20 56  |&6* THE CHIP - V|

In the ATASCII column those first two bytes render as &6, immediately before the banner's asterisk. That reads as decoration. Period software puts flourishes around a title constantly, and I had a whole banner starting two bytes later to confirm the impression.

They are the unlock code. Packed binary-coded decimal, low byte first: read $001 then $000—36, then 26—and you get 3626. Which is the number hand-written on the card that came with my drive.

So the O command performs no lookup and runs no algorithm. It compares the four digits you type against the first two bytes of its own firmware. That is the entire authentication scheme. The only attack on it is trying all ten thousand, and the only reason nobody did is that opening the file was easier.

Two things follow, and the second one is funny.

The codes were burned per chip. If one code opened every Chip ever sold, it would not need to be in the image at all—you would hard-code the comparison and save two bytes. Putting it in the ROM only makes sense if every ROM is different.

And a per-chip code stored in the chip defeats itself the moment the chip is copied. A 2732 is not a hard thing to duplicate, which the trade noticed early. George Morrison again, in 1986:

"Because the Archiver is a simple EPROM, it was widely pirated and sold (of course, with no support from Spartan) for prices between $15.00 and $80.00."

Every pirated Chip carried its original owner's unlock code to its new owner, intact, at offset zero. The lock and the key shipped in the same package, and the package was the thing being copied. A product built to defeat copy protection, protected by a scheme that travels with the copy.

I want to be careful about how much of that is inference. The per-chip conclusion rests on one chip, and I would like a second to confirm it. So if you have a Chip: dump it and tell me your first two bytes. Different from mine and per-chip codes are settled. The same as mine and something much stranger is going on. And if the images differ anywhere else, there were firmware revisions nobody has written down.

The scorecard

One out of five. The one I got right is the only one I would have bet on.

What I'd actually tell you now

1. Dump the EPROM before anything else touches it, record checksums, then cover the window.
2. Find a template. A dead board of the same revision is worth more than any photograph, because you can meter it.
3. Get the complete manual, not the chapter. The gaps in an excerpt are invisible until they cost you something.
4. Work by net, not by distance. Manuals describe one specific board; a meter describes yours.
5. Never modify a drive you depend on. My old board turned out to be unrepairable, which is what finally made the decision easy. Had it been salvageable I would have waited for a spare.
6. Expect a correct installation to look like a failure until you open the chip. Learn the boot ritual before you learn to doubt your soldering.
7. Read the numbers, not the letters. The ASCII pane of a hex dump is a convenience, not the data. Mine told me a story about decoration for a fortnight.

What I learned

Three things, and only one of them is about soldering.

A document that answers your question is not the same as a complete document. The installation chapter told me exactly what to cut and gave me three numbers that were wrong, and there was nothing in it to suggest I should look further. I only found the complete manual because I went looking for something else.

The dead thing was the valuable thing. I had thought of the old sideboard as a dead end, a repair I had lost. It turned out to be the only object in the process I could put a meter on and trust, and it is now going in the exhibit case.

And I read the column that was easy to read. The ASCII pane of a hex dump is right there, in letters, next to a wall of numbers. It told me a story about decorative characters and I believed it, in a file I had already opened a dozen times. The answer was two bytes from the start, in the column I was not reading.

Frequently asked

What is "The Chip" for the Atari 810?
A 1983 modification from Spartan Software of Minnesota: a 4K EPROM that replaces the 810's firmware, plus three cut traces and three jumper wires. It adds eleven commands to the drive's SIO vocabulary, allowing whole tracks to be read, mapped and written in ways a standard 810 cannot. The host software is called the Archiver/Editor.

How do I know whether a drive already has The Chip installed?
You cannot tell by using it normally. The modification is dormant by design and a drive carrying it behaves exactly like a standard 810 until the chip is "opened," either by the boot ritual—drive powered on first, then the computer, which executes sector $2D0—or by the Archiver's O command with the correct four-digit code. There is no status command that reports its presence.

Why does the Archiver return READ FORMAT ERROR?
On a protected or deliberately garbled disk, and—in the manual's own example—on unformatted tracks. With A6+ the software reads each track twice and compares; on a blank track the sector numbers come back as random values that differ between passes, so the comparison fails by design. The manual's own remedy is to switch to A6-, which drops the second pass. On my bench A6- is the default rather than the fallback.

Where does the Archiver's unlock code come from?
It is stored in the Chip's own ROM, in the first two bytes of the image, as packed BCD with the low byte first. On my drive those bytes are 26 36, which reads back as 3626—the number hand-written on the card that shipped with it. The O command simply compares your four digits against those two bytes, which implies the codes were burned per chip rather than shared across all copies. That is a one-sample conclusion and I would like a second dump to confirm it. If you have a Chip and no code, the boot ritual opens it without one.

Further reading

• The ARCHIVER/EDITOR manual, scanned in full—nine chapters and five appendices, including the theory-of-format and useful-hints chapters that answered my error: https://archive.org/details/ArchiverEditor
• The Chip's installation chapter on its own, which is where I started and should not have stopped: https://archive.org/details/rearc_the-chip-for-atari-810-ch-9-installation-198x
• The Archiver v1.0 software, 1983, Spartan Software—the same release I am running: https://archive.org/details/a8b_Archiver_The_v1.0_1983_Spartan_Software

I'm Jeffrey Mays. Bench Notes is where I write up the actual workshop work—burns, builds, repairs, and the occasional afternoon spent reading a hex dump without looking at it. Every screen photographed here was produced on my own hardware: an Atari 800, an 810 with the modification described above, and the Archiver/Editor V1.0. Period quotations are from the ARCHIVER/EDITOR manual (Spartan Software of Minnesota) and from George Morrison's Advanced Atari Protection Techniques (Alpha Systems, 1986). The drive is being rebuilt for exhibit at VCF Midwest 21 in September. Subscribe to catch the next one.

Next: stopping time—freezing a running game with a ROM monitor called OmniMon, on the shelf since 1981, and reading the code out from where it stopped.