question about master codes

[xhul]

Welcome.

I'm currently in the process of gathering some action replay codes for popular titles, from the web.
During my search, i came across some sets without master codes multiple times, and i'm not sure if people just forgot to specify those or not.
Unfortunately, i can't test anything right now, so here's what i'd like to know:
Is at least 1 master code required for regular codes to actually work?
If no, is a regular (non-master) "enable" code required as a replacement?

Thanks in advance for your time =]

 

[privateye]

Is at least 1 master code required for regular codes to actually work?

Master code is required to use cheat codes on real hardware, technical details are available here and in section 12x of the Pseudo Saturn Kai readme. Emulators can directly modify memory so they don't require it.

If no, is a regular (non-master) "enable" code required as a replacement?

Enable code basically acts like an if-statement as it activates all other codes only when a given address contains a specific value. This functionality is an essential component of these codes that allow Radiant Silvergun to be practiced way more easily on real hardware; technical details are available in the second spoiler.

 

[xhul]

Hello privateye, thanks a lot for the reply, it's much appreciated.

Master code is required to use cheat codes on real hardware.

That was my thought initially, but it seems there's at least 1 exception, please continue reading.

Enable code basically acts like an if-statement as it activates all other codes only when a given address contains a specific value. This functionality is an essential component of these codes that allow Radiant Silvergun to be practiced way more easily on real hardware; technical details are available in the second spoiler.

According to everything i've gathered so far, conditional codes seem to be interpreted in 2 pretty different ways:

- Inside the cheat entry, the conditional code is followed by at least 1 regular code (just like in the link about Radiant Silvergun you posted).
In that case, the condition basically determines in which context the other code(s) in the entry should be executed, and doesn't affect other entries whatsoever.

- Inside the cheat entry, the conditional code isn't followed by anything (way less common).
In that case, the entry is usually labelled "enable code (must be on)", and the condition appears to affect all other entries.
Furthermore, when an enable code is present and on, master codes don't seem to be required, at least not always.
Here's a good example: https://gamehacking.org/game/82542
I tested the "invulnerable" cheat with no master code at all (master code quantity 0 in the data), and it worked just fine on real hardware (AR4M+).
So, what i'd like to know, is if the enable code itself is the reason why no master code is needed.
It could also be that when there's no master code, the firmware uses a default one, but i'm not sure about that at all...

 

[privateye]

- Inside the cheat entry, the conditional code is followed by at least 1 regular code (just like in the link about Radiant Silvergun you posted).
In that case, the condition basically determines in which context the other code(s) in the entry should be executed, and doesn't affect other entries whatsoever.

As demonstrated by these Radiant Silvergun cheat codes, Action Replay doesn't support "local" enable codes :

1) Player one has unlimited Radiant Sword while on their last life
D6076AB6 0000
3601E5F2 00FF

2) Player one is invincible while their score is zero
D6076DFA 0000
3601E631 00FF

3) Player one is invincible while on their last life
D6076AB6 0000
3601E631 00FF

4) Player one always has unlimited Radiant Sword
3601E5F2 00FF

Activate (1) and (2) :

• Expected result - Both conditionals active.
• Actual result - Player one has unlimited Radiant Sword while their score is zero, but invincibility is never granted.

Activate (3) and (4) :

• Expected result - Player one always has unlimited Radiant Sword and, while on their last life, invincibility is granted.
• Actual result - While player one is on their last life, invincibility and unlimited Radiant Sword are granted.

- Inside the cheat entry, the conditional code isn't followed by anything (way less common).
In that case, the entry is usually labelled "enable code (must be on)", and the condition appears to affect all other entries.

Correct.

Furthermore, when an enable code is present and on, master codes don't seem to be required, at least not always.

A master code is absolutely required for an enable code to work because no master code = no cheat code handler = no ability to do conditional writes while the game is running. I guess it works because...

It could also be that when there's no master code, the firmware uses a default one, but i'm not sure about that at all...

... it's falling back to a default master code as you suspected, most likely one of these :

F6000914 C305
B6002800 0000

F6000914 C305
B60FF000 0000

 

[xhul]

Action Replay doesn't support "local" enable codes.

That's a bummer, but i guess there's a good reason for such limitation.

Activate code sets 1 and 2 :

