Picante: a Pi Pico-based handheld project

In The Beginning...

I'd been experimenting with SPI displays on the Micro:bit before now and was lamenting how little RAM they have.

So when I read about the Pi Pico's whopping great 264KB of RAM I immediately wanted to make a DOS-a-like handheld game platform.  It easily has enough RAM for a full 320x240x8bpp frame buffer and at 133MHz it's about the same speed as an original-series Pentium.  Plus, it's dual core!

All those figures made me think it would be an absolute doddle to make a DOS-a-like.

...but then I started to think about how it would actually be used.  Sure, I could make it so that C programmers could make games for it, but that might just end up with curiosity value.

But what if I could make it so that the students I teach could program games in Python?  That way it would have loads of inspiration power whilst also having high educational value!

With the magic mix of both idea and plausible use case, I set about making a prototype.

The Hardware

Some component-orders and shoddy soldering later, I had a the beginnings of a v0.1 prototype:



The screen is a 2.8" 320x240 Adafruit display from Pimoroni*.  It has a micro-SD slot and resistive touchscreen that I'll probably play around with later.  The 90-degree headers, microswitches and prototype board are cheapies off eBay.

I also bought an I2S audio module, but I have yet to try that out.

* I don't get any money or perks from Pimoroni or Adafruit - I just like their stuff.

Getting it running

Flashing the micropython uf2 firmware was an absolute doddle (see here).  Installing thonny was a little bit annoying because the Ubuntu version is so out of date that I couldn't follow the instructions I found. However, it was pretty easy to install the latest version via their website. 

I used rdagger's ILI9341 micropython library and after some initial problems (I had wired up MISO/MOSI the wrong way round, forgotten to short-out IM1, IM2 and IM3 and one of my cheap-ass wires was b0rked) I got the demo_shapes.py code running.

Thonny's REPL window was really useful for figuring out a way through those initial problems.  A lot of complications could've been avoided if I had actually read the display instructions properly the first time, but y'know - where's the fun in that?

Micropython problems

So I had micropython code driving the display, but it was sloooooow.  I had seen much faster framerates online, and it turned out I needed a full frame buffer in RAM.  The display works at 16bpp, so a full framebuffer needs 320x240x2 = 153600 bytes.  No problem, right?  I have 256KB to play with!

Wrong.

As impressive as micropython is (and it really is!), it sits on enough RAM to make a full framebuffer impossible.  But I really wanted people to be able to make little games in Python, so I had to figure another way round it.

Towards a Framebuffer Solution

So I figured I would have an 8bpp framebuffer (76800 bytes) and a 16bpp stripe that I could expand the 8bpp into for transfer (repeating once for each stripe on the screen).  I got it working in Python, but it was prohibitively slow.  I needed to get the 8bpp to 16bpp expansion running in native code.

Framebuffer handling in native code

A really impressive thing about micropython is its ability to put native code in a .mpy file that is imported just like a Python module.  Unfortunately I needed to re-compile the firmware with some tweaks for the RP2040, but I did get it working.  

The render buffer is in a strange format: RGBA:2321 (alpha not implemented yet), and later I intend to do colour-palettes because who doesn't like palette cycling animations?

Adding Sprite 'Blitting'

So, the latest thing I've added is C code to clear the 8bpp render buffer and 'blit' a 32x32 sprite to it.  A full-buffer clear and blitting a single sprite (on a single core) runs at just under 19fps!


This thing might just work after all!



Comments

Post a Comment

Popular posts from this blog

Micro:Bit and SPI display

I want to explore the full potential of the BBC Micro:bits my school has. Making rock-paper-scissors games and the like is all well and good, and the students love it (for the most part), but it always feels a little bit gimmicky.  But when students really get engaged and suggest ideas for them (e.g. games, compass display), it all gets a little bit cramped and feels like it could  kinda  work, but not really . Then I found out that all the tiny strips on the edge are actually GPIO pins, not just the fat 0, 1 and 2 ones.  Since then, I've wanted to explore what I can do with it. Hence, over the last few days I have been trying to get the microbit to control a TFT display. I first went for this 2.4" display with a touchscreen.  The SPI interface is just for the microSD, not for the screen but I didn't think that would be a problem because the micro:bit has so many pins.  After much frustration, I discovered that there are many of the pins you can't reliabl...
Read more

DCS World with TrackIR under Ubuntu

This is a record of my experience of setting this up.  It's meant more as a record for my future self than a tutorial, but maybe somebody will find it useful. 1 - Install DCS First step, install DCS World via the Steam client as normal.  2 - Install LinuxTrack Linuxtrack Download here: https://github.com/uglyDwarf/linuxtrack/wiki/Downloads   Instructions here: https://github.com/uglyDwarf/linuxtrack/wiki/universal-Linuxtrack-package   Using the gui (ltr_gui) requires qt4 libraries, which I could not find in my standard Ubuntu repositories, so I had to use the ppa instructions here: https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04 Run ltr_gui from linuxtrack's bin directory to check everything works so far before moving on to get it running under Proton.  3 - Install LinuxTrack into the DCS World prefix NOTE: Attempting to install for Wine games WON'T WORK e.g. here https://github-wiki-see.page/m/uglyDwarf/linuxtrack/wiki/Wine-Games   Th...
Read more

Polygon Triangulator!!

For my 3D games, I've been playing around with ideas around semi-procedural geometry, by which I mean geometry which is generated from a small amount of authored data.  For example, I could draw out the shape of an island in a dozen or so 3D points, and the actual terrain geometry could be generated from that. A big step along the way to that is splitting up a non-convex polygon into triangles.  The triangles mustn't overlap, nor must they cover any space which the polygon itself doesn't cover.  For example, this diagram . Today, I managed to get a python program* running which took a list of 2D points defining a polygon, split it into sub-triangles and displayed them in a tkinter canvas**. I am certain this has been solved by clever people in much better ways, but I still feel proud to have figured this one out (and I haven't managed to break it yet!). The basic algorithm is: Create a temporary copy of the polygon points list start with the three points fro...
Read more