KIM, Claude & Yaht-C
The KIM-1 was a 6502-based, single-board computer that was released fifty years ago. About the size of a clipboard… I suppose you might think of it as the first Arduino.
My own obsession with the computer began shortly after it appeared. I was maybe 12 years old when I was in a bookstore that had a small section of TAB books on electronics. One book caught my eye: “How to Build a Computer-Controlled Robot” by Tod Loofbourrow. The robot that Tod builds in the book very prominently featured this new, KIM-1 computer right on the upper deck. “What is this wonderful thing?” I wondered.
I was still too young and dumb though (and with no tutelage). Never mind that the price back then of $245 for the machine meant I was never going to be able to afford one. Still, the machine struck something within me that persisted for decades.
Loofbourrow is an unusual last name, I think. So when I was working at Apple as an engineer and came across a Loofbourrow in regards to a bug report or some such, I was immediately curious if this person was related to the Tod Loofbourrow who had written that book that had so intrigued me as a kid. He was another Apple employee so I emailed him and, sure enough, Tod was his brother. Smart family…
KIM-like
There was a small window in time, when eBay was new, where I might have picked up a vintage KIM-1 for a few hundred dollars—perhaps for even less. Sadly, those times have passed. When they do show up for sale, they fetch four figures.
Nonetheless, a number of hobbyists since have introduced a handful of KIM-1 “clones”. The clones have run the gamut—some based in fact on Arduino’s running emulation software. The ones that appeal to me try to match the original hardware of the KIM-1 as close as possible. There are however a number of chips on the original that are sadly as unobtainium as the KIM-1 itself. Clever hobbyists though have managed by substituting with the best modern equivalents they can find.
There is even a KIM-1 emulator that runs in your browser.
Right now (though a little pricey) I think the best, most faithful KIM-1 clone out there is the PAL-2 (the cost of shipping is a killer). I picked up one of these kits when they were first introduced (I might have #6 or something like that) and I have thoroughly enjoyed finally getting to play with my childhood dream machine.
While you 100% can enter programs into the PAL-2 (and other KIM-1 clones) with the hexadecimal keypad, all the modern clones also have a means to connect to them over serial—allowing you to use a terminal-like application on your regular computer to interact with them (and of course load software). While many clones may support something like the original cassette tape interface, I am not aware of anyone trying to save/load programs that way in 2026.
A great site for all things KIM-1 is Hans Otten’s Retro Computing site. And, related, he has a nice write-up and overview of the PAL-2.
The First Book of KIM
What do you do with a KIM-1?
I suppose, for me, there is something appealing about the relative simplicity of these old 8-bit machines. Programming them generally involved writing in 6502 assembly language—and there were only 56 instructions. An accumulator and an X and Y register were about all you had. No floating point (no multiply even!).
When the KIM-1 sold new back in the 70’s, it came with three manuals: The KIM-1 User Manual , The Hardware Manual , and The Programming Manual. These are authoritative, but not terribly fun. Instead, The First Book of KIM is probably that missing manual.
In addition to utility programs, The First Book of KIM contains 28 games (well, entertainment programs—most of which are games). For each of the programs, there is machine code and accompanying assembly. Many programs also include a hex dump to make it easier to just grind through entering bytes from the KIM-1 keypad.
Rather than hand-entering the hex though, the KIM Monitor (which is also on the PAL-2) has a couple of means to “load” a program. Loading in the 70s generally meant from a cassette tape or from paper tape over Teletype®. Fortunately, with a serial connection to your KIM-1 or clone, you can load a program by simply pasting text, in paper tape format, into your serial/terminal program. In order to keep from overwhelming the KIM-1 with a rush of pasted text, you have to specify a slow cadence for transmitting the bytes over the serial connection (I use CoolTerm on the Mac and it has settings where you specify this).
Here is an example of a small paper tape program. The last line is a checksum.
;180200A97F8D4117A93F8D4317A9E18501A9AC8502203702A91E850987
;18021800A200A0098C4217BD69028D4017206102E8C8C8E006D0ED0A0C
;180230C600D0E54C1202A205204D022907C907B0F7A8B96F029D6909BA
;18024802CA10ED60A008460266019006A50249B4850288D0F1A5010992
;1602606098A0C888D0FDA8600000000000000102040810204006B4
;0000050005
KIM, meet Claude…
I asked Claude what a modern 6502 assembly workflow would look like and he (?) suggested ca65 for the assembly and ld65 for the linker. Additionally, srec_cat is a tool that will generate the paper tape format from the binary. In a Github repo, I detail the steps and pieces needed for setting up a 6502 workflow on MacOS.
So I thought I would have a go at selecting the individual programs from The First Book of KIM and see if I could assemble/link them. But it seems the assembly in The First Book of KIM is not of a form that conforms cleanly to modern (ha ha) 6502 assembly practices. But of course I could lean on Claude again here to clean up the code.
And so Claude did. There are special routines in KIM’s ROM for things like lighting up the segments of the LED displays, reading the keypad—these were given equates in an include file and the equate substituted where appropriate in the cleaned-up assembly. Comments now all had the correct syntax. Lower-case was used in many placed instead of the ALL CAPS so popular back then…
The assembly that Claude produced absolutely assembled and linked—a paper tape then being generated as the final step. When I pasted the paper tape contents into CoolTerm and my PAL-2 loaded it, the program ran great.
Unsurprisingly, Claude found plenty of OCR errors from the program text I had copied from The First Book of KIM PDF. And he was quite good at it—knowing of course the context: that it was 6502 assembly, so the letter “O” that should have been a zero “0”, never slipped by.
I was surprised that he found inconsistencies in the code though—where the hex had specified one op-code but the assembly another. And then Claude would work out which of the two was correct by seeing how the two op-codes would affect the logic of the program.
That wild LLM even found bugs in the code itself—telling me about a bug in WUMPUS (Hunt the Wumpus)
Every time I put something forward to Claude, I am still somehow amazed that this… network of connections and weights can pull it off. I feel like I am always testing LLM’s. Like, “Hmm, I wonder if they can do this”.
An Idea…
There are some pretty clever games for the KIM-1 in the book. WUMPUS has alphanumeric text (of a sort—I mean, considering 7-segment LEDs) scrolling by to tell you which tunnel you are in, whether you hear the Wumpus… FARMER BROWN uses the 7-segment LEDs to display sort of stick-figure representations of a handful of animals.
While porting the programs, playing with them, I had a sudden thought that the classic dice game, Yahtzee, would be a perfect fit for the KIM-1.
I did a little looking around the internet but did not find Yahtzee for the KIM-1. So, naturally, I thought of Claude.
There is a part of me that wanted to try to write it myself. I do want to try my hand at a 6502 assembly program someday. Anyone that knows me though knows how many irons I have in the fire. Maybe Yahtzee would have been a little too ambitious too for a first 6502 program?
The experience of directing Claude to write the code though did give me a few interesting thoughts. It occurred to me that I still could write the game from scratch. I honestly didn’t look closely at his code, so it’s not like I would be cheating.
I can look at the time with Claude on it as a kind of round of fast prototyping. I was able to try out ideas quickly with Claude driving. Even if I get ambitious enough to have a go at it on my own, I know exactly what I am aiming for—and that it will work.
Yaht-C
I won’t bore you with the back and forth between myself and Claude. I think some people believe there is a “magic prompt” you invoke to get an LLM to work its magic, so let me thoroughly dispel that. I specifically directed Claude to work on Yahtzee that same way that I write code myself. I told him the idea of the whole program, but then directed him to just try to get a state machine up where 5 die rolls would be displayed and I, the user, could toggle on and off which ones to re-roll by entering the index of the dice on KIM-1’s keypad. (I detail a little more some of the prompts in a write-up I did for the PAL-2 google-group.)
As he delivered a piece of the code, I would assemble/link it and try it on my PAL-2. I would suggest a change, or we would move on to the next step.
I supplied Claude with some well-established code for generating random numbers on the KIM-1 and so in the next iteration the dice would now come up random.
I wanted the dice to “animate” so suggested a 4-segment box animate up and down for each die before the die roll is finally revealed. I also suggested the dice be revealed sequentially and with a slight delay—not all at once.
And so, bit by bit, prompt by prompt, we finally got a working game.
When the computer scores a hand, I had suggested names for each of the tricks that could be displayed with four of the 7-segment displays. So a Full House might be displayed as “FULL” on KIM-1’s LEDs. A Small Straight, maybe “SStr”. (You have to imagine the characters as they might be represented on a 7-segment LED of course.) I was unsure what to do with Yahtzee, and I think it was Claude that then came back with something like “yAht”. It was from this that I decided upon Yaht-C for the program name. You can even spell it all out using all six of KIM-1’s LED displays.
Surprises
Although I have been playing with LLMs for over a year now (has it been two?) Claude still surprised me.
I had decided that, given the limited user-interface of the KIM-1, the computer would score each player hand without any input from the user. A final roll of the dice giving: {6, 6, 6, 4, 4}. A full house? Sure. Unless the player already claimed the full house earlier in the game. Maybe a 3-of-a-kind, or “Sixes”, or “Chance”?
I thought the best strategy for the computer was to try to score each hand for all 13 tricks (modulo the ones that the player had already scored/used). For the aforementioned roll, evaluating it for a Yahtzee or a 4-of-a-kind would return zero points. But Claude determined that this strategy would award the roll to Chance or Three-of-a-kind rather than full house because the point value would be greater. A Full House though is less statistically likely though than the other two—less likely to come up again (and the player would have to then take a zero or “scratch” the trick).
Claude suggested a “margin rule” that compared the score for a given trick to the typical score for that trick (I presume that extra weight would be given to tricks that out-scored the norm). I countered with the suggestion we look at the probability of each trick and assign the points to the “rarest” trick that returns non-zero points for the hand.
Claude then “ran” (simulated) 20,000 games and compared the scores when using one algorithm versus the other. Wow. I am not likely to have invested in doing that on my own. (I don’t remember how we ultimately came down in the end, but I let the simulations be the guide.)
Another surprise was the degree to which he watched memory page boundaries and potential stack depth in order to ensure that the program would slot into the small memory footprint fo the KIM-1. At times, when things got tight, Claude would shuffle code between “zero page” and page one or two.
After announcing that Claude had used 511 of the 512 bytes allowed for a certain memory page, he went in and optimized the code in order to make room for the new code that represented the final score state. Claude mentioned combining the Small Straight and Large Straight code into a single subroutine. This, I thought, is something I think a human would have done from the outset—knowing the memory constraints of the KIM-1. (In fact, 3-of-a-Kind, 4-of-a-Kind, and Yahtzee could likely overlap but, as I say, I haven’t even really looked at his code. But if someday I implement the game myself…)
Closer
The code for Yaht-C and my and Claude's work to modernize the programs in The First Book of KIM are all in my GitHub repo that I referenced earlier.
Additionally, I am wrapping up a complete re-layout of The First Book of KIM that will include the fixes that Claude found. My initial motivation though was to simply have the book in a format that would not embarrass a physical print-run (that is, not look like a scan of an out-of-print book). I have been unable to restrain myself from a little modest cleanup so that the code from program to program has a more consistent format. I'm sticking with the classic IBM Selectric, mono-space, Elite font, but hopefully I am getting the text-wrapping a little more consistent (word breaks were clearly chosen by hand—and unevenly).
