If you need assistance with new formats try MFM discussion group
If --analyze doesn't find the format, it will need to be added. Easiest solution is if you can find a manual that describes the sector format. Very few give the complete information such as the CRC polynomial. If I can't find the format the steps I use are:
./mfm_read --transitions_file ../disk.tran --cylinders # --heads # --drive #
mfm_util --format WD_3B1 --tran disk.tran --ext /tmp/out --quiet 1 --data_crc 0,0,32,0 --header_crc 0,0,32,0
For SA1000 type 8" disks use --format unknown2 instead.
If it prints Got exp messages for most tracks then it found the sector flag byte.
There is logic to handle various header flags if sufficient information is available to figure how how they are encoded. Look for bits that change in the header that aren't the cylinder etc. values and see if you can figure out what they are likely to encode. See bad_block, alt_assigned and is_alternate in the existing code to see how they are handled.
Look for bytes that change at the end randomly to find the CRC length. When write turns off it generates false bits that can cause bytes with various values after the real CRC but they tend to not look random. You can increase the ,32 in the CRC to ,64 to see more trailing bytes.
Copy the closest match in the CONTROLLER data structure in inc/mfm_decoder.h. Note that entries need to be sorted by header_bytes. Add in inc/mfm_decoder.h the new controller enum value to the controller enum in the same location that you put the new entry in CONTROLLER structure.
There are various other fields that need to be set correctly such as write_first_sector_number. Some controllers number the first sector 0 and others 1. Error logical sector -1 out of range indicates first sector 1 but should be 0. Others that may need to change are write_sector_size, header_bytes, data_header_bytes, header_crc_ignore, data_crc_ignore, write_header_crc, and write_data_crc. Stranger formats may require others to be changed.
Also need to add new controller to mfm_decoder.c to call the correct routine. See the current code.
If --analyze doesn't work you can change the define at the top of mfm_decoder.c to dump the header or data for use in find_crc_info to find the polynomial and initial value. You must have the correct CRC length. Find_crc_info is in the mfm directory. It can be built on faster Unix machines.
./find_crc_info total_bytes crc_bytes > dumpdata
Total_bytes is header bytes + sector bytes + CRC bytes.
Header will always have patterns that work to decode CRC polynomial. Data
may not.
If data CRC not found with above get the data to use with reveng.
First line of header data is the hex values
mfm_util --tran disk.tran --format SHUGART_1610 --ext /tmp/t --quiet 0 > /tmp/tt
Got exp 0,0 cyl 0 head 0 sector 0,0 size 1024 bad block 0
0 0 1:0xa1,0xd9,0x8b,0x58,0x83,0xec,0x04,0xec,0xc8,0x8c,0x20,0x2d,0x05,0x00
,0x00,0xbe,
Edit /tmp/tt and extract two sectors with different contents and write the data to two files. Remove # # #: on the first line. For this example the data was written to /tmp/h1 and /tmp/h2. Use reveng. First convert the hex data to binary.
xxd -i -r -p /tmp/h1 > /tmp/h1b
xxd -i -r -p /tmp/h2 > /tmp/h2b
Set -w to correct size.
reveng -w 32 -b -s -f /tmp/h1b /tmp/h2b
32 bit brute force typically takes an hour but can be 16 hours if all polynomials need to be searched on somewhat old laptop. To first search common polynomials add -p 00a00805 -q 00a00805. Other common values 140a0445, 104c981. If the initial value isn't simple such as 0 or all 1's you can try removing the 0xa1 byte and see if that helps. Some controllers don't include it in the CRC. Some don't include the first two bytes.
Easiest way to create the TRK_L is to copy closest existing and modify. Run ext2emu and fix the data to get rid of the errors and warnings. Then run mfm_util to decode the data and verify no errors and output data matches input.