| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Tue, May 03rd, 2011 @ 20:45 ( . ) |
I'm guessing you're referring to the PAL version of Express Raider. I took a quick look at it and it uses track 38 like V-Max uses track 20. Waits for sync, then starts decoding GCR bytes 2:1. The decoded data starts getting written to the drive memory at address $170, building more drive code. This code is then executed and looks for a $77 byte, which it never seems to find, so this is where it fails in the emulators. If it were to find this byte and continue, it would move the head to track 39, set a timer, and start looking for a sync mark which it must find before the timer runs out. So this is also a track-sync protection. When the sync ends, it loads data into the $700 buffer using 2:1 GCR bytes like it did on track 38, then jumps to execute it when done. Since I forced the sync timer to never fail when testing this, I guess I got the wrong sync mark (there's a few on this track) and the drive got loaded with garbage, so I don't know what this code is supposed to do. Normally when the sync timer runs out, it moves the head back to track 18 and ends. There's illegal GCR all over the place on these tracks which could cause you problems. Also, the track sync is problematic for most drives. The illegal GCR seems to arrange properly with the nibconv -bf option, as Pete mentions in the database entry. Track 39 would need to be rotated in the G64 image so that the head lands at the correct spot for this to work in emulators, and/or the $77 byte placed in a spot on track 38 that accomplishes the same task. This requires some testing to see which block of data it actually needs and then what happens after it gets it. |
--- 0 Users Online --- 0 Recent Unique Posters |