BLuRry wrote:
> On Jan 25, 6:34 pm, sicklittlemonkey  wrote:
>> On Jan 26, 4:57 am, "Michael J. Mahon"
 wrote:
>>
>>> Just for the record, the only analysis that can be guaranteed to
>>> work is to faithfully (cycle-accurately) simulate the execution of
>>> the disk *from boot* on an Apple II.  This is equivalent to a fully
>>> automatic "boot trace" of the disk.
>> An emulator can easily record which tracks are and aren't used during
>> a complete play-through. And yes, I know - how can we be sure it was
>> complete? ;-) Well, if tracks are discarded, and then the emulator
>> alerts the user some day that the software is trying to access a track
>> not present, it must be recovered from the original full disk capture.
> 
> And on that note, if you intercept RWTS you can tell what track/sector
> is being read and where it is being stored in memory.  I've learned
> some interesting things about some dos 3.3-based disks lately.... :-)

Almost all of the difficult protections operate well below the
track/sector or RWTS level.

I would love to see an automatic boot tracer, but I'm not
holding my breath.

Since these disks cannot currently be imaged, the only way
to get the information is to run it on a real Apple II--there
a program can watch the data register shift in nibbles and reset
the state machine in mid-nibble!  And they aren't even really
nibbles (of course anything read by a Disk ][ Controller *looks*
like a nibble)!

And you'd also need an external analyzer to see exactly what
the timing is.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II 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."
--- SBBSecho 2.12-Win32