| Home | Forums | What's new | Resources | |
| question about master codes |
| xhul - May 23, 2025 |
 |
privateye | May 23, 2025 | ||||||||
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.
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 | May 23, 2025 | ||||||||
Hello privateye, thanks a lot for the reply, it's much appreciated.
That was my thought initially, but it seems there's at least 1 exception, please continue reading.
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... | ||||||||||
|
xhul | May 25, 2025 | ||||||||
That's a bummer, but i guess there's a good reason for such limitation.
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 | May 25, 2025 | ||||||||||||
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.
See above.
This one is kinda strange :
| ||||||||||||||
|
xhul | May 25, 2025 | |||
|
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:
| |||||
|
xhul | May 30, 2025 | ||
|
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). | ||||