Thank you Kihonkai.
After a bit of struggling I feel like I’m making progress.
I kind of felt the opposite about resolution - the pixels are a bit small, even when pixel-doubled. After a bit of fiddling around, I have managed to create a pixel-tripled mode, which is 80x80. I’m not sure whether I’ll actually use it in a game, but at least now I feel like I have more of an understanding of the display process. Here are some things I found:
The picosystem wiki looks like it claims that the pixel format is nibbles in order ARGB (A being transparency, which is irrelevant for the screen buffer). But you have to pay attention to the byte order in the diagrams - it’s actually GBAR if you load it into a variable as a 16-bit unit. Which is consistent with the comments in this thread.
But! The PIO programs both write out 12 consecutive bits - how? After some thought, I realised it could be happening during transfer via DMA to the PIO input buffer, and on investigation found that the byte order of the 32bit word transfer is reversed.
Why does it work like this? I think it’s because the screen driver chip wants to receive the pixel pairs in a different order to what you want in the screen buffer. Cool.
The sprite/display format is interesting, and obviously powerful, but I’m rather concerned that there isn’t a straightforward way of directly generating sprites to suit it. It’s a bit damning that the sample spritesheet provided is 1-bit alpha.
I feel like I need to make a decision on whether to try to figure out a pathway to interactively create new sprites, or to flat out ignore it and make a paletted sprite renderer.
All in all, I think I made a good decision to plump for the picosystem. I have some hopes of making stuff successfully.