Close
0%
0%

µGame

A handheld game console programmable with (Micro/Circuit)Python.

Similar projects worth following

I sell on Tindie

A small game console directly programmable in Python. I always wanted to make this, and after my work on #PewPew FeatherWing I finally decided that I'm ready.

The first version may be a bit of a stretch — I tried to make it as small as possible, fitting in the 5x5cm limit of PCB manufacturers, so that it will be cheap to make the PCBs. Using the cheap ST7735 TFT display, and a cheap ATSAMD21E chip. I also tried to put all the components on one side of the board.

Of course the hard part is writing a game library, and the actual games. There is already one simple platformer game written as a demo, and the software library is getting new features added as needed.

  • 1 × ST7735R 1.44" 14-pin TFT display
  • 6 × SKPMAPE010 tact switch
  • 1 × 2*4*3.5 tact switch
  • 1 × MK12C02 SPDT slide switch
  • 1 × DET402-G-1 speaker

View all 18 components

  • Another 3D-printed Case

    ꝺeshipu06/21/2018 at 20:40 0 comments

    A while back @davedarko made a simple case for µGame and made it available on Thingiverse. Now there is more choice, as Jovan Maric created another case. This one works even if you already attached your battery.

    Link to the design: https://www.thingiverse.com/thing:2971913

  • µGame Turbo is no More

    ꝺeshipu05/28/2018 at 07:28 0 comments

    After working on research and design for the #µGame Turbo for several months, and after Adafruit has started to work on their own version of a game console for CircuitPython, I decided that the improvements are not really worth the extra price and work, and decided to come back and focus on regular µGame more.

    There will be no more hardware iterations (except perhaps a small update changing the USB port to one that is more friendly to the fabricators), but there is still a lot that can be done in firmware and in the libraries. In particular, I have some ideas that I want to try to speed up the screen updates and to make more memory available for the games.

    The CircuitPython 3.0 is coming, Beta0 version was just released last week, and I've been working a little bit to make sure that all the libraries for µGame work with it. Right now I'm struggling with a change in the API for AudioIO, which makes CircuitPython try to allocate an extra 512 bytes of RAM every time you try to play a sound. Obviously that fails randomly in any larger game, as there is simply no room for it. But I'm sure a solution can be found — in the worst case, I will switch to a different way of making sounds.

  • In Stock Again

    ꝺeshipu04/30/2018 at 15:09 2 comments

    The freshly assembled µGames arrived straight from @Makerfabs and you can again get them from Tindie — there is a link at the top of this page. I will also take a few to #Hackaday | Belgrade 2018 — you can let me know in advance if you want to save on the shipping costs. I am not sure yet what other meetups I will attend (Makerfaire Prague is a possibility, and Europython is pretty much settled).

  • µGame Turbo

    ꝺeshipu04/02/2018 at 13:01 0 comments

    I didn't mention this yet here, but I have started work on an improved (and more expensive) version of this device. I the good old style of 80s, I decided to call it #µGame Turbo (if there is going to be a third version, it will be Super µGame Turbo, of course). I'm still researching most things, but the goal is to mostly have a physically bigger screen (same resolution), more memory and better audio (better speaker, volume control, headphone jack). It should be software-compatible with the current µGame, though.

    I am not sure how that project will go, and whether I will be selling that new version of the device too — there are currently simply too many variables.

  • New Shipment Soon

    ꝺeshipu03/23/2018 at 18:37 0 comments

    I just asked @Makerfabs for a quote on a new batch of µGames to be produced, and if everything goes well, they will be in stock in a couple of weeks. Also, the 3.0 version of CircuitPython is coming soon, and there will be a firmware update. The new version has greatly improved memory management, so it should help a little. I also fixed a few small bugs, and I plan to finally add the build-in art assets, which should also help with memory somewhat.

    In the meantime, I started to work on #µGame Turbo, and I entered it in the Hackaday Prize. I am not yet entirely sure where I will take this project, the only thing I'm certain of is that I want to keep it compatible with the current µGame — so that all the people who bought it are not left with an obsolete device. The new version will have more memory, so hopefully you won't need to pre-compile your files anymore, and I want to try and make it have proper audio, with volume control and headphone jack, a physically bigger display, and better connectors for external stuff. It will probably be more expensive, too, so it's more like an alternative to µGame coexisting with it side-by-side rather than a replacement.

    Finally, I just started today some sketches for another handheld, a #CircuitPython Game Badge, which is supposed to be even more minimal than µGame. The goal here is to minimize the price and power consumption, so that it could be used as a conference badge, given out to all participants. It's not going to be compatible with µGame, though.

  • µGame on ESP8266 with MicroPython

    ꝺeshipu02/24/2018 at 14:43 0 comments

    The SAMD21 chip is great for its native USB and the way you can just copy files on it, but since it's relatively new, the development boards for it are rather pricey. Plus, it really has small RAM and slow SPI, which limits what kind of games you can make.

    For making your own µGame clone, the ESP8266 could be a much better choice. 90kB of RAM and 40MHz SPI communication with the display (the esp can do 80MHz, but the display can't) make it a perfect solution. The only problem is a somewhat convoluted way of getting files on it, using external tools, but I might be able to do something about that with #ESP8266 Dev Board with True USB if I'm lucky. So I set out to try the µGame software on the ESP8266.

    The first try was using the CircuitPython firmware for Adafruit HUZZAH. Since the original µGame runs CircuitPython. Unfortunately, turns out that the HUZZAH board has been a little bit neglected, and some things don't work as expected with the current version. In particular, I couldn't get SPI to work while also using GPIO12 as D/C pin. After some failed attempts at fixing it quickly, I decided to try the good old MicroPython again.

    To do that, however, I had to port my _stage tile and and sprite engine to MicroPython from CircuitPython. While the two versions are very similar to the user, they differ substantially in their internal file organization, so I spent a whole night on this. But the result is very good:

    I'm using a new version of the #D1 Mini X-Pad Shield here, and a standard ST7735 breakout module. The picture on the screen doesn't look good, because of lighting — sorry about that, I don't have access to a better environment at the moment.

    In any case, the Jumper Wire game seems to be working very well. The modified MicroPython sources are available at https://github.com/deshipu/micropython/tree/stage so you can give it a go yourself!

  • The First Case

    ꝺeshipu02/22/2018 at 20:56 0 comments

    While several people are working on 3D-printed cases for the µGame, @davedarko is the first to deliver! He designed a minimalist case that covers the battery on the back, but leaves the PCB exposed for perusal. Since his µGame already had a battery attached, he sent the design to Szymon Jakubiak for printing and testing. When all was confirmed working, he printed two of them in colors matching the prototypes, and sent them to me:

    They look pretty slick, if I can say so myself!

  • Yes, we have no Bananas

    ꝺeshipu02/11/2018 at 19:54 0 comments

    It took less than two weeks, and all the µGames 10 are sold. I am both a bit surprised with how fast it went, and very grateful to everyone who bought one (a lot of them went to my friends). I don't plan on making any more of them for the next few weeks, at least until the Lunar New Year ends. I am now focusing on support of the devices that have their new owners, and on updating the firmware.

    Speaking of support, I already got some really valuable feedback. @Frank Buss seems to have a knack for finding all the rough edges, and his suggestions already improved the documentation and resulted in some ideas about improving the firmware. Jell also reported some issues, which have been added to the docs. I expect to receive even more feedback as the devices arrive and their owners start experimenting with them seriously.

    I'm also going to work on making an emulator for this device — even if it's not going to emulate all of its limitations, it should allow easier development and debugging. You will still need to test against a real device to make sure that there is enough memory and that the speed is acceptable, though — it's not going to be a "real" emulator, just a version of the Stage library that runs on regular Python.

  • OpenSCAD Model

    ꝺeshipu02/09/2018 at 20:24 0 comments

    I've been asked about the dimensions of µGame 10, hole sizes and placement, etc. — so I decided to sit down and update the OpenSCAD model that I made some time ago for µGame 6. I have put it in the repository at https://github.com/python-ugame/ugame-10-hardware

    You should be able to import it into most 3D modelling software, and from there you can use it to design cases and all sort of other things.

  • nGame Revisited

    ꝺeshipu02/05/2018 at 21:15 2 comments

    nGame (nano-game) is the tiny little brother of µGame that I made just to see if I can do it. It's a little bit bigger than an inch on a side. I got the hardware working, but I didn't have any program to test it with, since all the games I've written so far were too big to fit on the chip's flash (unlike µGame, nGame doesn't have a separate flash chip for the filesystem). When I was picking the projects to send to FOSDEM to be shown at the MicroPython table, I thought I could include nGame, and I realized that the bouncing ball demo that I added recently should fit just fine. So I quickly uploaded that, and it worked out of the box, except for the wrong colors (RGB vs. BGR) and different screen size (160×80 instead of 128×128). But I didn't have time to fix it, so I sent it like that.

    Today evening I finally had some time to sit down and do it properly — I just needed to fix the display driver, and fix the code where I hard-coded the screen size.

View all 49 project logs

Enjoy this project?

Share

Discussions

Cameron Blackwood wrote a day ago point

Im curious about the 4 debug pins on the back. They seem to be PA-14/15/16/28 on the chip. So these are just general purpose pins? Do you use them as a uart or i2c or something else? Ive just been pondering some cool uses for this with a bluetooth/wifi connection or some such.

  Are you sure? yes | no

ꝺeshipu wrote a day ago point

The debug pins are on the side — they are PA30 and PA31, for SWIM. The four pins on the back are just pins that I had free, so I broke them out just in case. I don't really have any use for them, but you could connect an accelerometer or some other sensor there, I suppose.

  Are you sure? yes | no

Hendra Kusumah wrote 06/08/2018 at 17:39 point

just bought an st7735 1.8 inch screen. Is it possible for me to build this using that screen and using esp8266/esp32 as the main microcontroller

  Are you sure? yes | no

ꝺeshipu wrote 06/08/2018 at 23:53 point

Yes, see https://hackaday.io/project/27629-game/log/100992-game-on-esp8266-with-micropython

However, you will need to find some way of handling the buttons. I used a small additional microcontroller connected over i2c to check the buttons, you might find a better way.

  Are you sure? yes | no

Hendra Kusumah wrote 06/09/2018 at 19:33 point

You sir are an awesome hacker. The ugame and st775r library is working but the _stage module means I have to compile the micropython firmware by myself right? Sorry if I am asking too much, but do you have a compiled firmware of your esp8266? 

And Btw, I am finally order your X-pad shield in order to build this with an esp8266.

Thank You

  Are you sure? yes | no

ꝺeshipu wrote 06/09/2018 at 20:23 point

Yes, unfortunately the _stage module is not included in MicroPython by default, and you have to build your own firmware with it. Give it a try, and if you have problems with it, we can look for a different solution.

  Are you sure? yes | no

Hendra Kusumah wrote 06/10/2018 at 21:45 point

The only thing that makes avoiding building the firmware since I tinker with micropython is linux. Since my PC only have minimum RAM for virtualbox and compiling it on the Raspberry Pi is a real challenge. But it seems I have to give it a try then. Thanks for the suggestion 

  Are you sure? yes | no

ꝺeshipu wrote 06/10/2018 at 23:00 point

I suppose that sooner or later you will install Linux on your computer. There is no xtensa compiler for the ARM processors, as far as I know, so you may have problems with compiling on the Raspberry Pi.

  Are you sure? yes | no

fabian wrote 05/31/2018 at 09:49 point

czy da sie na tym odpalic Ruby?

czy ma to MMU jak kolwiek to nazwac tryb chroniony czy separacje procesow

  Are you sure? yes | no

ꝺeshipu wrote 05/31/2018 at 18:34 point

Nie, to jest ARM Cortex-M0 z 32kB RAM i zegarem 48MHz. CircuitPython chodzi na tym bezpośrednio, bez żadnego systemu operacyjnego, który by zarządzał procesami. Wielozadaniowość da się osiągnąć korutynami.

  Are you sure? yes | no

codemasterPL wrote 05/30/2018 at 12:33 point

Hi,


can this be programmed with Arduino / C++ ?

  Are you sure? yes | no

ꝺeshipu wrote 05/30/2018 at 12:58 point

Yes, technically there is nothing preventing you from that. It uses the same microcontroller as Arduino Zero and many Adafruit boards, so the support is there. However, you will probably need to write your own board definition file (to expose the pins that are used for the screen, buttons and audio), and write or port the libraries for handling the screen and audio.

I was actually thinking about porting the Arduboy/Gamebuino libraries to it, however, there is only so much time I have, and I would rather focus on CircuitPython, as that's the unique feature of this device.

  Are you sure? yes | no

codemasterPL wrote 05/30/2018 at 15:30 point

the thing is i don't like the idea of that having some layer, i need barebones to code gfx library and the game engine itself - absolutely not based on python.

The console hardware is extremely cool (missing wifi only) - and i'm interested in coding C++ for that, so you say that's possible., that's very nice - as i am interested in building a real game engine for it in C++.

when you plug it into usb, is it becoming available as a serial port for Arduino IDE ? how is it programmed?

  Are you sure? yes | no

ꝺeshipu wrote 05/30/2018 at 15:40 point

If you press reset twice, that runs the bootloader, which makes a fake USB drive appear called "TRINKETBOOT" (because I used Adafruit's bootloader for that board). You just need to copy a .uf2 file to it to flash your firmware. You can generate an .uf2 file from a .hex file with uf2tool (https://github.com/Microsoft/uf2). I think that Adafruit's Arduino board definitions for the M0 boards do all this for you, so you could use that as a base, and just change the pin definitions. You can see which pins are used for what here: https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/boards/ugame10/pins.c

  Are you sure? yes | no

ꝺeshipu wrote 05/30/2018 at 15:49 point

Or you can just forget uf2 and flash the Arduino bootloader.

  Are you sure? yes | no

davedarko wrote 02/10/2018 at 21:57 point

  Are you sure? yes | no

ꝺeshipu wrote 02/10/2018 at 22:00 point

Thanks!

I wonder where they got the "10 games pre-installed" lie from, though.

  Are you sure? yes | no

davedarko wrote 02/11/2018 at 12:10 point

it says 10 game on the back of the pcb and in the title of the tindie product, I was about to ask why you've called it that way. Maybe @mickmake can issue a correction for the next one.

  Are you sure? yes | no

ꝺeshipu wrote 02/11/2018 at 12:22 point

It's the 10th version. I included the version in the name, because the firmware is not compatible between hardware versions (the pins changed).

  Are you sure? yes | no

davedarko wrote 02/11/2018 at 14:17 point

maybe uGame X gaming platform works better? or uGame10 gaming console kit

  Are you sure? yes | no

ꝺeshipu wrote 02/11/2018 at 21:59 point

Right, and put a fruit on it. Over my dead body.

  Are you sure? yes | no

davedarko wrote 02/11/2018 at 23:15 point

well it seems to confuse people :(

  Are you sure? yes | no

ꝺeshipu wrote 02/12/2018 at 00:18 point

I think that whatever I do, some people are going to be confused. And I think that this is fine. Confusion is a sign of learning — it means you are breaking the old patterns and discovering something new.

  Are you sure? yes | no

Frank Buss wrote 02/10/2018 at 17:04 point

I copied the files from https://github.com/python-ugame/vacuum-invaders to it, but get only a white screen on reset. Is this supposed to work on the ugame10?

  Are you sure? yes | no

ꝺeshipu wrote 02/10/2018 at 17:09 point

You are probably getting a MemoryError. Make sure you only copy the game.mpy and not game.py — that game pushes the limits of program size, and only works as precompiled code. More information about troubleshooting is available at: http://ugame.readthedocs.io/en/latest/usage.html#troubleshooting

  Are you sure? yes | no

Frank Buss wrote 02/11/2018 at 04:44 point

There is no game.mpy in the repository. I tried to use the console with minicom, and I can see the Python repl and enter commands, but there is no error output. I tried the tutorial, but it didn't autostart the main.py, only after reset (after I deleted all files and created a new main.py). And once the main.py file was corrupt after reset. Once it autostarted, but then the file in the editor was invalid, because it mounted the file system again.
I'm using Debian Linux. Doesn't look like a good system so far for newbie users. Compare this to Arduino, which works out of the box.

  Are you sure? yes | no

ꝺeshipu wrote 02/11/2018 at 11:49 point

I can assure you this also works out of the box. I suspect you have corrupted the filesystem by unplugging or hard-resetting it while the files were still copying. Normally you wouldn't touch the reset button, it resets automatically. You can run fsck on it, or follow the troubleshooting link I gave earlier to fix it. To avoid it in the future, please unmount the drive before unplugging or hard-resetting the device, so that all the data can be safely copied. I will add a section about this to the user guide.

  Are you sure? yes | no

Jon Raymond wrote 01/31/2018 at 19:15 point

What bootloader are you using for the SAMD21E18?

  Are you sure? yes | no

ꝺeshipu wrote 01/31/2018 at 20:38 point

The UF2, just like all the other CircuitPython boards: https://github.com/Microsoft/uf2-samd21/

  Are you sure? yes | no

davedarko wrote 01/27/2018 at 09:12 point

Do the schematics contain a hacked footprint for the LCD? because the labels and connections absolutely don't fit together :D

great project, good luck with tindie and everything :)

  Are you sure? yes | no

ꝺeshipu wrote 01/27/2018 at 09:42 point

Yeah, there are several problems with the schematic. The labels on the amplifier are reversed too. I need to fix those at some point, but since it worked, I didn't have much incentive.

  Are you sure? yes | no

ꝺeshipu wrote 01/27/2018 at 10:28 point

I fixed the schematic and put in the repository.

  Are you sure? yes | no

davedarko wrote 01/27/2018 at 10:33 point

marvellous :)

  Are you sure? yes | no

MatejEusk wrote 12/27/2017 at 07:44 point

Czesc.Nice project.Can I buy 1x and make 3d printed case and buttons?Also I can do pixelart ,chipmusic...

  Are you sure? yes | no

ꝺeshipu wrote 12/29/2017 at 23:46 point

I will be selling them on Tindie soon, I will post here when that happens.

  Are you sure? yes | no

święty wrote 12/12/2017 at 17:47 point

Czy bedzie kiedys komunikacja? Dało by się zrobić kalendarz, notatnik (baza danych)

albo komunikacja z internetu

  Are you sure? yes | no

ꝺeshipu wrote 12/29/2017 at 23:45 point

Nie przewiduję w tej wersji żadnej komunikacji poza USB. Projekt jest wystarczająco trudny i bez tego. Być może przyszłe wersje będą miały jakąś możliwość komunikacji — BLE albo WiFi — zobaczymy co los przyniesie.

  Are you sure? yes | no

Jasper parker wrote 12/06/2017 at 01:15 point

This looks fantastic Radomir, very impressive project! Should be able to sell these on Seeed.

  Are you sure? yes | no

ꝺeshipu wrote 12/29/2017 at 23:43 point

Thanks, I will be selling them on Tindie soon. I contacted Seeed, but I find it very difficult to talk with them.

  Are you sure? yes | no

Makerfabs wrote 02/02/2018 at 03:52 point

i take this comment  approval of we makerfabs'  production service :)

thanks. 

  Are you sure? yes | no

ꝺeshipu wrote 02/02/2018 at 14:12 point

Yes, it was much easier and more professional to talk with Makerfabs, that's why I choose them in the end. Big thanks for helping me with this!

  Are you sure? yes | no

ia wrote 10/29/2017 at 16:17 point

is possible to programing it using SDL library?

  Are you sure? yes | no

ꝺeshipu wrote 10/29/2017 at 18:29 point

No, the microcontroller is much too small for that.

  Are you sure? yes | no

Malik Enes Şafak wrote 10/29/2017 at 15:26 point

Is your screen 160x128? You can use new gamebuino meta libraries (not published yet) for this console. Same screen resolution, same microcontroller. Also check Pokitto, Gamebuino and Arduboy libraries. They all open source and you can learn lot of thing from these consoles. I really like this idea. If you will sell or publish this console open source please let me know. I really like to get one. 

  Are you sure? yes | no

ꝺeshipu wrote 10/29/2017 at 18:34 point

Thank you. I will definitely look at their code once it becomes available — what I have so far are tricks I picked up from old platforms, like Gameboy or NES. I expect they will be using similar techniques.

I think that gamebouino libraries won't work for me, because while the display has similar resolution (128x128 for mine) and number of colors, it's connected differently — mine uses SPI, their is most likely connected using parallel protocol — otherwise they wouldn't be able to achieve the speed they are claiming.

I also really want this to be easily programmable in Python, and all the consoles you listed use C, which admittedly is easier performance-wise, but not in the speed of development.

  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