I’m interested in experimenting with sprite-based graphics for small OLED displays (e.g., 128x64 or 128x128) and considering using the Picocalc as a development platform. Specifically, I want to explore display communication over SPI and I2C, and possibly work with I2S.
Can anyone speak to whether the Picocalc hardware or firmware design imposes any unusual constraints on GPIO usage for these interfaces? Are there pins that are already reserved or shared in a way that might limit general-purpose I/O flexibility for SPI/I2S experiments or fast graphics work? THanks Matt
On the left side, there are at least six pins you can use for SPI, I²C, or whatever you need. They are connected to external PSRAM, but if you don’t plan to use it, all of them are available to you.
You can experiment with SPI and sprites on the internal 320x320 IPS display. Using PIO, you can also use I²S on those pins, plus the two pins used for the Pico UART, giving you up to eight pins for SPI and I²S.
The schematic is here:
PS You could always scale down the screen resolution to 128x128 with
Black margin = (320 − 128) ÷ 2 = 96 pixels on each side (top, bottom, left, right) or any other integer downscale without margins (letterboxes), like 160x160, 64x64, 80x80
Worth noting that sadly, if you want to use MMBasic, sprites are not available in PicoMite since all of that functionality is strongly tied to HDMI/VGA PicoMite platforms. PicoMite has some other drawing routines that work on the PicoCalc, but performance may be poor. More information about the specifics can be found in the PicoMite user manual (though some of the latest stuff we’ve picked up from recent RCs from the mainline PicoMite, and some extra PicoCalc-specific features I’ve added are not in the documentation yet). That information is in release notes and posted to TheBackShed thread though.
But sprites can definitely be used on MicroPython and presumably other languages/firmware. Perhaps one day they will be supported in PicoMite as well.
Sprites are available in MMBasic. For LCD displays you create a framebuffer and execute the sprite logic in that. Then copy that framebuffer to the physical screen when you want. In addition there are sophisticated mechanisms for having 2 framebuffers with one overlaying the other and a merge and update of the screen taking place in the background on the second processor. This video shows this in use on a parallel connected display but the same program works just as well on an SPI display.
Search for Petscii on the backshed forum. The authors were Volhout and MartinH. They have also posted a document explaining how the magic happens if you search for it.
Ah, cool! I had read somewhere on the forums that they weren’t supported, and the PicoMite manual indicates the SPRITE command is only supported on the VGA and HDMI versions.
Thankyou @picouser, I was just girding my loins to try and explain this … but you did a much better job than I think I would ever have managed.
As I’ve said before one problem with the PicoCalc is that the 320x320 SPI display (c.f. the 320x240 of a good old ILI9341) is that it takes 33% more memory to create a framebuffer and 33% more time to transmit it to the display which makes games/sprites more problematic.
Hi, I know this is a ClockworkPi / PicoCalc forum, but unless you have some fetish for small displays and keyboards that doesn’t sound like a PicoCalc project to me. Just get a ~ £4 Pico 1 module, install the standard PicoMite firmware and connect to it via a serial terminal (e.g. TeraTerm), see Geoff's Projects - BASIC Interpreter for the Raspberry Pi Pico . That way you will have all the GPIO you could possibly want for your project. Get support from TheBackShed.com - Forum .
