| 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 |
4/02/2011 @ 00:35----Lord Crass --- 0 Users Online --- 0 Recent Unique Posters |