In a prior year I specifically asked about a variant with hardware registers to allow swapping the 4 colors (still 4 colors, but swappable by writing RGB values into RAM - I’d have modified the JS Octo build to allow this to work) and IIRC you vetoed it. Yet this year I see you specifically mention silicon8, which has a 16 color mode - quite a bit beyond your “official” XO-Chip spec.

So I’d like to again ask for clarification in this regard.

Also, is there a winner or prizes? (I don’t recall such from prior years)… if this is all just for fun isn’t the spirit of the law here a lot more applicable than the letter of the law?

I’m specifically imagining things that would seem possible given the Octo ‘hardware’… ie, in keeping with:

The additions are sparing and try to retain some degree of historical plausibility and the flavor of Chip8’s creative limitations.

• palette swaps - if the ‘hardware’ can show 4 colors (from 16 million) per cartridge it seems there ought to be some way a cartridge could change those 4 colors are runtime (this presumes the underlying LCD ‘hardware’ is 16/24-bit, etc)
• video RAM - in original implementations the video RAM had to be stored somewhere on the actual hardware - so making it accessible somewhere in the XO-Chip address space for direct reads/writes seems realistic and also very similar to how many other retro systems worked.

Thoughts?

Victor or not I’m also not seeking any kind of “advantage” here… I’d OSS whatever changes I made to the runtime (happy to submit them back upstream as well if we agreed on a spec)… so anyone who wanted to have a game with say palette swaps could just compile/build with my modified version of Octo and then upload…

There are no prizes awarded in the Octojam, just the warm fuzzy feeling of having finished a project, and the opportunity to have your game played and constructively critiqued in our annual post-jam stream.

Programs submitted to the jam should be compatible with CHIP-8, SCHIP, and/or XO-CHIP, and should run in Octo (with appropriate compatibility flags selected). Silicon8's additional color planes are not strictly legal. Timendus' game last year was designed such that it could be used in either Silicon8 or (degrading gracefully) in a stock XO-CHIP interpreter, which I viewed as somewhat bending the rules but not breaking them.

In the spirit of keeping everyone on a level playing field this year, I ask that participants refrain from using any custom extensions for jam submissions, as using such extensions disadvantages those who do not have the skills or desire to make their own interpreters/tooling, and makes it harder to fairly compare submissions to one another.

 If participants wish to separately explore an "enhanced edition" of their programs elsewhere they are, of course, free to do so. 

Makes sense, thanks!

Heheh, no bending the rules for me this year! ;)

But yeah, the 16 colours in Silicon8 don't require any new opcodes or changes to the spec or the interpreter. They are just a "creative interpretation" of the existing XO-CHIP opcode that selects the planes, and as such backwards compatible. I think it's a good rule of thumb to say that it should (be able to) run in Octo.

We've had some discussion about adding the ability to swap colours at runtime to the XO-CHIP spec, but IJ voted against it with some compelling reasons.

but IJ voted against it with some compelling reasons.

Is that discussion online somewhere? I’d love to read it.

Nope.

IIRC it was mainly that it would be hard to implement in a sane way on systems that don't have a (full) colour display. Having four static colours allows for manual intervention, whereas having unlimited dynamic colours does not.

For example, when going to four level grayscale: if the program selects red and green with equal luminosity, how would the interpreter know how to map the colours without losing legibility? For four static predefined colours a human can intervene and configure the program to use colours that make sense.