Thank you everyone! 125% backed and rising.
I am real, really working hard on releasing some tools for you guys ASAP.
I also promised you some footage of interesting stuff that can be done on the Pokitto.
Here you go:
awesome, and fool proof.
even though the “cough” emulation is slow it shows allot of the power that the device can handle
1 Like
Ah yes the video we were all waiting for! Thanks a lot. This video showing the working, screen and general performance means a lot. Gives a real nice indication of what is possible, thanks!
1 Like
I need to find the autofocus button on my camera… Its annoying af
1 Like
hehe nice video 
The gameboy emultor show the power of your CPU
Out of curiosity, what does the Pokitto do if you try to put more than one file on the Pokitto when it’s mounted as a flash drive?
If they are <256kb together, it should load them both into memory. Mind you, i have not tried this myself but that is how it works on other mbed systems
how would it select the program?
if it does work like that (I will try) it should load them in the memory space one after the other. The ability to jump from one program to another has to be done inside the programs.
@wuuff [quote=“wuuff, post:6, topic:95, full:true”]
Out of curiosity, what does the Pokitto do if you try to put more than one file on the Pokitto when it’s mounted as a flash drive?
[/quote]
I checked. The USB flash routines copy the files into the memory in the order that you drag them into the window. It is actually extremely cool, yet again.
You can make 3 programs, eg. pong.bin , pacman.bin and worms.bin
Then, if you drag them into the flash memory one by one, the first one you drag will go to the bottom of the memory 0x0000000, next on top of that, and so on.
Sounds like we need a game selector menu so we can have more than one game at a time (like gamebuino has) 
1 Like
what happens if you exit a game (return 0; in main) will it go to the next one?
Would it not be able to flash a new game from the sd card?
1 Like
@spinal Long story short: Pokitto WILL be able to flash new games from the SD. We are still looking for the most easy-to-use way of implementing this. All the components of the system are working separately, but a problem comes from our desire to make the system so that it is compatible with all the different development IDE’s that can be used (mbed online IDE, ARMGCC, ARMCC) because they all have a little bit different way of creating the binaries.
When we get good time, I will write a description of exactly what happens when the compiler creates a binary and teach how to look at it with a hex editor. The ARM Cortex program is surprisingly simple when you know what you are looking at.
Technical answer to @adekto: if the memory contains 2 binaries, lets say one at address 0x0000 0000 and a second one at 0x0000 2000 the MCU can not overrun the first program and then start executing the second one. A hard fault will occur, that will stop the MCU. The first program, however, can tell the MCU to jump to the second one. But what happens in a jump is more complicated than just pointing the PC (program counter) to the beginning of the next binary. Interrupt tables need to be copied to memory, and the second binary needs to have been compiled specifically to run from 0x0000 2000, not from 0.
i see, well that basically means cant be done (easly) without recompiling.
about the sd card, is there a way to make it show up as a drive or something?
There is a way to write PIE - position independent excecutable code. PIE code will run from any address. https://community.arm.com/tools/b/blog/posts/easy-as-pie----creating-bare-metal-position-independent-executables-with-arm-compiler-6
Different compilers need different compile settings to create PIE. It is a very interesting topic.
SD card can be made to show as a flash drive. It is basic stuff in mbed.
but that has to be part of every game to act has a sd drive right?
The flexibility of this ARM processor seems pretty cool. It sounds like your challenge right now is in deciding on a standard for all compiler platforms to follow so that all games are compatible? I guess it becomes a matter of having too many choices of how to design it rather than limitations to overcome.
1 Like
i kinda agree, we could all just set up the same set of tools having the main compiler/tools and focus on that, then fragment the userbase at the start, but it think some people might not like that since they like one compiler or another tool