[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hardware musings

Ed Eastman wrote:

Michael J. Mahon wrote:


All true.  But the key words are "proven" and "most likely".  If a
format can hold *everything* that a protection scheme could wish for,
then dropping anything that *might possibly* be needed is a mistake.
Wow, again with the perfection thing. The Disk II surface is analog. IT is not possible to capture every scenario that "might possibly" occur. One disk that comes to mind is the allignment disk. iT has analog tracks of variying strength magnetic fields. Luckily it is not program meant to be useful. So I guess you are again asking for the impossible. Too bad, we were sooo close. :) 

We still are.

I concede that we cannot capture two kinds of disks, and am interested
in how many of them were produced--I suspect very few.  (BTW, the
alignment disk is a special case, since it cannot be written on *any*
compluter.  It is the only truly analog disk that I know of.)

But "pruning" information from an image on what can only amount to
a "good hunch" is probably a mistake.  Most people will take only
a minute or two per disk to image it--they won't be doing all the
"quality control" work required for even "reasonable assurance" that
enough is known to re-create the physical disk.

Allowing possibly prematurely "pruned" images to escape into the wild
is a sure way of debasing the value of an image format that is capable
of representing *almost* all protected Apple II disks.

My only argument, therefore, is *not* to prune images for distribution,
unless they are clearly marked as a "derived" image that *may* not
capture all the info that is needed to recreate the complete disk
(assuming that it isn't one of the tiny few that can never be recreated
on an Apple II).

The only possible value of pruning is reducing the size of the image,
which I think we both agree is unnecessary.


I have never suggested that a disk could be written by writing all
the quarter-tracks!  Clearly, that won't work.

Instead, to be written to a physical disk, the image must be "decorated"
with additional information (I've proposed a description of the writing
process that could be treated as interpretive code by the "writer"
program) that would describe how to write a physical disk using a small
subset of all the data in the image--but a subset that is not fully
understood until someone takes the trouble to discover it.
A small subset? If all that was needed was a subset of the bitstream data, then ultimately that is the only data we would need to keep. (I am thinking of several early single load games that had special formatting for a fast load and only had a limited number of tracks formatted.) Or am I missing something on the subject of pruning? 

I know exactly what you mean, Ed--I'm just pointing out that *you* know
that, but it would not be a good assumption that everyone who will be
using the capture utility will know that.

And, when you get right down to it, unless the code has been completely
analyzed, it's hard to be sure that the disk isn't accessed in some
unusual situation.  (Though I realize that years of experience with
"single load" games suggests that they are pretty sure bets.  ;-)

You have reminded me, though, of a situation which I'll bet has
occurred more than once..   I had a protected disk (SIDEWAYS, IIRC)
that, after normalization, turned out to have deleted files on it.
In fact, one of the deleted files was the (licensed) source code to
the protection scheme!

If I had copied this disk preserving only what was needed to run the
program, I would have eliminated a very interesting palimpsest!

It would be fun to do some forensics on other original disk images to
find similar residues of the development effort.  ;-)


Then we should come out fine.  ;-)



I think we do.
But I have read of a protection scheme that moves the arm back an forth across this multi track wide data stream and is not allowed to be out of synch for one byte in the entire track. I therefore content that the 'wide track' could not be replicated by a normal drive. That sort of bit for bit alignment for a real apple II drive is not probable precisely because the rotational speed (often) varies from one rotation to another. 



Yes, and that's true of virtually *all* disk drives, which is why
it could only be written with a wide head.  It's pretty astonishing
that such a device would be made, since it would either considerably
reduce the capacity of the disk, or require duplication in two passes.




People are clever!



But they are also thrifty, and putting disks through two different
duplication machines to get a shippable disk is expensive relative
to the alternative.

Or, perhaps, they needed so little data on the disk that they wrote
the whole disk with a smaller number of wide tracks.  (That seems
like a reasonable strategy.)
If I remember correctly it was an EA thing. There was 'standard' code to read the tracks as the head traversed between the two tracks to make certain they were identical at all times. This was a scheme used on may disks and those tracks were never used by the game itself. But it was usually called at least twice, once on boot, another time after the game was in play, so you had to make sure and disable all copies of the code. Luckily they used almost identical code in each instance and it was not hidden on the disk. 

Interesting.  It actually sounds like it meets the "two-pass" criterion
I mentioned, since they probably purchased the disks with the wide track
pre-written, and then just duplicated their programs "around" the wide
track(s).


It would be interesting to know how many "wide-track" disks were
made for the Apple II, since they could not be re-created as a
physical disk with an conventional drive.
But in a duplication house, specialized equipment would be handy. Heck, for all I know they had a specialized drive with dead on rotation and used a standard head to write the tracks. (See alignment disk above.) 

