›<=<=<=<=<=<=<=<=<=<=<=<=<=<=<=<=<=››This  article  deals with various disk›protection  techniques.  Note: this is›not  a  beginners  article. Taken from›the  Unix newsnet. Transferred by Mike›Blenkiron.  Tidied  by  Dean Garraghty›(ENGLAND??),(in the early hours of the›morning!)›-----------------------------------››simonh@hpopd.pwd.hp.com  (Simon  Hunt)›writes:›>"Over  the  last few evenings, I have›been trying to discover how the copy›>protection   works   on  one  of  the›disk-based  games  I  have.  The  game›loads itself›>in several stages, to display a title›screen whilst the rest of the program›>loads..."›>›>HE CONTINUES:›>"Does  anyone  know  how the disk was›manufactured  such  that  reading  the›same›>sector   gave   TWO   different,  but›CONSISTANT, sets of data?›>›>Any ideas?"›››The various protection schemes used on›the   disk   based  Atari  800  series›computers  are  fascinating,  and some›are  very  clever.  Quite  a number of›them  used  custom disk formats, which›an  unmodifed 810/1050 would be unable›to  produce.  The  custom  disk format›allowed: bad sectors; sectors with CRC›errors;   unformatted  tracks;  tracks›with  extra sectors; sectors too long;›sectors  too  short;  and  tracks with›duplicate   sectors   (amongst   other›techniques).››Gosh I am remembering more and more of›these  techniques  all  the time. Some›custom  formats  had  20+  sectors per›track.››This is actually not too difficult, so›long  as  you have low level access to›the   floppy   disk   controller   IC,›something  which  was  impossible with›the  "intellegent"  Atari  drives. You›can  in effect program the floppy disk›controller   (FDC)  to  put  any  data›format  on  any  track  that you wish,›with the right computer system.››Now  each sector on a particular track›is  preceded  by a short header, which›contains  (if  my  memory is correct),›the  track  number, and sector number,›plus  a couple of other things (?) and›a  CRC. The floppy disk controller may›be  able  to  check  the  track number›against the track which it believes it›is  on  (a  flag  will  be  set in the›status  register  if  this  is not the›case).  If a certain sector number has›been  requested,  then as soon as this›sector  number  is  seen in the sector›header, the FDC will start to read the›data   portion.  Now  it  is  not  too›difficult to lay down a track in which›*all*  sectors  are  numbered  1  (for›example) and each have different data.›In  this case the data read will be in›effect  random,  and  depends  on  the›rotational  position  of the disk when›the  read  request was issued. The FDC›will  read  the  first  sector  with a›matching header.››On your disk, I suspect that there are›two   sectors  with  the  same  sector›number,  and  the  rest  may  well  be›normal. They will probably be arranged›to  be directly opposite each other on›the  disk (180 degrees apart). Now the›trick is all to do with timing. Send a›read  command  to the 810/1050. One of›the  2 sectors will be read, which one›is  random. With either no delay, or a›*calculated*  delay  do  another read.›The  disk  will  have  rotated by some›part  of  a  revolution  past  the 1st›duplicate  sector,  so  that  the next›read will catch the 2nd duplicate. The›trick to recreate this yourself is too›code up two reads in assembler back to›back,  and  check  the result. Run the›assembly  code  using  your  debugger,›rather than using the debugger to read›the  sector  twice.  In  the  assembly›code,  there  is a fixed delay between›both   reads.   If  you  are  using  a›debugger,  there  is  a  random  delay›between  subsequent  reads,  hence the›sector read is random.››This  is  very  clever.  Using the XOR›means  that it doesn't matter which of›the  two  sectors  gets read first. If›you  copy  the  disk  using a straight›forward  sector copier when it come to›the  track  in question, you will read›one  of the two duplicate sectors, and›it  will  be  written  onto the single›sector on the destination disk. As you›say  this  new disk will read the same›twice,  and  the  program  would crash›when  executing  the  unmangled  code.›Some  years  ago  when  I has an 8 bit›Atari,   I   bought  a  booklet  which›described  these  techniques,  from an›advertiser  in  Antic (or Analog), and›it  came  with  a  specially formatted›disk to play with, using some of their›supplied  programs  (this  sounds like›Atari Protection techniques, available›from  Gralin  International,  Ed.). It›really is a very interesting subject!››A   UK   software   house   (Red   Rat›Software),    used    an   interesting›technique.  They  burnt  a hole in the›disk  using  a laser (apparently). The›sector  never  read  the same twice. A›copy would always read the same twice.›A  friend  of  mine (who had bought an›original   incidently),   experimented›with  adding  a hole using a pin. I am›not sure of its success.››The well known "Happy Mod" allowed the›Atari  computer,  low  level access to›the  FDC,  and  so could read, analyse›then  format  these  custom formats. I›first  saw  a  similar mod called "the›chip"  for  an 810. Using the supplied›software,  it  was  fascinating to see›the  810  analyse  the disk format and›display  it  on  the screen. Duplicate›sectors were very easy to spot.›I believe that one of the commands the›810 supported was to return the status›from  the  FDC  after a read or write.›The  value  passed  back  came in part›(or  all?) from the FDC (an 1771 chip)›status  register.  The  register  knew›about CRC errors, data overflow, etc ,›which  is  why  some of the techniques›mentioned  above  were popular, as the›810   could   detect  these  specially›created    disk    faults.    A   disk›formatted/copied  on  the 810 would be›fault  free. When the 1050 drive first›came  out, a number of software titles›wouldn't   load,   as   the   software›believed itself to be copied, although›they  were originals. This was because›the  1050  used  a different and newer›FDC   (a   Western   Digital  2797  or›similar),   one  which  could  support›double   density.   The   1050  status›command  returned  similar information›to the 810 including a copy of the FDC›status   register.   As   the   status›registers  of  the  1771  and 2797 are›different  with  different meanings to›each  bit,  of  course  software which›relied  on  the  1771  status register›bits  been set according to these disk›faults,  got  confused, as the new FDC›returned   slightly  different  status›results.››On  a  different note, Atari used both›the  2797  and 2793(?) FDC's which are›virtually  identical  in  the  1050. I›bought  a  very  early Happy mod (from›B&C  Computervisions? in Santa Clara),›which  didn't  work  in my 1050 drive,›which  I  had brough over from the UK.›This  was  due  to  the  switch in FDC›(97->93  or  vica versa) used by Atari›in  the  1050.  The original Happy ROM›code,  which  replaced  the Atari 1050›ROM, was written with a particular FDC›in   mind.   I   discovered   this  by›disassembling  the  Happy ROM code. It›was  quite a lot of hassle to get them›to fix it.››Ah, those were the days.....››Article  by:  Gary  Morton. (REPRINTED›WITH THANKS!!)›› =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=›