Memory Limits for Embedded Environments

[Sewer56]

[Another series of incomprehensible ramblings until codified in the spec]

Context

Planned target min spec for Reloaded-III is somewhere along the lines of:

I can hypothetically mod an OG XBOX game with this.

The XBOX notably has 64M of total RAM, with the next console (GCN) clocking in at 43MiB of total memory between all components. Therefore, it is assumed that for multi-platform titles, the XBOX probably has some RAM to spare.

With that in mind I consider said target spec to be 'it can run some basic mods with less than 2MB of RAM used'.

Stretch goal is 'it can run with <0.5MB RAM', to make it embeddable in 6th gen game titles. That is very ambitious, it may be possible, but I won't count on it.

---

Note:

This does not explicitly mean 'Sewer will port Reloaded to 6th gen consoles'.

In fact have no plans of doing so. It simply means, the target spec is to make a port to something as low spec as a 6th gen console possible. (It seems cooler than saying 'make it work on microcontroller')

In practice, the Reloaded model of small mods with dependencies isn't super suited for platforms without an OS, as lack of access to a shared libc means a lot of code duplication.

Requirements

• Lightweight dependencies (no text formats).
• Optional features. (Certain loader features should be able to be compiled out if unnecessary on given platform)

Mod Settings Serialization

The server, which configures the mods should be able to serialize to a binary format (opt in supported by mods) which has minimal code size and maximal parsing speed.

Here is an arbitrary example of such format:

numitems: u16
item[numItems]

Where Item is:

key: u16
value: u8/u16/u32/u64

Type of values for each key is declared inside separate metadata file which contains all known settings. The purpose of the key is to allow for versioning. For example, if a field is removed, it will be ignored, as the mod will no longer read a field with that 'key'.

Minimal Hooks Backend

reloaded-hooks-rs is expected to weigh around 300kB in code!! This is more than the loader itself is expected to weigh (~100kB tops).

For X86 targets like Xbox, it will be necessary to create a more minimal version of Iced_x86 for reloaded-hooks-rs. This can be achieved by making various instruction sets optional (toggleable).

Alternatively, we do a self rolled minimal backend with very limited code rewriting support, like detours. We could self-roll our own JitX86 (which I plan to do at some point anyway) and for code rewriting, use detours as a backend.

Binary format for Loader Config

Runtime information for loader such as:

• Which mods to load
• Mod locations
• Mod metadata

Will need to use a binary file to save on code size.
This is planned to reduce startup times, as a merged file is needed to reduce I/O overhead. So no special accomodations needed here.

[Sewer56]

All docs work is done, apart from documenting the loader config format.

That has been moved to a separate issue:

• Memory Limits for Embedded Environments #13