{"slug": "a-tricky-commodore-pet-repair-tracking-down-6-1-2-bad-chips", "title": "A tricky Commodore PET repair: tracking down 6 1/2 bad chips", "summary": "The article describes the repair of a non-working Commodore PET computer from 1977, part of the \"1977 Trinity\" of early home computers. The repair was challenging due to multiple failed custom ROM and RAM chips, which are now mostly unobtainable. After replacing two failed ROM chips with adapter boards and using a logic analyzer to trace the processor's memory access, the computer still failed to boot properly, indicating further issues.", "body_md": "In 1977, Commodore released the PET computer, a quirky home computer that combined the processor,\na tiny keyboard, a cassette drive for storage, and a trapezoidal screen in a metal unit.\nThe Commodore PET, the Apple II, and Radio Shack's TRS-80 started the home computer market with ready-to-run computers,\nsystems that were called in retrospect the\n[1977 Trinity](https://web.archive.org/web/20080618072507/http://www.byte.com/art/9509/sec7/art15.htm).\nI did much of my early programming on the PET, so when someone offered me a non-working PET a few years\nago, I took it for nostalgic reasons.\n\nYou'd think that a home computer would be easy to repair, but it turned out to be a challenge. The chips in early PETs are notorious for failures and, sure enough, we found multiple bad chips. Moreover, these RAM and ROM chips were special designs that are mostly unobtainable now. In this post, I'll summarize how we repaired the system, in case it helps anyone else.\n\nWhen I first powered up the computer, I was greeted with a display full of random characters. This was actually reassuring since it showed that most of the computer was working: not just the monitor, but the video RAM, character ROM, system clock, and power supply were all operational.\n\nWith an oscilloscope, I examined signals on the system bus and found that the clock, address, and data lines were full of activity, so the 6502 CPU seemed to be operating. However, some of the data lines had three voltage levels, as shown below. This was clearly not good, and suggested that a chip on the bus was messing up the data signals.\n\nSome helpful sites online[7](#fn:troubleshooting) suggested that if a PET gets stuck before clearing the screen, the most likely cause is\na failure of a system ROM chip.\nFortunately, Marc has a [Retro Chip Tester](https://americanretro.shop/rctp), a cool device designed to\ntest vintage ICs: not just 7400-series logic, but vintage RAMs and ROMs.\nMoreover, the tester knows the correct ROM contents for a ton of old computers, so it can tell if a PET ROM has\nthe right contents.\n\nThe Retro Chip Tester showed that two of the PET's seven ROM chips had failed. These chips are MOS Technologies MPS6540, a 2K×8 ROM with a weird design that is incompatible with standard ROMs. Fortunately, several people make adapter boards that let you substitute a standard 2716 EPROM, so I ordered two adapter boards, assembled them, and Marc programmed the 2716 EPROMs from online data files. The 2716 EPROM requires a bit more voltage to program than Marc's programmer supported, but the chips seemed to have the right contents (foreshadowing).\n\nThe PET's case swings open with an arm at the left to hold it open like a car hood. The first two rows of chips at the front of the motherboard are the RAM chips. Behind the RAM are the seven ROM chips; two have been replaced by the ROM adapter boards. The 6502 processor is the large black chip behind the ROMs, toward the right.\n\nWith the adapter boards in place, I powered on the PET with great expectations of success, but it failed in precisely\nthe same way as before, failing to clear the garbage off the screen.\nMarc decided it was time to use his Agilent 1670G logic analyzer to find out what was going on;\n(Dating back to 1999, this logic analyzer is modern by Marc's standards.)\nHe wired up the logic analyzer to the 6502 chip, as shown below, so we could track the address bus, data bus,\nand the read/write signal.\nMeanwhile, I disassembled the ROM contents using Ghidra, so I could interpret the logic analyzer against the assembly code.\n([Ghidra](https://ghidra-sre.org/) is a program for reverse-engineering software that was developed by the NSA, strangely enough.)\n\nThe logic analyzer provided a trace of every memory access from the 6502 processor, showing what it was executing. Everything went well for a while after the system was turned on: the processor jumped to the reset vector location, did a bit of initialization, tested the memory, but then everything went haywire. I noticed that the memory test failed on the first byte. Then the software tried to get more storage by garbage collecting the BASIC program and variables. Since there wasn't any storage at all, this didn't go well and the system hung before reaching the code that clears the screen.\n\nWe tested the memory chips, using the Retro Chip Tester again, and found three bad chips.\nLike the ROM chips, the RAM chips are unusual: MOS Technology [6550](http://blog.tynemouthsoftware.co.uk/2024/06/mos-6550-ram-chips.html) static RAM chip, 1K×4.\nBy removing the bad chips and shuffling the good chips around, we reduced the 8K PET to a 6K PET.\nThis time, the system booted, although there was a mysterious 2×2 checkerboard symbol near the middle of the screen (foreshadowing).\nI typed in a simple program to print \"HELLO\", but the results were very strange: four floating-point numbers, followed\nby a hang.\n\nThis behavior was very puzzling. I could successfully enter a program into the computer, which exercises a lot of the system code. (It's not like a terminal, where echoing text is trivial; the PET does a lot of processing behind the scenes to parse a BASIC program as it is entered.) However, the output of the program was completely wrong, printing floating-point numbers instead of a string.\n\nWe also encountered an intermittent problem that after turning the computer on, the boot message would be complete gibberish, as shown below. Instead of the \"*** COMMODORE BASIC ***\" banner, random characters and graphics would appear.\n\nHow could the computer be operating well for the most part, yet also completely wrong? We went back to the logic analyzer to find out.\n\nI figured that the gibberish boot message would probably be the easiest thing to track down, since that happens\nearly in the boot process.\nLooking at the code, I discovered that after the software tests the memory, it converts the memory size to an ASCII string using a moderately complicated\nalgorithm.[1](#fn:conversion)\nThen it writes the system boot message and the memory size to the screen.\n\nThe PET uses a subroutine to write text to the screen. A pointer to the text message is held in memory locations 0071 and 0072. The assembly code below stores the pointer (in the X and Y registers) into these memory locations. (This Ghidra output shows the address, the instruction bytes, and the symbolic assembler instructions.)\n\n```\nd5ae 86 71   STX 71\nd5b0 84 72   STY 72           \nd5b2 60      RTS\n```\n\nFor the code above, you'd expect the processor to read the instruction bytes 86 and 71, and then write to address 0071. Next it should read the bytes 84 and 72 and write to address 0072. However, the logic analyzer output below showed that something slightly different happened. The processor fetched instruction bytes 86 and 71 from addresses D5AE and D5AF, then wrote 00 to address 0071, as expected. Next, it fetched instruction bytes 84 and 72 as expected, but wrote 01 to address 007A, not 0072!\n\n```\n step   address byte  read/write'\n112235   D5AE   86      1\n112236   D5AF   71      1\n112237   0071   00      0\n112238   D5B0   84      1\n112239   D5B1   72      1\n112240   007A   01      0\n```\n\nThis was a smoking gun. The processor had messed up and there was a one-bit error in the address. Maybe the 6502 processor issued a bad signal or maybe something else was causing problems on the bus. The consequence of this error was that the string pointer referenced random memory rather than the desired boot message, so random characters were written to the screen.\n\nNext, I investigated why the screen had a mysterious checkerboard character. I wrote a program to scan the logic analyzer output to extract all the writes to screen memory. Most of the screen operations made sense—clearing the screen at startup and then writing the boot message—but I found one unexpected write to the screen. In the assembly code below, the Y register should be written to zero-page address 5e, and the X register should be written to the address 66, some locations used by the BASIC interpreter.\n\n```\nd3c8 84 5e   STY 5e\nd3ca 86 66   STX 66\n```\n\nHowever, the logic analyzer output below showed a problem.\nThe first line should fetch the opcode 84 from address d3c8, but the processor received the opcode 8c from the ROM,\nthe instruction to write to a 16-bit address.\nThe result was that instead of writing to a zero-page address, the 6502 fetched another byte to write to a 16-bit\naddress.\nSpecifically, it grabbed the STX instruction (86) and used that as part of the address, writing FF (a checkerboard character) to screen memory at\n865E[2](#fn:screen) instead of to the BASIC data structure at 005E.\nMoreover, the STX instruction wasn't executed, since it was consumed as an address.\nThus, not only did a stray character get written to the screen, but data structures in memory didn't get updated.\nIt's not surprising that the BASIC interpreter went out of control when it tried to run the program.\n\n```\n step   address byte read/write'\n186600   D3C8   8C      1\n186601   D3C9   5E      1\n186602   D3CA   86      1\n186603   865E   FF      0\n```\n\nWe concluded that a ROM was providing the wrong byte (8C) at address D3C8.\nThis ROM turned out to be one of our replacements; the under-powered EPROM programmer had resulted in a flaky byte.\nMarc re-programmed the EPROM with a more powerful programmer.\nThe system booted, but with much less RAM than expected.\nIt turned out that *another* RAM chip had failed.\n\nFinally, we got the PET to run. I typed in a simple program to generate an animated graphical pattern, a program\nI remembered from when I was about 13[3](#fn:listing), and generated this output:\n\nIn retrospect, I should have tested all the RAM and ROM chips at the start, and we probably could have found the faults\nwithout the logic analyzer.\nHowever, the logic analyzer gave me an excuse to learn more about Ghidra and the PET's assembly code, so it\nall worked out in the end.[4](#fn:why)\n\nIn the end, the PET had 6 bad chips: two ROMs and four RAMs.\nThe 6502 processor itself turned out to be fine.[5](#fn:6502)\nThe photo below shows the 6 bad chips on top of the PET's tiny keyboard.\nOn the top of each key, you can see the quirky graphical character set known as PETSCII.[6](#fn:petscii)\nAs for the title, I'm counting the badly-programmed ROM as half a bad chip since\nthe chip itself wasn't bad but it was functioning erratically.\n\nCuriousMarc created a video of the PET restoration, if you want more:\n\nFollow me on Bluesky ([@righto.com](https://bsky.app/profile/righto.com)) or [RSS](https://www.righto.com/feeds/posts/default) for updates. (I'm no longer on Twitter.)\nThanks to Mike Naberezny for providing the PET.\nThanks to [TubeTime](https://bsky.app/profile/tubetime.bsky.social), Mike Stewart, and especially\n[CuriousMarc](https://www.youtube.com/CuriousMarc) for help with the repairs.\nSome useful PET troubleshooting links are in the footnotes.[7](#fn:troubleshooting)\n\n## Footnotes and references\n\n-\nConverting a number to an ASCII string is somewhat complicated on the 6502. You can't quickly divide by 10 for the decimal conversion, since the processor doesn't have a divide instruction. Instead, the PET's conversion routine has hard-coded four-byte constants: -100000000, 10000000, -100000, 100000, -10000, 1000, -100, 10, and -1. The routine repeatedly adds the first constant (i.e. subtracting 100000000) until the result is negative. Then it repeatedly adds the second constant until the result is positive, and so forth. The number of steps gives each decimal digit (after adjustment).\n\nThe same algorithm is used with the base-60 constants: -2160000, 216000, -36000, 3600, -600, and 60. This converts the uptime count into hours, minutes, and seconds for the\n\n`TIME$`\n\nvariable. (The PET's basic time count is the \"jiffy\", 1/60th of a second.)[↩](#fnref:conversion) -\nTechnically, the address 865E is not part of screen memory, which is 1000 characters starting at address 0x8000. However, the PET's address uses some shortcuts in address decoding, so 865E ends up the same as 825e, referencing the 7th character of the 16th line.\n\n[↩](#fnref:screen) -\nHere's the source code for my demo program, which I remembered from my teenage programming. It simply displays blocks (black, white, or gray) with 8-fold symmetry, writing directly to screen memory with\n\n`POKE`\n\nstatements. (It turns out that almost anything looks good with 8-fold symmetry.) The cryptic heart in the first`PRINT`\n\nstatement is the clear-screen character.My program to display some graphics. -\nSo why did I suddenly decide to restore a PET that had been sitting in my garage since 2017? Well, CNN was filming an interview with Bill Gates and they wanted background footage of the 1970s-era computers that ran the Microsoft BASIC that Bill Gates wrote. Spoiler: I didn't get my computer working in time for CNN, but Marc found some other computers.\n\n-\nI suspected a problem with the 6502 processor because the logic analyzer showed that the 6502 read an instruction correctly but then accessed the wrong address. Eric provided a replacement 6502 chip but swapping the processor had no effect. However, reprogramming the ROM fixed both problems. Our theory is that the signal on the bus either had a timing problem or a voltage problem, causing the logic analyzer to show the correct value but the 6502 to read the wrong value. Probably the ROM had a weakly-programmed bit, causing the ROM's output for that bit to either be at an intermediate voltage or causing the output to take too long to settle to the correct voltage. The moral is that you can't always trust the logic analyzer if there are analog faults.\n\n[↩](#fnref:6502) -\nThe PETSCII graphics characters are now in Unicode in the\n\n[Symbols for Legacy Computing](https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing)block.[↩](#fnref:petscii) -\nThe\n\n[PET troubleshooting site](http://www.dasarodesigns.com/projects/troubleshooting-common-problems-with-the-commodore-pet-2001/)was very helpful. The Commodore PET's Microsoft BASIC source code is[here](https://www.pagetable.com/?p=46), mostly uncommented. I mapped many of the labels in the source code to the assembly code produced by Ghidra to understand the logic analyzer traces. The ROM images are[here](https://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/). Schematics of the PET are[here](https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001/index.html).[↩](#fnref:troubleshooting)[↩](#fnref2:troubleshooting)", "url": "https://wpnews.pro/news/a-tricky-commodore-pet-repair-tracking-down-6-1-2-bad-chips", "canonical_source": "http://www.righto.com/2025/04/commodore-pet-repair.html", "published_at": "2025-04-13 15:45:00+00:00", "updated_at": "2026-05-23 17:43:34.670239+00:00", "lang": "en", "topics": ["hardware", "semiconductor"], "entities": ["Commodore", "PET", "Apple II", "Radio Shack", "TRS-80", "6502 CPU"], "alternates": {"html": "https://wpnews.pro/news/a-tricky-commodore-pet-repair-tracking-down-6-1-2-bad-chips", "markdown": "https://wpnews.pro/news/a-tricky-commodore-pet-repair-tracking-down-6-1-2-bad-chips.md", "text": "https://wpnews.pro/news/a-tricky-commodore-pet-repair-tracking-down-6-1-2-bad-chips.txt", "jsonld": "https://wpnews.pro/news/a-tricky-commodore-pet-repair-tracking-down-6-1-2-bad-chips.jsonld"}}