Remove unnecessary quirks

[tobiasvl]

Currently, due to the fact that Octo exports all quirks, many games list quirks that they do not actually depend on, using Octo's default behavior (if said quirk was even supported at the time of export) as the value.

This is probably unnecessary. Emulator developers should not need to implement uncommon quirks just because a lot of games claim that the quirk should be set to false when in fact the game doesn't care about it.

Each quirk has three states:

• true: Quirk should be enabled for the game to run correctly
• false: Quirk should be disabled for the game to run correctly
• Not listed: Quirk is not relevant for the game

[Timendus]

This is precisely why in my take on solving this issue, I have completely ignored the concept of "quirks" in favour of simply stating on which platforms (versions of CHIP-8) a ROM can run. If something ran on SUPERCHIP v1.0 back in the day, it will work on an interpreter that implements the opcodes and quirks of SUPERCHIP v1.0 today.

Quirk as they are exported in Octo are, in my view, an implementation detail of Octo that should not be a part of the meta-data of a ROM. Not even optionally. It just complicates things for developers.

[zZeck]

It is useful to track the quirks to know what to implement to support everything, but I also agree that it'd be better to indicate platform in the metadata. You don't want to end up with a combinatorial explosion situation, where program authors are making up quirk combinations that never previously existed.

[zZeck]

perhaps another file could be useful, platforms.json that is data on the platforms, and their quirks. Maybe this could also store interpreter speed information.

[tobiasvl]

It's a good idea, but then we'd definitely need to have a file like that platforms.json. It could perhaps somehow also contain all the other platform specifics (see https://github.com/chip-8/extensions), like unique instructions, machine code architecture, etc, although I have no idea how we could represent this data.

Also, this issue was created because not all quirks are relevant for every game, even within platforms. If a game doesn't use the load/store operations, it doesn't matter what load/store quirk the platform it was "made for" uses. Some games might be completely platform-agnostic, even though it was definitely targeting a specific platform back in the day.

It's important (at least to me) to remember that most developers involved with CHIP-8 are emulator/interpreter developers, not game developers. Most game developers simply target Octo with its default quirks and don't need to think about quirks at all, but it's always been a goal for me to influence interpreter developers to support more platforms than just CHIP-48 (or low-resolution SUPER-CHIP or whatever Cowgod's unholy guide is a specification for), and for those developers the details of quirks are paramount. If they want to support a specific game, they need to support a specific platform, and that means knowing what quirks it used. On the other hand, that's why I made the developer-facing library https://github.com/tobiasvl/octopt; this repo doesn't need to be developer-facing to the same degree.

[zZeck]

Definitely true that some games don't depend on quirks, or have different behavior if the font changes, or get too crazy with unexpected clock speeds. This was more of a frustration for me when I was trying to figure out chip 8 than a benefit.

For me, when I was writing an interpreter, my thought process was not trying to get games working. I wanted to re-create a particular old interpreter. Then I would know everything targeting that interpreter would work, and anything I might make for my interpreter would work there. Mostly this came from having followed the SNES and NES romhacking scene where you have these old hacks that only work in certain inaccurate emulators, where the emu authors lacked documentation and did things just to get popular games working. It feels like the benefits of accuracy are appreciated more widely in the emulation scene today. Maybe not as many first timers would have that attitude as I'd think though.

It can get to be a lot of work to document game dependence on peculiarities. Will a different font just be off center, or is there potential for collision with the stuff that is drawn. Does the quirk totally break the game, or is it still playable.

[Timendus]

For me, when I was writing an interpreter, my thought process was not trying to get games working. I wanted to re-create a particular old interpreter. Then I would know everything targeting that interpreter would work, and anything I might make for my interpreter would work there.

I think this goes for many people. And the issue they then run into is that they have no idea which ROMs then target said particular old interpreter. Be it CHIP-48 or CHIP-8 or SCHIP 1.1, as a developer I think you just want to have a shitload of ROMs to test with, that YOU KNOW will not bite you in the ass because they were really developed for a different system, or with some random quirks flipped.

Like I already mentioned, I think referencing a particular platform makes most sense. And yes, I think it would be very beneficial to have an overview of the differences between different platforms, but that's also what this tries to solve, right..? https://chip-8.github.io/extensions/ Because I'm not sure either how you would encode all that information in a machine-readable platforms.json 🤔

If a game doesn't use the load/store operations, it doesn't matter what load/store quirk the platform it was "made for" uses. Some games might be completely platform-agnostic, even though it was definitely targeting a specific platform back in the day.

