[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hardware musings
Ed Eastman wrote:
Michael J. Mahon wrote:
Ed Eastman wrote:
And this "evaluation" is a human or human-driven process, since it is
indeterminate when the program will actually do the verification.
(Sometimes it's well after boot time.)
Yes, this evaluation is done at the time the image is made. Right now
there is only a theoretical storage format to represent a protected disk
in it's entirety. By now _ALL_ apple II 5.25 floppy disk that have
protection have been produced and most of them have been hacked and
their general operation is understood even if not normalized and
deprotected fully. (Eg: I was never able to crack Silent service nor
normalize Prince of Persia.) But I can copy them.
But I thought part of the problem was making it possible for a user
with protected disks, but inexperienced in deprotection, to be able
to image their disks with some assurance that everything needed to be
able to run them under emulation, or duplicate them, has been captured.
If all that's needed is an "expert" tool, then there are many more
tradeoffs to be made and many places for human judgement to be
applied (each of which is a potential trap for the inexperienced).
No, since a file transfer is either good or not (much more likely to be
good), it is quite sufficient to simply checksum the whole thing.
True enough, but...
The only rational recovery in case of a bad transfer is to re-transfer
the file, which will almost certainly fix it unless it's bad at the
source.
That would be why. The checksum could tell you if the source itself is
bad.
Which it would also do if there were only one file-level checksum.
But you can tell a spiral disk from the sound... It is SOOO obvious.
And that is human observation, or one made *after* the image is created
by observing program behavior.
Before, I can lift the lid off my A2 drive and watch a normal and a
protected disk operate. (Don't try this with a CD!) I can even mark
the head position for different track locations. (I recall some
stickers one could buy for just such a thing.) Of course in today's
emulators you could certainly track the movements via software too.
Of course (I even had a drive with track numbers marked on the head
cam), but these are expert techniques, dependent on having a drive
connected to a working Apple II.
I'd like a method that works for *everyone*, with or without an
Apple II (if they use the OP's notion of a microcontroller-controlled
drive connected via USB for the capture).
There's all the time in the world to understand the protection
mechanism *after* the disk is captured, and that later info can
be used to re-create the protected disk, if desired.
If an expert wants to use the real disk and a real Apple II to get
to the bottom of the protection scheme, great--but that is neither
the most common case nor should it be necessary.
No worries unless it is a spiral disk. Those images promise to be up
to 512k in size! (39x4 +1) x 6.25k
That's exactly what I'm thinking--and there's no foolproof way to
avoid saving that unless the image creator already (correctly)
understands the protection.
But ONLY the spiral images would contain that much information. Most
disk images will not.
So, you're willing to let a little matter of 4x storage space stand
in the way of capturing images of disks that you may never see?
Let's see--10,000 protected disks, at about a megabyte apiece for a
completely uncompressed (unlikely) representation of *everything*,
adds up to 10GB--two DVDs or a tiny sliver of a recent hard disk!
Why should anyone worry about a 1MB image size today?
The .pdf of the documentation and game materials may be bigger! ;-)
But assuming the disk has ever been deprotected or even monitored
while booting, the protection routine will be known and where it is
at. Most protection schemes rely on data inserted between normal
sectors that does not get read by normal copy programs. The bit
steam format catches all of that.
Again, I think we'd all be better served by a format that didn't require
*any* knowledge of protection schemes (lest it be absent or incorrect).
Why? You would never need to save every possible bit location on a
diskette. The 1/4 tracking is almost irrelevant, each readable unique
track must be .75 tracks away form the next. Large gaps that would not
need be read. But of course this proposed format means we could.
For that matter if one were to read the whole thing, every .25 track
through trk 40, one could always purge unneeded tracks later.
My point exactly.
"Premature optimization is the root of all evil." ;-)
And in
the case of wide head tracks (where the signal is constant over several
tracks) you could simply copy track data form one to another to ensure
synchronization.
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.
New formats anyone??
A person could even use this format to make distinctive tracks every
quarter track and have a HD floppy disk when done!
Interfacing an HD drive with its thinner head is a fun idea--though
there are rotational speed differences, too. It would be easiest to
"gut" the drive electronics, as Woz did with the SA400 drive.
Retrofitting an HD head on an Apple drive is an interesting idea, but
more for the mechanically inventive. ;-)
-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."