Bounty Bob Strikes Back
in [Commodore]
|
Prev: Fwd: Commodore Free disk magazine
Next: C64 DTV
From: jimdrew on 29 Dec 2006 12:52 > > Since SuperCard+ can reproduce this protection (allegedly) then it must > > be simpler than first glance. I spent a month on this one program! It requires a special copier just for it, which does in fact duplicate the true 1/2 tracks. There is a LOT of head stepping (back and forth) necessary to duplicate that disk. You have to pre-format the normal tracks before you write the half tracks from what I remember. The data is spaced like this: 1.0 ---------------*************** 1.5 ************------------------- 2.0 ---------------*************** 2.5 ************------------------- The margin of error is extremely small. 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. In the copier, I wrote code that is similar to what they use in the original program and test each track and half-track after it is copied and repeat the copy if it doesn't pass. Fortunately, the amount of data was really small for this program. We would have been really screwed if they usd all of each half-track and had long tracks to boot! In the last week, I have been hounded by C64 people to provide information about copy protection due to some C64 emulator(s)? that are trying to support original GCR/MFM images. What someone needs to do is write a track dump program to a D64 type image. I might do this. I just went to my warehouse and found all of the THOUSANDS of C64 products (SuperCards, parameter disks, books, ROM boards, etc.) that I still have, along with source code and master disks for all of the UUI products and Copy ][64/128 (which I also wrote). I may throw some of this hardware up on eBay and clean out the warehoue.
From: Pete Rittwage on 29 Dec 2006 23:24 jimdrew(a)frontiernet.net wrote: > In the last week, I have been hounded by C64 people to provide > information about copy protection due to some C64 emulator(s)? that are > trying to support original GCR/MFM images. What someone needs to do is > write a track dump program to a D64 type image. I might do this. I > just went to my warehouse and found all of the THOUSANDS of C64 > products (SuperCards, parameter disks, books, ROM boards, etc.) that I > still have, along with source code and master disks for all of the UUI > products and Copy ][64/128 (which I also wrote). I may throw some of > this hardware up on eBay and clean out the warehoue. The track dumping is already worked out, but maybe you have better ideas on how it could be done on stock hardware? My MNIB program requires the parallel port connection to the VIA or 8k extra RAM (original SuperCard style) so that a whole track can be read at once. These can be converted to G64 and 99% of games run fine with full protection. There has been talk about breaking it up and stitching it back together on the PC, but nobody has shown any code to do so. It would be great to see your old notes and source for your old stuff if you are going to sell it. -- - Pete Rittwage http://rittwage.com C64 Preservation Project http://c64preservation.com
From: jimdrew on 30 Dec 2006 12:49 Pete Rittwage wrote: > The track dumping is already worked out, but maybe you have better ideas > on how it could be done on stock hardware? My MNIB program requires the > parallel port connection to the VIA or 8k extra RAM (original > SuperCard style) so that a whole track can be read at once. These can > be converted to G64 and 99% of games run fine with full protection. How acurate is the CPU clock in the 1541/1571 emulation. I do know that MANY of the nasty protected games are extremely timing sensitive. I also know that my own code is that way as well, especially when spooling GCR data directly from the head. I don't need to look at sync marks. I figured out a way to clock the data without doing that, but it relys on a perfect CPU speed, and I had seen some of the 1541-IIs have a slightly higher than normal CPU speed, like the oscillator parts were a different brand or tolerence. Also, the sync separator emulation circuitry would have to be dead on. What programs will not load? Perhaps I can help determine why. > There has been talk about breaking it up and stitching it back together > on the PC, but nobody has shown any code to do so. > > It would be great to see your old notes and source for your old stuff if > you are going to sell it. 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?
From: Pete Rittwage on 30 Dec 2006 15:39 jimdrew(a)frontiernet.net wrote: > Pete Rittwage wrote: > >> The track dumping is already worked out, but maybe you have better ideas >> on how it could be done on stock hardware? My MNIB program requires the >> parallel port connection to the VIA or 8k extra RAM (original >> SuperCard style) so that a whole track can be read at once. These can >> be converted to G64 and 99% of games run fine with full protection. > > How acurate is the CPU clock in the 1541/1571 emulation. I do know > that MANY of the nasty protected games are extremely timing sensitive. > I also know that my own code is that way as well, especially when > spooling GCR data directly from the head. I don't need to look at sync > marks. I figured out a way to clock the data without doing that, but > it relys on a perfect CPU speed, and I had seen some of the 1541-IIs > have a slightly higher than normal CPU speed, like the oscillator parts > were a different brand or tolerence. Also, the sync separator > emulation circuitry would have to be dead on. > > What programs will not load? Perhaps I can help determine why. > Hi Jim, 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. Also, some earlier (V2) V-MAX! games still check for something past the long tracks and track 20 loader. Defender of the Crown side 2 for example, and the original Star Rank Boxing. Remember anything about those? -- - Pete Rittwage http://rittwage.com C64 Preservation Project http://c64preservation.com
From: jimdrew on 30 Dec 2006 16:31
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. > Also, some earlier (V2) V-MAX! games still check for something past the > long tracks and track 20 loader. Defender of the Crown side 2 for > example, and the original Star Rank Boxing. Remember anything about those? Wow.. these were the first of the long track stuff. From what I recall, you just needed to slow down the drive to copy these. The first SuperCard (before the plus model) copied these just fine, so they can't be using track to track timing or anything. Where can I find these emulations that work with the drive? Is this done under a GPL? I would be interested in looking at this and helping resolve the issue. |