Defender dump does not look like an original

[tep392]

I was looking into the reason for some Defender xex's and bin's having 8 humanoids and others having 10. Note that the manual states there are 10. I started by comparing the official dump on this site to a cartridge dump posted by Mitch here in the forums and I found something very interesting. I found four area's where the files differed. I then disassembled Mitch's dump to investigate further.

Turns out that Atari included some code to write to ROM to prevent pirated code from running out of ram. I believe that the official version (red K) on Atarimania is actually a cracked version. It is also a bad crack, which is why it only has 8 humanoids. The person that did that version removed a line of code that looked like it wrote to ROM as a test for pirate code running out of RAM, but in fact it was just data. He created a bug that resulted in 8 humanoids. I simply changed those three bytes of code back to what was in the original (Mitch's) cart dump and now there are 10. So it appears that all the 8 humanoid versions floating around might be a version of this original crack because they contain the bug.

Here are the specific code differences.

Mitch's dump

file offset data opcode/operand notes
$0004 $a5 $13 lda $13 part of cold/warm start check
$0011 $a9 $ff lda #$ff part of cold/warm start check
$0b94 $8d $68 $b5 sta $b568 part of 1st ROM check
$2e15 $3e $20 $a9 rol $a920,x looks like it modifies ROM but just Data
$3481 $8d $3d $98 sta 983d part of 2nd ROM check


Atarimania download

file offset data opcode/operand note
$0004 $a9 $00 lda #$00 causes code to skip cold/warm check
$0011 $a9 $00 lda #$00
$0b94 $ea $ea $ea nop's tricks ROM check so RAM isn't detected
$2e15 $ea $ea $ea nop's this changed introduced 8 humanoid Bug
$3481 $ea $ea $ea nop's tricks ROM check so RAM isn't detected

Control is passed to the cart when the cold or warm start process jumps through the cart init vector. The first thing the program does is check the real time clock to determine if it was launched through this process. If not, it assume the program is a bootleg and was started through dos or some other manner. The Atarimania dump has this code effectively disabled by the changes noted above. There are also two segments of code that attempt to write into ROM space to verify a cartridge is present. These tests will fail if the program is being run out of RAM. The third bit of code at file offset $2e15 is not code at all, but some data. A disassember program would not know the difference and could assume it is code. My guess is that the person doing this crack mistook this for a write to ROM and thought it was another anti-piracy check. When this person replaced the line with NOP's, he created the bug that resulted in eight humanoids. It's just dumb luck that it didn't break the program enough to be caught as a bug. As a test, I took my xex version with 8 humanoids, and changed just the three bytes at $2e1b from $ea,$ea,$ea to $3e,$20,$a9. Note that the file offset is $2e1b, not $2e15, for the xex version. It now plays with 10 humanoids.

I've also checked an ATR version with 10 humanoids that was done some time ago by "Chumley". The three bytes, $3e,$20,$a9, are intact. Chumley, whoever he was, new what he was doing.

Based on what I have found, I suggest that Atarimania change their file to either the un-altered cart dump that Mitch provided, or another good dump. It is clear that the version on this site is hacked and could not be an official Atari version.

Regards

[tep392]

Update. I just purchased an original Defender cart and dumped it. It matches the dump posted on this site by Mitch. Doesn't match the official dump in the database.

[Allan]

For future reference, it looks like the hacked rom was replaced by a correct one.

Allan