Picosystem - all of it

So I spent some christmas money on a Picosystem, which looks like it approximates what I’ve wanted for …some years. And I’ve just managed to break through the barrier of getting set up to program it in earnest.
It’s quite a steep learning curve for me because I need to learn C (I’d like to get the full potential out of it.) I’m struggling quite a bit.
I’ve found a very few conversations about the picosystem scattered around, but I kind of want a more centralised and ongoing community. Is there anyone else on here working with it, or is there a secret forum where everyone meets or something?
If not, there should be. Could we do it here somewhere?

A secret hangout if you’ve got a PicoSystem on you could be fun ^_^. Unfortunately I think it’s maybe not that popular as it’s quite new though I’ve seen it out of stock a bit so people are buying it.

I brought two early in Dec-2021, one for me and the other a Christmas present for someone. I like the design and the somewhat minimal features. My thought was to be able to focus on making small demos / games without the option of networks and other things complicating it.

I didn’t do much more than the examples with c, I think getting a feel for the build process was tough, I still want to learn more about it in general for the RP2040.

I’ve done a bit more with MicroPython and managed to make a small word game but found the MicroPython API is limited, it lacks features of the PicoSystem API such as changing the font or font size. I don’t know how to extend it yet but have thought of trying.

One thing I can say is the 120x120 pixels resolution and the limited memory do make for a challenge compared to the typical business apps development I’ve done for years using C# and .NET. I managed to throw together a bit of a game before hit errors running out of memory.

On the forum, they have a category for 32blit that can be used directly on the PicoSystem from what I understand, but nothing specific to the PicoSystem. Maybe they don’t add stuff like that until there’s enough activity.

Hopefully some more people get involved. I did see there’s a bit of activity on the GitHub repository for it.

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.

@Loris, you’re certainly dived deeper into the display process than I have, it sounds like an interesting thing to look at, thanks.

So I think I have a route to generating C-style spritesheet arrays with full colour selection and partial transparency. It’s a bit of a bodge, and not really suitable for precise alpha-level control.
But here it is:
I’m going to call partially transparent pixels translucent even though that’s not strictly correct. The basic issue is that 4-channel, 4-bit per channel images arn’t a widespread format, and as far as I know, no editor works with that natively.
There is an online converter tool on the picosystem wiki which will process an image to the required output format, but trying to naively draw sprites in a true-colour mode would be a bit of a nightmare - colours you thought were different would match, and off-by-one colours which look identical may become distinct.

The alternatives are to write a bespoke pixel editor, or find a way to use a pixel editor in true-colour mode with the appropriate granularity. The latter seemed a lot easier.

So you’re going to need a pixel editor (duh), ideally one which provides layers. I use Asprite, which isn’t expensive and I recommend. I’m running it on windows. I see there’s an Ubuntu version but haven’t tried it on my Pi.

Firstly you need a bitmap with an area for the spritesheet and all the colours available as a palette. 4096 colours is just-about manageable as an in-image palette. You use the colour picker to pull these colours; those you like can go in your editor’s palette system at least temporarily.

There are two different options here.
If what you want is mostly opaque (or fully transparent) pixels, but with a few semi-transparent regions, you can draw each
translucency level on a separate layer. The trick is to make each of these layers itself partially transparent.
The obvious risk here is that you lose track of which pixels are on which layer - erasing may be a problem. Also, if you draw over the same pixel on multiple translucent layers you may get a colour which doesn’t colour-match in the output, although I don’t know if this is a big issue. I put the opaque layer on top which is at least better than the alternative.

If what you want is to have lots of individual semi-transparent pixels scattered around, for example to add antialiasing to edges, then you should have a palette set up at each required transparency level, and draw your bitmap on a single layer.
The down-side of this is the difficulty of picking colours from the larger in-image palette.
Both of these would be increasingly unwieldy with more transparency levels, but I think they’d be manageable with at least two or three levels of translucency.

There are some tricks to doing this which essentially boil down to being proficient in your chosen editor. Making sure you have tools set to the right mode (eg - your ink needs to replace colour and transparency, not blend), that sort of thing - but it feels workable to me. Obviously, being a pixel artist would help.

When you’ve generated your sprite-map, you can crop it down to just the spritemap, make sure any opaque background is hidden and export as png. From there it’s just a case of dropping it into the online converter.

So I’m reasonably confident this will work - although I haven’t actually gone through with uploading an image onto my picostation, I have checked the output and it matches what I expected.
If you’re building your own palette, I can tell you that the 8-bit channel values you probably want are multiples of 16 : 0,16,32,48…240. At least, if you’re planning on using the online converter.
I don’t think there’s a way of uploading attachments here, but if anyone wants the palette image I generated, or the Asprite ‘editor’ imagefiles, I can supply them.

You’ll find plenty of Picosystem love on the 32blit Discord (and there are some of us who have used the Picosystem API instead of leaning on the 32blit one, too)

Somehow I’d missed the wiki appearing :-)

I’m now on the discord, and have put the asprite and png files described above on there.
Also, I have another method which is is probably going to be easier for almost everyone who uses Asprite - it has a lua scripting language interface, so I made a script which changes the palette and image pixels of the current layer to picosystem-friendly colours. So you can just choose some colours and form them up, or import an image and see how it will look. It’s on the #picosystem-dev channel.