The Problem Wasn’t Knowledge — It Was Entry Cost
I’ve always wanted to tackle low-level hardware, but the problem was never motivation—it was the high entry cost. Getting oriented enough to begin would have taken weeks or months of reading and false starts, and at this stage in my career, I don’t have unlimited time. Without AI, the orientation cost for this hobby project would have been too high to attempt.
How This Escalated So Quickly
I started out wanting to write a little Atari 7800 code. Then I heard the TIA sound chip and had the immediate, irrational reaction of a part-time musician: this will not do!
Hear it for yourself: Donkey Kong Atari 7800 Longplay
The Atari 7800 had a great video system, but the designers did not have any room left on the PCB for sound. They had planned to use inexpensive on-cart sound, even adding an audio input line on the cartridge, but only two games used it due to higher production costs.
Once you notice a limitation you can’t unhear, you either accept it… or you disappear into a sound rabbit hole. And this is where the whole thing started to feel a little like the South Park World of Warcraft episode.
If you’re not familiar with it: the kids want to actually win the game, but there’s an almost impossibly powerful character blocking their progress. They can’t beat him head-on, so they spend hours grinding low-level enemies just to level up enough to have a chance. That’s more or less what happened here. At that point, the original goal was effectively on pause and I was grinding a skill tree I never planned to unlock. I wasn’t really “playing the game” anymore — I was fighting bugs in the forest just to level up.
This Started as a Pico Project
Initially, I planned to use a Raspberry Pi Pico or Arduino to emulate classic PSG sound chips, assuming they were no longer manufactured. However, I discovered that YM2149 clones are still actively produced and can be had for about $2 each. This realization shifted the project’s focus from software emulation to hardware integration, transforming it into a more compelling challenge of wiring real silicon into the system. I see the YM2149 PSG (Programmable Sound Generator) as a bridge to the Atari ST, its big brother. This gives us the Atari ST sound ecosystem, enabling the use of all its tools and sound effects on the 7800. The chip is also period-accurate for the console’s timeframe.
The Future of the Pivot: Now that I have a real PSG working, I may revisit the Pico someday. I already have a POKEY emulated on a Pico, and in theory, I should be able to use what I have done with the YM clone, but that is for another time.
GALs, Latches, and the Perils of the “Quad Write”
I eventually settled on using a GAL (Generic Array Logic) to handle the ROM (Read-Only Memory) decoding and capture the incoming commands for the YM2149. To a software guy, a GAL is a beautiful revelation—it’s essentially physical code. You write your logic equations, and the silicon executes them. I could have brute-forced my way through the GAL eventually, but the orientation cost was steep.
The real wall, however, was the need for a latch to stabilize the signals heading toward the YM2149. This is where my lack of a “Day 1” EE background really showed. Back in the 80s, an engineer would have possessed a shared mental map of which logic ICs to grab for address decoding. In the modern era, that map is largely a relic. AI served as my translator, taking my software-centric problems and reframing them within that historical, physical context.
Before I found the right path, I was attempting to “bit-bang” the chip using what I dubbed “Quad Writes”—essentially slamming the bus with data and praying it would stick. It reached the most dangerous of engineering states: it almost worked. It was flaky, unreliable, and frustrating. The AI acted as a Librarian of Lore, filling in the gaps I didn’t even know existed. I didn’t have the word “latch” in my vocabulary, nor did I realize the 6502 and the YM were speaking entirely different “physical languages.”
The AI pointed me toward the 74LS373 transparent latch, and suddenly, everything clicked. It acts as a physical “save button,” holding the address steady while the data pulses through. Do we absolutely need it? I suspect so, but more importantly, it works. Once I had the terminology to bridge the gap, my three decades of engineering experience finally had the traction it needed to take over.
The “Silicon Click”: Touching the Fabric of Reality
I want to be clear about something that would be “Day 1” common sense for an Electrical Engineer, but for a software guy like me, was an absolute mind-blowing revelation. I’ve spent 30 years moving bits around in memory as abstractions, never really looking at the physical layer. At the start of this, I didn’t even know what the acronym TTL (Transistor-Transistor Logic) actually meant in practice.
It might sound embarrassing to a pro, but I had this realization that felt like seeing the code in The Matrix. I looked at the board and thought: ‘Wait… 8-bit system. 8 copper lines on the bus. Binary 0 to 255. Are those the literal binary lanes I’ve been typing into my code for three decades?’
Yes. Yes, they are. Suddenly, those traces weren’t just “wires”; they were the physical manifestation of a byte. A High signal (5V) is a 1; a Low signal (0V) is a 0. Watching a 6502 assembly instruction like STA $A000 trigger a physical electrical pulse across those eight lanes is the closest a developer can get to reaching into the grid—without being sent there by a laser Tron style!
AI: A Tool for Time Compression and Challenging Assumptions
AI served as a tool for time compression, reducing the overhead required to navigate complex historical hardware, but you cannot blindly follow every suggestion. I challenged its outputs by asking “how” and “why” to ensure a genuine understanding of the engineering principles involved. More times than I can remember the AI responded “You were right to challenge me”. Maintaining the responsibility to think is critical; pasting answers without comprehension sets up future failure, whereas using AI to bridge knowledge gaps allows for a deeper, more efficient learning process.
A Community Project: The Lab Doors are Open
This project is, and will remain, Open Source. I’ve reached a point where I feel comfortable opening the doors. There is nothing quite like shouting from the mountains “I am working on this!” only for real-life responsibilities to step in and steal your momentum. I didn’t want this to be another “projected” idea; I wanted it to be a reality.
I spent a significant amount of time searching for an existing YM2149 implementation for the 7800, and I couldn’t find one. I have also integrated support for YM2149 into my custom forks of A7800 and js7800, so you can hear the results in your browser right now. I’m still deep in the woods, but it is working. The bits are hitting the silicon and music is playing.
This system relies on a suite of C# tools I built to generate music from YM and VGM files, allowing us to “stream” 16-bit sound to the 8-bit 7800, providing a stress test for the YM2149/Atari 7800 combo. I want to be clear that these are alpha level C# tools, just enough to get sound working in a 32k EPROM (Erasable Programmable Read-Only Memory). I may completely revisit this down the road.
The Full Circle
In my teens, this is the kind of project I dreamed about doing. Back then, the gap between writing a few lines of code and actually understanding the physical pulse of the machine felt like an unscalable wall. It’s been an incredible experience to revisit this late in life and finally build what my younger self could only wonder about—albeit a few years later! I crossed a boundary I’d avoided for decades, and I heard the bits move through the wires. Now I am off to build my first PCB!
The Lokey 7800 YM Project:
https://github.com/jbsohn/lokey-7800-ym
Experience the Atari 7800/YM2149 in your browser:
https://jbsohn.github.io/js7800-ym-player/
My YouTube Channel (progress videos):
https://www.youtube.com/@johnsmusicandtech