SD card capabilities


I have been following the progress of the Pokitto for a while now, and I was wondering about how the SD card will work for it. I have a Gamebuino, and I am used to the ability to load games directly from the SD card without having to directly program it. Does the Pokitto have something similar to the Gamebuino’s loader to allow someone to “flash” a new game on the Pokitto without connecting it to a computer? I assume it isn’t too hard to load code into program memory, but without a standardized bootloader, games wouldn’t be compatible and might not support loading a different game from SD. I think the value of being able to switch games without connecting to a computer is a killer feature, so I wanted to know if the Pokitto supports this by default.

Hi @wuuff !

I know your concern about this thing. Let me explain:

making the console so, that you can switch games from SD is not technically difficult. In fact, I already have the code to do so.

The problem is that Pokitto has several toolchains. 1) online mbed 2) offline armgcc and 3) simulator. These toolchains have different ways of working. The online mbed toochain is based on armcc. The offline is based on armgcc.

The trick here is to find a way of switching games that is user-friendly in all these circumstances. That is what I am working on at the moment, and I am confident I will find a good solution before the units ship. I have solved all problems until now.


Any news about the bootloader?

1 Like

Yes. I have figured it out. Its a binary blob compiled in the offline compiler to run from a high address. There will be a tool that hooks it up to the main code & verifies “bootability”. A little unorthodox, but bc mbed online IDE linker settings are not open, that is the best way to do it.

Good news is that I am going to Sweden by boat. Tomorrow. For two days. I hate cruiseboats, so the loader will probably be very far by the time I get back.


File selector almost implemented:

  • search for files
  • search step by step
  • search only files that have certain externsion (.dat, .bmp, etc…)

The underlying functions can be used without the fileselector


That is awesome!

At later date it would be good to have a more user friendly GUI on startup that shows the games stored on sd card, so kinds and newbies can just pick it up and play.

It would also allow us to use some metadata for a game akin to what something like Nintendo DS does (icon and name…maybe even a short description)

Yes this is still rough. One of the issues is that on Pokitto we can have many different windows sizes. So ideally you should be able to choose the size of the menu window:

Edit: menus have also been fixed. And randomize now works.

But the main achievement here was writing the directory listing capabilities, searching for first valid file and then filtering based on extension.


looks good, would like to set some best practices on having some sort of folder container (similar to .app) so we dont have game data scattered around the sd card from multiple games
that be also the place to put the metadata stuff

but this is already useable

1 Like

Problem is that directory support adds quite a bit of code overhead. This is due to the nature of the FAT filesystem.

I will have to see how much it costs in terms of RAM/Flash

What we should have is some sort of an asset packer.

1 Like

asset packer/unpacker is going to give us similar memory problems

The packing is done on a PC. What I am suggesting is a single file that has all the assets clumped together.

Edit: it is simply a matter of jumping to the right address in the file to retrieve the asset

yea ok i can see that

isnt that what pico8 dous kinda?

I don’t know. Does it do that ?

well the distro files are png and the lua is int he metadata,
but all its code sound and sprites are in the same p8 file
i think there like a title tagg inbetween them

ether way we may need some sort of index on top the file to know where stuff is at
im asuming this is read only, putting a save data in there aswell might be unsafe (unless we do those at the end of file)

what FAT version you using, since theres a max file size

FAT16 … its my custom version of PetitFATFS, that also has file writing capability

ok so that a file size limit of 2gb
im not sure how it loads the file in, does it have tor crawl true the hole thing?

I have been thinking about other options for a loader. For games to be loaded by just connecting the Pokitto by usb and placing a single compiled file on it, I guess there really is no other way besides linking the compiled binary with the loader.

Would it be possible, though, to load games with an independent loader by rewriting the assembly? One thing I was curious about is whether code always starts executing from a specific address on the Pokitto, and if so, what address it is. A small stub loader could be loaded at a high address, which could load a larger loader from a file with a fixed name in the top level directory on the SD card, as in the Gamebuino. As long as the first instruction of a game isn’t a jump instruction, it could be saved at a high address, overwritten with an absolute jump to the loader, and then every time the Pokitto is started control would first jump to the loader, which could either pass control back to the game (after which the loader could not be accessed unless the Pokitto was reset), or a different game could be initialized by the loader in the same way. The process could be started by placing a version of the loader with no game on the Pokitto by usb.

I doubt this is the approach you want to take with this, but I was just thinking about the possibility. I’m just concerned about if there’s an extra linking requirement, will it be possible to take any compiled game for the system and link it with the loader (space permitting), if the original creator of a game hasn’t? Will all compiled games for the system that are small enough be compatible? And how small can we make the loader to ensure games have as much space as possible?

Thanks for your ideas. I had to read that about four times and still am not sure what you mean :wink:

All ARM Cortex M0 begin executing code in the same way. After reset, the chip loads SP (stack pointer) and PC (program counter) from the beginning of the default vector table at 0x00000000.

All the problems in making a bootloader are caused by the mbed online compiler, that insists your program has to be linked to start at 0x0. Currently there is no way to avoid this. On offline compiler, you can link your app to run from a high address, no problem there.

Otherwise the mbed online compiler and the built-in USB ISP of the chip is a joy: no installation and the thing just works. Having pulled my hair with Arduinos that refuse to connect to STK-500 calls or need pressing reset at just the right moment, it definitely feels more robust.

There needs to be some quality control tool in bootable apps. That can not be avoided. What I will do is the loader checks the program the user is trying to switch to and if it does not find a verification checksum from the “make bootable” tool, it informs the user and stops before any accidents occur. I am also trying to do this in such a way, that since the SD card routines are already present in the booloader/loader stub, the user app can use them, thereby saving space.

Another thing I am trying to avoid is the “double-flashing” of the Gamebuino: first you flash the loader, then you flash again the program.

On the NXP LPC11U68, with 36kb SRAM the whole loader could fit and run from RAM. This is another possibility. The entire loader could be a header blob included in the Pokitto lib, called at startup before main runs.

little unrelated, might have answered before
but wen the pokitto is turned on and plugged into pc, will it act like an sd card reader?