I wanted show something that I had mentioned in some other thread. How portable CircuitPython Code can be. Adafruit has a version of Breakout with sound for the Metro rp2350 and the Fruit Jam. All that is needed is to make some tweaks to present a display object and add a keyboard object. Then Bobs your uncle. I was able to also port Zork and Minesweeper doing the same thing. Did I mention it has sound affects on the PicoCalc.
This version is unique in that 4 AI’s helped write it and modify it. No less than 4 Grok3, Copilot, Claude, and OpenAI Codex.
“”"
SPDX-FileCopyrightText: 2025 Anne Barela for Adafruit Industries
SPDX-License-Identifier: MIT
Breakout
Original GitHub - davepl/Grok3-Breakout by Grok3
Converted to CircuitPython by GitHub Copilot 2/20/2025
Further improved with keyboard controls via serial input, sound
with Claude Sonnet 3.7
Further improved with PicoCalc keyboard controls and sound
with OpenAI Codex, That’s Four AI’s that created this game on the picocalc.
“”"
This has some other benefits. The whole CircuitPython community can help with writing code. The other is It is mainstream enough the AI’s can actually help with writing code. So you Vibe coders, and you know who you are, can make real quality apps. Or at least use other CircuitPython Apps the exist.
yes but It does want more heap. The deep library of CircuitPython does require more resources. I am using the Pimoroni pico plus 2w. it makes out at 8meg heap and 16meg of flash. the pico cant handle more than that. if you upgrade adafruit has them in stock. the pi pico 2w only has 520k of heap. and the onboard PSRAM of the picocalc does not help with framebuffers since it needs to be in heap if you want to blit to the screen.
Here is a new clock I have. With Westminster chimes. B-)
How’s the performance with using the Pico Plus 2W’s PSRAM for CircuitPython’s heap? With zeptoforth on the PicoCalc I opted to just use the Pico Plus 2(W)'s PSRAM for a RAM disk due to the performance hit of accessing it (even though zeptoforth itself does support using it as just one big block of slow RAM). I’ve read that at least with uLisp they recommend turning off GC on every prompt when using the Pico Plus 2(W)'s PSRAM as heap because the GC delays are prohibitive and thus result in a poor user experience when applied with every prompt.
All that is needed is to make some tweaks to present a display object and add a keyboard object. Then Bobs your uncle.
Are these tweaks within the Python code or are your referring to adding the appropriate C drivers specific to PicoCalc hardware and recompiling the uf2?
IIRC @Neusse has display and keyboard objects implemented for CircuitPython on the PicoCalc, and was speaking of the need to add the right ones for the PicoCalc to outside projects originally developed for other boards, e.g. the aforementioned Metro RP2350 and the Fruit Jam.
CircuitPython currently can’t communicate with the PicoCalc keyboard “southbridge” over I2C (I’m not sure why yet). Fortunately, Blair Leduc wrote solid C keyboard drivers in his picocalc-text-starter project. Picoware uses those drivers, and a MicroPython binding layer was created so MicroPython can call into Blair’s C code. Once compiled into a UF2, those bindings appear as an importable module.
My work was focused on the binding layer:
I modified the existing binding layer and also wrote my own CircuitPython-friendly binding with some efficiency improvements.
The binding layer is “glue code” only: it does not re-implement Blair’s driver logic—it simply connects high-level calls to Blair’s C functions.
PSRAM: PicoCalc vs Pimoroni Pico Plus 2W (RP2350)
The Pimoroni Pico Plus 2W PSRAM is interesting because the Pico 2 / RP2350 supports PSRAM on the dedicated QSPI bus and can use XIP (Execute-In-Place). With XIP-capable QSPI PSRAM, the CPU can access that memory in a directly addressable way, which makes it useful as fast heap expansion (and can feel like “real memory,” not just slow storage).
That is not the same as the PSRAM people talk about on the PicoCalc. PicoCalc-style PSRAM is not accessible as true QSPI/XIP memory on the RP2350 via the header pins. Even if you optimize transfers (PIO, etc.), you still generally have to copy data into SRAM before you can use it efficiently. In that sense, it behaves more like “extra storage” than true addressable memory.
I compiled stock MicroPython and stock CircuitPython with the keyboard drivers added. I also enabled the relevant PSRAM/XIP flag and built a version of Picoware with it, but there wasn’t much interest. I also showed jblanked that I had this working.
Other languages and PSRAM
If someone is using another language/runtime and claiming to use “local PSRAM” on the Pimoroni board, they still need to understand XIP memory mapping to benefit from it. MicroPython and CircuitPython can take advantage of the work already done in those ecosystems to make PSRAM use relatively transparent. Other environments may end up doing a “copy into main RAM first” approach unless they explicitly support XIP-style mappings.
I don’t see a big penalty to using PSRAM as heap in typical PicoCalc apps, and most of what I’ve written doesn’t exceed the ~520 KB of SRAM anyway. If you allocate early at startup, you can also bias critical resources to land in SRAM.
