.cite { font-size: 70%;} .ref { vertical-align: super; font-size: 60%;} code {font-size: 100%; font-family: courier, fixed;} In 1977, Commodore released the PET computer, a quirky home computer that combined the processor, a tiny keyboard, a cassette drive for storage, and a trapezoidal screen in a metal unit. The Commodore PET, the Apple II, and Radio Shack's TRS-80 started the home computer market with ready-to-run computers, systems that were called in retrospect the 1977 Trinity. I did much of my early programming on the PET, so when someone offered me a non-working PET a few years ago, I took it for nostalgic reasons. You'd think that a home computer would be easy to repair, but it turned out to be a challenge.1 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. When 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. The Commodore PET started up, but the screen was full of garbage. With 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. The scope shows three voltage levels on the data bus. Some helpful sites online7 suggested that if a PET gets stuck before clearing the screen, the most likely cause is a failure of a system ROM chip. Fortunately, Marc has a Retro Chip Tester, a cool device designed to test vintage ICs: not just 7400-series logic, but vintage RAMs and ROMs. Moreover, the tester knows the correct ROM contents for a ton of old computers, so it can tell if a PET ROM has the right contents. The 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). The PET opened, showing the motherboard. The 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. With the adapter boards in place, I powered on the PET with great expectations of success, but it failed in precisely the same way as before, failing to clear the garbage off the screen. Marc decided it was time to use his Agilent 1670G logic analyzer to find out what was going on; (Dating back to 1999, this logic analyzer is modern by Marc's standards.) He wired up the logic analyzer to the 6502 chip, as shown below, so we could track the address bus, data bus, and the read/write signal. Meanwhile, I disassembled the ROM contents using Ghidra, so I could interpret the logic analyzer against the assembly code. (Ghidra is a program for reverse-engineering software that was developed by the NSA, strangely enough.) Marc wired up the logic analyzer to the 6502 chip. The 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. We tested the memory chips, using the Retro Chip Tester again, and found three bad chips. Like the ROM chips, the RAM chips are unusual: MOS Technology 6550 static RAM chip, 1K×4. By removing the bad chips and shuffling the good chips around, we reduced the 8K PET to a 6K PET. This time, the system booted, although there was a mysterious 2×2 checkerboard symbol near the middle of the screen (foreshadowing). I typed in a simple program to print "HELLO", but the results were very strange: four floating-point numbers, followed by a hang. This program didn't work the way I expected. This 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. We 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. The garbled boot message. How could the computer be operating well for the most part, yet also completely wrong? We went back to the logic analyzer to find out. I figured that the gibberish boot message would probably be the easiest thing to track down, since that happens early in the boot process. Looking 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 algorithm.2 Then it writes the system boot message and the memory size to the screen. The 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.) For 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! 007A 01 0 This 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. Next, 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. However, the logic analyzer output below showed a problem. The first line should fetch the opcode 84 from address d3c8, but the processor received the opcode 8c from the ROM, the instruction to write to a 16-bit address. The result was that instead of writing to a zero-page address, the 6502 fetched another byte to write to a 16-bit address. Specifically, it grabbed the STX instruction (86) and used that as part of the address, writing FF (a checkerboard character) to screen memory at 865E3 instead of to the BASIC data structure at 005E. Moreover, the STX instruction wasn't executed, since it was consumed as an address. Thus, not only did a stray character get written to the screen, but data structures in memory didn't get updated. It's not surprising that the BASIC interpreter went out of control when it tried to run the program. 8C 1 186601 D3C9 5E 1 186602 D3CA 86 1 186603 865E FF 0 We concluded that a ROM was providing the wrong byte (8C) at address D3C8. This ROM turned out to be one of our replacements; the under-powered EPROM programmer had resulted in a flaky byte. Marc re-programmed the EPROM with a more powerful programmer. The system booted, but with much less RAM than expected. It turned out that another RAM chip had failed. Finally, we got the PET to run. I typed in a simple program to generate an animated graphical pattern, a program I remembered from when I was about 134, and generated this output: Finally, the PET worked and displayed some graphics. Imagine this pattern constantly changing. In retrospect, I should have tested all the RAM and ROM chips at the start, and we probably could have found the faults without the logic analyzer. However, the logic analyzer gave me an excuse to learn more about Ghidra and the PET's assembly code, so it all worked out in the end. In the end, the PET had 6 bad chips: two ROMs and four RAMs. The 6502 processor itself turned out to be fine.5 The photo below shows the 6 bad chips on top of the PET's tiny keyboard. On the top of each key, you can see the quirky graphical character set known as PETSCII.6 As for the title, I'm counting the badly-programmed ROM as half a bad chip since the chip itself wasn't bad but it was functioning erratically. The bad chips sitting on top of the keyboard. Follow me on Bluesky (@righto.com) or RSS for updates. (I'm no longer on Twitter.) Thanks to Mike Naberezny for providing the PET. Thanks to TubeTime, Mike Stewart, and especially CuriousMarc for help with the repairs. Some useful PET troubleshooting links are in the footnotes.7 Footnotes and references So 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.  ↩ Converting 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). The 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 TIME$ variable. (The PET's basic time count is the "jiffy", 1/60th of a second.) ↩ Technically, 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. ↩ Here'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 POKE statements. (It turns out that almost anything looks good with 8-fold symmetry.) The cryptic heart in the first PRINT statement is the clear-screen character. My program to display some graphics.  ↩ I 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. ↩ The PETSCII graphics characters are now in Unicode in the Symbols for Legacy Computing block. ↩ The PET troubleshooting site was very helpful. The Commodore PET's Microsoft BASIC source code is here, 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. Schematics of the PET are here. ↩↩

Linear components are pretty nonlinear -- and parasitics don't tell the whole story.

In week 15 of the humanities crash course, we started making our way out of classical antiquity and into the Middle Ages. The reading for this week was Boethius’s The Consolation of Philosophy, a book perhaps second only to the Bible in influencing Medieval thinking. I used the beautiful edition from Standard Ebooks. Readings Boethius was a philosopher, senator, and Christian born shortly after the fall of the Western Roman Empire. After a long, fruitful, and respectable life, he fell out of favor with the Ostrogothic king Theodoric and was imprisoned and executed without a trial. He wrote The Consolation while awaiting execution. Boethius imagines being visited in prison by a mysterious woman, Lady Philosophy, who helps him put his situation in perspective. He bemoans his luck. Lady Philosophy explains that he can’t expect to have good fortune without bad fortune. She evokes the popular image of the Wheel of Fortune, whose turns sometimes bring benefits and sometimes curses. She argues that rather than focusing on fortune, Boethius should focus on the highest good: happiness. She identifies true happiness with God, who transcends worldly goods and standards. They then discuss free will — does it exist? Lady Philosophy argues that it does and that it doesn’t conflict with God’s eternal knowledge since God exists outside of time. And how does one square God’s goodness with the presence of evil in the world? Lady Philosophy redefines power and punishment, arguing that the wicked are punished by their evil deeds: what may seem to us like a blessing may actually be a curse. God transcends human categories, including being in time. We can’t know God’s mind with our limited capabilities — an answer that echos the Book of Job. Audiovisual Music: classical works related to death: Schubert’s String Quartet No. 14 and Mozart’s Requiem. I hadn’t heard the Schubert quartet before; reading about it before listening helped me contextualize the music. I first heard Mozart’s Requiem in one of my favorite movies, Miloš Forman’s AMADEUS. It’s long been one of my favorite pieces of classical music. A fascinating discovery: while re-visiting this piece in Apple’s Classical Music app, I learned that the app presents in-line annotations for some popular pieces as the music plays. Listening while reading these notes helped me understand this work better. It’s a great example of how digital media can aid understandability. Art: Hieronymus Bosch, Albrecht Dürer, and Pieter Bruegel the Elder. I knew all three’s work, but was more familiar with Bosch and Dürer than with Bruegel. These videos helped: Cinema: among films possibly related to Boethius, Perplexity recommended Fred Zinnemann’s A MAN OF ALL SEASONS (1966), which won six Academy Awards including best picture. It’s a biopic of Sir Thomas More (1478—1535). While well-shot, scripted, and acted I found it uneven — but relevant. Reflections I can see why Perplexity would suggest pairing this movie with this week’s reading. Both Boethius and More were upstanding and influential members of society unfairly imprisoned and executed for crossing their despotic rulers. (Theodoric and Henry VIII, respectively.) The Consolation of Philosophy had parallels with the Book of Job: both grapple with God’s agency in a world where evil exists. Job’s answer is that we’re incapable of comprehending the mind of God. Boethius refines the argument by proposing that God exists outside of time entirely, viewing all events in a single, eternal act of knowing. While less philosophically abstract, the movie casts these themes in more urgent light. More’s crime is being principled and refusing to allow pressure from an authoritarian regime to compromise his integrity. At one point, he says I believe, when statesmen forsake their own private conscience for the sake of their public duties… they lead their country by a short route to chaos. Would that more people in leadership today had More’s integrity. That said, learning about the film’s historical context makes me think it paints him as more saintly than he likely was. Still, it offers a powerful portrayal of a man willing to pay the ultimate price for staying true to his beliefs. Notes on Note-taking ChatGPT failed me for the first time in the course. As I’ve done throughout, I asked the LLM for summaries and explanations as I read. I soon realized ChatGPT was giving me information for a different chapter than the one I was reading. The problem was with the book’s structure. The Consolation is divided into five books; each includes a prose chapter followed by a verse poem. ChatGPT was likely trained on a version that numbered these sections differently than the one I was reading. It took considerable back and forth to get the LLM on track. At least it suggested useful steps to do so. Specifically, it asked me to copy the beginning sentence of each chapter so it could orient itself. After three or so chapters of this, it started providing accurate responses. The lesson: as good as LLMs are, we can’t take their responses at face value. In a context like this — i.e., using it to learn about books I’m reading — it helps keep me on my toes, which helps me retain more of what I’m reading. But I’m wary of using AI for subjects where I have less competency. (E.g., medical advice.) Also new this week: I’ve started capturing Obsidian notes for the movies I’m watching. I created a new template based on the one I use for literature notes, replacing the metadata fields for the author and publisher with director and studio respectively. Up Next Gioia recommends Sun Tzu and Lao Tzu. I’ve read both a couple of times; I’ll only revisit The Art of War at this time. (I read Ursula Le Guin’s translation of the Tao Te Ching last year, so I’ll skip it to make space for other stuff.) Again, there’s a YouTube playlist for the videos I’m sharing here. I’m also sharing these posts via Substack if you’d like to subscribe and comment. See you next week!

Solar PV adoption in Pakistan, a sodium-ion battery startup closing up shop, Figure’s humanoid robot progress, an AI-based artillery targeting system, and more.

If You're Switched On, This is Paradise.