Close
0%
0%

µGame

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

Similar projects worth following

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

  • Suddenly: A Speedup

    deʃhipu06/21/2019 at 15:53 0 comments

    The SAMD21 powering the µGame consoles is not a daemon of speed. With 48MHz clock and software floating point operations, not to mention the overhead from CircuitPython interpreter, it's barely enough for a dozen frames per second in a relatively simple game. But there is good news: a recently released beta version of CircuitPython, 4.1.0, has enabled an optimization option which has been so far disabled to save on firmware size. It had been re-enabled, because it turns out that it provides a five time speedup of the CircuitPython virtual machine, and the size savings weren't that big anyways.

    So now suddenly all µGames are going to be 5x faster as soon as you upgrade their firmware with 4.1.0 that you can download from http://circuitpython.org.

  • The Last µGame

    deʃhipu06/06/2019 at 19:57 7 comments

    Yesterday I received the order for the last µGame on Tindie. That makes it 111 units sold on Tindie (and maybe a dozen more sold elsewhere). Since I don't plan on making any more of them, that was the last µGame being sold.

    The project is not finished, of course — I will continue to improve the firmware, and I want to write a few more games for it. I won't be making promises, though — reality has a way of getting into my plans.

    If you want to try developing such games with CircuitPython yourself, you can now get the PyBadge board from Adafruit — apart from a slightly bigger screen and much more powerful MCU, it's compatible, so all the games should work on it.

    I have certainly learned a lot with this project, and I hope there will still grow a community of users for it.

  • CircuitPython 4.0.0 Released, Please Wait for 4.0.1

    deʃhipu05/20/2019 at 20:43 0 comments

    The CircuitPython 4.0.0 has just been released, and it does include support for µGame. However, due to last-minute breaking changes in RC4, and my travelling that made it impossible to fix it over the weekend in time for the release, the Stage library is broken in that release and won't work.

    So please refrain from upgrading for now.

    I'm being told that there should be a version 4.0.1 released next week or so, which will have it all fixed.

  • Underwhelming DMA

    deʃhipu04/19/2019 at 19:07 0 comments

    I finally worked on an improvement that I long wanted to do to the _stage library, which is at the heart of µGame: make the communication with the display asynchronous by using DMA. This way I can have two buffers, and calculate the contents of one of them while the other one is being sent to the display.

    As a test I used the balls demo from the tutorial, but with all waiting for the next frame removed — so they move as fast as they can.

    Here is how it works before DMA:

    And here is how it works with DMA:

    As you can see, there is barely any perceptible difference at all!

    The code I wrote for this is pretty nasty and hacky, and after seeing this, I don't think I have the heart to clean it up and send it as a pull request — it's simply not worth it.

    However, I will keep an eye for other ways of improving the firmware.

    UPDATE: Yes, I made some more precise measurements as well. Running through 1000 frames of the animation took the DMA version 31.034s and the non-DMA version 32.699s. That is 32.22 fps with DMA and 30.58 fps without.

    UPDATE2: I did a second test, with full-screen updates this time. 159.08s for non-DMA, versus 148.708s for DMA. That's 6.28 fps versus 6.72 fps. Even with such a large amount of data, the difference is negligible compared to the time spent computing it.

  • CircuitPython 4.0 and Display Support

    deʃhipu04/11/2019 at 23:12 0 comments

    The upcoming CircuitPython 4.0 introduces, among other things, built-in support for displays. That means that when there is an error in your code, you will be able to see it right there on the screen, without having to connect to some gnarly serial ports. For now the built-in display code is slow — fast enough for displaying text, but not for games. So I went and modified my #Stage, a Tile and Sprite Engine library to coexist with the displayio support, to get the best of both world — console using displayio, and fast updates using stage.

    There are still some tweaks left to do, perhaps use of a smaller font, and I still need to resolve the audioio problems that appeared with CircuitPython 3.0, but there are already nice improvements.

    I also hope to see if I can use DMA to speed up display updates considerably.

  • Updated Firmware with CircuitPython 3.2.0

    deʃhipu09/30/2018 at 10:21 0 comments

    CircuitPython 3.2.0 has been released a while ago, and brings a lot of bug fixes and some performance improvements. It would be nice to use it for µGame. Unfortunately, it also had some changes in how audio is handled, and since that interacted with available memory in ways that made the example games not work, it required more work on my part than just rebasing the repository.

    However, I managed to work around the problems, and a new version of the firmware is now available at https://github.com/python-ugame/circuitpython/releases/tag/ugame10-3.2.0. There is also a release of the Vacuum Invaders game specially updated for that version of firmware: https://github.com/python-ugame/vacuum-invaders/releases/tag/3.2.0. The other example games, as well as the tutorial, should work without any changes.

    In order to upgrade your device, you need to download the .uf2 file, and copy it to the TRINKETBOOT disk that appears when you press the "reset" button (located next to the direction buttons) twice. Once the file is copied, the device will reboot with the new firmware in place.

  • Another 3D-printed Case

    deʃhipu06/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

    deʃhipu05/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

    deʃhipu04/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

    deʃhipu04/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.

