µ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.

  • Debugging CircuitPython

    ðeshipu4 days ago 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

    ðeshipu05/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

    ðeshipu05/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

    ðeshipu05/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?

    ðeshipu04/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

    ðeshipu04/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

    ðeshipu04/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

    ðeshipu03/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:

  • Connectivity Considerations

    ðeshipu03/22/2018 at 19:48 0 comments

    While still waiting for parts, I'm going to think about connectivity a little bit. This is something that I almost completely ignored in #µGame, and only at the end added a small header with four pins that I had free. Due to routing difficulties, that header is right in the middle of the PCB, normally under the battery, and so not very useful. Oh, there is also a debugging interface broken out, but that's also of limited use.

    This time I want to do better. The SAMD51 has much more pins that will remain free, so it makes sense to break them out on a header somewhere on the edge of the PCB. If I also break out all the pins that are used for buttons, that would make it possible to connected external controllers to it.

    Another option I'm considering is to use Seeedstudio's "grove" connectors, at least for some I2C/UART pins. This standard seems to be getting popular, and it would make it easy to connect additional sensors.

    If I end up using one of the ESP chips, I will have wireless connectivity for free — even though it's a bit tricky to use. Writing some libraries for simplifying communication for games seems like good idea then.

    Even with the SAMD51, I might want to add an IR LED and sensor. That would allow for some multiplayer games, and maybe things like trading. Plus, it could double as a TV-be-gone then.

    I'm not planning on any kind of SD cards or flash cartridges, even though the software supports it. Somehow I always preferred to have all the games in one place, with a menu to select them.

  • Preparing for the Tests

    ðeshipu03/20/2018 at 18:24 3 comments

    If you have read the very first log on this project, you know that I'm considering at least three different microcontrollers for this version of µGame. While I have already tested the ESP8266 option briefly, and I'm still waiting for an ESP32 devboard I want to use, there currently are very few options for testing SAMD51. Thanks to the generosity of Adafruit I have an early Metro M4 board, but I want to test with a little bit bare bones setup. There was a mouser order being made, so I decided to order two ATSAMD51J20AAU chips — the smallest package that has 256kB RAM.

View all 14 project logs

Enjoy this project?



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

ðeshipu 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