 | Author: | Jason Compton (guest: search) |
|---|
| Date: | Fri, Aug 13th, 2010 @ 01:31 ( . ) |
Such as? I've sent in a number of Rapidlok titles (mostly Accolades, I think) over the month or so I've been imaging. |
|
 | Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Fri, Aug 13th, 2010 @ 05:13 ( . ) |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Fri, Aug 13th, 2010 @ 08:38 ( . ) |
I own most of these titles in multiple copies. The problem is there is no easy way to verify them. A better approach would be to use the Rapidlok tool from CSDb to copy the files to regular CBM-DOS disks for testing/comparison. You need a REU to do it, though, and a lot of time.
|
|
 | Author: | swolff (registered user: 26 posts ) |
|---|
| Date: | Thu, Aug 19th, 2010 @ 05:09 ( . ) |
Going slightly off topic: The Heatwave nib seems to be fine, as I've recently created a working g64 image from it. As usual for RapidLok images, the key track needs editing, though.
My RapidLok extractor shows only the usual header checksum errors (which are normal -- these checksums aren't even checked by RapidLok itself), no other errors.
Heatwave is NTSC. Running on a PAL system, the loader fails in mysterious and random ways :)
|
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Fri, Aug 20th, 2010 @ 01:09 ( . ) |
Ah. so thats why it won't work on my pal machine. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Tue, Aug 24th, 2010 @ 23:37 ( . ) |
Hello swolff. Is it possible you could email me your patched g64 of heat wave?
send it to whocrazy at gmail dot com
email address mangled to thwart spammers or email address filters. |
|
| Author: | swolff (registered user: 26 posts ) |
|---|
| Date: | Mon, Aug 30th, 2010 @ 16:40 ( . ) |
I've attached my modified g64.
|
Attachments: |
|
| 1283200805_heatwave.zip |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Mon, Aug 30th, 2010 @ 23:35 ( . ) |
Hey, thanks very much swolf. Perhaps we could add this one to the next version of the gamebase.
I notice also that pirates!ntsc is the only version in the gamebase. maybe you could include bangui-bob's original .nib pal version too. |
|
 | Author: | Mayhem (guest: search) |
|---|
| Date: | Thu, Sep 09th, 2010 @ 10:23 ( . ) |
I've dug out my PAL Sinbad for you and reNIBed it using 0.7.6 tools. Have sent the images to Pete, so let's see if there's any improvement on matters ;) |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Thu, Sep 09th, 2010 @ 21:12 ( . ) |
could you attach them here and I'll try and remaster them to see if they work?
Thanks.
|
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Thu, Sep 09th, 2010 @ 21:17 ( . ) |
I've tried them- they aren't yet working, even in emulation. When Mayhem gets some more time I asked if he could image it a couple more times, and with newer nibread. |
|
| Author: | Mayhem (guest: search) |
|---|
| Date: | Fri, Sep 10th, 2010 @ 13:59 ( . ) |
Silly V-Max... still, yes, I'll try to give the disk another few goes next week (I have to take out, setup and then put away the equipment currently!) when I get the chance... |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Fri, Sep 10th, 2010 @ 21:30 ( . ) |
as I said earlier the ntsc version that Peter sent me can be remastered without a problem, it was dumped in 2007.
|
|
| Author: | Mayhem (guest: search) |
|---|
| Date: | Sat, Oct 02nd, 2010 @ 14:44 ( . ) |
Redone Sinbad three times using the new 472 build and sent them to Pete... let's see if he makes anything out of that :p |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Tue, Oct 05th, 2010 @ 04:46 ( . ) |
so does this mean that sinbad can be remastered properly like this? nibwrite -px sinbad1.nib?
All I have to do is get the speed correct?
Thanks. |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Tue, Oct 05th, 2010 @ 09:41 ( . ) |
It will take experimentation. You can try -pc (Cinemaware) as it is different from regular V-MAX. Or try without switches. Sometimes one or the other will work.
The speed issue might be a problem. I can't support what you are doing to slow your motor, you will always get erratic results doing that.
|
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Thu, Oct 07th, 2010 @ 00:17 ( . ) |
wow. I'm getting there. but a couple of niggling issues remain.
some tracks such as 9, 22 and 24 struggle to load for some reason.
It's quite random.
Sometimes when you load the game, they'll load quite quickly, but other times they'll take for ever to load.
What I'd like to know is does this happen on the original disk? or do all tracks load in just under a second, like they do on vice?
Thanks. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Thu, Oct 07th, 2010 @ 00:45 ( . ) |
ps: I'm talking about side 1.
|
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sun, Oct 10th, 2010 @ 02:08 ( . ) |
Hi peter, can you please clarify something for me? in the disk database entry for this game, it says "cannot remaster sync-less tracks" can you tell me which tracks are they? are you talking about side one or side 2?
Thanks. |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Sun, Oct 10th, 2010 @ 10:15 ( . ) |
Either that's an error or it was fixed long ago.
|
|
 | Author: | VMAXX (registered user: 6 posts ) |
