[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hardware musings
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. :)
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?
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.
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.)
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.
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.
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.
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?)
The 'mark' to synch by would need to be dynamic and change track to
track. 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.
Thankx,
Ed