Re: Direct access to disk drive in DOS 3.3?

[mjmahon@aol.com (Michael J. Mahon)]

Jayson Smith wrote:

>Actually just a while after I posted the original message I managed to crack
>the program in question.  There's one line of a certain Applesoft program on
>the disk which calls a machine language subroutine to check the disk to make
>sure it's legit.  I just inserted a "poke 47426,24" before that line and a
>"poke 47426,56" after it.  With the poke patch in place, any disk, protected
>or not, will pass the protection check.  I think this has something to do
>with turning off RWTS's checksum checks or something.  Thus we want it
>turned back on for normal operation once the protection check is over with,
>so we poke back in the original value.

This patch, often given in hex as: B942:18
has the effect of disabling most of RWTS's error checking,
allowing bad sectors to be read for copying or data recovery.

There must also be an ONERR GOTO construct in the Applesoft
program, since for the copy protection to be effective, the program
must _require_ the error to be there for the copy to be valid.

Either that, or some other place in the code is verifying the
existence of the error when it attempts to read that sector.

>On a somewhat related subject, digging around on Google I found a way to
>change the way RWTS deals with I/O errors.  The traditional method is to
>read the sector, recalibrate the head which causes a really long and
>annoying bzzzzzzzzz, read again, then if it's still an error, give up and
>report it as such.  The patch described below makes it just keep reading the
>sector, over and over again, until it gets a good read.  It doesn't make
>that annoying buzzing noise!

One slight correction--RWTS makes quite a few tries before it
resorts to recalibration and more retries.

The thinking is that if you are reading a marginal sector, just
re-reading it until there is no checksum error does not guarantee
that there are not multiple compensating errors.  For example,
assume that there is a lot of noise on the track.  Then every time
you read it, you get a random checksum.  Since there are only 
256 different checksums, you don't have to read it too many times
before "0" comes up, and the checksum test passes, but that
doesn't mean the data read is OK.

The way the checksum gives you confidence of a good read
is that almost every time you read it, the checksum is good.

>To turn this on from Applesoft, do
>poke 48588,76:poke 48589,193:poke 48590,189"
>To turn it off and restore normal error handling, do
>poke 48588,16:poke 48589,243:poke 48590,173

If using this approach, it would be good to do it at least twice
to see if you get the same data each time.

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/