'Nibread on no-sync tracks'
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.


REPLY: [With No Quote] --- [With Quoted Text]

Replies:
--* Nibread on no-sync tracks
4/10/2011 @ 21:01--Pete Rittwage
4/11/2011 @ 10:35----hyper active
4/11/2011 @ 12:00------Lord Crass
4/11/2011 @ 12:26--------Lord Crass
4/11/2011 @ 19:29--------Lord Crass
4/12/2011 @ 02:40--------hyper active

--- 0 Users Online --- 0 Recent Unique Posters

Q32=1653259766 - Threads: / 1653259766