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. 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! 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 Hope this helps! Jayson. wrote in message news:ci6vi9$ubf@odah37.prod.google.com... > There are many ways to approach this problem, depending on the details > of the copy protection scheme, and what you are looking for in > entertainment value. > > One approach is to disassemble the DOS RWTS, figure out how to patch it > to write the format you wish, and then write a short Applesoft program > which POKES the patched values for the special sectors. Ideally, you > also PEEK beforehand to make sure the DOS is valid, and restore the > proper values afterward. The most extreme case of this is to BLOAD your > own hand-assembled RWTS substitute. > > This is easiest if the scheme changes some of the magic values for > prolog/epilog or checksums. Way back when, there was a program called > "Super IOB" which allowed for these patches to be standardized and > swapped as "softkeys" > > http://www.apple2.org.za/mirrors/ground.icaen.uiowa.edu/MiscInfo/Programming /meccopy.dasm > > contains some discussion of this approach. > > Another approach, which was very common in the days of BBS pirating, > was to find the code in the program which checks for the protection > scheme and disable it by changing the 6502 machine code in the > program. There is probably a dedicated routine that checks for the > protection and returns a flag (perhaps carry set or carry clear). You > can replace that routine with a simple SEC RTS or CLC RTS depending. > This strategy also works with disks that use a modified RWTS. You can > undo the modifications, allowing the program to run on fully standard > DOS disks. > > The only argument against this is aesthetic: it feels nice to have the > pristine application instead of a hacked version. > > The easiest way to make this change is Copy II+. Its sector editor has > a disassemble function to inspect the code before you alter it. > > Another approach is to use a patched RWTS that ignores errors on read > and writes out standard format, and then using a track editor to put > the "error" back in by hand. > > All of these can be made to work, and several of them can lead to lots > of fun exploration and puzzle solving. Have fun! > 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/