Some ideas for further improvement

[Timendus]

Extensions

• [x] Add a field to specify the copyright of the file
• [ ] Maybe have a field for someone who's not the author, but who ported it to a new platform or whatever..?
• [ ] Display requirements (low-res/high-res, b/w or four/sixteen colour)
• [ ] Maybe add support for reduced colour palettes for more constrained platforms, for example a monochrome one, a grayscale one, a 16 primary colours one?
• [ ] Sound requirements?
• [x] Allow markdown for the description?

The display one so an interpreter can better determine if it can run the ROM.

Breaking changes

• [x] A version number to indicate the version of the file type
• [ ] Maybe don't make the cover art depend on the colour configuration of the ROM
• [x] Allow for multiple bytecode segments, for each of which we can specify which platforms can run it (so we can get rid of the dumb "compatibility configuration")

Example of the latter: for my game 3D VIP'r Maze I've released two separate binaries: one for CHIP-8 and one for SCHIP. The one for SCHIP can run on both v1.0 and v1.1 interpreters (I think, but it's an example 😉). It would be really nice to have one binary that holds both versions of the bytecode with annotations of which interpreters can run them, as well as all the meta-data!

[Bandock]

That would definitely be nice. Kind of reminds me of DOS executables where they even have multiple headers. That should not be hard to implement. Heck, I might even try to add a special feature on my interpreter that could take full advantage of such a feature. ;)

[Timendus]

I think the structure of the header should change to something more along these lines, to allow for multiple binaries and multiple platforms per binary:

## Header

# Magic number
0x43 0x42 0x46
# Version number
0x01

# Pointer to binaries table
0x08
# Pointer to properties table
0x00  # Zero, meaning: not present in this example

## Tables

# Binaries table from byte 8
# Example: we have one binary that's compatible between CHIP-8 and SCHIP...
0x01  0x00 0x1D  0x00 0x10  # CHIP-8 from 0x001D for 16 bytes
0x2C  0x00 0x1D  0x00 0x10  # SCHIP v1.0 from 0x001D for 16 bytes
0x2D  0x00 0x1D  0x00 0x10  # SCHIP v1.1 from 0x001D for 16 bytes
# ...and another binary that makes use of XO-CHIP for something extra
0x34  0x00 0x2D  0x00 0x10  # XO-CHIP from 0x02D for 16 bytes
0x00 # End of binaries table

## Data segments

# CHIP-8 / SCHIP binary starting from 0x001D
0xe0 0x00 0x0a 0x60 0x0a 0xa2 0x06 0xd0
0x08 0x12 0x80 0x82 0x8a 0xf2 0x8a 0x8a

# XO-CHIP binary starting from 0x002D
0xe0 0x00 0x0a 0x60 0x0a 0xa2 0x06 0xd0
0x08 0x12 0x80 0x82 0x8a 0xf2 0x8a 0x8a

# End of file

I think the pointers to the binaries table and properties table can both be a single byte. This restricts the number of entries in the binaries table to 49 OR the number of entries in the properties table to 82, depending on order. Which I think is way more than we need in either case.