| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 10th, 2011 @ 11:23 ( . ) |
In trying to analyze a number of the other V-Max V2 titles (Infiltrator II, Into the Eagle's Nest, etc), I've noticed that track 20 in the image is typically bad. This is due to the track having no sync marks, bad GCR that causes a loss of framing, and the imaging routine reading the track across these this bad GCR. A fix for this would be to insert a function in the 1541 drive code for nibread that waits for a certain string of GCR bytes to match before reading the track in. These header bytes could be obtained in 3 ways: 1. The custom protection handlers could provide this string based on what protection was chosen (ie. V-Max V2 = 5A 55 5A FF 37) 2. The autogap function could find the longest string of bytes, then provide that back to the drive code and re-read that track looking for those bytes. A better method would be to move the autogap function into the drive code and just search for the longest string there before reading in the track. This may still read the track in bit-shifted, but at least it's a consistent shift instead of a mix of different ones. 3. The user could supply it on the command line. Except for #2, these solutions also ensure that the data doesn't read in bit-shifted incorrectly. Not an issue for remastering, but an issue for emulators. This would also fix the issue with imaging the newer Vorpal disks. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Apr 10th, 2011 @ 21:01 ( . ) |
That could be done- I'll see how hard it would be to wedge into the code... There used to be a "read track after certain byte" sequence, but it was lost long ago due to never using it and needing extra RAM in the drive for other routines. |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Apr 11th, 2011 @ 10:35 ( . ) |
Hi. This is what we thought with sinbad and the throne of the falcon until someone reimaged it with a recent version of nibtools. If possible, try redumping into the eagle's nest with rev: 493 and see how track 20 turns out. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 11th, 2011 @ 12:00 ( . ) |
It's possible to "get lucky" with the current nibread and manage a successful read of these tracks. It all depends on where it started reading the track into memory. As an example, take the following layout in memory where the track was read in: Data1 Data1 .. Track gap/write splice Data2(start of track is actually here) Data2 .. Data2 will be shifted differently from Data1 because of the illegal GCR in the write splice. So even if you rotate the track in memory so that the gap is at the end, you'll wind up with this: Data2(start of track is here) Data2 .. Data1 Data1 Track gap/write splice Unless you know exactly how to bit-shift Data2 to match Data1 (or vice-versa), the track is ruined. These particular V-Max titles have a lot of illegal GCR in this track, not just in the write-splice area, so it exacerbates this problem. Adding the header search ensure that you always start reading where the data is and that the illegal GCR is preferably all at the end of the track and you'll get something like this: Data(start of track is here) Data Data Data .. Track gap/write splice If you look at track 20 in these non-working V-Max images, some of them do have the data all at the beginning, so it's good, but it's shifted. It would probably remaster OK, but won't work in an emulator because V-Max loader specifically looks for $5A $5A, not the shifted $4B $4B which is in the image. On a real C64/disk, if it doesn't find the $5A byte pattern, the disk will just rotate past the bad GCR causing the framing to shift and hopefully it finds it on the next pass. It might take 8 reads to get the right shift, but since the disk rotates 5 times per second, it's not very noticeable to the user. Current emulators will never shift the data, it will always read back the same, so it will never work and you'll see it reading track 20 forever. Other than the illegal GCR reducing your chances of getting a good read, the track 20 loader for this version of V-Max is always the same. You can copy it from a working image and it will boot just fine. BTW, Into the Eagle's nest has a sync-length check as well (I forget which track, I'll have to check my notes when I get home), so you'd need to pass that after you get get a good image of track 20. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 11th, 2011 @ 12:26 ( . ) |
Correction to my last post: Just because the data is showing up at the start of the track in the image does not necessarily indicate a good read. I forgot that Pete's protection-handler routine for V-Max track 20 will look for bit-shifted versions of the $5A header and align the start-of-track based on that. The track could still have been read in a manner that put data on both sides of the illegal GCR and caused a shift half-way through. So even if you bit-shift the whole track in the image after this, the loader's checksum will fail since some of the data was bad. Also, a header-search feature ensures that the data comes in framed exactly how you want it, you wouldn't have to bit-shift an entire track after that just to get it to work in an emulator. On a side note, getting a good read of the V-Max version on Gauntlet: The Deeper Dungeons (Mindscape NTSC) is an exercise in patience right now. There's bad GCR all over the place on almost every track. So the image loads for a while, then stalls on some track load looking for the $64 byte forever. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 11th, 2011 @ 19:29 ( . ) |
Into the Eagle's Nest has the sync check on track 24. It sends the drive off to track 27 if it fails. Header block syncs should be: 2B FF FF FF FF FF Data block syncs should be: AF FF FF FF FF FF Verified working in a G64 on Vice. Haven't verified remastered. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Apr 12th, 2011 @ 02:40 ( . ) |
Ah, I understand now. Thanks for the heads up. |