BX portable game console | project collaboration


I look forward to playing the gateroids game.

I have been looking through the beginning of the Wikipedia article on the best games ever, wondering which ones we can recreate.


I have received and assembled my board, and here is Pacman running on it:


I bought one of our rivals to see how it compares. The screen is not as big, but it is cheaper and has a volume control, built-in speaker, and audio and AV out. And 50 games.


I’ve received my board now too - just need to order a display for it and I’m sorted :slight_smile:



Here’s a (mostly) built FPGC sitting amongst a bunch of its relatives at the Syntax '18 demoparty in Melbourne :slight_smile:

(Time was too tight to get a ‘demo’ ready unfortunately)…



… and the proper display arrived today… :heart_eyes:

It took a little while to figure out the correct commands to get the lcd display the right way up, but I got there in the end.

I am currently running without audio as I couldn’t get things to fit. I’ll keep prodding away at it.



So today I found out that Clifford Wolf had done something wonderful, and added some major, major improvements to the mainline version of nextpnr. As well as speeding up routing time for the current iteration of the Game SoC from hours (or not at all) to seconds/minutes, it’s allowed me to finally get things to work with almost everything that I wanted in there.

This means that both audio and video fit! With the pin constraints for the FPGC!

As well as the eight standard sprites, I also managed to squeeze in a couple of extra “bullet” sprites (white 2x2 rectangles which are X/Y positionable), and a “horizontal interrupt” - ie. an interrupt that’s triggered when the raster hits a given scanline.

The horizontal interrupt has been interesting. I’ve been experimenting with “chasing the raster” – doing things like repositioning sprites when the raster hits a certain point. This allows for more than the 8 sprites (or two bullets) to be on the screen at once. It seems to work okay, although not particularly well in C code, nor with the standard ASM IRQ handler which takes a long time to save and restore all of the registers (more time than a single line takes to raster out :frowning: ).

I’m pondering maybe adding some more Q registers so I can do a super fast IRQ path for certain effects code.

It feels nice to be able to jump back up a layer again. Hopefully soon I’ll be able to start making some progress with the C code again.

Oh, my buydisplay LCD seems to have a few issues with the power-on init sequence - it often seems to just start up and stays fully white. I might be dreaming it, but it seems to happen more when it’s cold. I’ll try to dive into what’s going on there at some point too.




Feels like having an hardware upgrade :slight_smile:

Do you mind sharing binaries so that we can try on our FPGC?
I don’t have nextpnt yet.


Yes, I get this and other effects (screen corruption) as well. I often have to start games by pressing reset. They start more reliably then. One thing that definitely makes a different is how charged the batteries are. It works more reliably with more volts.

I currently have about 3 nearly playable games: Pacman, Tetris and Adventure, but they all have issues and are incomplete, with Pacman being the most playable. The SD card menu allows them all to be on an SD card and selectable from the menu, reverting to the menu on reset or power-on. Starting games from the SD card via the menu, again seems more reliable than starting them from power-on.

I am currently programming the Adventure Atari 2600 game without “chasing the beam” as I thought I would wait for you to get that working. It is still using the BRAM-only SoC and direct driver of the ili9341, but with some hardware assist.

I built nextpnr a month or so ago, but haven’t used it yet. Sounds like I need the latest version.


Of course not… :slight_smile:

It’s entirely a work in progress, but gateroids has a homescreen, and a sort of a playing field now…

gateroids-work-in-progress.zip (81.4 KB)

Press A or B to go from the home screen to the “playing field”, and X or Y to go back again. In the playing field, left/right rotates the ship (which is currently aimlessly drifting)…



Thanks, it looks so good!


Yes, it looks stunning. I can’t see to shoot any Asteroids, though.


@gundy, how do you create the tile maps? I see that you use Tiled files.


It’s a bit of an involved process at the moment…

I use GIMP to edit the texture - essentially just as a 128x128 image (which is split into 8x8 tiles):