You're absolutely right. That's also why I'm moving away from the one-on-one mapping of ROMs to platforms for the next version of my spec. I'm gravitating towards:

• One file represents one program or game
• It can hold multiple ROMs
• Each ROM targets one or more platforms

This way you can have a version of a program that targets CHIP-8, SCHIP 1.0 and SCHIP 1.1 and another version that targets XO-CHIP (adding a bit of colour, for example), bound together in the same file. Maybe this is also a useful direction for the meta-information in this repository..?

[zZeck]

Yeah probably having a platforms.json is not useful, since there is far more than simple quirks that very. The complexities of quirks, extensions, run speed, can be learned from your extensions documentation, and interpreter authors can pick what platforms they want to support.

I think the main thing to track is really just the historical record of the interpreter the author was targeting. That's the easiest information to identify. Not really much testing or judgement calls required. People can always try running programs on a platform setting other than the original, and see what happens.

Perhaps a compatibility matrix could be added to the extensions document, so developers at least know what platforms are near supersets or subsets and might be interesting to try? If they have only implemented some platforms, they can run the program in the most compatible implemented platform and give the user a warning.

Maybe lower, game level information about the problems they'll have on non-target interpreters could be in its own more detailed json? Does it use the system font, what instructions does it use, does it use them in a way where the differences matter etc. That would be useful for game compatibility focused interpreter developers, who want to start with the simplest games, or identify the most commonly used features.

Thinking about distributing an interpreter, I would want to ship it with just the small database only having the platform documented, kind of like how HLE emulators such as Dolphin have a database of what emulator settings work best for particular games, and auto apply them for users.

[Timendus]

I'm curious to hear what you all think of my approach in #11.

In it, I define a platforms.json file that holds "all the known platforms", with their properties and quirks. The quirks refer to quirks.json, which defines (as unambiguously as I could) what the quirks do. As a reference for interpreter developers.

Then, in programs.json, most ROMs can just reference the platform that they are compatible with in an array of platforms. For those few ROMs that are not really compatible with any "proper" platform, because the author used a mix of quirks that makes it impossible to run otherwise, I have introduced the property quirkyPlatforms, with which you can define a base platform and override the offending quirks.

The idea being that interpreter developers can first implement support for the platforms list, and filter out the platforms that they support. As their interpreter matures, they can accept more platforms, and at some point even accept quirky platforms.

So far I've only needed to define quirkyPlatforms for a handful of ROMs. So to me this does feel like the way to go.

[zZeck]

The idea being that interpreter developers can first implement support for the platforms list, and filter out the platforms that they support. As their interpreter matures, they can accept more platforms, and at some point even accept quirky platforms.

Yeah, that would be what I'd do if I was writing an interpreter again and had this information.

Seems most of the quirkyPlatforms ROMs originate from developers setting octo to random compatibility flags, except for Astro Dodge [Revival Studios, 2008]. I dunno what interpreter that originally targeted. I do like the idea of having a kind of canonical set of platforms, based on popularity and historical significance, to avoid a situation where every rando interpreter is going to be added.

It would be nice to have a field for storing origin information. VIP manuals, magazine issues for Dream and ETI programs etc.
I have some disorganized research into some of that here. Tracked down a bunch of release threads for schip programs and a few other things. Some other origin discussions here.

Programs list is missing some of the stuff from Game Manual II. I started trying to transcribe them years ago.

It will be much easier for people to do a chip-8 interpreter these days compared to a few years ago, and actually know what they are getting into.

[Timendus]

It will be much easier for people to do a chip-8 interpreter these days compared to a few years ago, and actually know what they are getting into.

Hahaha, yeah that's kind of the point I guess: helping things make a little more sense. But preservation of early hobbyist computing history is a good second. So I like your suggestion of adding the origin or the source of a program. Currently there's only event, but that's easy enough to make generic.

I know that the list is far from exhaustive. And so is the meta-data for a lot of ROMs. But if we reach agreement on a structure, then we can start collecting and organising the information as a community effort.

[Timendus]

I've swapped out event for origin, which has a type (option from a list) and a freeform reference:

"origin": {
  "type": "object",
  "description": "The origin of this program; was it created at some event, for a game jam, or published in a magazine somewhere?",
  "properties": {
    "type": {
      "type": "string",
      "enum": ["gamejam", "event", "magazine", "manual"]
    },
    "reference": {
      "type": "string"
    }
  }
},

So the old event is now:

"origin": {
  "type": "gamejam",
  "reference": "Octojam1"
}