'Tools to work on g64 et al'
Author:Lord Crass (guest: search)
Date: Mon, Apr 04th, 2011 @ 21:08 ( . )

Looks great! How about an option to display the data as 8-bit GCR as well? I think most folks who are used to editing raw GCR are probably more familiar with that format.


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

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Tue, Apr 05th, 2011 @ 02:45 ( . )

Sure, will do that. I assume you mean a set of 5 bytes (40 GCR bits). I will also add a comment with the 4-byte decoded version alongside so it looks like this:

aa bb cc dd ee ff aa bb cc dd # 11 22 33 44 55 66 77 88

The decoded version would not be parsed when rewriting the data. Of course, you can rework the GCR lines themselves any way you want (any number of bytes per line, different line lengths, etc.)


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

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Thu, Apr 07th, 2011 @ 06:22 ( . )

what would be really good is if we could take all the raw tracks and splice them back together in a g64 or .nib file.


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

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Thu, Apr 07th, 2011 @ 16:04 ( . )

Of course... you extract all the tracks into a simple text file, edit as you wish, then re-run it to generate the corresponding .nib/.g64 file.

I'll put this online soon. It needs more cleanups.


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

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Fri, Apr 08th, 2011 @ 08:48 ( . )

This is an interesting and easy way to accomplish this- I like it. I'm not so sure about the 10-bit HEX, though- I've never worked in that format before. Is this common in modern embedded development or something?


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

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Fri, Apr 08th, 2011 @ 19:55 ( . )

hmm. this is not quite what I had in mind. I've been using the hidden raw track dump mode and each track has been extracted into a file, tr1.0d3, tr2.0d3, tr3.0d3 etc.
When Lord Crass showed me what to change on track 12 recently, I simply loaded up the tr12.0d3 file in ultra edit. The problem is that I have no way to splice these tracks together in to nib or g64, and that was what I was hoping that Nate's program could do.


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

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Sun, Apr 10th, 2011 @ 13:34 ( . )

Made some more progress on this and now have some questions. The code currently lets you do the following by editing the text dump of an image:

* Read/write .nib or .g64
* Insert, change, delete GCR bytes
* Change SYNC length, delete SYNCs, add them, etc.
* Format is 5:4 bytes (GCR to decoded), two sets of these per line (10 bytes GCR)

There are also commands to do the following:

* Shift track: output 7 .nib or .g64 files with rotates of 1 to 7 bits for a given track #

I'm looking at adding support for these features but uncertain which ones are most useful:

* Align a given track (rotate in image), based on the following:

- First sync found (10 bits of 1)
- Sector number (does some decoding)
- GCR pattern

Are there any others that would be useful? Start track at longest sync?

Of course, you can implement arbitrary track-to-track alignments with this by rotating track 1 to start at sector 0, track 2 to sector 15, or whatever.

* Density conversion -- How should this be done? I understand that if you want to convert a range of data from higer density to lower, you just discard bits. But I think there's no way to go from lower to higher.

For density, I support the g64 per-byte extended map so you can set arbitrary density for byte ranges within each track. Of course, you lose that info if you write out a .nib.

Comments welcome.


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

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sun, Apr 10th, 2011 @ 21:00 ( . )

There are already some alignments done in the code (used in nibconv and nibwrite, contained in prot.c). There is a V-MAX, and there *was* a Rapidlok one, but it seems to be lost/gone. I think someone did a better one and may submit it, though.

The PirateSlayer alignment used to shift the track for you also when converting, and it looked for the magic sequence automatically. I'll look and see why that is gone now, too.


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

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Tue, Apr 12th, 2011 @ 22:11 ( . )

Any answers to my other questions on density conversion?

Does anything support the extended g64 density map such as nibwrite or VICE?


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

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Tue, Apr 12th, 2011 @ 22:58 ( . )

I don't believe anything supports alternate densities within a track. VICE knows nothing of density, I am sure of that. It only sees the whole bytes in the G64 no matter what.


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

'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

Q292=1653265495 - Threads: / 1653265495