Thank you for sharing your work,you've done a great job.

 great console ) i'd like to try to port your invaders to my one. ESP8266 has MicroPython and as i know it's relative to CircuitPython. Hope it will not be hard to do.

Hi, great idea! Check out #Stage, a Tile and Sprite Engine — there is a MicroPython branch there for a working version of the library I'm using for µGame. It only misses sound support, because at the time ESP8266 being a second-class citizen in MicroPython didn't have support for the Sigma-Delta peripheral or another easy way to play PCM/WAV files in the background. You might be able to port the code from NodeMCU for that: https://nodemcu.readthedocs.io/en/master/modules/pcm/

Hi deshipu, I would like to know from where you source your st7735 ? Because it's quite to find outside ebay/aliexpress/etc, and I want to be sure to get the exact same reference each time I order some.

For prototypes I got them from aliexpress, and for production I let Makerfabs handle it, since they are in China and have all the contacts.

Ok thanks. And when buying from aliexpress, did you always get the same exact display ? Or are they physically different sometimes ?

There are several different models out there, however, so far they all were compatible as long as I was careful to specify the number of connections.

Thank you for all. I'll take care of the pin number.

Another one… Do you know if there is any difference between the red,green,blue tab version ? I tried setting FRMCTR1 to a higher refresh rate on my blue one, and I can't really (the screen becomes white). But with the default parameters, if update the whole buffer really quickly I can clearly see white lines appearing, as if the screen couldn't handle it. Do you have any tip on that ?

The different versions of this display will be connected to the chip in different ways: some will be RGB, some BGR, they will have different offsets (since the chip can handle up to 132x162 resolution, and the display is only 128x128, there is some freedom in which pins you can use horizontally and vertically).

Finally, some of those displays don't actually use the ST7735 chip, but a different one that just happens to use the same commands. Those chips will have different timing requirements.

I haven't seen the white lines effect on any displays I have tried, so I'm not sure what you describe, and of course I have no solution for it.

You can look at those pictures : 

https://photos.app.goo.gl/24v6hrUCXAS7y31X7

The first one is when refreshing the whole screen at 40/50fps, and the second at 10/20fps. The moving square is blurry mainly because of my smartphone, but the background is "whiteish" and this is my problem. The display seems to not handle correctly this refresh rate.

Edit:  Here https://photos.app.goo.gl/rPQSrKKuJRss3VX28 , here I use the same code on a st7735 128x160. Off course the square is blurry too, but as you can see the background is the same color on the fast and the slow fps. But this one has red tab. I think there are different performances for each display model.

I have no idea what the problem is. It may be the difference in chips, it may be difference with the TFT panel itself, it may even be something as trivial as the viewing angle.

Ok, thanks for your time. I've ordered other displays on aliexpress to test. Since the problem isn't present on the 128x160 I think (hope :p) the screen is under performing.

Ah ! Found the problem !

https://photos.app.goo.gl/sQVEk79K6EATy9ZH7

On the first image the sprite is going up and down and on the second left and right. When going up and down you can see black (empty ?) lines like some kind of interleave. And when going up and down no problem.

No idea yet to resolve it… Do you never had this kind of behavior ?

No, sorry. I'm not that experienced with TFT displays, really. I find it interesting that you have that effect not only at the edges of the moving sprite, but also in the middle of it, which, strictly speaking, didn't really move, at least not for a few frames.

For records, I understood what's going on. 
The hint is on this picture : https://photos.app.goo.gl/yp4FMHTamYB2uhyQ7

(zoom is your friend)

This is a problem of pixel density. Each pixel is composed of 3 leds (R,G,B), and each led is in a rectangle shape. If you use only (or mainly) 1 led for a pixel in a horizontal movement (or vertical depending of how your setup is) the distance between each illuminated led is greater than for a pixel with 3 leds illuminated. Resulting in a "black strips" problem.

So for low pixel density screens, using sprites with composite colors is a good idea.

This device is really cool, mine arrived today and I can't wait until tonight when I'll start writing games on it. One concern I have though is static discharge on this cute thing. Do you know if anyone has designed a 3D case for this yet? Do you have CAD file available for the uGame that I can draw a case around? Cheers!

Found the case that @davedarko made as well as the logs for the other case :) 

and I found the SCAD, I really didn't look very hard. Links for those even more lazy than myself:

https://www.thingiverse.com/thing:2797538
https://www.thingiverse.com/thing:2971913
https://hackaday.io/project/27629-game/log/89349-openscad-model

ah great, totally forgot that I made this :D I know I made one for myself, but it's much thinner because I was able to score a very thin LiPo :)

Sorry, I didn't see it, as Hackaday decided to not send me a notification (again). I see you found all you need already.

Could you get this to run GB, GBC, and GBA games?

GBA surely not, GBC or GB probably, but I don't want to. The point is to make your own games.

If you could get GB games to work on it then people could use something like GB Studio to make games for it, that's why I asked.

That is true, but they already can use GB Studio to make games for GB and a million GB emulators, including the Pocket Sprite, ODROID-GO, Pokitto, all RetroPie-based consoles, and, last but not least, pretty much any single Nintendo console. Porting a gameboy emulator to this device would be a lot of work, and I wouldn't really make this any different from all the other devices already on the market. I would rather spend that time writing new games.

Is there a documentation for the ugame library and how to use it? the paragraph here is just blank: https://circuitpython-stage.readthedocs.io/en/latest/

Sorry, I didn't get a notification about your message. It's fixed now.

Is there a firmware version based on CircuitPython 3? Or even better - is it possible to compile one from CircuitPython source code?

I'm still working on the version of firmware based on CircuitPython 3. The tests I did while it was developed worked fine, but there are several details that require some changes — in particular, the API for playing WAV files has changed, and that requires some work, which in turn changes the memory use and makes the Vacuum Invaders no longer fit...

TLDR: it's coming, but I can't promise when.

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.

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.

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

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.

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

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.

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 

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.

czy da sie na tym odpalic Ruby?

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

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.

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.

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

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

https://youtu.be/OFwM2CcnCAg?t=12m12s just saw it here :)

Thanks!

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

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.

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

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

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

well it seems to confuse people :(

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.

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?

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

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.

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.

What bootloader are you using for the SAMD21E18?

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

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 :)

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.

I fixed the schematic and put in the repository.

marvellous :)

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

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

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

albo komunikacja z internetu

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.

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

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

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

thanks. 

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!

is possible to programing it using SDL library?

No, the microcontroller is much too small for that.

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. 

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.