| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, May 24th, 2012 @ 21:46 ( . ) |
Yes, you really have to hand it to activision, it's a very clever and sneaky protection, it doesn't activate the check until side 2 is flipped. Once the check is switched on however, neither your copy of side 1 or side 2 will load unless it's an original or it's been dumped with nibtools of course. |
 | Author: | LordCrass (guest: search) |
|---|---|---|
| Date: | Fri, May 25th, 2012 @ 10:56 ( . ) |
I haven't checked this game, but I have the feeling this isn't some sneaky protection check. It's likely just an issue with the disk ID bytes in the sector headers and the way the loader doesn't bother to update the ID when you change disk. Portal (also by Activision) had this same issue. If Fighter Bomber uses KeyDOS, then this is the reason for sure. |
| Author: | LordCrass (guest: search) |
|---|---|---|
| Date: | Sat, May 26th, 2012 @ 00:24 ( . ) |
Confirmed. The original disk has two spaces for the disk ID in the directory on both sides. The sectors contain $30 $31 for the disk ID bytes. When asked to change disk, the loader keeps reading track 30 sector 4, and sends the disk ID bytes back to the computer, which only checks that the second byte is now a $32. When you convert this game to a d64, you no longer have sector headers. If this info is requested by a game, the emulator will supply it based on other data. In this case, it will always give you what was in the directory track for the disk ID bytes. When writing a d64 back to disk, it will write every sector with the ID taken from the directory. Mismatched sector IDs are easily copied by any software nibbler. Another way to bypass this is to change the ID in the directory to what the loader wants. Change side 1 to "01", and side 2 to "02". With Portal, this wasn't possible as the directory sectors on side 2 were used by game code instead of valid directory info. Changing the appropriate bytes would have corrupted the game. |