| Author: | Nate (guest: search) |
|---|---|---|
| Date: | Fri, Apr 01st, 2011 @ 17:08 ( . ) |
On 04/01/2011 @ 12:01, Lord Crass wrote :
I think the dumps themselves are fine and redumping wouldn't yield any additional information. : : There's 2 problems here: : : 1. This protection simply won't work in current emulators because they don't have any concept of density and its effect on the time it takes a byte to be ready at $1C01 in the emulated 1541. Therefore this protection doesn't get the different timing values it's expecting. Might be worth adding this + different track skew values to VICE. Right now, it aligns on sector 0, which works form some but not all schemes. : 2. Remastering this cannot be done in one pass when using a 1541. I did some rough calculations, and you *should* be able to reproduce this density change by altering the drive speed for each special track, then writing that track to disk. : : For example, with the Star Rank Boxing V-Max V1 example I gave a few posts up, the special tracks are 14/15, 16/17, and possibly 18. If we take 12/13 as "standard density at 300RPM", then we get tracks 14/15 being 2.8% less dense, and 16/17 being 2.9% more dense. Track 18 might be standard as well, you'd have to use nibtools to see what the track capacity is and see if matches. : : So if you write the whole disk at 300RPM, then rewrite tracks 14/15 at 308.4RPM, and 16/17 at 291.3RPM (Pete, are these speeds realistic for the 1541 or will you run into some limitation?), then you should probably be able to pass this protection check. The sync length check on track 12 might be a little trickier though. As long as the sync stored in your image is close enough, you might be able to sneak a successful check in by altering the drive speed that you write that track with a little faster or a little slower, but you'd need to know what timer value is coming back from the protection in order to know which way to adjust the speed. Also, if you adjust the speed of track 12 too much, you'd also need to adjust the writing speed of 13-17 accordingly as well. : : The protection doesn't check for an exact value when it counts the cycles when reading the header. It simply compares the values between the tracks to ensure that they differ in specific directions. So as long as you can get that criteria to match while still being able to get readable data from the disk, you'll pass the check. : : All in all though, it doesn't seem worth the effort involved. You're better off using something like KryoFlux to reliably write back a protection like this. -- First, my main hope is that people will patch up the .nib files (say by increasing sync length) to match as closely as possible what the code expects. This way they will work unchanged in emulators once better drive support is added. Also, it would be nice for nibwrite to work for as many schemes as possible, but that's secondary. Since you can only write a byte at a time, we can't do bit-timing. The only variables we have there are drive speed, density setting, and clock speed (2 Mhz for 1571). Perhaps nibwrite could be tweaked to be able to master patterns like you describe using some set of those parameters. But if not, let's focus on analyzing the schemes and patching up the .nib files and let other systems like Kryoflux do bit-accurate mastering. -Nate |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Apr 01st, 2011 @ 18:02 ( . ) |
sorry I should have made things a bit more clearer. My redump request wasn't meant to try and test if nibread could dump it better so that it would work on emulators, I just wanted to find out if it could be remastered with nibwrite with the right details so that it could be played on the real thing. Both Nibread and nibwrite have been optimized a bit since DOTC and the other v-max titles with the special tracks were dumped several years back. A good example of this is Sinbad and the throne of the falcon. Although there don't appear to be any special secondary checks in this game, previously the tracks were unable to be written back to the disk properly because they were sync-less. After a redump with a more recent version of nibread last year, I was able to successfully remaster the game and get it up and running. |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 00:35 ( . ) |
It should be remasterable with the current nibtools, provided you adjust the speed of your drive properly for each of the checked tracks. No update to nibtools can improve this since the software cannot adjust the speed of the drive motor or the rate at which data is written (past the usual density setting). |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 01:55 ( . ) |
but in the old dumps the tracks are too long, just over 8k, and even if you do manage to slow your drive down to 290rpm, the track will still truncate. It will not let you write anything if it detects your drive is below 290rpm. That's why I thought the new nibread would do something different with the tracks so that they can be remastered at a slower speed without any truncation |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 02:40 ( . ) |
How much is truncated? It might be ok if it's just useless gap bytes being left out. You should be able to get all the actual sector data written on the track, since even a software nibbler with a standard 300RPM speed could do this. I don't think the protection is too picky either. It averages values all over the place, so I guess it's anticipating some differences. As long as there's a measurable difference from the other tracks... Only way to find out is to try it. I'm guessing you'll still get caught by the track 12 sync check though. Easiest way to tell on a real C64 is to listen to the drive and watch the screen when you choose the "go raiding" option (assuming this is Defender of the Crown). If you're failing the density check, you'll hear it clicking as it reads tracks 12-18 over and over again. When it fails track 12 sync check, it'll pause for about 2 seconds on one track, then reset the computer. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 05:42 ( . ) |
it's not DOTC, it's superstar ice hockey |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 07:06 ( . ) |
Tracks 16 and 17 are very long and impossible to remaster without some truncation, even at 290rpm. Tomorrow I'll test superstar ice hockey and remaster the long tracks at 290rpm and let you know if I get anywhere. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 12:06 ( . ) |
Superstar Ice Hockey has the same track layout as DotC (12/13 are normal, 14/15 are short, 16/17 are long, 18 is normal) 12.0: (3:7809) [] (7809) (fill:$55) {badgcr:5} 13.0: (3:7808) [] (7808) (fill:$55) {badgcr:4} 14.0: (3:7598) [] (7598) (fill:$55) {badgcr:4} 15.0: (3:7594) [] (7594) (fill:$55) {badgcr:4} 16.0: (3:8051) [rsync:99 trunc:24 ] (7928) (fill:$55) {badgcr:4} 17.0: (3:8052) [rsync:100 trunc:24 ] (7928) (fill:$55) {badgcr:4} 18.0: (2:7157) [] (7157) (fill:$55) {badgcr:4} I still have to look at these long tracks to see what "extra" data on them is making them so long. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 03rd, 2011 @ 02:00 ( . ) |
I only had a bit of time with the C64 today, but I was able to try writing one of these long tracks with a 1541 (with Maverick's track editor though, not nibtools). My assumption about 308RPM/291RPM was based on a regular track being 7800 bytes. This is incorrect. At maximum density setting, the drive spec says it writes 307692 bits/sec. 307692 / 5 / 8 = 7692 ($1E0C) bytes per track This makes the problem even worse though. The Track Editor read in track 16 as being $1F76 bytes. I was able to adjust the drive speed to write a track this long, and it did write that track back, but when re-reading it with the track editor, it seemed to take longer to read the copy than the original. The resulting data looked correct, but perhaps this borders on unreliable depending on your diskette quality. So, $1F76 (8054) bytes on a track is an increase in capacity of 4.71% 300RPM * 0.953 = 286RPM for tracks 16/17 Tracks 12/13 are 7806 bytes in length. In fact, tracks 1-13 are typically written at the same density. To achieve this density on a copy: 7692 / 7806 * 300RPM = 295.6RPM Tracks 14/15 are 7598 bytes in length: 7692 / 7598 * 300RPM = 303.7RPM And track 18 is handled by V-Max as standard density for that speed zone (285714 bits/sec = 7143 bytes per track). V-Max is showing 7156 bytes on this track, which is close enough to standard, so this track is written at 300RPM) You can reduce syncs and track gap bytes for 16/17 as the protection doesn't check sync length on them. This should reduce the track to about 7908 bytes which could help you from overwriting the start of track. You still need to slow the drive down to about 286RPM though to get the proper density. If nibtools won't write to a drive that slow, perhaps you can modify the source to either adjust the limits, or remove them entirely. It's in the write.c file. The line is if( (motor_speed > 310) || (motor_speed < 290)) Or, if you don't have the dev tools to compile nibtools, but you're handy with a hex editor, you can try modifying the binary nibwrite.exe. Search for: 00 00 91 43 Replace with: 00 80 8E 43 This will change the lower RPM limit to 285, which should be sufficient. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Apr 03rd, 2011 @ 03:05 ( . ) |
Yo! thanks for that! appreciated! |