View all 55 project logs

Enjoy this project?

Share

Discussions

kingcredie168 wrote 06/27/2019 at 03:52 point

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

  Are you sure? yes | no

RomanS wrote 05/05/2019 at 22:12 point

 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.

  Are you sure? yes | no

deʃhipu wrote 05/06/2019 at 16:19 point

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/

  Are you sure? yes | no

guillaume.ludwig wrote 05/01/2019 at 18:40 point

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.

  Are you sure? yes | no

deʃhipu wrote 05/01/2019 at 19:08 point

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.

  Are you sure? yes | no

gml wrote 05/03/2019 at 14:36 point

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

  Are you sure? yes | no

deʃhipu wrote 05/03/2019 at 14:42 point

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.

  Are you sure? yes | no

guillaume.ludwig wrote 05/04/2019 at 20:15 point

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 ?

  Are you sure? yes | no

deʃhipu wrote 05/04/2019 at 20:30 point

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.

  Are you sure? yes | no

guillaume.ludwig wrote 05/05/2019 at 08:34 point

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.

  Are you sure? yes | no

deʃhipu wrote 05/05/2019 at 11:14 point

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.

  Are you sure? yes | no

guillaume.ludwig wrote 05/05/2019 at 12:27 point

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.

  Are you sure? yes | no

guillaume.ludwig wrote 05/05/2019 at 18:11 point

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 ?

  Are you sure? yes | no

deʃhipu wrote 05/05/2019 at 18:38 point

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.

  Are you sure? yes | no

guillaume.ludwig wrote 05/06/2019 at 19:10 point

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.

  Are you sure? yes | no

Josh Lloyd wrote 05/01/2019 at 00:09 point

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!

  Are you sure? yes | no

Josh Lloyd wrote 05/01/2019 at 00:35 point

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

  Are you sure? yes | no

Josh Lloyd wrote 05/01/2019 at 00:40 point

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

  Are you sure? yes | no

davedarko wrote 05/01/2019 at 06:45 point

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

  Are you sure? yes | no

deʃhipu wrote 05/01/2019 at 19:10 point

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

  Are you sure? yes | no

PixelDud wrote 04/27/2019 at 05:49 point

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

  Are you sure? yes | no

deʃhipu wrote 04/27/2019 at 07:17 point

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

  Are you sure? yes | no

PixelDud wrote 04/27/2019 at 13:54 point

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.

  Are you sure? yes | no

deʃhipu wrote 04/27/2019 at 15:39 point

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.

  Are you sure? yes | no

Dimitri wrote 09/27/2018 at 21:07 point

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/

  Are you sure? yes | no

deʃhipu wrote 04/27/2019 at 07:18 point

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

  Are you sure? yes | no

Szaja wrote 09/07/2018 at 14:53 point

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

  Are you sure? yes | no

deʃhipu wrote 09/07/2018 at 15:16 point

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.

  Are you sure? yes | no

Cameron Blackwood wrote 07/19/2018 at 08:08 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

deʃhipu wrote 07/19/2018 at 08:32 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

[deleted]

[this comment has been deleted]

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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

deʃhipu 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