That gets me the basic 2bpp (albeit grayscale) data to work with. I export that into a C header file from GIMP to use in the code, or I use the image directly in Tiled for editing the larger maps.

At this point things are still greyscale. Colouring the maps is a bit more of a hassle.

I export the data from tiled as a CSV file, convert the CSV into hex format using a little utility, and then kind of manually find the sections that I want to apply a different palette to and update the upper bits to chose the “sub-palette” to use.

The way the tile/colour data is stored in memory is as 12-bit values:

11 10 9 8 7 6 5 4 3 2 1 0
P3 P2 P1 P0 T7 T6 T5 T4 T3 T2 T1 T0

Where T7-0 represent the tile number (0…255, corresponding to the different tiles in the map above), and where P3-0 are a sub-palette selector.

There are 16 possible 4-colour sub-palettes, and each of the 4 colours for a given sub-palette comes from one of 16 global colours (which in turn can be any RRGGBB value).

It’s probably easiest to demonstrate with a picture. Here’s the gateroids sub-palette map:


So if I want to make a particular section of the tiled map greyscale, I simply set the sub-palette selector to “0” (the first group of 4 colours from the left in that map). In practice that means setting the upper nibble of the 12-bit value to 0.

If I wanted to make something purple, I’d apply a palette selector of “1”, and so on.

The same sub-palettes are also used for the sprites, which also use two-bits per pixel. For sprites, the bit pattern “00” always maps to a transparent pixel, but for background tiles it can be used as a normal colour.

As I mentioned above, all of the colours in the “sub palette” swatch come from a global palette of 16-colours, which have been selected from the 64 total available RRGGBB values. For gateroids, this palette looks like:


So yeah, the short version is that I use GIMP + Tiled, with a bit of finessing afterwards :slight_smile:

ETA: I’m currently using more-or-less the same process to edit sprites too:

The other orientations of the ship are generated by X/Y flipping in hardware.



I have a project that generates code from Tiled files, maybe that could help.


I designed a new version of the PCB:

  • Based on the actual screen, not the evaluation board
  • Backlight is always on (1 more BX pin available)
  • TinyFPGA-BX is now on the front and above the screen
  • The board width is reduced by 1.4 cm (because the screen takes less place than the eval board)
  • So far it is pin compatible with the previous rev

Let me know what you think.


Looks good.

I would like the SD card pins connected so that I can put all the games on an SD card and run them from that with my menu. If we are not using the development board, then presumably we lose the SD card reader so would have to add one.

You suggested in a private message that I open an issue on your repository for that. I can do that if you still want that.

On my FPGC, I soldered the SD card pins (32 - 35) to the direction button pins as my SD card menu does not use the direction buttons.

It makes a far better demo of the device if you can run all the games from a menu rather than having to load each one separately from a PC.

But creating a menu that stays in flash memory and runs the games from a different address in the flash memory requires setting up a new multiboot configuration, which isn’t trivial. It is quite easy to do but is risky if you don’t have some sort of SPI programmer. I used a second BX as a programmer.

I also quite like the idea of having a built-in speaker rather than having to use the headphone jack. That would require an amplifier.

It would be good to do a 3D printed case for the device. If we did that it might be best to have the USB connector at the edge of the board. Getting access to the reset button, power button, headphone jack, uart connector and SD card reader could also be difficult.


I was thinking this too. To help here it would be useful to have additional holes through the board that could be used for screwing two halves of a case together.


I do like the idea of having multiple games. The question is the balance between features and complexity of the design.

So far there is not enough pins available to connect an SD card.

Can you elaborate on that? Why can’t we aggregate the games and the menu app all in the SPI flash?

I like the raw PCB style myself, but I can make it easier to create a case (see below).

For the orientation of the USB connector, I am limited by fact that the BX board is a through hole part. So if I put it on the back like in rev-A, the pins stick out to the front and that means the screen cannot lay on the PCB. It also means that the BX is taller than the battery holder, so when you put the FPGC on a table it sits on the reset button.


I replicate the lower right “lanyard” hole to each corner of the screen.

Like so: