search

simonowen / samdisk

A portable disk image utility, specialising in copy-protected PC-compatible formats.
http://simonowen.com/samdisk
MIT License
86 stars 11 forks source link

DSK format: report value of unknown DAM when it is discarded (+2 more commits) #4

Closed shattered closed 6 years ago

shattered commented 6 years ago

Some of the floppies I've scanned recently had larger than expected gap2, I am not sure how they were formatted, but apart from that they are normal ISO MFM disks.

simonowen commented 6 years ago

If MX and Agat aren't detected as FM by the normal bitstream scanner then they're not really IBM FM and shouldn't be flagged using that encoding type. If they're a special format they should keep their own type, which will allow them to be correctly converted back to a working bitstream.

Similarly, using the 0xfb data address mark to force the output types to accept them isn't a good solution. The output formats are going to become stricter in what they accept too -- currently EDSK doesn't reject Amiga encoding either, but it doesn't really support that.

If necessary there could be an option to force the encoding type between input and output, but it should be a manually requested conversion and not an implicit one. If the input image is a regular format, you can always do it legally as a two-step conversion via raw:

$ samdisk a-a3-07.scp a-a3-07.raw --mx
Wrote 80 cyls, 2 heads, 11 sectors,  256 bytes/sector = 450560 bytes

$ samdisk a-a3-07.raw a-a3-07.dsk -c80 -s2 -s11 -z1 --fm

$ samdisk scan a-a3-07.dsk -c0 -h0
[a-a3-07.dsk]
Cyl 0 Head 0:
250Kbps FM, 11 sectors,  256 bytes/sector:
  0.0  1 2 3 4 5 6 7 8 9 10 11

ccdbc30 and 05dcc85 are good, but I think 23ff478 shouldn't fake its encoding and dam types.

simonowen commented 6 years ago

On the same topic, do MX and Agat need gap data extraction?

The bitstream decoder is quite messy because some Amstrad CPC disks hide data in the gap areas that is required for copy protection. It extracts the sector data plus gap areas, then removes the gaps is they don't appear to contain custom data. That makes it much more complicated than just extracting the basic data fields.

The change to support MX and Agat duplicated the gap extraction code, but I suspect those formats probably don't need it. Do you know if any MX or Agat disks that require custom gap data? I already removed it from my code as part of moving some functions, but I thought I should check with you before I push it.

shattered commented 6 years ago

I'm using EDSK as container format for --repair option, to try and recover as much data as possible using various pll-adjust/pll-phase options, so an override would help.

MX has data in gap4 (contents vary depending on formatter program used).

Agat did have copy-protected software, but I don't have any of it on physical disks, so gap extraction can be omitted until proven necessary.

simonowen commented 6 years ago

I've added datarate and encoding override options in c31e8957f41d8c8b29e3e77f0b1454b76c06d219, which allow you to force the output encoding to something EDSK accepts. Using --encoding=FM should give you what you were after.

You'll still need to set the DAM type to 0xfb to give normal data sectors without a warning. I might change the PC-specific DAM byte to be a more general encoding enum, so non-PC encodings that don't explicitly set it will get "normal" data sectors.

shattered commented 6 years ago

Looks good, I will test that :)