Game ROM on SD card

[nezvers]

I want to make something like a handheld game console with ESP32 and keep the game's logic and art on an SD card, like ROMs on a cartridge. Is there some way to serialize the logic)?
I'm intermediate at C and C++ and I know how to serialize data, but not the whole logic. The end goal would be a project that could be like an open-source handheld game console. If creating like a Lua script (I don't like Lua) on SD card with VM on system theoretically would be the best but I don't know how to achieve that.

[Radu79]

Why do you want to serialize data, when you can just use the file system on the SD card?

[ESP_Sprite]

Radu79: Serialization can also mean that you have game logic as an interconnected set of structs and objects in memory and need to 'flatten' it to store it in e.g. a file. I imagine that's the way nezvers used the word.

Nezvers: You can't execute code in a practical sense from anywhere other than flash at this moment (iram is an option, but it's not very large.) Other game consoles like the Odroid-Go effectively load a file from SD-card, then flash it into a flash partition, then reboot into it in order to execute the game. I think the ESP32-S2 and onward can execute from PSRAM, so that might be an option, but I don't think anyone really tried that yet.

[nezvers]

Why do you want to serialize data, when you can just use the file system on the SD card?

My goal is to make something like Odroid-Go and have games on SD card, so the user can travel without the hustle of reflashing the microcontroller. By serialize, I meant a way to turn the game's logic into something that can be read and executed. Thanks to Javidx9 (youtube channel) NES emulator I know how to read data as Assembler code but it wouldn't be fun to code games in an assembler way. If you know good easy to understand material about it, please share.

Radu79: Serialization can also mean that you have game logic as an interconnected set of structs and objects in memory and need to 'flatten' it to store it in e.g. a file. I imagine that's the way nezvers used the word.

Nezvers: You can't execute code in a practical sense from anywhere other than flash at this moment (iram is an option, but it's not very large.) Other game consoles like the Odroid-Go effectively load a file from SD-card, then flash it into a flash partition, then reboot into it in order to execute the game. I think the ESP32-S2 and onward can execute from PSRAM, so that might be an option, but I don't think anyone really tried that yet.

I guess that for game console flash memory lifetime could be enough, but how to make it hold whole game logic (functions mainly, since assets can be easily serialized on SD card)? Any good learning material for that apart Odroid-go source?

[Radu79]

So let me understand. By serialization you mean putting all the assets in the game in a single large file on the SD card?
If so (or even if not), why not just putting the files separately, such as every asset in its own file?

[nezvers]

So let me understand. By serialization you mean putting all the assets in the game in a single large file on the SD card?
If so (or even if not), why not just putting the files separately, such as every asset in its own file?

I meant the whole game logic whole or DLL-like with functions and asset data. Because the goal is pretty much an NES-like engine where visual assets are sprites (just palette indexes) and music are instruments and notes (one of the ideas is using hardware oscilators). So I want to have users just compile single file game ROM and drop in SD card. Ideally, I'd have like a game engine on-chip that calls game loop and load in needed data from SD card.

So far I know only 2 solutions that I'd like to not do:
1) Programming games in an assembler-like manner with esp32 doing the translation. Super not fun development.
2) NodeMCU firmware and have Lua script for the game. I don't like Lua and some performance is lost. I love C/ C++ fine detailed logic and great performance.

TL.DR. I want to get it so users can write their game logic and drop it on an SD card and play games without needing to flash the chip in case of travel. I'm open to any suggestion that can achieve it.

[Radu79]

Putting all the data in a single file is much less convenient while developing the game, because each change you make you have to repack the data.
Anyway, if you really want to do the single file thing, you can use a zip archive. Take a look at the zlib.

But I don't understand why you mention ASM and Lua, instead of just doing it in C/C++? The standard for this chip is C/C++, via Arduino or via their development platform.

[nezvers]

But I don't understand why you mention ASM and Lua, instead of just doing it in C/C++? The standard for this chip is C/C++, via Arduino or via their development platform.

I have a feeling you didn't read what I was saying.

TL.DR. I want to get it so users can write their game logic and drop it on an SD card and play games without needing to flash the chip in case of travel. I'm open to any suggestion that can achieve it.

The end goal is to have game logic contained on an SD card and a single file is not mandatory but highly probable it will end up so. While prototyping the project I certainly will do on chip development.
As far as I know, your suggested Zlib is a compression library, so how exactly it allows the execution of program logic from it?
Please stop concentrate on the asset part because that's trivial to serialize and deserialize, my problem is to contain programs/ games logic on an SD card (atm doesn't matter several games or single).

I mentioned ASM because that's the only way I KNOW to serialize logic and parse it. You can see the how-to here: https://youtu.be/8XmxKPJDGU0.
I mentioned NodeMCU Lua because that would be the EASIEST way to have logic on an SD card because that's just script. And I also said that I don't like Lua and prefer C/ C++.

[Radu79]

I've read all you have said, but as a game developer for over 20 years I am having trouble understanding why you want to do things that way.
I don't understand why you want to serialize data on the SD for example. I mean, the only advantage I can see for doing that would be not linking to the file system libraries, and having less code in RAM, but the trouble for doing so is not worth it, unless if you really want to squeeze every last bit of performance from this small MCU.

So you are saying you know how to serialize data in assembly. Did you write any assembly program for this MCU? Keep in mind that the next version of ESP32 will have a RISC based core, so you'll have to write your game twice. And if you want to use c/c++ and know how to serialize data in assembly, why can't you do it in c?

One other thing I don't understand is why you want to load binaries from the card. If you plan to write a mini OS that loads different binaries (games) and does some memory management and disk I/O stuff, then this would make sense. Otherwise you should put all your game logic in a single binary that you flash via USB, and use the SD for the game data only.

[ESP_Sprite]

Radu: I think you're reading too much into this. As far as I understand, Nezvers' goal is to have a game console like device where the end user can plunk a game as a single file onto an SD-card, insert it into the console and play it. The single file contains both assets (images, sprites, sounds, whatnot) as well as the game logic. This is the end goal; development of the game is a separate issue.

With that being said, loading the game logic (the 'code') into the ESP32 and executing it is an issue. The ESP32 is not a PC, so you can't just extract the executable code blob, run it into RAM and execute it. As Nezvers already said, there are two alternatives. One is to effectively implement an emulator for a (custom? imaginary?) game console and write the game itself in assembly / bytecode, to be executed by the emulator. The other one is to write the game in an interpreted HLL, like Lua.

Finally, I would like to add that the last option would be to go the Odroid-Go way and load the executable subset of the game (which would be a standard ESP-IDF/Arduino binary) and flash it into flash, then rebooting into that.

A fourth option, by the way, would be to use the ESP32-S2. If I recall correctly, it can execute code from PSRAM, so you could load the game into that and execute it from there. Note that that is not trivial at this point, though, and there is no software support I know of for a solution like this.