I present to you, the first ever Cheetahmen II TAS that plays the original (not bugfixed) version AND shows the final boss!
History
Cheetahmen II was never released. Copies of this rare cart were discovered in a warehouse after the Action 52 company went out of business. It was a prototype for a sequel for the "hit" game Cheetahmen on the Action 52 cart. Not releasing this was a good decision, not only is it a terrible game, it had numerous bugs that made the game unplayable. The most significant was a bug that prevented the game from progressing after you beat the level 4 boss. While the game had 6 levels, for a long time people did not know this, due to not being able to get past level 4.
However, it was discovered that sometimes the game would start on a random level, and it was discovered that one of these was level 5! Now people could finally see the rest of the game (unfortunately for them).
The reason for this glitch is due to the fact that the board registers start off in an unpredictable state. This is a known issue in hardware, and most any board is built to clear out registers before attempting to use them. Good NES carts like MMC3 would do this for instance. Also, good games are programmed to loop and clear out ram, and set registers BEFORE attempting to use them. However, Cheetahmen II uses a custom board built by the Action 52 company and not surprisingly, this board is bad. It has no logic for clearing out these registers. Cheetahmen II is a badly programmed game, so it actually reads from mapper registers before setting them. Furthermore, in this perfect storm of crappiness, the game is built on a multi-cart board design. So it happens that each level is built on a separate PRG bank. Normally if the PRG register was set badly in a game, it would likely crash (as any program would if you started it halfway in).
Determinate indeterminacy
In TASing emulators, random register states and ram are bad things, they will cause indeterminacy and it is impossible to have a movie sync reliably. So emulators tend to program ram values to 0's, and all mapper registers as well. However, this is just one of many valid and possible start up scenarios! I suggest that a TAS can and should be able to exploit the initial state of hardware! If the all powerful superhuman that TASes represent can predict future RNG values, why can't he have full control over when to turn on the hardware to get the values of his choosing? With this in mind, I modded Bizhawk so that you can set the initial register values inside a movie file. This way we don't violate determinacy issues, while still giving full power to the TASer to control this situation. In this case of this submission, my movie file starts the game on PRG bank 11 (which is the start of level 5) with a prg mode of 1 (not terribly important detail, but needed for the game to run properly from bank 11).
Ending
After you kill the level 6 boss (or level 4 boss), the end of the level does not trigger. The "Fixed" from fixes this bug. But since an ending was never programmed into the game, it simply triggers a game over screen.
Wow, in search for excuses to use a sneaky technique which is irrelevant to TASing, we're now using some gossips as a proof. What has science done.
Also, wait, didn't the guy actually beat the last boss on this video?
Link to video
Also, wait, didn't the guy actually beat the last boss on this video?
He did (edit: and used original version), and the comments also mentions it's possible to start the level 6 (glitched too) with resetting, not sure it was mentioned already.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I share nach's enthusiasm for discovering whether this can happen with power cycling instead of just reset, and am dismayed that it took his dedicated skepticism to discover someone we were using as evidence mumbling about demoing it with a hacked rom file.
However, if it can happen on an actual cart, via power cycling, I don't care what initial register state is possible vs which was used. We'd know its possible to get a certain outcome from certain hardware, so we have to emulate that as best we can. Maybe the IC is in some glitched metastable state. Emulating that faithfully isnt even sensible. But emulate it we must, as best we can, and if that means by arbitrarily selecting startup values that match known behaviours (as we do for RAM) then so be it.
Regarding this cart being hand manufactured and the possibility that various carts supposedly identical could be acting differently, I think ordinarily I would suggest as an acid test verifying a behaviour on two independent carts. However if all we had was a diversity of anecdotal evidence to rely on, it sounds sufficient.
Regarding meshuggah's suggestion to somehow study the NES ram startup state... first of all, thats been done by someone sometime I'm sure, and second of all, its meaningless. It's known to be bizarre, variable, and unpredictable, IIRC, and there is no correct answer. We select a pattern, deterministically, which is most advantageous for our purposes--which results in the fewest possible glitching games. This situation is already well-decided.
Regarding meshuggah's suggestion to somehow study the NES ram startup state... first of all, thats been done by someone sometime I'm sure, and second of all, its meaningless. It's known to be bizarre, variable, and unpredictable, IIRC, and there is no correct answer. We select a pattern, deterministically, which is most advantageous for our purposes--which results in the fewest possible glitching games. This situation is already well-decided.
Any links? references? All I found were only Action 53 mapper tests and other memory tests.
"Goofy" values and "bizarre" words means (for me) that nobody knows exactly which but "some possibilities should work".
So, does all combinations could be possible for initial RAM state or there are values that doesn't ever happen to be?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
"Goofy" values and "bizarre" words means (for me) that nobody knows exactly which but "some possibilities should work".
So, does all combinations could be possible for initial RAM state or there are values that doesn't ever happen to be?
This is not a question of electronics, it's a question of physics, so you'll never get a definite answer, because all models are crude.
Here's a layman's explanation of what "goofy values" mean.
In general, state of a trigger circuit (the basic component of RAM) at poweron is undefined, so the value can be either 1 or 0. But because of certain patterns in schematics, the initial value always gravitates towards 0 in one case and towards 1 in another. So it's not like the value of e.g. the byte #1 can be anything from 0 to 255 with even distribution of probabilities. No, the value will be 00000000 in 98% of cases and maybe 00000100 in 1% of cases, other cases take the rest.
So, chances of getting a "00000000FFFFFFFF" pattern are very high, the probability of getting "00010000FFFFFFFF" is still high (you might get it after a dozen of tries), but the probability of getting "0123456789ABCDEF" is vanishingly small and maybe even zero - you'd have to switch power on and off for billions of years to check it.
But my point in this entire argument wasn't about physics, it was about the philosophy of TASing. The proverbial superhuman may have amazing reflexes and a quantum brain to predict RNGs, but he doesn't have the right to mess with the console RAM/registers/etc directly. Instead, his playthrough will depend on the initial state, and each time will be perfect within the given conditions. In our case the conditions were given by emulator authors without a bias towards a specific game or a specific TASer.
Even if the superhuman is actually able to manipulate electrons (which is unrealistic and overpowered to no fun), he must still only use the controller, by definition. Or else TASing loses its point, because once he affects electrons at the beginning of the movie, why doesn't he affect them in the middle?
This should probably be discussed in a dedicated topic, but honestly I'm already tired of this and don't want to enjoy yet another round.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
AnS wrote:
MESHUGGAH wrote:
"Goofy" values and "bizarre" words means (for me) that nobody knows exactly which but "some possibilities should work".
So, does all combinations could be possible for initial RAM state or there are values that doesn't ever happen to be?
This is not a question of electronics, it's a question of physics, so you'll never get a definite answer, because all models are crude.
Here's a layman's explanation of what "goofy values" mean.
In general, state of a trigger circuit (the basic component of RAM) at poweron is undefined, so the value can be either 1 or 0. But because of certain patterns in schematics, the initial value always gravitates towards 0 in one case and towards 1 in another. So it's not like the value of e.g. the byte #1 can be anything from 0 to 255 with even distribution of probabilities. No, the value will be 00000000 in 98% of cases and maybe 00000100 in 1% of cases, other cases take the rest.
So, chances of getting a "00000000FFFFFFFF" pattern are very high, the probability of getting "00010000FFFFFFFF" is still high (you might get it after a dozen of tries), but the probability of getting "0123456789ABCDEF" is vanishingly small and maybe even zero - you'd have to switch power on and off for billions of years to check it.
There's an important point in all this you're missing. Yes, the individual state of some circuit may randomly be 0 or 1, and perhaps have some likelihood to either one, the memory as a whole will generally not be like that. Some electronic components will receive their value from other electronic components, and initial values in some circuits will propagate values to multiple other circuits. Therefore memory as a whole will not be able to initialize with just any random values, some cases are electronically impossible (barring extreme operating conditions and flaws). In most memory circuits, you'll come across initial states that are filled with some kind of pattern based off of initial states from a much smaller set of circuitry.
Therefore, MESHUGGAH is right in his suspicion that not all combinations are possible. Of course this differs from design to design. There can be designs where every single bit can initialize completely randomly, but generally, there is some method involved which disallows anything but certain combinations.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Good addition, Nach, I didn't elaborate on the propagation aspect (only mentioning "certain patterns in schematics"), because I didn't want to focus on the technical part for too long. There are certainly other missed aspects which further decrease the entropy of the system.
But anyway, can you tell me, why would you accept a movie which requires an uncommon initial state (proved to be possible under specific conditions)? Don't you think that creating these confitions is a part of replaying such a movie? As in, the superhuman has to either manipulate the hardware or spend real time waiting for those conditions to happen (thus making watchers wait for eons)?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
AnS wrote:
But anyway, can you tell me, why would you accept a movie which requires an uncommon initial state (proved to be possible under specific conditions)?
Once something is valid, why should I reject it?
I see no reason why a movie must start with one specific state over any other which is a valid starting possibility.
True in even competition, everyone should receive the exact same conditions (which is pretty much never the case). And part of the beauty of TASing is that everyone works within the same black box. So I can appreciate that the starting state should be a constant. But we need to realize that part of the same beauty is that every aspect of the starting condition and activity is fully documented. Anyone else is free to copy the exact same starting condition for their run too. Therefore, I don't see it as cheating, as long as it's known to be a valid way to start.
AnS wrote:
Don't you think that creating these conditions is a part of replaying such a movie? As in, the superhuman has to either manipulate the hardware or spend real time waiting for those conditions to happen (thus making watchers wait for eons)?
The idea behind TASing is that you have full knowledge of everything, and act optimally. You know the hardware and how it works down to the minutest detail. You know the software running to the same extent. You therefore play perfectly.
With the same token, the ultimate player will set the temperature in the room to just the right percent of a degree. They'll have the sun hit the console at just the right angle. They'll have the electricity to power the system primed to just the right frequency. They'll use just the right television. Presto, they turn on the machine, and the audience sees the exact starting state the perfect player wanted them to.
In TASing, our perfect player sees nothing as random. Every outcome is the product of a perfect mathematical formula, with every input perfectly planned and executed.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
If it really is possible to start from the Level 6 memory bank as MESHUGGAH mentioned, and still beat the final boss and complete the game as in the video AnS posted, shouldn't these improvements be implemented in this run through further manipulation of the PRG register?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Valid means that it is permitted by rules, but there's no written rule on the matter yet. And I hope you're not going to hastily add it without a proper consideration.
Nach wrote:
With the same token, the ultimate player will set the temperature in the room to just the right percent of a degree. They'll have the sun hit the console at just the right angle. They'll have the electricity to power the system primed to just the right frequency. They'll use just the right television. Presto, they turn on the machine, and the audience sees the exact starting state the perfect player wanted them to.
Hm. I thought the superhuman is not supposed to bend the reality around the game, because it would be the same (or even more far-reaching) as modifying the console.
So, can he also affect how the light reaches the audience eyes, and therefore add some effects and other inexistent content to the game's output? Does he even need to play the game when he can just manipulate the audience to believe it was played?
I think your definition is much wider than the traditional image of TASing. It gives TASer an inadequate amount of power which is then used inconsistently and inefficiently.
But it doesn't answer my question. OK, so he can control the electricity and the sun, and he already used it to write the needed data into RAM at poweron. Why doesn't he use the same fine-tuned electricity outburst to write another value to RAM while playing?
Previously I thought the line was at having full knowledge and controlling own body optimally (omniscience + reflexes). Claiming something beyond the necessary minimum was prohibited, e.g. no unlimited resources (1-coin TASes of arcade games), and everything must be justified (e.g. a movie must be extremely entertaining or novel to be able to start from dirty SRAM). But your new definition really makes things more difficult to shape...
Perhaps it can be achieved through hard resetting on a certain frame?
Frame-perfect reset is obviously not enough.
I thought an instruction-perfect reset could do the trick, but this way I could only begin from level 2. It seems that using only subframe resets is not going to be enough, in addition it's necessary to improve the accuracy of mapper 228 emulation (but who needs this crap???).
Try playing with this script, maybe you'll be more lucky than me.
Press "A" key to issue a reset at a random instruction of the next frame.
If you ever happen to appear at level 3 (5), you've hit the jackpot.
Download subframe_resetter.lua
Language: lua
resetAtInstructionCount = -1;
numberOfInstructionsAfterVBlank = 0;
function checkAfterEveryInstruction()
if (resetAtInstructionCount >= 0 and debugger.getinstructionscount() >= resetAtInstructionCount) then
resetAtInstructionCount = -1;
-- simulate subframe CPU reset
memory.setregister("pc", memory.readword(0xFFFC));
--debugger.hitbreakpoint();
end;
end;
memory.registerexec(0x8000, 0x8000, checkAfterEveryInstruction);
oldKeys = {};
currentKeys = {};
while true do
oldKeys = currentKeys;
currentKeys = input.get();
if (currentKeys.A and not oldKeys.A) then
numberOfInstructionsAfterVBlank = math.floor(math.random() * 9000);
resetAtInstructionCount = debugger.getinstructionscount() + numberOfInstructionsAfterVBlank;
end
gui.text(10, 10, numberOfInstructionsAfterVBlank);
emu.frameadvance();
end;
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
AnS wrote:
Nach wrote:
Once something is valid, why should I reject it?
Valid means that it is permitted by rules, but there's no written rule on the matter yet. And I hope you're not going to hastily add it without a proper consideration.
There's nothing hasty about how I feel here. I've been complaining for nearly a decade now about the lack of documentation of initial states. If there's only one initial state allowed for something, the emulator should enforce it. If there's multiple, the emulator should allow the user to set the possibilities, or use rand().
AnS wrote:
Hm. I thought the superhuman is not supposed to bend the reality around the game, because it would be the same (or even more far-reaching) as modifying the console.
To be honest, I couldn't care less about the console. What I care about is the intended platform (design-wise), the software, and the consequences thereof. I find hardware nothing more than a vehicle for the software.
Emulators should provide a compatible platform for the software, with more or less the same expectations of running them as any given console that is supposed to implement the platform.
AnS wrote:
So, can he also affect how the light reaches the audience eyes, and therefore add some effects and other inexistent content to the game's output? Does he even need to play the game when he can just manipulate the audience to believe it was played?
This is outside the platform and the software, so no, it does not count.
AnS wrote:
I think your definition is much wider than the traditional image of TASing. It gives TASer an inadequate amount of power which is then used inconsistently and inefficiently.
My views of emulation are different than the norm. My views have rules that can be applied consistently.
AnS wrote:
But it doesn't answer my question. OK, so he can control the electricity and the sun, and he already used it to write the needed data into RAM at poweron. Why doesn't he use the same fine-tuned electricity outburst to write another value to RAM while playing?
An electrical outburst modifying data once it's on would fall outside of standard operational characteristics. Software is designed to work within normal operation parameters. True these things do happen, but this is not something we should be expecting programmers for normal systems to handle.
If the game was designed with hamming codes at every level, extreme regulation on all aspects and so on, giving the sense it was defensively programmed against such issues, implying they are part of normal operating conditions, then that would be an entirely different story.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I'll prefer to see the run starting from clear ram and watch the run doing a couple of random reset until the ram registers get dirty enough to see this happening.
How many reset from clear ram registers would be required to see the trick working with the current setting of the emulator, anyway? I guess it can't be completely random either, even with different game console, they should have a similar pattern, so we can extract some metric out of this.
That said, I'm not a fan of any kind of reset spam behavior and I wouldn't like to see some good title getting owned this way.
edit: fixed ram to register
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I support doing the thing from resetting at a needed subframe point.
- First of all, this feature itself gives amazing advantages to heavily glitched TASes. Everyone benefits.
- Second, it doesn't affect the rules/policies. All runs are still judged in the same conditions.
- Third, it doesn't selfishly benefit from an emulator feature that only applies directly to one game.
Even though technically, the same can possibly be done by mere power on (and be the fastest), the only way consistent with the current set of things is doing it through soft reset.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I don't approve of the dodgy power on state manipulation method being used to gain access to the last 2 levels. I'd rather see a run which uses the bug fixed version to complete all 6 levels.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
After reading the discussions, I realized that PCs could and DO have is problem as well. When a variable is declared (use X Bytes) in assembly but is not Initialized (Zeroed), any usage of that variable, is totally unknown. Who knows what is in that memory area? It could be ANYTHING. All Zero, all One, or any random bytes. If you attempt to use those bytes before you zero it out, god knows what happens. The best (and probably most unlikely solution) is that nothing bad happens. The worst, the program gives some really bad results.
What's happening here, could also be quite possible. The game is not properly zeroing out it's register (which is an instruction, if I am remember correctly) which is an assembly no-no.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
lol, I find all the whining about Adelikat’s “hack” to be quite hilarious
“wow, he’s using an arbitrary starting state, he should be using the arbitrary one we have always used up to this point instead!!11”
but still, like Nach says this TAS isn’t valid until it’s proven that said state can be reached from power-on
just wanted to tune-in in favor of what Adelikat’s doing because of all the opposition that it’s getting
There's nothing hasty about how I feel here. I've been complaining for nearly a decade now about the lack of documentation of initial states.
Is there a thread discussing this? One that would collect pros and cons of documenting the initial state in TASes. It's not a problem to implement (specifying the state was available long ago, see my savestate-anchored movie), but it's a matter of deciding which direction the site should take and which audience to consider.
Nach wrote:
If there's only one initial state allowed for something, the emulator should enforce it. If there's multiple, the emulator should allow the user to set the possibilities, or use rand().
That's it, between these two alternatives you would choose forcing the user to set values, while I would choose rand(). I'm saying "forcing him" instead of "allowing him", because we all know: missing an opportunity is not an option in TASing.
In a way, emulators already use rand() now, if you remember this picture: http://xkcd.com/221/ The returned state is random enough in that it doesn't correlate to player's wishes. Unfortunately, it can't be truly random, as this would make TASing impossible.
Nach wrote:
If the game was designed with hamming codes at every level, extreme regulation on all aspects and so on, giving the sense it was defensively programmed against such issues, implying they are part of normal operating conditions, then that would be an entirely different story.
Yeah, it would be called "software testing". That's what I meant by the technique being irrelevant to TASing.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
AnS wrote:
Nach wrote:
There's nothing hasty about how I feel here. I've been complaining for nearly a decade now about the lack of documentation of initial states.
Is there a thread discussing this? One that would collect pros and cons of documenting the initial state in TASes. It's not a problem to implement (specifying the state was available long ago, see my savestate-anchored movie), but it's a matter of deciding which direction the site should take and which audience to consider.
This is not TASVideos related. I've worked on developing several emulators, with many other developers, and we've had long discussions on the topic. The single biggest issue is that some games depend on an initial state, which the board enforces, or the SRAM is preset from the factory, and our emulators do not handle it properly. I believe that emulators need to emulate things here properly, and currently it's all up in the air.
AnS wrote:
Nach wrote:
If there's only one initial state allowed for something, the emulator should enforce it. If there's multiple, the emulator should allow the user to set the possibilities, or use rand().
That's it, between these two alternatives you would choose forcing the user to set values, while I would choose rand().
No, I wouldn't enforce the former. I'd default rand() between the different states, and allow the user of the emulator to choose one of the possible states if they choose to.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Site Developer, Site Owner, Expert player
(3571)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
An owner of the game was kind enough to make a more thorough video demonstrating this glitch, here is video proof. This video shows it can (easily) be recreated by ONLY pushing the power button.
Here's a brief summary of the proof I'm offering:
1) As shown, this glitch can occur from simply powering-on the game. The only possible explanation of that behavior is some sort of variable being in an unknown state and used
1) messing with the initial RAM pattern (0000FFFF) has NO effect on this game. I tried, via scripting enough random combinations using this technique (all 0's, all 1's etc, then pure random patterns). I left a script running for some days and never once did the game do anything but start normally. This eliminates the NES's ram as the culplrit.
2) Debugging shows that the game runs a for loop to clear out the NES WRAM space, so it is expected that random ram initializations would not affect the game
3) The only other variables in play would be on the cart itself (these are mapper registers). This game have prg registers to control which part of the program to execute from. Messing with these values give you consistent results with the videos showing this glitch, including starting from level 5
4) There are 32 possible PRG register combinations, only one of which starts you at level 5 and in a playable state.
5) This movie uses that one combination and produces results IDENTICAL to video evidence
6) Videos evidence shows that this can be done from reset OR power, and that this is consistent with the theory that it is a random register issue
7) "How do we know this EXACT register state is possible?" It is KNOWN among EE people that registers can be in a random state. In this case is 6 bits, nobody has said anything other than it is likely and reasonable to assume all are possible states. Furthermore, the results produced are identical to video evidence, AND there is only 1 combination that yields this evidence. And if there wasn't more than one, who cares? If I put in 13 instead of 11 and they both produce this, the end video is identical.
I personally think that I've given more than enough evidence to suggest that this is the explanation of how this glitch is occurring and that the emulator is faithfully emulating this behavior. Can we move on from me defending the TAS itself? The implications of accepting this movie's premise (exploiting the initial hardware state) is a good debate and worth having, and I hope we will focus on that now, going forward. (Note: this post intentionally avoids this subject, but I do have a lot to say on the matter)
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Your evidence is pretty good. My question left is the state, you keep talking about the state of the PRG register. I previously thought there was no more state, but your post above now clarifies that you previously only spoke to a single register, as opposed to the register state as a whole.
When we speak of state of registers, we don't mean a single register in isolation. If you're using a state, the combined state of all registers needs to be valid. So what's the story with them? Does the game initialize them?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Having such a proof I now support this submission's acceptance.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Emulator Coder, Site Developer, Site Owner, Expert player
(3571)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Nach wrote:
Your evidence is good. Only question left is the state, you keep talking about the state of the PRG register. Are there other registers? If you're using a state, the combined state of all registers needs to be valid. If you tell me there are no other registers, or the game initializes them fine.
I've linked this too may times, your question clearly shows you haven't even bothered to click it
but I will appease you and put it directly in this post! To save you 1 click:
1 bit prg mode(needs to be 1 in this movie)
5 bit prg bank (needs to be 11 in this movie)
5 bit chr bank (can be anything and achieve these results, irrelevant, as char usually is, worst case you get a garbled but playable game
1 bit mirror register (irrelevant here, either value has no effect on start up behavior)
1 bit bank size - only action 52 uses this
2 high prg bits - only action 52 uses these
