Sector numbers starting with 193

[RCPDesigns]

I'm trying to read some old floppies from a Z80 CPM/2 system. It uses a PD765 floppy disk controller setup for MFM Mode.
The floppy is double sided and 96TPI. The manual mentions 512 bytes per sector and loosely implies that there are 15 sectors per track. The PD765 data sheet implies there are 8 sectors per track. The manual says the disk holds 800K.

I've gone through all the formats and the ones that "find something" all have the messages...

T0.0: Ignoring unexpected sector C:0 H:0 R:193 N:2
.
.
.
T0.0: Ignoring unexpected sector C:0 H:0 R:202 N:2

I assume R is for sector. The lowest sector number is 193 and the highest is 202. All sector numbers between 193 and 202 are found, usually twice. Assuming N is the bytes/sector code... that looks correct as the PD765 data sheet says 02 is for 512 bytes/sector.

My question is what would explain the sector numbers being so high?

I've looked at the source and it is very well laid out so I think that I can tweak the MFM parameters if given some direction as to why I'm seeing the high sector numbers.

[keirf]

Although most systems start sector numbering from 0 or 1, it isn't universal. There is no requirement for sector numbering to start from a particular base, nor even to be consecutive. On this system the numbering starts at 193d = C1h. It's not a problem. Amstrad CPC does this too iirc.

[RCPDesigns]

Yes, we're back to the 10 sector disk. I checked out master this morning. I updated the hardware with gw update last night.
I can't seem to convince MacOS to let HxC export a file. So that seemingly perfect image up there only exists in HxC.
-edit- looks like HxC is failing to export the Atari ST format. The raw .img format works and I guess works for me.
My format looks like this right now.

    clock = 2e-6
    time_per_rev = 0.2
    gap_3 = 42
    nsec  = 10
    id0   = 193
    sz    = 2

[keirf]

I'd suggest gap_3 = 30. But for checking in HxC I would suggest raw dump, no --format= option which would make gap_3 unused anyway.

If you can get a raw dump gw read my.scp perhaps just with a --tracks= parameter, and upload it, I can take a look.

[keirf]

Because if you specify --format= then your SCP is "cooked"/regenerated, and not actually a raw dump. Unless you also specify --raw.

[keirf]

You can specify --adjust-speed= alongside --raw though. That's legit, if your dump drive is wrong speed.

[RCPDesigns]

ok, doing that now. Couldn't figure out --tracks so there will be a couple extra tracks.
Thanks for taking the time to look at it. Where do I upload?

[RCPDesigns]

raw3.scp.zip

disk format is only 80 tracks so 2 extra tracks in the read

[keirf]

Load this into HxC tools, and look at the disk view. Note the red bits. Switch to stream view and look at some tracks on side 1. Look at how on bad (red) sectors the bit bands "drop out" and flux turns to noise. Could be due to mould on disk. Sometimes cleaning the disk surface can fix this.

The good HxC visualisations were probably because Greaseweazle had regenerated the tracks. However it would have written filler bytes into sectors it could not decode in the raw dump. So it was a false sense of success.

[RCPDesigns]

Great, I'll try cleaning the disk. Thanks a ton for the help!
GW is one of the coolest things I've bought in a long time. Last week I managed to read in 50 disks from 1980 for my first computer, the Intecolor 3650. The atari.90 format worked perfectly. I load them into my emulator and was back in high-school immediately. Some of those disks were marked "bad" so the flux technology is amazing!

[RCPDesigns]

Cotton ball and some isopropyl alcohol and a perfect read. Only one retry. The fun thing about the disk image is you can see where to look on the physical disk.