[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EDD + CARD
- Subject: Re: EDD + CARD
- From: mjmahon@aol.com (Michael J. Mahon)
- Date: 31 Jul 2002 23:59:44 GMT
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <ai9d97$jci$1@venus.itns.co.za>
- Xref: archiver1.google.com comp.sys.apple2:21752
Stephen Shaw suggested:
>On Fri, 26 Jul 2002 17:18:42 GMT, Dick Sisco wrote:
>
>> On Fri, 26 Jul 2002 15:33:17 -0000, russotto@grace.speakeasy.net
>> (Matthew Russotto) wrote:
>>
>>>In article <md61ku4rts0okshsusisv15ifgeeuv9g2r@4ax.com>,
>>>Dick Sisco <dsisco11111@mchsi.com> wrote:
>>>>
>>>>But that is exactly why it works as a protection scheme. After about
>>>>8-10 0 bits the standard Apple (or IBM) controller begins returning
>>>>random bits.
>>>
>>>Why does it do that? A 0-bit is a lack of transition on the disk; while
>>>the controller may not be able to figure out how many non-transitions
>>>occurred, I don't see why it should start returning 1s.
>>
>> As it was explained to me, the circuitry in the disk controller turns
>> up its aplification(?) if it doesn't see transitions. It eventually
>> senses a transition when there really isn't one. I can't swear that
>> that's an accurate description, but that was the way the instructor at
>> a disk duplicaton seminar explained it to me. And it did seem to
>> work.
>
>Ok. if the above is the case then it is quite easy to back door into the data
>stream with an RS232 converter to a PC/Mac/Linux box and read the binary data,
>sort out what copy protection is being used and nullify it.
With the bit stream at 250,000 bits per second, that seems unlikely.
-michael
Check out 8-bit Apple sound that will amaze you on my
Home page: http://members.aol.com/MJMahon/