Note: if this is just an empty box, something went wrong. Try Firefox.
Here is a password generator for the classic NES game, The Battle of Olympus. A few notes: Of the eight unknown bits (other than 95 which just seems to cause glitches and is not set on any password I've seen), I imagine they have to do with the Centaur and/or Ladon, and things in Crete, Phrygia, and Tartarus. I haven't have a chance to investigate these areas thoroughly yet.
At some point I'll go into more detail about the encoding.
Since there are two full checksum characters, only one in 4096=2^12 passwords are valid, which explains why guessing always fails so miserably. There is also a redundancy of 64 different encodings of the same information. This shows up as a freedom to cycle the characters. I therefore hold the second character constant (since the checksum character is no good for this), so that changes only affect the parts of the password to their right.
The maximum number of salamander skins is 31.
I think the max life is 56 with the golden apple, 28 without. But up to 63 can be entered without a problem. Starting with only 1 life is glitched for me. Zero is allowed, but I promise you won't get far.
I've written a utility to enter passwords into an emulator window automatically (in Linux at least), and may post it at some point.
Steve Hicks (sdh33 at cornell edu)
BoO passwords have 26 characters from an alphabet of 64. In order, 0-9 correspond to 0x00-0x09, A-Z to 0x0A-0x24, a-z to 0x25-0x3D, and ? and ! to 0x3E and 0x3F. Thus, each character is 6 bits, and all arithmetic we will do from now on is thus modulo 64.
The actual information content of the password is 23 characters long. Two characters are used for checksums and one is arbitrary. Call the 23 characters a(1) through a(23). The first checksum is to pick a(0) such that a(0)+...+a(23)=0x00. Now pick an arbitrary character c(0). Compute c(i+1)=[c(i)^a(i)]+d(i) where d(i)=0x38,0x0A,0x12,0x26,... for i=0,1,2,3 and repeating with a period of 4 beyond that.
We now have c(0)...c(24), giving 25 characters. The last character c(25) is computed soo that c(0)+...+c(25)=0x00. If both of these checksums are satisfied, then the password is valid.
A note about how I figured this out: I began with a list of all 64 null passwords (names 000000 and not collecting any items - FCEU's "~" key, which runs the game at super speed, made this a LOT easier). XORing any pair of these together, shows strong (but not quite fully-ordered) patterns, as well as XORing adjacent bits. I also XORed with slightly more advanced passwords (at a different location, with 1 or more olives, etc, and picking the null password that was most similar). Finally, what really started to open it up was changing the name by one or two letters. I noticed that there was a single byte, to the left of which it matched one null password and the right matched the other ("xorpass | grep 00" was a lifesaver, especially since it highlights the zeros in red). In light of that, and noticing repeated patterns in the set of null passwords, I tried finding a recursion formula for the next letter given the previous that would work for all 64 passwords with the same meaning, and came up with this XOR-ADD pattern. The checksums were pretty easy since all the characters just add to zero, and it was obvious where they were by how passwords always changed the first and last characters.