• Expected result - Both conditionals active.
• Actual result - Player one's Radiant Sword is filled up immediately and invincibility is never granted.

So set 2 is completely ignored, i see.
What if the player has 3 lives and score 0, will the invincibility be granted?

Now, let's say:
- The player is on its last life, with score 0.
- The condition in set 3 is removed.
- Sets 1,2,3 are enabled.
Will the invincibility be granted?

Sorry for all these questions, i'm trying to understand the algorithm as sharply as possible.
Thanks in advance =]

 

[privateye]

So set 2 is completely ignored, i see.

Perhaps my original pre-edited post gave that impression but it's not completely ignored, it becomes a weird mix of both sets as player one has unlimited Radiant Sword while their score is zero, but invincibility is never granted.

What if the player has 3 lives and score 0, will the invincibility be granted?

See above.

Now, let's say:
- The player is on its last life, with score 0.
- The condition in set 3 is removed.
- Sets 1,2,3 are enabled.
Will the invincibility be granted?

This one is kinda strange :

• Player one has unlimited Radiant Sword while their score is zero.
• Player one is invincible while their score is zero AND on their last life.

To test this, I had to set Player Stock to 1 as it's impossible to lose lives without gaining score.

 

[xhul]

Interesting =]

I managed to find a way to test multiple combinations, as carefully as possible.
The design of the algorithm is much clearer now, though its behaviour doesn't exactly make sense.
Note that my tests were performed on SUS 2.06, which has a decent chance to parse codes exactly like ARP 2.02.

Facts:
- The way codes are distributed into entries doesn't alter the way the algo works, it always treats all codes in all enabled entries as a single list (take that as a confirmation to what privateye said earlier).
Now, the list is processed as follows:
- If no condition is present, all actions are executed unconditionally, as expected.
- If only 1 condition is present, all actions are executed|skipped if true|false, no matter if they're stated before or after it.
- If 2 or more conditions are present:
--- Only the condition stated last is evaluated, all others are ignored.
--- Only actions stated before it are executed|skipped if true|false, all others are ignored (to be clear, "before" also includes actions stated before ignored conditions).

So the code order matters quite a bit, here's a few examples:

Spoiler

- condition 1 - ignored
- action 1
- action 2
- condition 2

- action 1
- condition 1 - ignored
- action 2
- condition 2

- action 1
- action 2
- condition 1 - ignored
- condition 2

- condition 1 - ignored
- action 1
- condition 2
- action 2 - ignored

- action 1
- condition 1 - ignored
- condition 2
- action 2 - ignored

- condition 1 - ignored
- condition 2
- action 1 - ignored
- action 2 - ignored

 

[xhul]

I might have made an interesting discovery.
First of all, it's already known that non-master codes are basically handled like this:

CAAAAAAA VVVV (each digit hexadecimal)
C = command identification
AAAAAAA = RAM address
VVVV = value to deal with

When it comes to the command identification, the following values are documented:

0 = 16-bit write (once at boot)
1 = 16-bit write (continuous or conditional)
3 = 8-bit write (continuous or conditional)
D = 16-bit read+comparison

As you can see, the quantity of available commands is a joke compared to what was available for the Playstation, for example.
The lack of 8-bit comparison sucks, at least.
Anyway, since it seems i like to dig, i tested all other prefixes, just in case...

Prefixes 2,5,6,7,8,9,A,B,C,E,F:
Inputting those using the user interface causes a bug that changes the data upon saving it, pretty randomly.
It's safe to assume they don't correspond to any command at all.
My guess is that they were supposed to be handled at the time of saving (most probably by changing the digit), but they screwed up the security code.
However, it would be interesting to see what happens if you inject those on the firmware instead of manually...

Prefixe 4:
That's where it becomes interesting, since no bug occurs at the time of saving with that one, just like with 0,1,3,D.
I just started investigating, the idea being to spot either a write, read+comparison, or maybe something else.
It's too early to tell how it's interpreted exactly, all i can say for now is that it's definitely not ignored by the code parser.
EDIT 1: I can say with 100% certainty that it's processed differently than commands 1,3,D.
EDIT 2: It appears to be a duplicate of command 0 (it does what command 0 does at least, i haven't checked for additional effects).