The emulation of Bubble Bobble is already virtually perfect, but there is still a doubt about the clock item.
Currently, when you pick it up the enemies stop but the bubbles continue moving.
It would make sense if the bubbles stopped moving too, and this idea is corroborated by the way variables are set up in the MCU shared RAM. The MCU would be responsible for stopping the bubbles and make them start again when the clock effect ends.
What we need is to verify the behaviour on an original board. Bootlegs don't count (the clock behaviour is definitely wrong in them), nor do other emulator or ports count. Only the original board matters.
Can anyone help?
Friday, February 24, 2006
Saturday, February 04, 2006
Coinmaster
Pierpaolo Prazzoli made me look at the encrypted question ROMs of the Coinmaster games.
It's nothing interesting, just a permutation of the address and data lines. The interesting thing, however, if how they gave away the encryption on the data lines by implementing the ROM checksum test in an unwise way.
To verify the checksum, the game reads all bytes in the ROM except the one at offset 2, and adds them with 8-bit arithmetic. It then takes the opposite of the result and compares it with the byte at offset 2, expecting them to be equal. What this actually means, however, is that adding all bytes in the ROM will always give as result 0.
Knowing that the sum of all bytes must be 0 instantly kills the data lines encryption. All one has to do is try to apply different permutations on the encrypted data, and calculate the resulting checksum. First look just at bit 0, ignoring the others. Try a permutation that leaves it in place, then one that replaces it with bit 1 of the encrypted data, then bit 2, and so on. Look at bit 0 of the resulting checksum. If it's 0 for all ROMs, then you got the right bit. So, in at most 8 tries, you'll find bit 0 of the permutation. Then move on to bit 1, and repeat the procedure. In at most 7 tries, you'll find bit 1 of the permutation. And so on.
It's nothing interesting, just a permutation of the address and data lines. The interesting thing, however, if how they gave away the encryption on the data lines by implementing the ROM checksum test in an unwise way.
To verify the checksum, the game reads all bytes in the ROM except the one at offset 2, and adds them with 8-bit arithmetic. It then takes the opposite of the result and compares it with the byte at offset 2, expecting them to be equal. What this actually means, however, is that adding all bytes in the ROM will always give as result 0.
Knowing that the sum of all bytes must be 0 instantly kills the data lines encryption. All one has to do is try to apply different permutations on the encrypted data, and calculate the resulting checksum. First look just at bit 0, ignoring the others. Try a permutation that leaves it in place, then one that replaces it with bit 1 of the encrypted data, then bit 2, and so on. Look at bit 0 of the resulting checksum. If it's 0 for all ROMs, then you got the right bit. So, in at most 8 tries, you'll find bit 0 of the permutation. Then move on to bit 1, and repeat the procedure. In at most 7 tries, you'll find bit 1 of the permutation. And so on.
Subscribe to:
Posts (Atom)