| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Mar 09th, 2011 @ 01:10 ( . ) |
A-HA! I finally figured it out. The protection code is loaded into the $700 buffer of the drive by the C64 and executed. This copies it to $200 buffer and runs from there. However, after the code executes and does it's 5 checks, it goes back to track 18 and the C64 uploads ANOTHER block of protection code to execute. This one is short, but nasty! It goes back to good old track 12 again, finds the sector 0 header, then skips to the sync mark of sector 1 header. It counts this sync length using the VIA timers in $1804/$1805 since the old BIT/BMI isn't accurate enough, then compares it to a predetermined value. It does this for the next 255 sync marks! Takes about 2-3 seconds to run on the track. The drive then gets one last small block of data into $700 from the c64, and it copies it to $120 and we're done. The game loads the raiding section starting at track 24. So in total all these extra-level protections probably add an extra 8-10 seconds to the load time. Crazy. The first round of protection checks can probably be passed if remastered correctly. I doubt the exact sync count can be. This is likely why it was always patched out. Vice would probably be able to emulate this if it were cycle exact (apparently 2.3 is, not sure if that also applies to the 1541 emu code as well). Lots of fun looking at this one! And I never even looked at the c64 side of the code yet... Attached is the updated disassembly with comments. The extra $700 sections are at the bottom. |
Attachments: |
| 1299651028_dotc-vmax.txt |
--- 0 Users Online --- 0 Recent Unique Posters |