home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.cbm
- Path: sparky!uunet!UB.com!pacbell.com!decwrl!csus.edu!netcom.com!fuzzy
- From: fuzzy@netcom.com (Fuzzy Fox)
- Subject: Re: V-MAX: Copy protection with disk drive mystery
- Message-ID: <1993Jan27.061342.882@netcom.com>
- Organization: Foxes 'R' Us - Seven locations to serve you
- References: <1k18tiINNln9@fstgds15.tu-graz.ac.at>
- Date: Wed, 27 Jan 1993 06:13:42 GMT
- Lines: 24
-
- schuetz@fm11ap01.tu-graz.ac.at (Alexander Schuetz) writes:
-
- >Explanation: If the read routine doesnt find the header bytes, the speed
- >bit and the led is being toggled; a wait loop of 20 ms appears; and the
- >led and speed bit is being toggled again (back to normal speed 00) ; and
- >then; a jump to the header-read routine appears. And then, after some
- >seconds, the mystery happens, the header-read routine finds the headerbytes
- >without being synchronized by a sync mark or similar means.
-
- >My question is: * How the HELL can some speedtoggling (from speed 0 to 2
- >waiting 20 ms and back to speed 0) synchronize the disk drive???????
-
- By changing the bit-receive clock rate, a pattern of data which does not
- normally appear to be a sync mark might appear to be one if caught at
- the proper time. This really sounds like an attempt to simply "kick"
- the clock on the read head until it happens to sync onto the data at the
- proper time. Probably only a couple of disk revolutions would be needed
- to find the data, which is less than a second access time.
-
- --
- #ifdef TRUE | Fuzzy Fox fuzzy@netcom.com
- #define TRUE 0 | a.k.a. David DeSimone an207@cleveland.freenet.edu
- #define FALSE 1 |
- #endif | "911 Emergency Rescue Service - Can you hold, please?"
-