DjayBee

Besides the counter there is some more difference between sector 365 ($16D) on different disks. The counter is located in the first byte of the sector. But bytes 123 ($7B) and 126 ($7E) differ also for the four dumps I analyzed recently. The counter is always written back immediately while the game boots up. So I doubt that these two further bytes are a high score or some playing time. It might be some serial number of the disk. Perhaps somebody else can check this sector own her/his own copy of the game. See below. The first screen shot shows the differences between Farb's and Zarxx's dump and the second between a .PRO-dump from pigwa and Atarimania's dump. Btw.: Sector 369 ($171) seems to be a copy of the original sector 365 with the counter set to 0.

Stay tuned.

If you can mix Linux/Cygwin with Windows go this way: Convert your binary files on Cygwin/Linux to a hex dump using xxd -g 1 "BINFILE" "HEXDUMP" and then use Winmerge http://winmerge.org/?lang=en to see the differences. I would guess that something similar is also available for MacOS. This way I do my comparisons of different disk dumps.

Did you try to write ATX files back to real floppies? Because for converting flux dumps to ATX the above is a known bug of a8rawconf v0.8 which is fixed in the current build.

Further investigation showed that there are several titles from Datasoft which use the exact same protection as Lost Tomb. All titles have the same boot loader which in fact is a wrapper which does the - up to now from Lost Tomb missing - first protection check and loads three sectors which are a boot loader themselves (including the 6 byte header). And these following three sectors are the same ones which the current dump of Lost Tomb used as its initial boot loader. Replacing the first three sectors of Lost Tomb with the first three sectors of Dig Dug made Lost Tomb behave identical to these other titles. So, mistery solved: Lost Tomb uses the first check for duplicate sectors as well and now the ATX should be very close to the real thing. It seems that only Mr. Do has the fourth protection on track 40. Lost Tomb (1984)(Datasoft)(US)(p).atx.zip Lost Tomb (1984)(Datasoft)(US)(p).atr

Thanks, this was fast and exactly what I wanted. Did you hand-craft this or do you have a tool? Find the result here: http://atariage.com/forums/topic/234684-atari-8-bit-software-preservation-initiative/page-22?do=findComment&comment=3686745

Some more archaeological uncracking. Shanghai (1987)(Activision)(GB) Thanks to Zarxx for providing the needed blank ATX image with weak sectors. Have fun. Shanghai (1987)(Activision)(GB)(uncracked).atx.zip

Can somebody come up with an ATX file that has all-good sectors except 595-605? Sectors 595-605 all must have "weak bits" with 64-65 stable bytes. These are the first 11 sectors on track 34 (if counted from 1). ATR Tools would have been my tool of choice but the currently released version can only show ATX images.

Here is a set of two different versions; each cracked and as an ATX. The ones with "(a)" in their name are derived from the Atarimania dump. The ones without are modified .PROs from post #2 of this thread. The dictionary disks are identical except for one sector. I guess that this is the result of a bad disk, but I don't know which one is the good one. Give it a try Spell Wizard Master (1982)(Datasoft)(US)(a)(uncracked).atx.zip Spell Wizard Master (1982)(Datasoft)(US)(a)(uncracked).atr Spell Wizard Dictionary (1982)(Datasoft)(US)(a).atr Spell Wizard Master (1982)(Datasoft)(US)(p).atx.zip Spell Wizard Master (1982)(Datasoft)(US)(p).atr Spell Wizard Dictionary (1982)(Datasoft)(US).atr

Leaked maybe but not before CP was put in because a LOT of its code is already there. The first two examples above show the same code with two exceptions: In the first case a single assembler command "STA $1C80,Y" is missing. It is the one which writes the decrypted byte back to RAM because the ATR has the code unencrypted on disk. BUT the "LDA $1C80,Y" and "EOR $1C00,Y" are still there. In the second case a complete EOR-loop is missing. It looks like somebody had the source of the loader, commented out a few lines which where essential for protection and assembled it.

