Pico‑6522 Bridge: Real 6522 Smart Peripheral Auto Handshake

[noneya]

Hi everyone,

I’ve been a member here for a few years now, and I wanted to share a project in hopes of giving something back to the community. This started as a small personal tool and unexpectedly grew into something much larger. I’ve now released it publicly in case it’s useful to others.

GitHub repo:
https://github.com/DonaldMoran/pico-6522-bridge

----------------------------------------------------------------------
How this project started
----------------------------------------------------------------------

This whole thing began with a very simple goal: I just wanted an easier way to get my 6502 assembly programs onto my machine without fumbling with SD cards (though I’ve enjoyed bit‑banging those), waiting on slow copy/paste transfers, or dealing with XMODEM (which I also enjoyed exploring). Every time I made a change, the workflow slowed me down.

Once I had a basic file‑transfer mechanism working through a Raspberry Pi Pico, I realized I could also use it to demonstrate that my 6522 emulation — via my 6502 Pico emulator — was behaving correctly. From there, the project grew almost by accident.

I found it surprisingly convenient that I didn’t need to implement a filesystem on the 6502 side at all — instead the Python 3 file_server.py handled everything by exposing a network file share behind the scenes (i.e. a folder on the machine I write my assembly on). That meant I could write code, assemble it into something like X.BIN, and from my NETDOS environment simply type “X” as a command. The system automatically loads (bloads) and executes X.BIN without any extra ceremony. That workflow turned out to be so smooth that I kept extending the idea.

----------------------------------------------------------------------
Smart Peripheral Mode (Real 6522 Hardware)
----------------------------------------------------------------------

One of the most interesting directions this project took is the smart peripheral mode, where the Pico connects to a *real* 6522 VIA and acts as an intelligent co‑processor for a 6502 system.

The 6502‑side assembly is written in ca65, and the pico bridge uses the 6522’s
automatic handshake mode (CA2 pulse‑on‑write) for parallell communications.
The GitHub repo is built around automatic handshake, though I have also
tested manual handshake mode offline (while fighting with the "ghost byte" in auto mode , and the protocol behaves correctly in
either configuration. I stuck with automatic handshake mode for the theoretical speed boost, and the challenge of the "ghost byte" at transaction end, which I beat /solved elegantly I think.

In this mode, the Pico:

- responds to VIA handshakes
- handles CA1 and CA2 or CB1 and CB2 correctly
- provides a clean, deterministic parallel interface
- exposes a command‑driven API to the 6502

This allows a 6502 system to access modern capabilities (filesystem, Wi‑Fi, external commands, dynamic loaders, etc.) through a real VIA chip, without needing any custom hardware beyond the Pico and the VIA.

----------------------------------------------------------------------
About the emulator
----------------------------------------------------------------------

A special thanks goes to jfoucher, whose original emulator provided the foundation for this work. I’ve modified it heavily along the way, but his contribution was essential in getting this started.

The emulator work wasn’t originally meant to be a standalone project — it was simply a way to make firmware development easier for my *real* breadboard 6502 computer. Instead of constantly flashing hardware or wiring up test circuits, I could iterate quickly in the emulator and then move the same code over to the physical machine once it was stable.

Over time, the emulator grew significantly. I’ve had it working with LCDs, bit‑banging SD cards, and various other experiments. More recently I added proper support for CA1, CA2, CB1, and CB2, and made sure they behave as expected. I’m also reasonably confident that the 6522 timers work at least to a practical degree for typical use cases.

The emulator ended up becoming a surprisingly powerful development tool, even though it started as a convenience layer for my hardware work.

----------------------------------------------------------------------
Two System Builds: NETDOS and Microsoft BASIC 2.0
----------------------------------------------------------------------

The project now includes two complete builds that run on top of the bridge:

1. NETDOS (my own disk operating system)
This is a DOS‑like shell environment I wrote specifically for this project. It uses the Pico as a smart peripheral to provide:
- directory listings
- file loading and execution
- command dispatching
- dynamic external commands

NETDOS lets me write code, assemble it into X.BIN, and simply type “X” at the prompt to run it instantly. No SD cards, no serial transfers, no XMODEM — just edit, assemble, run.

2. Microsoft BASIC 2.0 Integration (from the mist64 reconstruction)
There is also a build that integrates Microsoft BASIC 2.0 using the excellent mist64 reconstruction. In this version:
- LOAD works
- SAVE works
- CD works
- DEL works

This gives BASIC a modern, DOS‑like backing store without needing a real disk drive or filesystem on the 6502 side. BASIC programs can be loaded and saved through the Pico’s virtual filesystem, and the environment feels surprisingly natural.

----------------------------------------------------------------------
What the project does now
----------------------------------------------------------------------

The Pico emulates a 6522 VIA and exposes a command‑driven interface that lets a 6502 system access:

- filesystem operations
- directory listings
- Wi‑Fi configuration
- external commands
- dynamic command loading
- binary dispatching
- and more as the library evolves

The goal is to provide a clean, extensible bridge between a 6502 machine and modern peripherals or network services.

----------------------------------------------------------------------
What’s available
----------------------------------------------------------------------

- Full source code (MIT licensed)
- A growing command library
- Documentation and examples
- Pre‑built binaries for convenience (UF2 + BIN)
- A clean GitFlow structure for contributors

----------------------------------------------------------------------
Dual‑Pico Wiring Diagram (Emulator ↔ Bridge)
----------------------------------------------------------------------

Code: Select all

       HOST PICO (Emulator)                     BRIDGE PICO (Pico W)
    +-----------------------+                 +-----------------------+
    |                       |                 |                       |
    | GP0  (PA0) <--------->| [DATA BUS] <--->| GP6  (PA0)            |
    | GP1  (PA1) <--------->| [DATA BUS] <--->| GP7  (PA1)            |
    | GP2  (PA2) <--------->| [DATA BUS] <--->| GP8  (PA2)            |
    | GP3  (PA3) <--------->| [DATA BUS] <--->| GP9  (PA3)            |
    | GP4  (PA4) <--------->| [DATA BUS] <--->| GP10 (PA4)            |
    | GP5  (PA5) <--------->| [DATA BUS] <--->| GP11 (PA5)            |
    | GP6  (PA6) <--------->| [DATA BUS] <--->| GP12 (PA6)            |
    | GP7  (PA7) <--------->| [DATA BUS] <--->| GP13 (PA7)            |
    |                       |                 |                       |
    | GP11 (CA2) ---------->| [REQUEST]  ---->| GP14 (Input)          |
    | GP10 (CA1) <----------| [ACK]      <----| GP15 (Output)         |
    |                       |                 |                       |
    | GND  -----------------| [COMMON GND] ---|--- GND                |
    |                       |                 |                       |
    +-----------------------+                 +-----------------------+

----------------------------------------------------------------------
System Architecture Block Diagram
----------------------------------------------------------------------

Code: Select all

                   +------------------+
                   |     65C02 CPU    |
                   |                  |
                   |  - Executes user |
                   |    programs      |
                   |  - Issues I/O    |
                   |    requests      |
                   +---------+--------+
                             |
                             | 8-bit data + control
                             |
                   +---------v--------+
                   |     6522 VIA     |
                   |                  |
                   |  PA0–PA7  <----> Data Bus
                   |  CA1/CA2 <-----> Handshake
                   |  CB1/CB2 <-----> Optional HS
                   |                  |
                   +---------+--------+
                             |
                             | Parallel smart-peripheral link
                             |
                   +---------v--------+
                   |  Raspberry Pi    |
                   |      Pico W      |
                   |  (Smart Peripheral)
                   |                  |
                   | - Implements VIA |
                   |   protocol layer |
                   | - Handles FS,    |
                   |   Wi‑Fi, NETDOS, |
                   |   BASIC I/O, etc |
                   | - Loads/executes |
                   |   external cmds  |
                   +---------+--------+
                             |
                             | High-level operations
                             |
        ---------------------------------------------------------
        |                        |                             |
+-------v-------+      +---------v---------+        +----------v----------+
| Virtual FS    |      | External Commands |        |   Wi‑Fi / Network   |
| (file_server) |      |  (X.BIN loaders)  |        |   (optional)        |
| - LOAD/SAVE   |      | - Dynamic loading |        | - Future expansion  |
| - CD, DEL     |      | - Command dispatch|        | - Remote FS access  |
+---------------+      +-------------------+        +----------------------+

----------------------------------------------------------------------
A personal note
----------------------------------------------------------------------

This forum has given me so much over the years — knowledge, inspiration, and a sense of community. I hope that in some small way this project (and others I contribute in the future) can give something back. Thank you all for the shared technical wisdom that has kept the 6502 world alive and thriving.

— Don

[BigEd]

Looks great - thanks for sharing! And thanks for the ascii block diagrams - for me, they help a lot to give an idea of what is connected to what.

> - provides a clean, deterministic parallel interface

Excellent. You've avoided, perhaps, the distraction of trying to cope with the other case - timeouts, checksums, retries, watchdogs. It's good to scope things and design things so you have a clean channel, and you can build higher level protocols on top of that.

[GARTHWILSON]

BigEd wrote:

And thanks for the ascii block diagrams

and Ed posted a way to make nice pictures out of such diagrams, at viewtopic.php?p=35519#p35519 .

[No True Scotsman]

Hi, Don!

I missed this post before, but i independently stumbled upon your Github yesterday whilst researching a number of I/O related topics. I almost went with a Pico W in my project, before I realized the Picos I bought aren't of the "W" variety.

[noneya]

Hi No True Scotsman,

I’ve been reading through a couple of your threads and like the perspective you bring. I saw the portable‑6502 idea and the ESP32 terminal angle, and it reminded me of a project I put on the back burner: a Pico‑based 640×480 color HDMI terminal with 80 columns. Even had small sprites going. I should probably dust that off and get it into shape for GitHub.

This past week (well… a little over a week), I’ve been working on another 6522<>Pico link, this time using PIO for the communication. Both directions run through state machines, and I got it fully working about an hour ago. So far it seems rock solid - no timing tricks, just clean byte transfers. I’ll be posting this smaller, clearer PIO example on GitHub soon, and update this thread when it’s out there.

The one you stumbled across was originally meant to be a small example of how to tie a Pico into a 6522, but it kind of spiraled into a full project. Interesting in its own way, but if someone just wants to understand the communication, it’s easy to get lost in the NETDOS bits, jump tables, BASIC hooks, and so on.

With the new handshake in place, I’m planning to use the Pico for things like ROM banking and other helper tasks. Even the non‑WiFi Pico has a lot to offer once the link is solid.

Looking forward to seeing where you take your build.

[No True Scotsman]

The desired end product being a portable device, it wouldn't do to try to stuff everything and the kitchen sink into the case. I have to avoid function creep, and try to do much with as little as possible. Many things can be optional accessories, rather than built-ins. The Model 100 did an amazing amount of stuff for its size and given the constraints of 8-bit computers of the era, by exploiting hardware features in novel ways. It's my all-time favorite computer, but I've learned from other designs as well.

For instance, every user port cartridge I owned for the Commodore 64 was some kind of hardware serial interface, e.g., a modem or RS-232C port. On the new C-64 Ultimate, the opening where the user port used to be is filled with Ethernet and USB ports. (The old user port is still accessible via pin headers on the motherboard.) That's where my idea for pluggable serial adapters came from. USB, MIDI, LoRa, RS-232C, RS-485, cassette... all of these interfaces could be on little cartridges that plug into an onboard UART.

[BigEd]

> I have to avoid function creep

Sometimes this feels like the most challenging challenge of all!

[No True Scotsman]

Well, I'm going to take a modular approach and experiment with various things and see which fit the final product best. For instance, I haven't decided whether the audio system will be a DAC or an SAA1099. Both circuits would have the same output buffers, LPFs, volume control, and amplifier. The main difference would be how many registers there are to write to. Maybe the sound chip could be pluggable.

[barnacle]

BigEd wrote:

> I have to avoid function creep

Sometimes this feels like the most challenging challenge of all!

"How did this circuit get so many components?"
"One sprint meeting at a time..."

Do I sound cynical?

Neil