'Tools to work on g64 et al'
Author:Lord Crass (guest: search)
Date: Wed, Apr 13th, 2011 @ 11:00 ( . )

Is there any value in adding a density conversion option? Usually if data was read from a real 1541 at the wrong density, it's not very useful since you can no longer guarantee that it conforms to the C= GCR standard. It's possible to have too many 0's come in and clock in a phantom bit, or perhaps read in 10 1's in a row. This would probably be rare, but I think the chance of data corruption is high enough that it's not worth attempting to fix through software.

For the rare disk that does use multiple densities on the same track, it's probably easier to just read it at each density and paste it together after, marking those bytes with the appropriate speed zone, should any program decide to use that data in the future.

Or were you thinking of using this tool for other disk images as well, where the drive used to read the data doesn't have faulty shift registers or issues with reading sync? In that case, it might be useful.


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

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Thu, Apr 14th, 2011 @ 17:29 ( . )

That's what I was wondering -- how you guys determined which data was needed when the density used to read the image was wrong. I think you are just disassembling the protection code and looking for the pattern it is searching for and what it sets the density to before doing so, right?

I'll make it easy to specify density for ranges of bytes in a track. This will get written out to the g64 correctly (using the extended speed map) but will be lost if writing a .nib file. This way you can read out the track multiple times with nibread and then piece back together each track by just putting in the text file something like:

(2, xx xx xx) (3, yy yy)

BTW, does nibwrite or VICE support the g64 extended speed map? It doesn't seem like it.


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

'Tools to work on g64 et al'
Author:Lord Crass (guest: search)
Date: Thu, Apr 14th, 2011 @ 19:56 ( . )

Yes, I just disassembled the drive code to see what it was doing and how that data was used on the C64 side.

As far as I know, Vice doesn't use the speed zone data.

I don't think nibwrite does either. Based on the tight timing loops when writing out a track, I'm not sure if there's enough cycles available to check the speed zone and adjust the density before writing the next byte. There might be a missed byte if density needs to change on the fly. Pete would know more about this.


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

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Thu, Apr 14th, 2011 @ 20:25 ( . )

Sure, it might be able to be done with a small change in the writing code. At least on the 1571@2MHz, it would be easy. The 1MHz code is kind of tight. I'm not sure it's worth the trouble for this one protection that is used on a couple disks, though, but for the sake of completeness...

I'm not sure how many cycles it takes to change density, so it would need experimentation. Another idea is to do something where we wait for a signature to pass by and then write, which you could use to append data to a track at a different density.


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

'Tools to work on g64 et al'
Author:J Achernar (registered user: 36 posts )
Date: Fri, Apr 15th, 2011 @ 23:10 ( . )

From working with Black Hole, neither VICE or CCS64 uses the speed zone data, but it does not hurt anything either. I manually added the speed zone data to Black Hole, even though it was not necessary to make it work in the emulators, so that it was as accurate as I could make it.


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


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

Q130=1653258379 - Threads: / 1653258379