If you're going for some kind of meta-format, wouldn't it be wiser to use a zip-container including all files necessary and optional? Like some meta-data (e.g. json-encoded), and the binary data for the ROM. Optional data would be manual and box-art.
I really like this idea, but I'm concerned that it would make the game unloadable on SD carts like harmony and uno. Perhaps if we allocate 128KB to firmware on the uno there would be enough room for a zip and json library.
Looks good to me. I would kick the "scheme_head_offset", though; if the scheme requires a header, it will be part of the actual scheme "image" after the header. There is no such thing as a "raw" bin image for anything other that 2k and 4k anyway, they all need interpretation anyway. I would also change "version" to an uInt32 that increments with every revision.
I was thinking it would be nice to provide additional scheme information in a more explicit way for some of the fancier roms. I. E. 3e with 48KB ROM and 24KB of RAM. But, yeah, there would be cases where the offset just points to the header that's embedded in the bin.
I would add more, e.g. default difficulty switches and controllers. IMO almost basically everything you can find in Stella's "Game Properties" dialog would make sense.
Also a checksum of the ROM itself would be helpful. And maybe some bookkeeping info, like how often the ROM was loaded and how long it was played. I even wouldn't mind a full resolution (160 x ~240) screenshot.
Would be really cool to capture the screenshot as a frame worth of 6502 execution so it could be replayed on hardware. You could have a slideshow mode to select which game to play.
Official game URL field?
DRM enforcement flag?
URL good, DRM bad. If you want DRM just make it fit in the MCU and enable memory protection.
There's a lot of potential here, but it's not part of the critical path for implementing MegaFlex or ARM Custom Executables. So let's shelve the metadata discussion for now and revisit it when someone is available to work on it.