I thought you knew how to do that, since you said you removed the menu from the title screen.
EDIT:
Never mind, I think I got it. There is another global variable that holds the controller status, at 0x926E, and is used by the intro/title screen function (0x227BC) and the stage selection screen function (0x17C4E).
I was going to try to find that out some day, but, since you asked, I felt obliged to start doing that immediately.
I already knew from previous attempts at hacking the game that the password (note: I’ll call it the password even though I haven’t told you whether it’s a password yet), unlike in eg. Insmouse, does not get stored anywhere into the WRAM, probably because there is nowhere to enter it. So I had to find the function that displays it. That was easy, and fortunately it was a separate function, while most of the gameplay code is in one huge function.
I assumed that the function only displayed the password and was not responsible for calculating it, so I thought I had to go somewhere else to find the calculating function. Common sense dictated that the call to the calculating function had to be close to the call to the displaying function. Well, there is only one place in the code where the displaying function is called and I noticed it was being passed two values. One of them was the current level, the other one was unknown to me. But it was a dead giveaway that the function was not only responsible for displaying the password, but for calculating it as well.
Virtual Lab code is very hard to follow and completely unlike the code in Insmouse: the functions are long, full of redundant instructions, and everything seems to be as complicated as possible; apparently the code was compiled without any optimizations. Since the password function contained both the code to calculate the password and to display it and was very long (much longer than you’d think, considering what it does), I really didn’t want to figure out how it works.
Instead, I decided to play with the two values passed to it. They were both global variables (so I don’t know why they decided to pass them as parameters, but at least it made reverse engineering much easier) and I knew one of them was the level. It shouldn’t be too hard to figure out what the other is, right? It turned out to be the “MAX” value. Amusingly, the game has two MAX-related variables, both of them global: one is incremented each time the on-screen MAX display is incremented, and the other is calculated before the incrementing begins.
Now that I knew what both values were, it was time to try out different combinations of them to see how they influence the generated password. Here are some of them:
Level 1, MAX 0: 0000000
Level 1, MAX 1: 0000016
Level 2, MAX 0: 0032000
Level 2, MAX 1: 0032016
A pattern emerges. We can see that to get the password of a given level and MAX value, we simply use the formula
P = L * 32000 + M * 16
where L is the completed level, starting with 0 for level 1, and M is MAX, which may be no higher than 62, although that value is impossible to get during gameplay. Let me also point out that, according to this formula, some of the passwords listed on this site are invalid because they are odd, while the formula only produces even numbers. All others are valid. I will speak about this later.
This formula works only for values of L up to 7. If you use it for L = 8, you will get 0256xxx, “xxx” depending on MAX. The game, however, gives you 1256xxx for completing level 9. Well, if you look at the password list on this site, you will see that the passwords for L values of 0 to 7 begin with a 0, 8 to 15 with a 1, 16 to 23 with a 0, 24 to 31 with a 1, and so on. So, in programming terms, if the bitwise AND of the level and 8 is nonzero, the password starts with a 1, otherwise it starts with a 0. This extra step appears to exist only to make reverse engineering the passwords slightly harder, as you will see later.
But even that only works up to L = 15. Starting with 16, things get weird. If you use the formula with 16, you get 0512000, but the game says 0002xxx. Long story short, if you look at the password list, you will see that, if you ignore the first digit, the passwords don’t just keep getting higher, but “roll over” to a smaller value periodically.
It was midnight (it was already 7:31 PM for me when you asked the question) and I was tired, so I went to sleep and continued the research in the morning before going to school (it starts at 8:40 AM on certain days). I discovered that the correct encoding algorithm (but not necessarily the one used in the game) is this (presented in an obscure programming language called NewtonScript, which is my favorite programming language and has a syntax similar to Pascal):
P := (L * 32000 + M * 16) mod 510000;
if BAnd(L, 8) <> 0 then P := P + 1000000;
Note: “mod” is the modulo operator, which here is effectively the remainder of division and is responsible for “rolling over” the number. “BAnd” is the bitwise AND function.
As you can see, L = 16 now gives us 0002000, which is a valid password. Now I only had to find a way to decode the level and MAX from any given password. My previous method was
P := P mod 1000000; // ignore the first digit
M := P mod 1000;
L := (P – M) div 32000; // get level
M := M div 16; // get MAX
but that only worked for values of L lower than 16. (Note: “div” represents division whose result is rounded towards zero.)
My classmate Sebastian Čolić (got to give credit where credit is due!) figured out the rest during history class.
For example, if you have the password 0034000, you will see my decoding algorithm fail. 34000 div 32000 is 1, but the correct level is 17. It turns out you have to pay attention to the remainder too. 34000 mod 32000 is 2000. Divide 2000 by 2000, multiply the result by 16, add 1, and you get 17. The correct algorithm, which I then tested against all the passwords listed on this site, except the odd ones, is this:
P := P mod 1000000; // ignore the first digit
M := P mod 1000;
P := P – M; // get rid of the last three digits
M := M div 16; // get MAX
Q := P div 32000;
R := P mod 32000;
L := R div 2000 * 16 + Q; // get level
Here are the rules for determining whether a given password is valid (there may be more):
* If the bitwise AND of the 0-based level and 8 is nonzero, the first digit of the password must be 1, otherwise it is 0.
* The last three digits, taken as a number, must be divisible by 16 and must not be higher than 832, because 52 is the highest possible MAX value (I think).
* The 0-based level must not be higher than 99.
Here is one more interesting fact about the game, which is not related to passwords: the game indeed ends and repeats on level 100, but since the level display is only two digits wide, the number 100 doesn’t display correctly. The programmer[s] accidentally checked for level 99, forgetting that it will be displayed as 100, while they should have checked for 98 instead.
The 17-year old mystery has finally been solved.
Yes, that’s an annoying flaw in the game. I’ve thought about hacking the ROM to fix this, but the code is such a mess that I can’t promise anything.
EDIT:
If it bothers you that much, play on the lowest speed. The scoring rules are the same anyway.