Bounty Bob Strikes Back
in [Commodore]
|
Prev: Fwd: Commodore Free disk magazine
Next: C64 DTV
From: Pete Rittwage on 30 Dec 2006 20:06 jimdrew(a)frontiernet.net wrote: > Pete Rittwage wrote: > >> There are a few scattered instances of protections that won't load, but >> the one that still sticks out most obviously is RAPIDLOK. We can remove >> the track 36 key check, but some games still fail on a track sync check. > > RapidLock is one of those that requires precision everything. To > DUPLICATE (not copy mosly and crack the rest as most parameter copiers > did) the protection, you need to use an index hole and line the tracks > up. How do you guys deal with rotational speed and such with the > emulated GCR images? RapidLock expects to find data within a few > milliseconds of a successful head step, which is why some drives don't > load RapidLock until you clean the head rails! > > It sounds like to me the reason why RapidLock and Bounty Bob won't load > is that there is no simulation of the rotatiing disk. Do you simulate > the head step time? These are really crucial requirements if you want > everything to work. > Nope, you are spot on. There isn't any simulation of the exact timings, as far as I know. At least in VICE, the disk routines are being rewritten so that may change in the future. There is another emulator called HOXS that is said to be closer, but I don't have as much luck with that one. For openers, it emulates a PAL 64 only. -- - Pete Rittwage http://rittwage.com C64 Preservation Project http://c64preservation.com
From: Glenn Holmer on 31 Dec 2006 10:52 jimdrew(a)frontiernet.net wrote: > The original program would > load data, step the head and expect to find the next valid sync mark > within 'x' number of bytes. If it wasn't there, it would retry over > and over. Could you post some of the original drive code? I can imagine how that would be done, but I'd love to see the real thing. -- Glenn Holmer (Q-Link: ShadowM) http://www.lyonlabs.org/commodore/c64.html
From: Pete Rittwage on 31 Dec 2006 11:47 Glenn Holmer wrote: > jimdrew(a)frontiernet.net wrote: > >> The original program would >> load data, step the head and expect to find the next valid sync mark >> within 'x' number of bytes. If it wasn't there, it would retry over >> and over. > > Could you post some of the original drive code? I can imagine how that > would be done, but I'd love to see the real thing. > Hi Glen, I'll disassemble this sometime soon and put it up on my site. -- - Pete Rittwage http://rittwage.com C64 Preservation Project http://c64preservation.com
From: Jerry Kurtz on 31 Dec 2006 17:23 jimdrew(a)frontiernet.net wrote: > I am not sure what I will do with the source code. I have actually had > offers to buy it and the master disks, and rights to all of the > products. Is there really THAT big of an interest in this stuff again? There is some interest in this stuff, but not enough where you could sell thousands of pieces of any given item.
From: David Horrocks on 2 Jan 2007 17:33
"Pete Rittwage" <rcade(a)rittwage.com> wrote in message news:45970D22.8020509(a)rittwage.com... > jimdrew(a)frontiernet.net wrote: >> Pete Rittwage wrote: >> >>> There are a few scattered instances of protections that won't load, but >>> the one that still sticks out most obviously is RAPIDLOK. We can remove >>> the track 36 key check, but some games still fail on a track sync check. >> >> RapidLock is one of those that requires precision everything. To >> DUPLICATE (not copy mosly and crack the rest as most parameter copiers >> did) the protection, you need to use an index hole and line the tracks >> up. How do you guys deal with rotational speed and such with the >> emulated GCR images? RapidLock expects to find data within a few >> milliseconds of a successful head step, which is why some drives don't >> load RapidLock until you clean the head rails! In Hoxs64, the 1541 disk emulation allows the disk head to step from one half track to the next half track in one clock cycle (one millionth of a second). This is probably way to quick. I don't know what a real 1541 drive does if you try to step the disk head serveral tracks too quickly. My guess is the drive will miss some steps. But it is hard to see how reliable data can be read while the head is in transist. Does RAPIDLOK expect the previous track to be readable for a short time whilst the head is in transit? In Hoxs64, the new track becomes readable and the prevous track becomes not readable immediately after the controller receives the step command. Are there any disks images that are failing to load due to suspect step timing? David >> It sounds like to me the reason why RapidLock and Bounty Bob won't load >> is that there is no simulation of the rotatiing disk. Do you simulate >> the head step time? These are really crucial requirements if you want >> everything to work. >> > > Nope, you are spot on. There isn't any simulation of the exact timings, > as far as I know. At least in VICE, the disk routines are being rewritten > so that may change in the future. > There is another emulator called HOXS that is said to be closer, but I > don't have as much luck with that one. For openers, it emulates a PAL 64 > only. I should look at NTSC. Its has not been a priority for me as the vast majority of my metal banging software collection is for PAL. Is missing NTSC the only reason for having problems loading copy protected images? David |