Re: "Fat tracks" are not really fat tracks

Re: "Fat tracks" are not really fat tracks

From: Pete Rittwage <peter_at_rittwage.com>
Date: Sun, 22 Mar 2009 11:52:52 -0500
Message-ID: <49C66CE4.9030200@rittwage.com>
Wolfgang Moser wrote:
> Hello Pete,
> 
> Pete Rittwage schrieb:
>> 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.
> 
> can you poove that observation with my cbmrpm41 tool (currently 
> available through OpenCBM CVS only)? Job mode 2 measures out relative 
> track synchronization regarding the the relation of two "neighbored" 
> sector numbers between the two tracks. You can advise cbmrpm41 which 
> sector to choose and also limit the measurement to these two tracks:
> 
>     cbmrpm41 -j 2 -b 34 -e 35 -c 2  8

Hi Womo,

That tool doesn't seem to work because track 35 has CBM errors (it is a 
copy of track 34 so it has the wrong sector ID's for track 35).


-- 
-
Pete Rittwage
http://rittwage.com


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

Archive generated by hypermail 2.2.0.