[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hardware musings
Ed Eastman wrote:
Michael J. Mahon wrote:
Exactly--that's been my position, too. Why are we arguing? ;-)
I thought we were -discussing a new a2 file format that captures
protected disks.
Indeed, we are--but I detected a tone of disagreement! ;-)
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... ;-)
Then one should thoroughly test each image before dumping extraneous
tracks. Again, no one using modern PC storage is going to care that a
file is larger than necessary. Of course having extra data might make
reproducing a real disk a pain. :)
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.
Because of this, I have been saying "why take a chance--just keep all
the data."
"Pruned" images are a space optimization that can seldom be *proven* to
completely replace the un-pruned image.
Even without an Apple II... Wow, that's ambitious. I just don't see
that happening unless someone comes up with a diskette reading
mechanism that does proper CGR.
We were origninally talking about a Disk ][ drive connected to a micro
connected via USB to a PC.
But I agree, my machine of choice for capturing images would be an
Apple II.
Until a viable alternative is found, I'd suggest using a real A2 to
capture the data is the best way.
Agreed.
Sure, but how can an inexperienced user *be certain* that they are not
dealing with that small bunch of disks that require quarter track info?
Better safe than sorry.
If they are that inexperienced, then they definately should capute every
possible track increment.
Agreed.
Put another way, if, this late in the game, we are contemplating a
*new* disk image format, then there had better not be *any* disk that
it can't represent!
I'm still waiting for one protection format this proposed bitstream
format could not represent. (Having read ahead, I don't think the
physically damaged disk could be represented, so there is one!)
Yes, although the missing media at the point of damage would result
in reading "soft" data. Unfortunately, that's not enough to deal with
a program that writes to a track in order to sense the damaged media.
So if there are more of those, it's disappointing. But, after all,
I'm a pragmatist. ;-)
Actually, you can't guarantee rotational uniformity to anywhere near
the length of a bit on a track, so if data was written with a non-
standard-width head, it can't be written with a standard-width one.
Recreation of some original disks in it's original analog format is
impossible without specific special hardware. So recreation becomes
irrelevant so long as the data was captured and the disk image is
usable in an emulator. Maybe later hacking could reproduce a copy
that works, but that's not what you want.
I'm not convinced of that. That assumes that some disks were written
on non-standard disk duplicating machines, which seems unlikely, and
that the effect of such writing is discernable by an Apple drive.
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.
The only case of this I can think of would be writing a disk with
a wider-than-normal head, so that over a space of more than one full
track of movement, in quarter- or half-track increments, a Disk ][
reads identical data. If anyone knows of any such disk, I'd like
to hear about it.
OK, you got me, I can't name one either. But then I never owned many
disks I didn't just capture the program from. My goal was always to get
a program onto a normal diskette, and maybe patch DOS to load it faster.
Likewise. I always viewed protection as a problem to be solved,
not as a relic to be preserved. ;-)
With that exception, I think that an Apple drive, of appropriate
(perhaps non-standard) speed, is capable of writing any disk that
an Apple program is capable of detecting.
Oh, we are in agreement there. Nevermind. :)
;-)
Of course, discovering exactly *what* needs to be written and *how* to
write it (leaving all other relevant info intact) might take some doing.
That is where hacking/ intelligent guessing takes place. Many many
times I can copy every bit of every track from a protected disk and it
won't boot because the track to track alignment is off. The only way to
circumvent this is to make certain that the tracks are synchronized. Not
really an option with the current emulation of 5.25 disk drives, the
nibbles are not delivered timed responces. The current Nib format could
potentially handle synch as long as the data was presynchronized and the
emulator (or device) took into account the timing necessary to move the
arm and to rotate the disk. As long as it is a funciton of the program
or hardware, the Apple II could run at any speed and the data could come
back at any rate...
True.
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.
All things considered, it sounds to me like we're in "violent
agreement". ;-)
What's not to agree on? You asked for a way to store copy protected
disks, I provided one based on my experience with NIB format and what is
lacking.
Well, we seemed to be in disagreement about "pruning" early or late
and it took me a while to see what your "track length" field was.
I think we're on the same page now.
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".
-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."