That is how it worked on C64. It has even dedicated char codes for changing the color 
Thought char-gfx was very rarely used in the game UI. C64 games implemented own UI by using bitmap graphics (not very re-usable!)
The most extensive usage of char based UI, that I have seen, was Borland Turbo Pascal for Dos! It implemented the whole windowing system using it.
It’s like a neon bar is glowing on the screen. The effect is very nice.
I will re-draw the icons as soon as I get back home (1h or so). Will have them done today 
EDIT: …and done.
@jonne Here are the SD icons redrawn in 8x8 grid. I tried to reuse the same “characters” as much as I could (not sure if you needed it this way). This is how they all fit together:
The first four tiles (left top & bottom and middle top & bottom) in each icon are always the same. The top right is always different and bottom right is only different in ? and text file icons.
The faces are aligned so you can call them at the same X and Y+4 as the sd card (assuming that black will be transparent)
Here’s the tileset in 1x1 ratio
:
If you need any changes, let me know. I will grab some food and check the forum in an hour or so
Looks good to me
I love how all of these tests are on incomplete Pokitto units… It would be nice to see a completed console doing something though 
Yes I think its bad PR for me to use an open prototype, I’ve thought about that also. Scares people away.
Another thing I should invest in is a camera that is not a 1.2 megapixel potato.
No actually I have a good camera. Its just the hassle of setting it up etc. I should have a photo-corner with fixed lights etc.
Quick sketch of the prompt box. @spinal 's little pixel Pokitto keeps on getting on the camera.
I would like to use the same widgets (list) as much as possible in the UI because then there is no code duplication = least amount of memory used.
Looking really good. I can;t wait until we all get to try it out
Loving this! Freaking awesome!
Just a question:
Using EmBitz will be possible to debug and develop using the same pokitto lib as the Code::Blocks project?
If so, do we need special hardware to debug?
Are there benefits against using the simulator solution?
I suppose I’ve ended with 3 questions… 
Yes. That was the whole point. I write almost all my code in Code::Blocks and use the same code (no changes) in EmBitz. The core project files are the same.
Yes, but I have good news:
a) we will have a really cheap legal debugger option for you (20USD-ish) that is already tested and fully open source
b) I think it might be possible in the near future to debug Pokitto with another Pokitto. At least I seen no technical reason why not
c) You can also use an LPCXPresso LPC11U68 board (it has a LPC-Link debugger on it) to debug Pokitto (https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-embedded-mcu-dsp/786?k=LPC11U68&k=&pkeyword=LPC11U68&v=982&FV=ffe00312&mnonly=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25)
d) If you want to work like a pro, you can buy Segger J-Link Edu at 60 USD
If you only make games, you can get very far with the simulator / debugging using output from the program. There is actually a console class already designed for outputting debug data during execution but I havent had time to update it. It allows you to output debug messages on screen on top of your application. That said, a hardware debugger is a beautiful thing, but it can be difficult to learn. One of my aims is to publish information on how anyone can get started with ARM Cortex debugging on the cheap and explain how free/cheap software is used for development. There’s alot of things I’ve had to figure out on the way and I want to share that also.
I was sure I had to buy 2 pokitto 
Anyway can the a option be added to my pokitto to share the same shipping cost?
Let me see if that is possible.
Loader is now jumping cleanly between 2 programs. This means the MCU shuts down cleanly and jumps to the new program cleanly and runs it 100% correct. This means we can have many resident programs at the same time that can all control LCD, read SD, read buttons, make sound etc. It’s very very nice. Video coming later
Some day I will tell you exactly what happened but good grief there was some nasty nasty stuff on the way. I had to learn to debug with multiple symbol files from gdb command line among other things. I found a mistake in the cmsis_nvic initialization that was done by ARMmbed themselves.
The bootloader in Pokitto is pushing the boundary of whats been done on the Cortex-M0+.
That is fantastic news!
SS PokittoLoader going where no one has gone before 
Captain Jonne leading the way 
Hey !
I need feedback / graphical testing / ideas
I am thinking about something like this. The idea is that each game (if the author has supplied it) has an embedded icon of 32x32 pixels at 16 colors. This icon & basic info “pops up” in the file loader windows as you scroll down the files.
The reason for this size (32x32) is that I can then put the icon of the current program into the EEPROM and use it in the start menu even when SD card is not present (its a bit complicated but anyways). Also included is the name of the game and 1 byte for the “game style” (action / puzzle etc)
Do you “get” this idea or should I think about another kind of UI?
I do not have any improvent ideas, but to me that looks very nice! Definitely better with screenshots than without.
It looks good to me.
Would it be a fixed palette, or a custom one per icon?
