µGame Turbo

Python game console like µGame, only faster, bigger and with more memory.

Similar projects worth following

We desperately need to learn to use and control computers, before the computers use and control us. But it's hard. We don't really have very good teaching tools — the desktop computers are too complex, the retro computers are boring to children, the cool devices that can play games are all locked down and unhackable. There is the Raspberry Pi and the Micro:bit, and they improve the situation greatly, but we need more. The #PewPew and #µGame projects were created in an attempt to make it easy and exciting to write simple computer games with Python — removing all the obstacles, making it as simple as just connecting them to the computer and editing some files. And they work. The community around them is still very young, but people are using them.

That encourages me to keep working on µGame, and trying to turn it into a more polished and more powerful product. From user feedback and testing the main problem of µGame is memory problems — as soon as your program exceeds several hundred lines of code, you have to start jumping through hoops again — pre-compiling the Python code to save space, optimizing your code. The second problem is the small size of the device — which was required to keep the price low, but which is giving problems many users. I want to try and address those problems by designing and building another version of the µGame console, fully compatible with the current version, but bigger and with more memory — at the price of a higher cost of the device.

Once at it, I also want to improve other aspects, that were somewhat neglected in the initial design: sound, ergonomy, visual design, connectivity, etc.

  • PewPew M4

    deʃhipu09/04/2019 at 17:02 0 comments

    I have merged this project with the #PewPew Standalone a little while ago, and now I'm working on it at #PewPew M4 — follow there if you are interested.

  • Official Platform

    deʃhipu05/28/2018 at 07:12 7 comments

    Adafruit has just announced recently that they are working on a gaming platform for CircuitPython on their own. I'm very happy about that, because that means that I can stop working on µGame Turbo. You know, I only did this because I wanted this to exist, and I'm confident that Adafruit can do it much better and reach a much wider audience than I was ever able to.

    At the same time, I need to focus on the games and documentation for the existing #µGame consoles, as they still make a lot of sense. They are much smaller and cheaper than the Arcade Wing, and I think there is still some improvement that can be done for them in software to make them even more powerful. Together with the PewPew Wing they should make an excellent platform for workshops.

  • Debugging CircuitPython

    deʃhipu05/24/2018 at 08:34 0 comments

    As I said previously, I have µGame mostly working with CircuitPython 3.0 (Which today released the first beta! Congratulations!), but there are still some issues to be resolved. In particular, I have two libraries there that I need working: gamepad and _stage. The gamepad library works perfectly fine when being imported and initialized on the interactive console, but for some reason always tells me that no buttons are pressed when imported from a module. The _stage library works, but seems to crash after a minute or two. Today I decided to tackle both problems.

    Read more »

  • Taking Shape

    deʃhipu05/13/2018 at 19:30 0 comments

    Now that most important components are decided, I slowly started thinking about the exact shape of the console. Since I can't fit it in 5×5cm area anymore, and since the next limit, 10×10cm is so big, I decided to use some standard size. That would let me easily find boxes, among other things. So why not use the ISO/IEC 7810 ID-1 standard, also known as "the credit card"? It's large enough to hold comfortably, small enough that the 1.8" display doesn't look ridiculously tiny, and leaves me a lot of room for all the components, including the large headphone jack. Here's a mockup of how it could look like:

    The display sits inside a cutout, with the ribbon soldered to the bottom of the PCB. The only components on top of the PCB are the buttons, because it will be covered with a laser-cut transparent plate. On the lower edge of the PCB we can see the power switch, the USB port, the expansion headers, and the audio jack. There is also going to be a volume slider somewhere in there, as well as a reset button with a paperclip hole. There is going to be a set of more laser-cut plates on the bottom, holding the battery. The ports on the bottom will probably need to have their own recesses, so that they don't stick outside the credit card outline.

    This way I hope to achieve a very sturdy and relatively simple case. The PCB's silkscreen and etchings on the top plate can add markings and decorations, and the color of the PCB and the bottom plates can make it look gaudy. For example, the front plate might look like this:

  • CircuitPython 3.0 Bugs

    deʃhipu05/13/2018 at 08:42 0 comments

    CircuitPython 3.0 is now at its Alpha 6 release, but there have recently been some changes in how the clocks are handled on the SAMD51, and it seems everything is broken. The good news is that my game engine is *much* faster now — I can switch to updating the whole screen every frame (yay, scrolling!) without any noticeable slowdown. There is also all the RAM for the assets — it's definitely a huge improvement.

    On the other hand, when using partial updates the board crashes after several seconds of running (probably due to some race condition in SPI handling), the gamepad module that reads the buttons doesn't work at all, behaving really weird and not reading any presses, and even flashing the new firmware can make the board crash sometimes.

    But of course that is all expected in an alpha version of the firmware, and hopefully I can work around all the issues eventually, even if it takes a bit of work.

  • Stage Running on Metro M4 Express

    deʃhipu05/09/2018 at 20:46 0 comments

    Thanks to Adafruit, I have a prototype Metro M4 Express to test. In the last log I designed a shield for it with the screen and buttons, and today those PCBs came, so I assembled one, and got it to work.

    Well, mostly got it to work. As you can see, the colors are wrong (need to switch from RGB to BGR), the screen offset is wrong, and the screen size is wrong too. But those are simple fixes.

    What worries me more is that the current master build of CircuitPython is freezing after several seconds of playing the bouncing ball animation, and I will need to debug that.

  • Why not an Arduino Shield?

    deʃhipu04/26/2018 at 08:56 0 comments

    Adafruit has released their first SAMD51-based board, the Metro M4, and like most of their first prototypes, it's in the Arduino form factor. It makes sense for testing, really — it's big, relatively easy to route everything, a lot of space for adding components or changing connections when you iterate, etc. It also makes it easy for me to see how well it will work for µGame. I could just connect the display and buttons with a bunch of wires, but since I love procrastinating, I decided to make a shield instead:

    It's really very simple. I was lucky that the 1.8" display uses the same footprint as the 1.4" display I used earlier, so I didn't even have to make that. I made the button footprints double, so that I can use two kinds of buttons — the quiet silicon ones, or the standard clicky ones. I have a huge bag of the latter kind, and I need to use them up for something. The resistor is for limited the current for the backlight LED, and there is also the audio circuit (amplifier and speaker) copied from µGame on the back of this — I will be experimenting with audio anyways.

    I ordered the PCB at Aisler, because I need it quickly and it seems they have improved their CNC routing techniques greatly.

  • PyWeek

    deʃhipu04/15/2018 at 19:57 0 comments

    I didn't work much on this project recently, mostly being busy with #CircuitPython Badge, but I have plans for the upcoming week: there is PyWeek, with a theme of "two worlds", and that's a great opportunity to finally write an emulator for µGame, bridging the hardware and software worlds together. I am not actually going to be emulating the SAMD21 and the display etc. — instead, I will write another version of the #Stage library suitable for running in regular Python on the computer. That means there probably will be discrepancies, especially in terms of limitations, and to make sure your game actually works on the real hardware you will have to test it there — but it should still be a big help in developing the games.

  • ESP32 with TTGO 1.0

    deʃhipu04/03/2018 at 11:24 0 comments

    Looking for an ESP32 dev board that I could use to test my µGame libraries, I stumbled upon this TTGO 1.0 board, with a built-in ST7735 display. It was very cheap (how do they do that?) and had almost anything I needed — except for the buttons. So I made a simple daughter board with buttons for it:

    I still need to compile the firmware for it, and write the button-handling routines, though — that will take some time, with all the things happening recently.

  • Display Conclusion

    deʃhipu03/28/2018 at 18:03 0 comments

    After doing some work on the #Display Module Survey and also playing a litttle with M5Stack and Pokitto, I conclude  that I will use the 1.8" version of the ST7735 display. Why? It's large, but at the same time has pretty low resolution of 160×128. That means I can refresh it whole relatively fast, and that it has nice big pixels for all that pixelart graphics. It also means that it will be compatible with µGame's 128×128 graphics without having to do any double-pixel tricks or straining your sight to see a screen the size of a post stamp.

    The 320×240 displays have too tiny pixels — you can't really see the graphics on them properly, and to be visible, the sprites would need to be pretty high resolution, which means a lot of work for the artist and slow speed transferring them.

    The OLED displays are all too small — the biggest is SSD1351, which is pretty much the same as the one in µGame. They are also a bit hard to drive, with the need for high voltage.

    All the other displays are either too small, or too expensive, with little gain over the ST7745. So at least one design parameter is decided. I still don't know whether I will be driving it with 4-wire SPI, like in µGame, or with a parallel interface — some experimenting needs to happen for that. If I use the parallel mode, a new version of the #Stage, a Tile and Sprite Engine will need to be written for that, but there is a chance that it will be faster than SPI.

    Below you can see a comparison of the #µGame and the new display I plan to use:

View all 16 project logs

Enjoy this project?



aks69php wrote 09/23/2019 at 16:15 point

  Are you sure? yes | no

aks69php wrote 09/23/2019 at 16:14 point


  Are you sure? yes | no

aks69php wrote 09/23/2019 at 16:14 point

<a href="">game</a>

  Are you sure? yes | no

zakqwy wrote 03/22/2018 at 16:54 point

Those ALPS switches look excellent. Will need to pick some up.

  Are you sure? yes | no

deʃhipu wrote 03/22/2018 at 19:50 point

Might be the best thing that came out of #Ye Olde Nowt.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates