22 Dec
2005
22 Dec
'05
3:41 p.m.
On 12/22/2005 at 10:24 PM ard at p850ug1.demon.co.uk wrote:
But to read the IDs, it appears you _have_ to submit
the next command as
soon as you get the results from the current one, or risk missing a
sector. And as far as I can see there's no way to be sure of doing that
on a multitasking system.
Okay, I'll drop another hint (geez, you guys really need to read the data
sheets). Let's assume that the disk contains something other than format
pattern in all sectors; i.e., assume that the contents sector-to-sector
differ. If you're not sure about the latter bit, you could always read
the sectors up and save them, write your own pattern, do your ordering
determination, then write the original data back.
Read a bunch of ID's repeatedly so that you're relatively sure that you've
got them all. Based on the number of different sector ID's you have,
figure out how many sectors are on the track.
Now, issue a Read Track for the appropriate sector count--stash the data
away for a bit.
Now, read each sector individually and hang onto the data.
Using a good checksum or hash, compute a sum for each sector in each of the
two buffers. Use the Read Track buffer to tell you what the order of
sectors is on the track.
Here's the thing about Read Track--it starts at the index and reads sectors
without regard to what's in the IDAMs--so you get the sector data in the
order that it occurs on the track--and so you can figure out how things are
ordered.
It's not perfect, but it will work pretty well.
Cheers,
Chuck