Re: EDD Plus Project

["Michael J. Mahon" <mjmahon@aol.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...

> > 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.

> 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.  ;-)

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.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."