Re: EDD Plus Project

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

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
n7WdncbzlbRjRxbanZ2dnUVZ_jSdnZ2d@comcast.com">news:n7WdncbzlbRjRxbanZ2dnUVZ_jSdnZ2d@comcast.com...
> Henry S. Courbis wrote:
>> Hello Michael.
>>
>>
>>>Henry, there have been a couple of *very* long threads on the topic of
>>>1) capturing all the relevant data on an Apple II disk and 2) re-writing
>>>that data on another Apple II disk.
>>
>>
>> So I've seen over the years.
>>
>>
>>
>>>The problems become much more difficult as you attempt to handle almost
>>>all protected disks and/or later protected disks.
>>
>>
>> I agree.  Not having any experiance with the EDD software I was hoping 
>> someone to help point out any pitfalls or areas that would need to be 
>> addressed.  Even if it only worked with 60% of the software out there to 
>> start with, then releasing the source code and allowing people to 
>> experiment with new ways to possible close in the gap.  Maybe in the end 
>> it will be come more like Copy II+ where you just select the title and it 
>> eneters the pererameters for you.  I don't know exactly where this is 
>> going just yet.
>
> That only happens because *someone* determined which parameters worked
> for (at least some version of) that software title.
>
> That is, of course, a natural "open source" kind of growing body of
> data, but once someone has reverse-engineered the protection, then
> that title can be archived with protection intact.
>
> How many times does each title need to be separately archived?
>
> Isn't sharing the archives (and the data) a more inclusive goal than
> just sharing the parameters for creating the archive?
>
> If I know that someone has created an archive of the ABCD game disk that
> I have, then I no longer need to worry about archiving it myself.
>
> The archiving project should be organized to avoid duplicated effort
> in order to achieve better coverage.
>
>>>The upshot is that a much larger, more "capable" image format (perhaps
>>>.FDI) is needed to capture the required information.
>>
>>
>> I agree.  .2IMG really needs to be looked at.  I have a feeling this will 
>> be the direction we'll be going rather then trying to create another 
>> format or use .NIB.
>
> I wasn't aware that .2mg was even remotely capable of representing the
> kinds of data we were discussing.
>

It isn't capable of representing data in the way we've been discussing.  It 
is extensible so that it could contain a new format but that really doesn't 
solve anything.

Charlie