'Radwar Protection and Cyan Loader issues'
Author:hyper active (registered user: 296 posts )
Date: Wed, Oct 19th, 2011 @ 17:18 ( . )

the radwar protection and cyan loader protection are incompatible with each other, even though they use the same weak bit concept, this is because it uses track 18 which also contains the disk's directory listing.
There are several solutions available.
1: find someone with the original and get them to dump the game using the current nibtools
2: you can fix it yourself with the soon to be available nib and g64 editor.
3: another method I've used is to remaster a working cyan protected game with nibtools and then convert the broken ghouls-n-ghosts nib image to a d64, and write it out. Remastering a d64 through star commander will leave the gcr code untouched.


REPLY: [With No Quote] --- [With Quoted Text]

'Radwar Protection and Cyan Loader issues'
Author:francob (registered user: 3 posts )
Date: Sat, Oct 22nd, 2011 @ 15:47 ( . )

I prepared a master using this procedure:

- nibwrite ghouls_n_ghosts_damaged.nib
- nibwrite -S32 -E32 BlackTiger_USGold_1989_PAL.nib
- rewrited only sectors 2 to 16 of track 32 using Star Commander with image
Ghouls'n'Ghosts [PAL] [patched].d64. I used this image and not the D64 converted
from ghouls_n_ghost_damaged.nib because there are sectors with errors that stop
loading after protection

The master as prepared works fine.

After, I dumped master creating Ghouls'n'Ghosts_USGold_1989_PAL.nib.

Using this .nib I remastered another disk. Even this disk works, but randomly
loading fails for cyan protection.

Is there a solution of this problem?


REPLY: [With No Quote] --- [With Quoted Text]

'Radwar Protection and Cyan Loader issues'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sat, Oct 22nd, 2011 @ 20:26 ( . )

It's a "weak bit" protection, meaning it takes advantage of how the 1541 reacts when no flux transitions occur for more than 3 interpreted byte lengths.

These disks have this check on track 32, sector 1, I believe. If you zero out that sector in the image, it will pass protection. It expects the data to be different every time it's read (and it tries 8 or 10 times). When you read the disk in, it is not read in as '0' or no flux transitions, you get the 'random' data instead. nibtools tries it's best to detect this and zero it out when remastering, but it's not always enough to pass the protection. You can try to make it more aggressive with the -f[n] switch where [n] is an integer. Larger numbers zero out larger areas around the detected 'weak' parts.


REPLY: [With No Quote] --- [With Quoted Text]


--- 0 Users Online --- 0 Recent Unique Posters

Q58=1714900969 - Threads: / 1714900969