During dump comparison I found three different dumps of Ace of Aces. Two different program versions with three different loaders. It would be quite interesting to find out the story behind these dumps. The probaly main released version is "Ace of Aces (1987)(Accolade)(US)[req 64K].ATX" from Farb's archive. It is protected with two sets of duplicate sectors, one sector with a CRC error and heavily EOR-encrypted code. So there is nothing special about this one. Examples: Decyrption of code: 1C23: A0 7F LDY #$7F 1C25: B9 80 1C LDA $1C80,Y 1C28: 59 00 1C EOR $1C00,Y 1C2B: 99 80 1C STA $1C80,Y # This one is missing in the ATR 1C2E: 88 DEY 1C2F: 10 F4 BPL $1C25 More decryption of code: 1CD7: A9 09 LDA #$09 1CD9: 8D 9B 1D STA $1D9B 1CDC: 20 72 1D JSR $1D72 1CDF: A0 00 LDY #$00 # This whole loop ... 1CE1: B9 00 80 LDA $8000,Y 1CE4: 59 00 81 EOR $8100,Y 1CE7: 99 00 80 STA $8000,Y 1CEA: B9 00 81 LDA $8100,Y 1CED: 59 00 82 EOR $8200,Y 1CF0: 99 00 81 STA $8100,Y 1CF3: C8 INY 1CF4: D0 EB BNE $1CE1 # ... is missing in the ATR 1CF6: A5 14 LDA RTCLOK+2 1CF8: C5 14 CMP RTCLOK+2 1CFA: F0 FC BEQ $1CF8 The area $8000-$82FF contains the protection check. . Atarimania and Fandal have the same program version but with no protection at all in the image "Ace of Aces.ATR". It uses the same loader as the ATX. The weird thing about this loader is the fact that it seems not to be cracked BUT to be assembled specifically to not have the protection checked. It omits single instructions or whole blocks of code in several palces. They are not NOPed out but just not there. No cracker would have made such an effort to remove a copy protection. But why would a developer create a specifically unprotected copy of its own software? The same code as above as an example: NON-decryption of code: 1C23: A0 7F LDY #$7F 1C25: B9 80 1C LDA $1C80,Y 1C28: 59 00 1C EOR $1C00,Y here is an STA in the ATX 1C2B: 88 DEY 1C2C: 10 F7 BPL $1C25 1C2E: C8 INY More NON-decryption of code: 1CD1: A9 09 LDA #$09 1CD3: 8D 7E 1D STA $1D7E 1CD6: 20 55 1D JSR $1D55 here is an EOR-loop in the ATX 1CD9: A5 14 LDA RTCLOK+2 1CDB: C5 14 CMP RTCLOK+2 1CDD: F0 FC BEQ $1CDB The area $8000-$82FF is empty. . The third dump is "Ace of Aces (1987)(Accolade)(US)[a1][!][req 64K].ATX" which again is part of Farb's archive. This one has different game code and a loader which checks for the same protection as the first ATX but fails completely in its task due to ludicrous programming errors. Programming errors: Missing "#" leading to sector reads to non-existing sectors 721-767: 1BEF: A9 BE LDA #$BE 1BF1: A0 02 LDY #$02 1BF3: 20 45 1C JSR $1C45 # read sectors $2be-$2ff 702-767 1BF6: AD 0A 03 LDA DAUX1 1BF9: 18 CLC 1BFA: 69 01 ADC #$01 1BFC: C5 CE CMP $CE # =$00 => (should be #$CE) 1BFE: D0 F1 BNE $1BF1 # ... until sector $2ff (instead of $2cd) "unexpected" read error of sector with bad CRC which should be expected: 1C66: 20 78 1C JSR $1C78 # =JSR SIOV 1C69: 30 01 BMI $1C6C # sector bad => crash => ($2ce is intentionally bad) 1C6B: 60 RTS # go ahead if good 1C6C: 00 BRK # bad result of sector $2ce branches to BRK-interrupt, ... 1C6D: A9 00 LDA #$00 # ... runs into this code ($1c6e is BRK) ... 1C6F: A0 04 LDY #$04 # ... $1c70 is NOP $8D ... 1C71: 8D 04 03 STA DBUFLO # ... $1c72 is NOP CASINI+1 ... 1C74: 8C 05 03 STY DBUFHI # ... and returns "by accident" to the calling code 1C77: 60 RTS # ... with this RTS Verify contents of protection sectors. 1C7F: A2 00 LDX #$00 1C81: BD 00 21 LDA $2100,X # contents of sectors $2cf 1of2 and $2cd 2of2 1C84: DD 00 20 CMP $2000,X # contents of sectors $2cf 2of2 and $2ce => (instead of $2cd 1of2) 1C87: D0 05 BNE $1C8E # exit loop if bytes differ => (succeeds always at sector $2ce) 1C89: E8 INX 1C8A: D0 F5 BNE $1C81 1C8C: F0 DE BEQ $1C6C # => crash if both buffers are identical 1C8E: A2 00 LDX #$00 1C90: BD 80 20 LDA $2080,X # contents of sector $2ce 1C93: 49 FF EOR #$FF 1C95: DD 01 31 CMP $3101,X # => nothing done with the result of the CMP! 1C98: E8 INX 1C99: E0 26 CPX #$26 # only bytes $00-$25 of sector 1C9B: D0 F3 BNE $1C90 1C9D: A2 00 LDX #$00 1C9F: BD 00 21 LDA $2100,X # contents sectors $2cf 1of2 and $2cd 2of2 1CA2: 5D 00 A1 EOR $A100,X # => (which are the ones read by a standard copy anyway) 1CA5: 9D 00 08 STA $0800,X 1CA8: E8 INX 1CA9: D0 F4 BNE $1C9F 1CAB: 60 RTS . Attached are all these dumps (including cracks of both ATXs). Ace of Aces (1987)(Accolade)(US).zip

