[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hardware musings
Ed Eastman wrote:
Michael J. Mahon wrote:
I'd be worried about discarding information from the image file that
later (maybe *much* later) turned out to be needed. (Say, after you
reach the treasure chest and drop the bronze key... ;-)
True, look at Silent Service or was it PHS Pegasus... Whatever. I have
a supposedly cracked copy that works on a IIc, but on an enhanced IIe,
it turns all enemies into destroyers part way through. (So I'm told.)
The problem is that no amount of testing can be proven sufficient
> Until a program has been driven into every nook an cranny of its
> states, you cannot be sure that it isn't going to do some protection
> check, unless you have a priori knowledge of that protection scheme.
>
> There have been several cases lately in which a "deprotected" game
> has failed well into its scenario--because the deprotector overlooked
> some state.
>
Actually if you can play the game all the way through to the finally
several times, then the game is most likely OK.
You have to remember that most game that were produced were not designed
with protection in mind and it had to be added via disk format
modification or adding a subroutine to check a disk signature or track
synch. Only the truly devious went back and modified their code to
inhibit a game.
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.
Because of this, I have been saying "why take a chance--just keep all
the data."
Agreed, if the bitstream image works then great! (Seen next responce.)
"Pruned" images are a space optimization that can seldom be *proven* to
completely replace the un-pruned image.
But a pruned image would be more likely to succeed in recreating a real
floppy because the head on an A2 drive is wider than a normal (half)
track. That is why the A2 used every other track to store data. Double
density disks are 96 TPI, the apple II uses half that due to physical
propertied of the head.
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.
I'm a pragmatist. ;-)
Me too!
Then we should come out fine. ;-)
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.)
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.
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?
It would be very interesting to see a "breakdown" of the frequency of
various types of protection, and their combinations--and then plot
the data versus the date the disk shipped, since the whole process
was evolutionary.
I guess I'd like to see any such format have an extensible part that
could contain additional information about the protection scheme and
perhaps some interpretive code to guide a disk "writer".
Sounds like you'd want something like the Copy II+ parameter file in the
disk capture/ write utility. Maybe an accompanying text file if there
is known formatting.
Exactly. There would be benefits to both a part that is intended to
be used by the writer utility and an informal part that is additional
information for the human--like "must be write-protected to work".
I finally found one disk I was never able to back up or crack, "Clue:
Master Detective". This bitstream format would be ideal to test this
game with as it fails quite early by not allowing a necessary part of
the game.
Excellent!
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.
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.
-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."