|---|
| Date: | Fri, Feb 25th, 2011 @ 04:26 ( . ) |
If the code has been patched, some version of V-Max around that time had a self-check built in which calculated a check sum, and if it failed to match the expected value, decremented the stepper motor minimum delay value, until the stepper motor routine pulsed the head too quickly, eventually resulting in one or more missteps when moving track to track. Which would result in random load errors in the copies... Such self checks could be buried in any sector, since sectors often would overload the last byte of the load routine with their own RTS instruction, unless they were copy protection sectors. One failure to pass the check sum routine wouldn't cause a load failure, it took repeated failures to decrement the delay value past the physical limits of the stepper motor itself. |
|
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|
| Date: | Fri, Feb 25th, 2011 @ 08:03 ( . ) |
Heh- that's a neat idea. :)
|
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sat, Feb 26th, 2011 @ 00:55 ( . ) |
I was able to remaster it in the end, so hurrah for nibtools. |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Sat, Feb 26th, 2011 @ 04:31 ( . ) |
ps: a question for Mr. Vmaxx, can you explain how the protection was done for defender of the crown? I mean the protection on side 2 on tracks 12 and 17.
It's also found on superstar ice hockey. |
|
| Author: | VMAXX (registered user: 6 posts ) |
|---|
| Date: | Mon, Feb 28th, 2011 @ 09:32 ( . ) |
We tried various things at different times, looking for reliability as well as protection value. I vaguely remember we tried sync counting (long syncs), illegal GCR (looking for a a byte which had different values on repeated reads), and even track to track synchronization (like I first used on DiskMaker's protection) (Yes, I know, the irony :p). We also checked to see if tracks were written in one pass (no breaks) and played with non-standard disk densities. Eventually we abandoned many of these protections as they caused compatibility problems with some drives. |
|
| Author: | VMAXX (registered user: 6 posts ) |
|---|
| Date: | Mon, Feb 28th, 2011 @ 11:31 ( . ) |
A couple of other things we tried was burying a short sync inside a data block, and writing a particular weak bit pattern which created a shifting but predictable set of of alternate values on subsequent reads.
We abandoned the embedded syncs because our duplicators had no way to verify these tracks on their machines (they hated doing "blind" copies). The shifting but predictable values probably failed on different disk drives, and we gave up on the as well.
I'm just not sure which of these protections were on which product, some of our most outrageous protection signatures never again saw the light of day after being used on DiskMaker. |
|
| Author: | VMAXX (registered user: 6 posts ) |
|---|
| Date: | Mon, Feb 28th, 2011 @ 09:49 ( . ) |
I think we ended up stripping the gears on some drives as a result, so we discontinued that trick eventually.
Another random protection crash could happen on On Field Football. There each time you were tackled, the screen would shake. If the scroll registers on the C64 were updated at a random point in time (as it would in a Basic timing loop) there would be screen tearing during the shake. But worse, the same hardware controlled the RAM refresh circuitry, so that randomly timed changes to the scroll register could cause the RAM refresh to be missed, resulting in random loss of data and eventual lockups. In the authentic game, the scroll register update loop waited for V-sync... |
|
| Author: | hyper active (registered user: 296 posts ) |
|---|
| Date: | Mon, Feb 28th, 2011 @ 18:57 ( . ) |
wow. this is a real eye opener.
Perhaps the defender of the crown protection was the one that used non-standard densities, the same for superstar ice hockey as well. The protected tracks for ice hockey are tracks 16 and 17, while the DOTC protection is located on track 12 and track 17.
Can you tell me is there any way in nibtools to remaster this protection properly?
Thanks. |
|
 | Author: | Fungus (registered user: 20 posts ) |
|---|
| Date: | Sat, Mar 12th, 2011 @ 01:16 ( . ) |
I think your memory fails. Your confusing v-max 3 and 2 with each other. Heh. Anyways, every single sector in v-max 2 was executed after loading. There was always a small ml routine there to set the next track and sector to read, and then jump back into the loader. Of course any embedded check could be implanted into any sector in the load chain. This is how DOTC really has the check embedded, so you need to be able to decode the GCR which is being used to see the sector construction.
Granted all my originals with v-max 2 have this particular scheme and I've written generic tools to pull out files and sectors to look at them. I've only seen 2 different block id codes, but there could be more. However it seems v-max 2 was either different, or updated for different regions or runs, because some of Pete's disks differ from mine. |
|