Another conversion with missing sector 707 (instead of a "long" one): HardBall! (1985)(Accolade)(US)

My cart arrived on time for christmas and works fine. THANKS An idea for enhancement: SInce there are carts which work only on OS-A or OS-B it would be nice to have them run on XL or XE by pushing an OS image to the XL/XE-RAM under the OS before starting the cart. This would be similar to the ATR-loading of the cart. Does this work? One of the currently unused bytes of the CAR-header could be used as a flag for the UnoCart to decide this automatically.

Assuming the track count starts at 0, this is exactly the same sector which is bad in the current dump. Then maybe it has to be bad and is just not used when loading the game.

Read from here on: http://atariage.com/forums/topic/256683-altirra-280-released/page-9?do=findComment&comment=3627637

Hi Farb, results of dump comparison for the latest images submitted here: Same version as the one on Atarimania which I submitted some time ago. @remowilliams: Do you have an ATX of the first side as well? I suspect the current dump in the torrent to have a gone-bad sector. There is a version of Zaxxon which only works on unpatched NTSC OS-A and OS-B. It crashes exactly as you describe. Maybe you tried it with the patched OS-B which comes with PC XFormer archive just like me. This is a third version of the game beside the "picky one" from above and the older (patched?) one on Atarimania (which you removed from the torrent some time ago).

When the computer is switched on, the memory is read. When the computer is switched on, it reads something into memory. This sounds like the auto-loading of a handler over SIO. And since DDR ist the former eastern part of Germany it is reasonable that it might be an 850 clone.

Better verified twice than not at all.

See post #358 of this thread: http://atariage.com/forums/topic/234684-atari-8-bit-software-preservation-initiative/?view=findpost&p=3607035 In case you want to play it, see attachment. Wargame Construction Set v1.1 (1986)(SSI)(US)(Disk 1 of 2 Side A)(Editor).atr

LOL - yes.

I'm in for a cased one

Nice work. No need to do this and to disabled the decryption. Only the first some 16 bytes of sector 3 are actually encrypted and verified in memory. So you can hook up yourself there and work with live-patching the needed code. You only need to add one filler-byte to get the correct 1-byte sector checksum which is indeed verified. original end of decryption: 0834: 4C 12 07 JMP $0712 replacement: 0834: A9 08 LDA #$08 # original code runs to here 0836: 8D E5 07 STA $07E5 # JSR DSKINV => reroute to own code @$0853 0839: A9 7B LDA #$7B 083B: 8D BC 07 STA $07BC # JMP $0880 => reroute to own code @$087B 083E: 4C 12 07 JMP $0712 # original code from $834

@remowilliams: Great work, thanks Results of dump comparisons for the above dumps by remowilliams for Farb's database: The following are identical to the Atarimania dumps I submitted some time ago. The ATXs differ, so keep either of them: Bible Baseball Elektraglide.Atari Smash Hits Volume 6.Disk 1 Side 1 Timeslip.Atari Smash Hits Volume 6.Disk 1 Side 2 Tink! Tonk! - Tinka's Mazes.Side 1 Tink! Tonk! - Tinka's Mazes.Side 2 Tink! Tonk! - Tuk Goes to Town This dump is the same version as the Frankendisk I submitted (so kill my submission which is probably named as APX version): MECC Instructional Computing Demo @remowilliams: Is this a disk with an original MECC-label? I suspect this to be a gone-bad disk: Joe and the Nuclear Caverns It has five bad sectors scattered over the disk and none is accessed while loading the game. Two of these are inside an unsed DUP.SYS file. @remowilliams: Can you dump it a second time please?

They should because the code is unmodified except for the protection.