32blit Retro-inspired Homebrew Handheld with Open-source Firmware


SD card is something we considered- but since this thing will have gobs of - with any luck mounted as mass storage - flash on it, it will be redundant anyway for the majority of users.
My current definition of 'gobs of storage' starts at 1TB which would admittedly be far too expensive for a project like this. From the link above it looks like this project defines 'gobs of storage' as 32MB of flash... Is that a typo? A microSDXC slot would potentially open this up instantly to 'up to 1TB'.

2. No headphone socket
That instantly kills any consideration I would have otherwise had for this product.

Good luck to you on it, though.
 
My current definition of 'gobs of storage' starts at 1TB which would admittedly be far too expensive for a project like this. From the link above it looks like this project defines 'gobs of storage' as 32MB of flash... Is that a typo? A microSDXC slot would potentially open this up instantly to 'up to 1TB'.
It's funny, when I first got my first ARM computer with a 40MB hard disc it took me years to fill that up with crap, although that was before the internet which helped a lot. For a handheld which similarly isn't connected and also isn't intended as an emulation target 32MB is almost as big as my original hard disc. If it does take off as an emulation target it could be problematic though - my SMS archive alone is 128MB.
 
isn't intended as an emulation target

I think that's the relevant point. With a fairly slow CPU and only 1MB of RAM, this not only isn't intended for emulation, but simply wouldn't be up to the job. This really is a homebrew-only system. With the specs this modest, I wouldn't expect games made for the 32blit to take up more than a few tens to a couple hundreds of kilobytes each. You can fit quite a few games like that into 32MB.
 
Being successful enough that there’s 1Tb of first-party software people want to install would sure be a nice problem to have!

The flash is also execute-in-place, quad-SPI meaning the chip can effectively stream instructions directly from it with no loss of performance versus its internal flash. This is a guarantee that an SD card could never make. Granted you could contrive some solution to stream program code off the SD onto flash, execute it and then stream assets across... but then we’re just diving into complexities for a feature that - face it - is only desirable to people looking at this as an emulator handheld, which it’s not.
 
I wonder whether it'll be possible to get some early Archimedes games running on this, largely ports from the Amiga but there was the odd few commercial games made by one or two people specifically for the platform. Especially the early stuff doesn't depend very much on the OS subroutines to run. And the early Archimedes only had 512kB of RAM, and everything came on 720kB 3.5" DD diskettes. I guess the framebuffer writing code will need to be tweaked, and anything that loads in level data will need to be changed, but that depends on what this is running as a boot medium.
 
For me the most critical aspect for such a handheld (there are plenty of those lately) is the quality of the 4-way d-pad. Gamebuino has an OK one, where ClockworkPi has a sub-par one that in 1/20 of the cases registers a wrong keypress. For me even the one from GCW zero, while acceptable was not perfect. I guess I can only dream of GBA-micro quality. Probably you will test it more than others with so much homebrew stuff developed in house... Who knows that might also be a great differentiating factor.

It's hard to judge the size of the handheld from the video. My guess it is between gamebuino and GCW zero. But to which of the two it's closer?

One last question: why did you decide on analog stick up and d-pad down? Do you expect more homebrew titles with an analog stick controlls?
 
Last edited:
cant believe this device only has 1 mb? I would expect memory to be cheap.
I cant imagine there being much memory left once the OS and framebuffer are allocated.
Is this device going to only support palettes and tiles for graphics?
 
It depends largely on what resolution this is targeting I think. Say it's 320x480 or something then even at 32-bit colour that only needs a 300kB framebuffer according to python's maths. Limit it to 16-bit colour which still looks pretty good especially for retro gaming to my eyes and it'd be half of that, so double buffering should be doable. I guess it can't be running any flavour of linux kernel though, cos that would eat through that pretty pronto. You basically want an OS that is simply more or less a set of libs that code running can call for assistance, but otherwise the bootloader just jumps into the game code at its start address, like all games consoles used to be up till the PS2 gen.
 
@zoranc we're just as keen on getting the d-pad right. Hopefully the beta testers will help us do this- although the parts we're using have already been battle-tested and - like you say - we're using the hardware ourselves so we'll certainly catch all but the subtlest of problems.

