A2Pico is about Apple II peripheral cards based on the Raspberry Pi Pico. It consists of two parts:
- Several hardware reference designs
- A software library for projects based on A2Pico
- A2Pico TH card and design
- A2Pico SMD card and design
- A2Pico SMD card for the U.S.
- A2retroNET (https://github.com/oliverschmidt/a2retronet)
- Mouse Interface (https://github.com/oliverschmidt/mouse-interface)
- softSP (https://github.com/oliverschmidt/softsp)
- Appli-Card (https://github.com/oliverschmidt/appli-card)
- Super Serial Card (https://github.com/oliverschmidt/super-serial-card)
- Apple2-IO-RPi (https://github.com/tjboldt/Apple2-IO-RPi)
- Apple II Pi (https://github.com/oliverschmidt/apple2pi)
- Brutal Timer (https://github.com/oliverschmidt/brutal-timer)
- Bad Apple !!gs (https://github.com/oliverschmidt/bad-apple-iigs)
- A2Pico Demo (https://github.com/oliverschmidt/a2pico/tree/main/demo)
Every A2Pico firmware is flashed in the same extremly simple and foolproof way.
- A2Pico: It doesn't matter wether the card is inserted into an Apple II slot or not. Just make sure the Apple II turned off if the card is inserted.
- A2Pico2Lite: Make sure the card is not inserted into an Apple II slot.
- Press and hold the
BOOTSELbutton on the card. - Connect the card to a PC.
- Release the
BOOTSELbutton. A new drive,RPI-RP2orRP2350, will appear. - Copy the firmware
.uf2file to theRPI-RP2orRP2350drive, e.g., by drag & drop. - Disconnect the card from the PC. Done.
Soon after the introduction of the Raspberry Pi Pico in 2021 Glenn Jones and I started to experiment with directly connecting it to the Apple II slot bus. In 2022 I published a working Pico firmware on GitHub. Based on that we started to implement the A2retroNET project which I presented at KanasFest 2023 (https://youtu.be/ryiH8t4yIuw).
In the meanwhile Ralle Palaveev created his own A2Pico hardware for the firmware I had published before. In contrast to the hardware I presented on KansasFest, A2Pico consisted completely of through-hole components which allow for very easy DIY assembly. However, at that point my Pico firmware relied on the behavior of components only available as SMD fine-pitch packages. Therefore A2Pico had some functional limitations.
Considering the next steps after presenting the prototype at KansasFest I decided that my firmware should be accessible to the DIY community so I teamed up with Ralle to modify both hardware and firmware to enable full functionlity with through-hole components only and without any PLDs.
Ralle has now developed an A2Pico variant with SMD components for efficient automated assembly. Both A2Pico variants are 100% functionally identical.
Additionally I wanted to establish a software library that avoids duplication of low level code into the different firmware projects that all share the same hardware. The name A2Pico is now used for both the common hardware and the common software.
The introduction of the Raspberry Pi Pico 2 in 2024 brought true 5V tolerance, thus eliminating the need for the A2Pico's transceivers. However, the A2Pico also uses these transceivers to multiplex address and data lines onto the same GPIOs.
To take advantage of the 5V tolerance and truly eliminate the transceivers, the multiplexing of address and data lines also had to be removed. Without this multiplexing, however, there is a critical shortage of GPIOs. Therefore, the A2Pico2Lite does not have a Micro SD Card slot. Hence the Lite in its name.
In addition to the transceivers, the A2Pico2Lite also eliminates the A2Pico's AND gate. Therefore, it requires no ICs at all (apart from those on the Pico 2 module). This allows for the simplest possible DIY TH variant.
/DEVSEL, /IOSEL and /IOSTRB are combined to ENBL via an AND gate. A0-A7 and D0-D7 are multiplexed to the same GPIOs. D0-D7 direction is controlled by GPIO.
| GPIO | Usage |
|---|---|
| 0 | UART0 TX |
| 1 | UART0 RX |
| 2 | ENBL |
| 3 - 14 | A0 - A11 |
| 3 - 10 | D0 - D7 |
| 15 | R/W |
| 16 |
|
| 17 | RESET |
| 18 | /IRQ |
| 19 | SPI0 TX |
| 20 | SPI0 RX |
| 21 | SPI0 CSn |
| 22 | SPI0 SCK |
| 26 | TRX0 OE |
| 27 | TRX1 OE |
| 28 | TRX1 DIR |
There are four PIO state machines: addr, read, write and sync. The ARM core 0 is operated in a traditional way: Running from cached Flash, calling into the C library, being interrupted by the USB library, etc. However, The ARM core 1 is dedicated to interact with the addr, read and write PIO state machines. Therefore it runs from RAM, calls only inline functions and is never interrupted.
On the falling edge of ENBL, the addr state machine latches lines A0-A11 plus R/W and pushes the data into its RX FIFO. In case of a 6502 write cycle, it additionally triggers the write state machine. The ARM core 1 waits on that FIFO, decodes the address parts and branches based on R/W.
In case of a 6502 write cycle, the write state machine latches lines D0-D7 ~300ns later and pushes the byte into its RX FIFO. By then, the ARM core 1 waits on that FIFO and processes the byte.
In case of a 6502 read cycle, it's up to the ARM core 1 code to produce a byte in time for the 6502 to pick it up. As soon as it has done so, it pushes the byte into the read state machine TX FIFO. That state machine waits on its TX FIFO and drives out the byte to the lines D0-D7 until the rising edge of ENBL.
| GPIO | Usage |
|---|---|
| 0 | /IRQ |
| 1 |
|
| 2 - 13 | A0 - A11 |
| 14 - 21 | D0 - D7 |
| 22 | R/W |
| 26 | /DEVSEL |
| 27 | /IOSEL |
| 28 | /IOSTRB |
There are seven PIO state machines: devsel, iosel, iostrb, addr, read, write and sync. The ARM core 0 is operated in a traditional way: Running from cached Flash, calling into the C library, being interrupted by the USB library, etc. However, The ARM core 1 is dedicated to interact with the addr, read and write PIO state machines. Therefore it runs from RAM, calls only inline functions and is never interrupted.
On the falling edge of /DEVSEL, /IOSEL or /IOSTRB, the devsel, iosel or iostrb state machine triggers the addr state machine. The addr state machine latches lines A0-A11, D0-D7 plus R/W and pushes the data into its RX FIFO. In case of a 6502 write cycle, it additionally triggers the write state machine. The ARM core 1 waits on that FIFO, decodes the address parts and branches based on R/W.
In case of a 6502 write cycle, the write state machine latches lines D0-D7 ~300ns later again and pushes the byte into its RX FIFO. By then, the ARM core 1 waits on that FIFO and processes the byte.
In case of a 6502 read cycle, it's up to the ARM core 1 code to produce a byte in time for the 6502 to pick it up. As soon as it has done so, it pushes the byte into the read state machine TX FIFO. That state machine waits on its TX FIFO and drives out the byte to the lines D0-D7 until /DEVSEL, /IOSEL and /IOSTRB are all high.