Cortex M0+ compatible?

[zet23t]

Hi,

I am seeking some advice here...
I have a small TinyDuino with a Cortex M0+ processor (32kb ram, 256kb flash @ 48mHz) connected with a TinyScreen that's featuring 96x64 resolution at 16 bit color depth. It's pretty neat and I intend to make games for it.

While making a game in native C/C++ works, I am somewhat unsatisfied with the need to program the board with an USB cable. A far simpler method would be to use an SD card and provide games via files that get loaded dynamically (I'm thinking here of possible consumers who don't want to deal with puzzling error messages when something fails).

So the idea is to have a VM runtime that's interpreting code from SRAM that's loaded from the SD card. As usual, the code inside the flash memory provide all the functionality to draw graphics at reasonable speeds while the game code is more concerned about processing user inputs and storing game values and utilizing the provided functionality to draw neat graphics. I have used Lua in the past for Desktop games and really loved it for that purpose.

So I am now looking at possible ways to go... and eLua seems to be at least one possibility. The most concerning problem I am looking at is speed and memory: Aiming to have 20 frames per second means that code must be executed fairly efficient. Moreover, a lot of memory is required to actually draw images. As it stands, I'd reserve around 16kb for graphics[1]. So game code and game variables must fit into the remaining 16kb. It would be possible to reload content from SD card as well as storing data there as well, but I guess that this would have a quite heavy impact upon performance - though it'd be better to test this assumption first.

Since this list has many people with much more experience than I have, I'd be very grateful for your input on this subject.

Thank you in advance,
Eike Decker

[1]: 96x64 use 6kb when in 8bit mode and 12kb in 16 bit mode. I could add some compression functions to minimize sprite sizes and such, however I'd also need some additional memory for managing the rendering. 16kb seems a reasonable compromise. I could maybe shrink it to 10kb if really needed, but that would be a bit disappointing.

[jbsnyder]

Hi Eike,

I think your memory constraints are going to be too tight to consider eLua for your project.  It is possible to run it on a platform with 32kB of SRAM, but this is fairly limiting for script complexity, though being able to keep the bytecode in flash is helpful. When loading from an SD card (as you note) bytecode will need to be kept in SRAM. I've not actually tried constraining an eLua environment to 16 kB of SRAM, but with 5kB for the VM to start up, a few kB of stack, at least a few kB for bytecode, and fragmentation from dynamic memory allocation I can't imagine getting very far.

As for frame rate, there have been some monochrome game examples that that we had running on LM3S dev boards that had OLED displays. You can find example videos of those here for an idea of how well they perform on a  Cortex-M3 (Games for specific platforms): http://wiki.eluaproject.net/Projects

Best.

-jsnyder

On Thu, Sep 17, 2015 at 2:26 PM, zet23t [via eLua Development] <[hidden email]> wrote:

Hi,

I am seeking some advice here...
I have a small TinyDuino with a Cortex M0+ processor (32kb ram, 256kb flash @ 48mHz) connected with a TinyScreen that's featuring 96x64 resolution at 16 bit color depth. It's pretty neat and I intend to make games for it.

While making a game in native C/C++ works, I am somewhat unsatisfied with the need to program the board with an USB cable. A far simpler method would be to use an SD card and provide games via files that get loaded dynamically (I'm thinking here of possible consumers who don't want to deal with puzzling error messages when something fails).

So the idea is to have a VM runtime that's interpreting code from SRAM that's loaded from the SD card. As usual, the code inside the flash memory provide all the functionality to draw graphics at reasonable speeds while the game code is more concerned about processing user inputs and storing game values and utilizing the provided functionality to draw neat graphics. I have used Lua in the past for Desktop games and really loved it for that purpose.

So I am now looking at possible ways to go... and eLua seems to be at least one possibility. The most concerning problem I am looking at is speed and memory: Aiming to have 20 frames per second means that code must be executed fairly efficient. Moreover, a lot of memory is required to actually draw images. As it stands, I'd reserve around 16kb for graphics[1]. So game code and game variables must fit into the remaining 16kb. It would be possible to reload content from SD card as well as storing data there as well, but I guess that this would have a quite heavy impact upon performance - though it'd be better to test this assumption first.

Since this list has many people with much more experience than I have, I'd be very grateful for your input on this subject.

Thank you in advance,
Eike Decker

[1]: 96x64 use 6kb when in 8bit mode and 12kb in 16 bit mode. I could add some compression functions to minimize sprite sizes and such, however I'd also need some additional memory for managing the rendering. 16kb seems a reasonable compromise. I could maybe shrink it to 10kb if really needed, but that would be a bit disappointing.

---

If you reply to this email, your message will be added to the discussion below:

http://elua-development.2368040.n2.nabble.com/Cortex-M0-compatible-tp7578538.html

To start a new topic under eLua Development, email [hidden email]
To unsubscribe from eLua Development, click here.
NAML

--

[zet23t]

Hi jsnyder,

No idea why, but I didn't get an email notification on your reply.

Sorry to hear that the memory constraints are too harsh for eLua. I was thinking so. So basically, I'll try to come up with something on my own. I looked a bit around, but most scripting languages are fairly chunky.

If I come up with something that works, I'll send a followup ;)

Cheers,
Eike