| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Apr 14th, 2011 @ 00:38 ( . ) |
Has anyone noticed anything odd with Vice 2.3 when it comes to sync marks (maybe related to illegal GCR), specifically with V-Max V2? In my attempts to get a working copy of Gauntlet: The Deeper Dungeons, it would always hang on some track and entering the debugger would show the drive code looking for the sector header on the track and it would never find it, even though I could see it in the image. Checking the $1C01 register to see the GCR bytes it was seeing on the "disk" showed byte sequences that didn't even exist in the image. I encountered the same problem with Bad Street Brawler on track 8. However, loading these images in Vice 2.2 works. I found that for the problematic tracks, if I added a sync mark in front of the $64 byte of the first sector on the track (in relation to where the track started in the image, not necessary logical sector 1), it would then load properly in Vice 2.3. However, it would sometimes, depending on the track, fail the V-Max sector checksum in Vice 2.2 unless I made the sync mark another 8 bits longer (as seen on BSB track 10). So does Vice 2.3 adjust framing when it encounters bad GCR? Or is this just an odd bug? In the end, I was able to get a copy of Bad Street Brawler that worked on both versions of the emulator by adding the sync marks to the tracks it was hanging on, but I can't figure out why, since the protection doesn't even look for sync. It moves the head to the track and immediately just starts reading GCR bytes and comparing the byte read to $64. |
4/14/2011 @ 20:28----Pete Rittwage --- 0 Users Online --- 0 Recent Unique Posters |