How big are programs/games allowed to be on the Pokitto?
I was working on the bootloader last night. It was annoying to stop & go to sleep b/c I got it so close to 100% functional.
Anyhow the bootloader is at 20kB at the moment.
So I would say 256-24=232 to be on safe side.
I will check later today how much of that is the core lib
~232Kb is what you figure? What about using the SD card? Is there a way to read in data through the SD card reader from within an app, for instance, having an app that can read a text file?
Yes, data can be read from SD no problem. Anything you need really, from levels to gfx to music. With this bootloader I’ve made, would actually be possible to extend game over multiple binaries (because it can jump without reset cleanly)
does anyone here actually know how the multi disk games were coded on things like the Amiga?
I actually saw this video a while back and searched like 20 minutes for it: https://www.youtube.com/watch?v=NLEMsw1SjDY
The entire video is interesting, but he talks about bank switching on the Atari. Is this what you meant?
Bank switching is a similar thing yes. For example Gameboy and NES did it to enable larger games.
Bank switching on Pokitto… … … would be possible…
my geeklodes are tingling
Ok so I’ve had an idea. Thanks @crait
Traditionally the bootloader on mcu’s is done in a way that resets the device after loading (for example Gamebuino)
Because I need to take into account the fact that mbed online compiler does not allow for a custom linker script, I had to develop a workaround. This involves de-initializing and re-initializing the mcu without a reset. I didn’t think about it but it would also give us an ability to jump from binary to binary and keep the mcu executing. Game part 1 loads game part 2 loads game part 3 etc while maintaining game state.
This idea needs to be worked on after we ship the KS units. Just like with the old game systems, the opportunity for cool hacks is limited only by imagination and determination.
ok its not soft rebooting but its still reflashing itself? or are we talking ram execution?
Its flashing itself while running… its a bit crazy
Somebody asked me what’s so hard about this bootloading thing I’ve been coding. I told him its like a surgeon operating on his/her own hand. You gotta be sure you don’t need the hand you’re cutting while the operation is in progress, otherwise you’re… screwed. The “other hand” in this case is how to handle interrupts, SysTick and stack while flashing.
Can’t the Cortex-M0 run code out of RAM? The M3’s & 4’s I normally work on do. So you do a two-step dance. The bootloader and bit of code to copy it to flash are copied to ram, then you jump into that code and to install the bootloader.
Yes indeed that can be done.
One strategy would be to have the loader as a blob that is copied to RAM and then run.
At the moment I am using the last page of the flash to store the loader. The interrupt vector table is in the RAM.
Problems are mainly caused by the limitations of the mbed online compiler. Its ARMCC based, and the user can not compile with a custom scatter file. So any bootloader strategy has to take into account that the mbed online ide will always produce position-dependent code that is linked to run from 0x0.
You also can not have custom startup files. Therefore you have no real way of running custom code before main is called and/or positioning code at specific address until runtime.
CAVEAT EMPTOR: I have no formal training on any of this. You may well find flaws in my logic.
What’s the feasibility of an upcoming project I want to work on?
I have designed a fun lil’ card game similar to the Pokemon TCG. More specifically, like the Pokemon TCG on GBC.
I’m still working out how I’d best be able to load cards from the SD card as if they are some kind of script. I think I know of a clever way to pack the data.
Having the cards in a database on the SD card will allow me to include card art, as well as have an expansive database of cards.
The formal training comes in the form of data sheets. Also, in the world of software development, I’m at least 30 years into this, and I’m pretty sure we make it up as we go along.
is there a way to do this with sd to ram and execute system code? or do we have to do interpreted systems basic, python, forth?
i can deal with the small memory alocations like a bunch of tiny ram games together to make a biger game almoust like a unix system handing off proceses from one program to the next.
im concerned about bricking the flash or just wearing out the flash since micro controller flash isnt meant for constant rewrites
you can dump a binary straight from SD to RAM and jump to it
thats neat, but need some examples for that on how to do that
also how to return back to flash or load another section of the program into the ram
and how to retain some “global” data
basicly a tiny os almoust
- you can’t brick this MCU. The built-in ROM bootloader is burned on the silicon and will always respond, unless you physically burn the chip
- the modular construction of Pokitto allows us to sell spare parts of all components at a reasonable price and those will be available. A new PCB will be alot less than a complete system. I hope everyone experiements alot and will try to support it as much as possible
Well, lucky you. That’s exactly what I had to learn for the bootloader and I’m happy to pass it on.
Out of curiosity, why is the bootloader “so” big…? Is that 20KB doing other things besides loading USB data into program rom? And that 20KB doesn’t include the ‘free’ built-in ROM bootloader, so your bootloader is on top of, or separate from the built-in bootloader? I’m guessing part of the size is due to bloatware of mbed?
What specific mcu is part number this lil guy? Will the whole design be open enough to allow us to write out own bootloader, or other low level code avoid all the annoyances of mbed? I’d much prefer “baremetal” development without an IDE, just vim and gcc-arm-none-eabi if I can pull it off. Sounds like I’ll have to write my own low level drivers to make that happen?
Lots of questions, going to answer in parts (on the move, tapping on the phone)
The 20kB is a loader, not a bootloader. The entire business logic is in it: initializing SD, lcd, gpios (buttons), display menu, error screens. You may ask why and I will explain it later in detail. But the main thing is I was involved on the Gamebuino bootloader and have seen the problem that comes when users get no “feedback” on the progress of the bootloader. They report “it does not work” and you have no way of helping them because you don’t know what happened. The Pokitto loader shows flashing progress & reports errors on sd, directory, file and flash errors. Trust me when I say its going to spare a lot of headache for all of us this way. But if you want to make a smaller loader there is no problem in making a cut-down alternative.
As for the mbed / low level coding, there is no need for concern. I write alot of the code on register level, and use the mbed lib usually just to make a proof of concept as fast as possible . But now I need to drive a bit and will get back to you later.