The prototype is - I'm pretty sure - much closer to a GCW Zero in size. Albeit I must admit I don't have a GCW Zero to compare it to. We're talking 15cm x 6cm approximately.

I'd say we expect more software to use the analog stick, since it's a bit of a modern twist to the retro handheld- but the stick is far more proud than the D-Pad and we've only got a single PCB to mount these to so I dare say they wouldn't swap well without the analog getting in the way of d-pad use.

@Pickle it's all about developing retro-styled games for a basic system so the RAM limits aren't concerning. This RAM is what's available inside the MCU itself and external parts (we'd be looking at things like Quad-SPI FRAM) have neither the capacity nor the low cost you might expect from DRAM.

I'm doing okay running a textured raycaster with 5k sprites on-device. If you look at the MCU datasheet you'll find the RAM is also split into non-contiguous banks which lend themselves well to handling different features- we hope to provide peek/poke access to these as if they were hardware registers, and recapture a little of the classic programming vibe. It doesn't *need* to use palette-based assets but I personally prefer them. We have an asset packer that supports 1-8bit graphics in indexed palette mode, and also support for regular RGB and RGBA. I've started doing pixel art just to test it!

@levi we're targeting 160x120 (pixel-doubled to the 320x240 display) and consider this limitation a feature. It's possible to run the screen at native-resolution but with 4x the pixels you have to consider carefully what you do with it. That said we've run our awful unoptimised in-house demos at native res for giggles at pretty respectable framerates. The system is double-buffered between an RGB565 320x240 display back-buffer and an RGBA32 160x120 in-game drawing surface.

There's no Linux-OS and what little OS we do have will be extremely minimal- just a bootloader with our engine and Lua VM baked in and the ability to load in and run user games from flash- whether they're written in C++ or Lua.

Note that technical details of the software are all subject to spontaneous change as we get a better feel for what works.

While I don't like comparing us to PICO-8 - we have a good relationship with Zep and don't want to detract from the fantastic product/community he's built - the 32blit really is more "PICO-8 with hardware" than us putting together a hamfisted emulation console. Although we'd still love to see emulators!

By and large we're listening intently to what people are saying about the device and asking for.
 
160 by 120, eh? Gameboy Color and Game Gear were 160 by 144, IIRC. I assume you had to cut the other 24 lines of pixels to make room for the extra 24 bits in the 32 bit processor, right? ;)
 
It’s a low resolution for sure- but we’ve already got some really satisfying results out of it. I’m definitely more in the “force people to make interesting choices with limited resources” than the “eh! Just run in 320x240 mode.” The stuff people have done with PICO-8s 128x128 is nothing short of brilliant. I’d love to see inspired titles like Dank Tomb pushing the limits of 32blit. I’ve also had a lot of fun coming up with original sprites and textures
 
True. That! That being said, we're doing extensive testing at 320x240 to see how far we can push this thing and many of the possible optimisations for pixel pushing remain to be found since they might involve SIMD instructions.
 
I believe I've heard of it but never actually tinkered with one. I've got VGA output working on, and games written on an Arduino Due using a Megadrive controller for giggles.

We actually sell Arduboy which I guess is the portable equivalent of this in a way, so we're well aware this market is full of pretty cool options already. And, of course, I've been around here since the GP2X days :D

32blit is making up for all the time I never got to spend writing games for the GP2X, Dingoo A320 and OpenPandora- back in those days I just didn't have the head for it. But it's amazing how quickly you'll pick something up if you do it for a day job.

It's also making me want a Pyra more! 32blit titles could be trivially ported.
 
Not yet- tools will be available to beta backers first so we can get some feedback and finalise them without too many voices pitching in.

We're pushing stuff forward on about a dozen fronts. I had a full in-browser Lua-running engine and IDE with intellisense working, but we've drastically refined the engine since then and tore out all the Lua stuff until the C++ API is nicely nailed down.

Right now - for our own uses as much as end-users - I'm focused on making it easy to build a C++ project to multiple targets, and refining down what defines a "project" to as few essential files as necessary. We don't want you to have to manage a whole bunch of boilerplate garbage and want project files to be directly portable to test/debug/deploy targets (on and off device, with or without an IDE) with - ideally - just a variation in what command you call.

Suffice to say- it's a busy time!
 
Back
Top