Ok, so now I ended up drawing the whole thing in GLCDFont creator. Bummer
Edit: took exactly 33 minutes from scratch. C64 font for Pokitto coming right up
Sorry, I am a sw guy. I do not quite figure out how the ram vs. flash mem setup works. Is it so that the games, that are loaded from SD, are in ram or flash mem? If I think about c64, the games were always in ram. But in c64, the rom could not be reflashed (it could be replaced by ram but that is another story). So what is in flash mem and what is in ram in Pokitto?
2 Likes
The ARM Cortex chips have a unified memory map. This means that everything is inside the same 4GB memory addressing space (0x0000 0000-0xFFFF FFFF). There are some differences between the different Cortex products, but they all share pretty much the same basic architecture.
In Pokitto:
- FLASH is at the bottom 0x0000 0000 ⌠0x0004 0000
- RAM (SRAM0) starts from 0x1000 0000 ⌠0x1000 8000
- additional RAM that can be used (only in this chip) is the 2kB SRAM1 and further 2kB SRAM2 (see pic). This is a unique feature in this NXP chip, for example Arduino Zero does not have it
- another unique feature is the USB & other non-overwritable ROM routines at 0x1FFF 0000 (boot ROM), also a feature not found on Atmel chips (in other words on the Arduino)
- PERIPHERALS, the timers, UART, SPI, I2C, GPIO and everything else is also mapped into ports in the 4GB address space
And knowing @Hanski that you have some affection for the C64⌠you know what this means? Yes, you can basically make the ARM Cortex-M0 do pretty much anything you want by peeking and poking directly into ports in the address space!!
Now isnât that lovely?
2 Likes
And now @Hanski, comes the actual answer to your question.
ARM Cortex chips can run programs from the FLASH (ROM) or from RAM or in higher level Cortex chips even from external RAM/ROM chips that are mapped to the 4GB memory space (not possible on Pokitto)
The answer to your question of whether the games run in RAM or ROM (FLASH) is both.
- executable code and constant data (declared with const such as font bitmaps), that does not change during runtime is coming from the FLASH (ROM)
- dynamic data that changes during the execution (such as the screenbuffer that holds the pixels) is naturally inside the RAM
What makes this different from C64 is that the ARM Cortex can overwrite the FLASH ROM memory while the chip is running. This process is called IAP (In-Application Programming). In IAP, the chip goes into a special mode, where it can wipe and rewrite areas of the FLASH ROM while it is running.
It is like a doctor would be performing surgery on his own hand. Thatâs what makes this bootloader business tricky. You canât use the hand while you are operating on it 
4 Likes
That is all very interesting!
Poking & peeking is very cool 
Is it so that if you load the game from SD card, it stays in Pokitto even if the power is switched off, as it has been flashed to rom using iap? So you do not actually need SD card any more ?
Also does this mean that loading the game code do not eat 36 kb ram area, but 256 kb flash rom area?
Ok @jonne, I just watched your video #1, where you basically answered these questions. After reset the game is still there.
So Pokitto is able to run code in ram but that is just not currently used as there is not much ram?
Pokitto is able to run code in RAM, just like any other ARM Cortex device. Itâs not normally used, but if you want to do self-modifying executable code that is completely / partially in RAM, go ahead. Nothing is stopping you. The real challenge here is that in order to jump to code that is in the RAM space, you need to understand how to place executable code in RAM using linker files (.ld). But thats a bit of a long topic to cover here.
Think about this: Pokitto has 36kB of RAM, whereas the ATMega32u-based Arduboy has 32kB of FLASH with 2.5kB of RAM. You could do quite a bit just inside the RAM.
3 Likes
Such an interesting topic here. Thanks @jonne, youâre always clear and patient, I had some doubt as @Hanski and now something to study. Will the bootloader code release public too?
1 Like
Yes ofcourse. Only limitation is that you wonât be able to build it in the online mbed IDE because the online IDE canât support the necessary linker scripts. You need ARMGCC (I use EmBitz) offline toolchain to do it.
1 Like
First version of the loader without UI interface but with all SD card code and LCD code included now builds at 14800 bytes. So that means 15k out of 256k. Naturally the UI logic will probably add 5-15k more.
@Spinal @VonBednar probably we will have to hold a bit on the icons and stuff until I get an idea of how much memory we have left for that stuff.
So we need UI primitives, like window, list box, label, text edit box, virtual keyboard. And higher level elements like cancel dialog, progress dialog, info dialog, status bar, etc.
Do you need help in these?
1 Like
Yes please.
Pokitto lib already includes some elements (like keyboard) that are direct copies from the Gamebuino API (menu, keyboard, popup), but the problem is that they were made for a smaller-screen device (84x48) and secondly menu is built around declaring menu items as a list of const strings (so they go in flash) because Gamebuino had so little RAM memory. You can use them but the limitations are obvious.
If you feel like putting some code together, hereâs some thoughts:
- Window item should work with (at least) the 110x88 and 220x176 gfx resolutions (scalable)
- Listbox is what is needed first
- Dynamically allocation (push/pop new items) would be super appreciated, although I donât know how much overhead things like vector would cause
- Prompt box with ok/cancel would probably also be needed
So window and listbox.
@Initgraph has already made pretty nice listbox elements in his Chip8 editor. I emailed/messaged him about if its OK to re-use some of his code.
1 Like
I was thinking that a window can have borders. Maybe not needed for the main window.
Dynamic array for a listbox would be nice, but maybe we can manage with reallocating the whole array, when items are added. Using granularity of e.g. 5 items to avoid reallocating each time.
That leads me thinking about heap memory managing and fragmentation (ram). How that is handled in ARM malloc-code? Can it reuse free blocks and possibly combine them?
All I know about this is that the implementation is according to C++ standards, so I assume so.
However, it seems there is a significant overhead in allocating memory from the heap, which brings us to the question of whether its actually better to use a static array with a start and end pointers.
https://developer.mbed.org/questions/5277/Cant-allocate-more-than-3kb-heap-memory/
I like the convenience of vectors and stuff like that but since this is intended to be as compact as possible, maybe that convenience is not worth adding the whole vectors part.
The problem with Gamebuino was that the menus were stored in flash. Here we have enough RAM to store an array for the menu, and manipulate that. Maybe there needs to be a âmax menu itemsâ kind of limit to limit the amount of memory needed.
The original example in that was quite extreme; it allocated one byte at a time! In real use case the situation is not quite that bad.
Example:
- Having a list of 100 files. Each file has name and extension, letâs say: 10 chars for name + dot + 3 chars for extension. That results 2-bytes for alignment which is a nice estimate.
- String is 14 bytes. In addition, malloc uses 4 bytes for size and 2 bytes for 4-byte address alignment. So that is 20 bytes per string.
- For 100 strings that is 2kb (instead of 1.4kb)
Maybe that is still bearable (?). At least in this use case.
I am more worried about the statement that new-operator do not return NULL on OOM case.
Pics do not do justice how freaking crisp this thing is beginning to look.
@spinal your graphics thing is pure genius. I can print the whole interface, saving a lot of memory
@VonBednar Icons can be used. If you have time, please draw them so that they are 8x8 characters (the SD card outline) and the internal gfx as another 8x8 characters.
8 Likes
Genius eh? Sounds good, what graphics thing?
The way I âdrawâ that screen, borders included, is like this:
print("|FILE|")
directColor=CYAN
print("|SETTINGS| ") and so on
all the âbordersâ are characters in the character set. No other drawing operations are needed.
I must say you are a pretty clever dude. I would not have thought of such a brilliant scheme myself.
Edit: so for example, top of the file tab is jus print(âabbbbcâ); !!
Makes sense, similar to how an old text based graphics system might have done it.