Re: Hardware musings

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> > I'm mainly suggesting that it it contains a relatively reliable bank of
> > information regarding used tracks on a disk - I'd venture good enough
> > in most cases for image pruning.
>
> But, again, this would only be a space optimization, and introduces
> the possibility of losing needed data.

Not just a space optimisation, it's necessary information for
recreating the image on a real disk. I agree that we needn't throw the
data away as storage is now such that it really doesn't matter much,
but it's still necessary to know which tracks are actually valid.

> Best to capture *everything*, from track 0 to track 39 in quarter-track
> intervals, synced to t0,s0, and with "soft" nibbles marked.  Of course,
> one must capture the length of nibbles, too: 8-, 9-, 10-bit lengths, at
> least.  And the write-protect status.

Sounds right, except that I seriously doubt there'd be anything copy
protected on 40 track disks. No commercial software is going to rely on
there being more than 36 tracks accessible to the the drive, and in
most cases 35 is sufficient.

But, no sense limiting what the format can handle. Just as long as it
doesn't require all tracks to exist to be valid.

> > It'd certainly be easy enough to have an emulator log what track
> > positions were actually used.
>
> Exactly.  Then the only problem is making sure that the program has
> been sufficiently put through its states that it has actually accessed
> all the data that it could potentially access.

An intractable problem - so we just have to 'guess' with regards to
recreating disks. I think it'll work out just fine except for a few
fringe cases, and as long as no data is thrown away, the images can be
adjusted later to include newly discovered active disk regions :-)

> > I have a feeling the disks that are going to be the nastiest are the
> > ones that appear unprotected, right up until they stop and some unusual
> > point. Often it's a case of data on track $23, or a sector epilogue
> > hack. When it's not one of those, it get's really interesting :-)
>
> I agree--the trickiest protections are those that don't appear to
> be there at all until long after the copy was made.

I have originals for one such title to experiment on too - Where in
Time is Carmen Sandiego employed this trick. It allowed the application
to be hard disk installed, but begged for the first disk to be inserted
at various points within the game.
 
Matt