Loading programs from SD

zet23t · 3 · 6668

zet23t

  • Full Member
  • ***
    • Posts: 44
    • View Profile
I have recently ordered a SD card reader - I have a vague idea of what I want to achieve and I wonder if anyone could contribute expertise or is interested in the result of this project.

The idea is to make the TinyDuino Game kit an actual complete portable gaming console. One on which you can chose and play several games without connecting it with a computer, simply by loading a game from SD.

As far as my knowledge goes, it is possible to define a bootloader function and make it rewrite the flash memory with any content. So I guess it should be possible to load data from SD, store it in memory, write it to flash, repeat until the program is loaded and then reset via software and let it restart.
The loaded program would contain the game as well as the code to load other games to repeat the entire process. I guess that such logic would consume 4-12kb of memory. However, games could consist then of several programs that get loaded when needed, e.g. a program where you play on a world map vs. a jump and run program to play a specific level.  Communication between program parts would happen then via EEPROM stored values. Saving a gamestate would be done by writing to the SD card.

Any thoughts or considerations about all this? Any reason why it would not work? Interest in having such a system?


Alderin

  • Newbie
  • *
    • Posts: 1
    • View Profile
Having started down a slightly different road with Arduino+SD myself, and the Atmega 328 microcontroller outside of the Arduino programming system, I'll say that while your plan is technically possible, game programming on a 328 is already extremely starved for code space and RAM. I would also be slightly concerned with the re-write limit of the code flash area. Wouldn't be a big problem for the big socketed Arduinos, as a replacement 328 is cheap and easy (~$2 US), but a Tinyduino would have to be fully replaced (~$15 US).

My personal journey with SD slants more toward running an "interpreter" on the 328 that runs code/script from the SD card. A cleverly built interpreter with useful libraries built in would be able to (theoretically) run most functions anyone would need. My plan was for SD+Ethernet to enable scripted interaction with a system for things like downloading logs and issuing commands, but a similar system minus Ethernet and plus Tinyduino Gaming Kit specific libraries would be very cool, too. Allowing level data to be loaded from the SD, save-game data, and multiple games is completely within the realm of possibility.

The downside is that in your version you need to build your own bootloader with SD+Fat32 and programming capabilities and a method to allow reset into the new code afterwards, while for mine I need to build a full interpreter, possibly replacing the bootloader completely (for space), and the "programs" need to be written in whatever language is being interpreted (preferably a derivative of the Arduino C-like system).

Love to know what you come up with!


zet23t

  • Full Member
  • ***
    • Posts: 44
    • View Profile
Your thoughts are similar to what I have been pondering about...

The rewrite limit: 10k rewrites are unlikely to be hit within a reasonable time. If you'd play each day 3 different games it would take more than 4-10 years to hit he guaranteed minimum rewrites. Since I think that this is a highly unlikely scenario, I came to the conclusion that this doesn't matter much (to me). Even if a game would consist of multiple programs, it would still take plenty of play time to trash the chip. (If it was so much fun to play, 15$ would be sort of OK to pay once per year I'd think ;))

About the boot loader: I have no idea how to work with it, but I have some ideas. I was thinking to have some code that takes an address of the SD card file and starts loading the content, not taking (much) file system code into the loader. One way to do it would be to have a "Loader" program that has FAT32 code to look through the SD card, showing ROM thumbnails and allowing to load a game.
When a game is selected to be loaded, the game's properties (FAT32 first cluster table entry) as well as the loader program's address is stored on EEPROM. It then loads the code from flash through the bootloader that only needs to handle loading files through the FAT cluster table, which should be reasonably simple to read. So to load the loader program from the game again, very little FAT32 code is required because all required cluster information is stored on the EEPROM. Note: If the ROM format of the files on the SD card has a size limit like 128kb and the cluster size of the FAT32 format is 4k, the 32 cluster addresses of the file entries could be just stored on EEPROM - so loading content would be really simple by just reading the eeprom. Especially if the file structure is aligned with FAT cluster sizes.
I researched a bit the topic of resetting and using the watchdog timeout it's possible. So I would think that the life cycle would be:
:: Loader => user selects a game => store cluster file data in eeprom => flash the ROM => restart. Game.
:: Game => user selects option to quit => load loader cluster from eeprom => flash the ROM => restart. Loader.
I am curious if that could work out this way...

Regarding an interpreter: I've considered this as well for quite some time. It would be great! After all, loading code dynamically from SD and executing it would drop lots of limits. However, I am worried about two things: RAM and performance. The interpreter would need some RAM that would not be available to the program. And interpreting code will take quite some extra cycles. The more since data needs to be loaded from SD continuously. Having played a bit with the tinyduino, I think using an interpreter would be fine for plenty of applications but games that require every CPU cycle to achieve 20fps+ in native code would probably not run at reasonable speed when executed partially via interpreter.

I still think that an interpreter would be cool for various things and I am intrigued of it. But I am afraid that it might turn out to be not usable for most games. With the render API I wrote where you can issue draw commands to draw textures / rectangles or circles, you could certainly make a simple game such as pong and maybe asteroids with interpreted code... but anything more complex would be quite difficult if not impossible.
Another reason why I'd prefer flashing is that loading textures from SD and blitting them to the tinyscreen is probably quite slow as well in itself.

I'd be interested to know if you see any problems with my considerations!


 

SMF spam blocked by CleanTalk