Duplication houses were production operations, and any deviation from
a simple flow would have been disruptive and expensive.  I also doubt
that there was any high-volume equipment made that could do wide tracks.

I'm betting that these wide tracks were written by a copy protection
firm that sold them--and their scheme--to software and duplication
firms.  This would be exactly analogous to the way that the laser-burned
disks were marketed to software houses.

The protection outfit got their income from a markup on the specially
prepared disks.


So we've now identified two different schemes that would prevent
physical disk re-creation (but not "running" from an image):
precise physical damage to the media, and writing wide tracks.

Are there any others?  And how many total disks are we talking
about with these unusual protections?
I dunno, but again perfect reproduction may not be possible, but preservation of the code certainly can be. 

Agreed.  But it would still be quite interesting to know how many
"original" disks are not reproducible on an Apple II...
Anyone want to make a utility to read the track in a few times? Maybe someone with a IIgs, it has enough RAM to do a bitstream image in memory all at once. OF course a II could if you had a slinky with a meg on it. The IIgs could also potentially make a better timing program as it is 2.6 times faster than a standard IIe, but that may take special hardware to bypass the cluch mechanisms in the IIgs that ensure 'normal' speed for Diskette access. 


Right.  I think that a //e (or even a II) will work fine, allowing
five copies of any track to be read into memory for analysis.

Stephen Thomas' code is at least a good starting point--it's very small,
though exquisitely timed.  ;-)  It does make some (usually warranted)
assumptions about self-sync nibbles, but he privately discussed a method
for avoiding those assumptions at the cost of more memory...
Anyone want to make a hack to the disk II to put an index hole reader circuit in to alleviate the track synch capture issue? Maybe add it to the EDD board and modify the program a bit? Again, on a IIgs this has potential to becomes a wee bit more powerful. 


The only thing that would avoid is the "speed drift" that occurs during
the seek from the timiing reference point, which, with cleverness, can
be made very small.
Just remember that the seek time varies. To get the head in motion from a stop requires a specific amount of time. Then each phase varies a bit. I bet someone out there has the timing for seeks. From start to stop on any given seek duration, form .5 track to all the way out. 

It varies in a cycle-precise way, since it is completely controlled
by software.  You can make it as simple or as complicated as you like.

Adjacent track seeks would *always* be simple, since acc/dec tables
are irrelevant.
One more thought keeps running through my brain. The head apparently slight,y less than 3/4 of a track wide. And since we can stop on every 1/2 track reliably, why would we need to capture every 1/4 track? If the disk routine required a stop on a quarter track, just stop on the *'previous' half track increment. It would give the same value and half the size of the necessary largest image and also simplify the disk routine needed for track seeking. 

*previous being depending on which direction it was headed.


Because we don't know _a priori_ where the boundaries *between* recorded
tracks are, and you can't read the information written unless you are
aligned with the "writing" alignment within a quarter track.  If the
head crosses a boundary during any part of a rotation, then the data
read will not be what was written.

The issue is not how many *tracks* were written on a disk, but how
many possible *alignments*.


For example, each track can be timed from a unique string on the
adjacent "good" track, so that the largest seek before resuming reading
would be about one track.  This is a small fraction of a rotation, so
the speed error would be quite low.




Tests could be done to see if the cumulative error is significant, but
I would expect it to be less than the error resulting from speed error
during a full-stroke seek.

This approach also offers the possibility of capturing a full-disk,
synchronized image in a single pass of the disk, without requiring
repeated seeks to a sync track.
In theory the bit copy programs in synch mode have the synch thing down. They have taken into account the time it takes to seek form a given point and when writing uses the exact same timing to start the write. So long as the read and write are ont eh same mechanism, the timing should be close to exact. (Why reinvent the wheel?) 

No, they are only approximate, because in seeking from track 0 to the
target track, which may be a full-stroke seek, the disk continues to
turn accumulate angle uncertainty because of speed irregularities.

The shorter the time between reading the "mark" data and reading or
writing the "target" data, the more precisely the target data is
located relative to the mark.

All the copy programs I know of used track 0 (presumeably sector 0)
as the "mark", and therefore took some long seeks to reach higher
target tracks.  It is possible to do much better than this.

In fact, when originally writing a synchronized disk, all the seeks
were likely single (or fractional) track seeks, allowing for very
good angular precision.  No copy program that I know of uses a sync
algorithm that is capable of this precision.

I'm talking about a fundamentally better way to do track sync.
The 'mark' to synch by would need to be dynamic and change track to track. 

Exactly--and this is not hard.
And what about a disk that deliberately has a largely unformatted track.? If we can get the index hole pulsed, it would be a more reliable marker. 

If there's really nothing written on it, then sync is moot.  And if
there is something written on it, then that's the mark!

The index hole thing is a red herring and a needless complication.

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

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