Re: "Fat tracks" are not really fat tracks

Re: "Fat tracks" are not really fat tracks

From: Pete Rittwage <>
Date: Sun, 22 Mar 2009 20:32:02 -0500
Message-ID: <>
Pete Rittwage wrote:
> Hi guys,
> With the help of "TeaRex" on my forum, I added a simple way to 
> read/write disk images using the index hole sensor built into the 1571. 
>  Through this addition, a revelation occurred.
> We had always assumed (since the 80's) that the Electronic Arts' "fat 
> tracks" protection had 2 tracks (34 and 35) perfectly aligned.  I added 
> the index hole code and wrote out the disk perfectly aligned to track 0 
> and thought it was beaten.  :)
> Well, it turns out this assumption is *not* true.  When reading against 
> the index hole, track 35 is actually skewed back 1/4 track or so on all 
> the original disks.  If I write it back out skewed in this way, it 
> boots.  These were never "FAT" tracks at all, just a specific track skew 
> between two identical copies of a track.
> XEMAG 2.0 (the Activision variety of this protection) is skewed about 
> 1/2 track between 35 and 36 (and some amount between 34 and 35 also that 
> doesn't appear to be checked).
> I noticed years back that this protection boots if the drive motor is 
> slowed down to 298.5 or lower (within reason) no matter what the skew. I 
> guess something about how their timing check is setup allows this to pass.

I had an error in my skew calculations, it seems.  They are fat tracks 
after all.  Working too late...  :)

Disregard my previous findings.  However, we can now measure track skew 
pretty accurately.  EA protection can be written back, XEMAG cannot.  On 
the original disks, track 34.5 is readable.  Since we cannot write with 
that level of accuracy, even with IHS, the middle track is trash.   EA 
will skip a little and pass it, XEMAG won't.

Pete Rittwage

       Message was sent through the cbm-hackers mailing list
Received on 2009-03-23 02:59:33

Archive generated by hypermail 2.2.0.