Re: EDD Plus Project

["Charlie" <charlieDOTd@verEYEzon.net>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
p5idnfQ99KuUgxDanZ2dnUVZ_u6rnZ2d@comcast.com">news:p5idnfQ99KuUgxDanZ2dnUVZ_u6rnZ2d@comcast.com...
> Charlie wrote:
>> "Michael J. Mahon" <mjmahon@aol.com> wrote in message 
>> IYidnSm5NJ9NmRDanZ2dnUVZ_jSdnZ2d@comcast.com">news:IYidnSm5NJ9NmRDanZ2dnUVZ_jSdnZ2d@comcast.com...
>>
>>>Charlie wrote:
>>>
>>>>"Bryan Parkoff" <nospam@nospam.com> wrote in message
>>>
>>>>>Why do you desire to capture floppy disk into image?
>>>>
>>>>
>>>>I have about 1000 floppies (most not copy protected) and disk2fdi is by 
>>>>far the fastest way to make archive images of them (.do, etc.).  FDI 
>>>>need be used only for copy protected disks since the files are large and 
>>>>the process slow.
>>>
>>>Of course, using a PC drive to capture images requires a special
>>>hardware hack to capture the "back" side of any double-sided disk.
>>
>>
>> Yes, I should have mentioned that.  I just copy the back sides to the 
>> front of another disk before using disk2fdi.
>
> So, there's a snag for copy-protected back sides...

Yep, a pretty big one :-(

>>>Also, can a PC floppy deal with half- and quarter-tracks?
>>
>>
>> Good question and I can't answer it.  Disk2fdi allows 6 different track 
>> densities 48, 67, 96, 100, 135 & 192 tracks per inch but it also allows 
>> the use of several different floppy drives.
>
> Since Apple II 5.25" disks are 48tpi, using 96 or 192 would get half-
> or quarter-tracks.  Good news.

Well, maybe.  Disk2fdi allows those settings but remember it allows a 
variety of floppy drives.  I'm not sure whether 5.25 inch PC floppy drives 
can step that number or not.

>
>> Disk2fdi also has a "double-step" command switch when used with a 
>> high-density 5.25 in drive.  This seems to imply that a high-density 
>> drive can deal with half-tracks at least but I may be misunderstanding.
>>
>>
>>
>>>There's the software issue of dealing with unrecorded areas that
>>>cannot be read repeatably.  And, of course, for a protected disk,
>>>there is no simple way to determine whether a sector/track has been
>>>read correctly except by re-reading--and this requires that "soft"
>>>(unrecorded) bits be tolerated at the risk of accepting errors.
>>>
>>>There doesn't seem to be any way to escape the need for testing
>>>to demonstrate that the correct information was captured.  ;-(
>>>
>>
>>
>> Unfortunately, I have to agree :-(
>>
>>
>>>>>I wonder why FDI does not work or can't read copy-protected image from 
>>>>>floppy disk.
>>>>
>>>>
>>>>Disk2fdi does work on (read) most (maybe all) copy protected Apple ][ 
>>>>disks. At least it should but as of now there is no way to check the 
>>>>resulting images.
>>>>
>>>>
>>>>>  If it is true that you expect to capture floppy disk into image 100% 
>>>>> accurately, it may not be possible to emulate FDI format into Apple II 
>>>>> Emulator successfully.
>>>>
>>>>
>>>>I don't see why not.  But again I'm no expert on emulating a floppy 
>>>>drive. There is an Amiga (I think) emulator that supports FDI and 
>>>>Ciderpress can read FDIs of DOS/ProDOS disks.
>>>>
>>>>
>>>>
>>>>>  I have been reviewing over threads.  Nobody is interested to write 
>>>>> FDI program inside Apple II Emulator.
>>>>
>>>>
>>>>True :-(
>>>>
>>>>
>>>>
>>>>>  I thought that the software should be able to capture Apple II floppy 
>>>>> diks into image using EDD+ card.  Does it?
>>>>
>>>>
>>>>I don't know.  I never owned an EDD+ card.
>>>
>>>It allows faithful reading of the bit stream, subject to the standard
>>>limitation on noise being read as data in regions with more than a few
>>>consecutive zeroes.
>>>
>>>It still requires knowing what needs to be captured to satisfy any given
>>>protection scheme, which complicates knowing whether or not you have
>>>actually captured it until the image has been tested.
>>
>>
>> Can it be used to read everything on the disk?  By that I mean every 
>> quarter track.  Obviously, that couldn't be used to create another floppy 
>> but could be stored in an image that could then be read by some "yet to 
>> be written" emulator.
>
> Yes, if all the relevant transitions are imaged, the vast majority
> of copy-protected disks should be able to be captured.
>
> The process of testing can then be used to verify that the useful data
> has actually been preserved.  Further analysis could then be used to
> winnow the accidental "data" from an image if it were desired to reduce
> its size by a factor of 4 or so.
>
>>>You may recall that all copy programs, including EDD 4+, required the
>>>user to copy some programs multiple times until a working copy was
>>>achieved...
>>
>>
>> Yes, I did run into that a few times :-)
>
> For some disks, it took lots of tries.  ;-)
>
> Copy-protection on the Apple II was an evolutionary process involving
> constant competition between protectors, deprotectors, and copiers.
> The result was the adoption of methods specifically designed to
> frustrate attempts at deprotection and copying, even using some
> rather difficult and/or sophisticated methods.
>
> It should not be surprising that some "species" of protection developed
> that were quite robust in protecting against copying.
>
> Of course, boot tracing always left the door open to clever deprotectors
> with lots of time and motivation, for which the usual countermeasure
> was extensive obfuscation.  ;-)

Yes, I did some boot tracing back in the dim dark past.  As you've mentioned 
before I too usually found it to be more fun than the games I was trying to 
crack.

> Another approach was the insertion of "original disk" checks *late* in
> game play, so that considerable effort was required to get to the check,
> making it difficult to verify that a good copy or deprotection had been
> achieved.

I sometimes wondered if I had fully cracked a game because I usually lost 
interest in playing it before I'd gotten very far.  I could just imagine 
getting to the 33rd level of some "shoot-em-up" game only to have a 
"gotcha!!!" come up on the screen as the program erased the disk :-(

Charlie