Analyzing The 6502 With Python And Cheap Dev Boards

The Before Times were full of fancy logic analyzers. Connect the leads on these analyzers to a system, find that super special ROM cartridge, and you could look at the bus of a computer system in real time. We’ve come a long way since then. Now we have fast, cheap bits of hardware that can look at multiple inputs simultaneously, and there are Open Source solutions for displaying and interpreting the ones and zeros on a data bus. [hoglet] has built a very clever 6502 protocol decoder using Sigrok and a cheap 16-channel logic analyzer.

This protocol decoder is capable of looking at the ones and zeros on the data bus of a 6502-based computer. Right now, [hoglet] able to stream two million 6502 cycles directly to memory, so he’s able to capture the entire startup sequence of a BBC Micro. The hardware for this build was at first an Open Bench Logic Sniffer on a Papilio One FPGA board. This hardware was changed to an impressively inexpensive Cypress FX2 development board that was reconfigured to a 16 channel logic analyzer.

The software stack is where this really shines, and here [hoglet] documented most of the build over on the stardot forums. The basic capture is done with Sigrok, the Open Source signal analysis toolchain. This project goes a bit further than simply logging ones and zeros to a file. [hoglet] designed an entire 6502 protocol decoder with Python. Here’s something fantastic: this was [hoglet]’s first major Python project.

To capture the ones and zeros coming out of a 6502, the only connections are the eight pins on the data bus, RnW, Sync, Rdy, and Phy2. That’s only twelve pins, and no connections to the address bus, but the protocol decoder quickly starts to predict what the current program counter should be. This is a really fantastic piece of work, enabling an entire stack trace on any 6502 computer for less than $20 in parts.

10 thoughts on “Analyzing The 6502 With Python And Cheap Dev Boards

  1. This is the sort of thing that got me into Python! I wanted to run an old BBC Micro program I had transcribed, but the emulator didn’t support text files. So I used some Python code to transform it into cassette dumps, it worked quite nicely, I revived a program unexecuted for years, and I’ve used Python almost daily ever since. It’s a much longer dramatic story, but I’ve forgotten much of it.

  2. If $16 (price from the linked british shop) are impressively inexpensive, what qualifying adjectives coud used with the exact same board that can be purchased direct from China with free shipping at Ali or Ebay for $4 ?!

    Now the blog entry title insists on this cheap board, (even if this board is nothing specific to this 6502 decoder and just happen to be supported by sigrok and described on their wiki as a Salae Logic clone since 2011) but at the same time, shows a setup that connects to the analyzed on-board 6502 CPU with a Pomona DIP-40 test clip (to reply to Tomo’s comment)
    Those are some difficult to find, “impressively” expensive pieces of platic with pins and springs… around $50 for their (still available) 3M equivalents.

    Then a better title would be “Analyzing The 6502 With Free Software, Cheap Dev Boards and Rare Pricey Test Clips !”

  3. I’m always a little nervous about these low cost “logic analyzers”. They often lack the trigger mechanisms necessary for tracking down a hardware error. But more so, in this case, the limited and narrow amount of bits captured…just the data bus and a few control lines… seems lacking.

    As described, the address is inferred or predicted based on data bus activity, and that sounds like a dangerous leap of faith. I suppose if you have working hardware and merely wish to capture code execution, it will work. But for tracking down a hardware malfunction or design error, you likely need a 32-bit capture for an 8-bit micro with 16-bit address bus.

  4. A long time go in a job long past, we had an HP logic analyzer. We were developing boards with Analog Devices DSPs and the board was designed with headers around the DSP chip to hook the analyzer to all the data, address, and control lines. We could load up a special program add-on to the HP analyzer that would capture the whole bus and do a complete reverse assembly on the data and show the actual code being run. I thought it was a really impressive thing and ever since I’ve thought about making my own similar system. These days it wouldn’t be hard to do, but also wouldn’t be that useful since so few devices run software or firmware from external memory.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.