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

Re: Toy Shop

sicklittlemonkey wrote:

On Jan 22, 3:27 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:


Actually, it's pretty easy to get on an Apple.  You read track 0,
sector 0 address mark, then seek to the track you want to read and
start storing nibbles.



It's easy ... most of the time. I recall seeing bit copiers fail to
sync, so the algorithms can be fooled (though since new copy
protection will not be written, we can fix every case engineered to
fool the old algorithms) and also non-boot sides don't need to have a
track 0 etc. ;-)


Of course, any unique signature on any track will do fine as a
track sync (relative position) reference, so missing track 0 is
not much of a problem, even for an automated capture.

When bit copiers failed, it was not because they failed to get
tracks synced properly--unless they were easily fooled into choosing
a non-unique pattern to sync on (a possible countermeasure to an
overly simple copying technology).

We don't have that problem now.  There are no new copy protection
systems for old programs, and so a capture program can be built,
by incremental refinement, that can correctly capture essentially
every disk's contents.

The hard problem is in determining just what bit patterns (or non-
patterns) are actually relevant to the program's correct execution.
That's the part that has the difficulty of the "stopping problem",
and must ultimately rely on human heuristics.

Of course, that's only relevant when a physical disk must be re-created.


Anyway, it's fine if sync protection is removed ... it's just that
then someone has to do it, and it becomes a crack project rather than
a sure-fire imaging system.


True.  But with an accurate disk hardware-simulating emulator,
an accurate capture of synchronized track images should work fine.
We just don't have such an emulator or such captures.


It is possible to recreate everything about a game's behavior--
except perhaps the nibble count seeking sounds ;-)--from a completely
deprotected game.



True of course ... if one has the time to write the loaders,
relocators and miscellaneous routines needed to package a foreign
format into DSK. I don't want to lose the cool animated boot-up of
Borg (which is a pretty crappy game) just because it's too much work
to merge that code into an RWTS boot. What I like about NIB is that
it's often easy to "deprotect" it enough to run in a NIB format if all
data has been captured properly.


Once you drop the need to create a deprotected image of a 5.25" disk
*on* a 5.25" disk, no sacrifices need to be made, but I see your point.

A "super-.nib" format would allow automated captures of essentially any
disk (we have to have a *little* wiggle room ;-) that could be executed
on a properly accurate emulator.  As noted, neither currently exists in
the Apple world, and I'm not sure there's critical mass to create such
a scheme and populate it with the vast library of software.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

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