Yet another MCU handheld console kickstarter: 32blit


I noticed that on Twitter. Impressive hardware.


The promise of tooling is nice. Interesting that they are using C++ or Lua for programming.


The tools offer is really rich: sprite, map, sound and music editor. Combined with a pack of game tutorial.
Only lack seems the absence of any IO for electronic hack.

1 Like

And it’s quite expensive.


Hrm, I have mixed feelings.

I’m tempted to back it purely because I like Pimoroni and I like supporting local businesses.
(Not that Sheffield is ‘local’ exactly, it’s quite far up north.)

And I like the C++ and Lua combination.

Personally I don’t care about the asset editors or tutorials,
I’m used to working with bare mimimum tools and writing my own tools.
I’m more concerned with how good the API is and what tools+IDEs are available for programming it.

But it’s got a very hefty price tag, which is what really puts me off.
I’d be tempted to get involved in beta testing if it weren’t for the fact I’d need tools to assemble it.
Also the fact it’s Discord rather than a Discourse forum isn’t as good.


Lack of easy extensions or IO is a deal breaker for me.

Is there no SD card? The best feature for a portable game console is the ability to carry around lots of games…

1 Like

It’s got a “32MB flash via QSPI interface which supports XiP”.

Usually flash is easier to program for because instead of messing around with file paths you can often just treat it as more addressable memory (depending on how it’s implemented).

Either way, you could probably build something to allow game flashing on the go.

I hadn’t noticed it was missing, not having an SD card slot really ruins it. :confused:
That and the price.

The 32 MB QSPI flash is good for holding games. But if you want to stream music, 32Mb runs out pretty fast

We’ll have to see how big their games are. I have the feeling that the looser constraints will lead to much larger games and less data compression. When emulators get ported to it, 32mb of ROMs is pretty small.

Also, the games would have to be compiled with position-independent code for the user to be able to choose which ones he wants to run. I think that’s not an option on GCC+Thumb2.

By golly, you are right. How do they plan to use the 32mb flash? By running from RAM?

This is an odd detail indeed.

But, otoh, I am not familiar with the MMU of the Cortex M7, and don’t know what it is capable of.

EDIT: I’m going to answer my own question. Clearly the idea is to run mainly / only LUA compiled bytecode. That explains the arrangement.

1 Like

Free assets!

A repository of free (libre) assets sounds very nice, I was once thinking about this in Pokitto context as well. Wouldn’t be bad to get inspired :slight_smile:

All of 32blit 's software, libraries, and firmware will be released under the MIT license

  • DRM-free and region-lock free
  • Open media & game formats
  • Respect for your privacy (no telemetry/phoning home)
  • You have complete control over the hardware

Sounds good, but the details will matter. Adding this to my watch list.


It doesn’t actually say what the licence is (if any),
so be careful with throwing ‘libre’ around.

(Personally it makes no difference to me anyway,
I wouldn’t be likely to use them unless they’re exceptionally good.)

They changed their minds, it does have an SD card. They also created a forum, for those who don’t like discord.
In other news, beta units have been shipped and they’ve openly released their lib on github. It’s interesting to see what design decisions they make differently, due to the different hardware.


And the ones that aren’t due to the hardware.
There’s a lot of really bizarre design decisions in there.

They’ll happily use classes like std::vector and std::string, and they’ll put their code in a namespace,
but they’ve decided to use the deprecated C libraries, avoid C++11 features (even to the point of using #pragma pack instead of the align keyword) and design most of their library like a C library.
(And it seems they don’t know what const-correctness is, but sadly that’s a disturbingly common problem among these sorts of libraries.)

Worryingly they’re passing std::strings to functions by value instead of by (const) reference,
which suggests to me that they either don’t know what a reference is or don’t understand the implications of passing a string by value.

And I’m really not sure what to make of the ‘tweening’ part of the library.

I had noticed some of these issues (tbh I didn’t look too far) but didn’t think too much of them as they’ve stated things are still in flux. If you look in the “Projects” tab on github (a nice feature I should try), you’ll see they’re planning an “API Overhaul”. Maybe right now they’re just busy getting things to work and it’s just a prototype.

I definitely recommend it.
I used a project in automated kanban style for developing Minesweeper V2:

Milestones are also handy, for tracking which features and bugfixes were part of which versions of the code,
and for tracking longer term goals (like removing accidental -fpermissive-permitted code).

(I keep meaning to look into Actions but I’ve never got round to it.)

Perhaps so, but personally I think it pays to aim for correctness as early as possible, even if the API is subject to change.
If you set a precedent of correctness at the start then it should encourage that correctness to be carried forward as the API changes.

Besides which, usings consts and references correctly isn’t that difficult in the grand scheme of things:

  • Anything that doesn’t need to be modified is const
  • Anything that’s expensive to copy should be passed by reference
  • 9 times out of 10 a reference is better than a pointer
  • Any function that doesn’t need to modify this should be marked const

(There’s probably a handful of exceptions to those rules,
but pretty much every rule of thumb in programming has exceptions.)

Talking about that, you should at least port it over to pokitto in full colour and bigger playfield. Would be about time :stuck_out_tongue: