Планирую сделать FDD эмулятор на Atmega8

[EvgenRU]

не, есть обычный байт C2 а есть с меткой С2 отличаются пропущеным импульсом

Вот тут http://info-coach.fr/atari/hardware/...le_of_CRC_Code описано по этому поводу в разделе MFM Synch Byte Pattern

Хотя да, понял о чем речь.

Т.е. тут еще выходит, что F5 и F6 это не данные дорожки, а команды контроллера....

Note that with the WD1772 an $A1 sync byte is produced by sending a $F5 byte to the FDC during the command, a $C2 sync byte is produced by sending a $F6 byte, and that the 2 bytes CRC are written by sending one $F7 byte. Normally the $C2 sync byte is is only used before an IAM and therefore normally not used in standard Atari diskettes. However having an IAM records on a track (as formatted on a PC) is perfectly acceptable on an Atari.

Указал в первом сообщении данную информацию.

- - - Добавлено - - -

Сравнил свою таблицу и значения в HFE файле, некоторые отличаются, например,

для 0x4E 01001110
МОЕ 0010010010101001 0x24A9
HFE 0100100100101010 0x492A
NEW 1001001001010100 0x9254

Следующие байты располагаются последовательно в файле

для 0x6E 01101110
МОЕ 00101000 00101001 0x28A9
HFE 0010100010101001 0x28A9
NEW 1001010001010100 0x9454

для 0x69 01101001
МОЕ 0010100000101001 0x2892
HFE 1010100010100010 0xA8A2
NEW 1001010001001001 0x9449

для 0x76 01110110
МОЕ 0010101000101001 0x2A29
HFE 0010101000101001 0x2A29
NEW 1001010100010100 0x9514

не пойму, то ли я где-то ошибся, то ли HFM, но скорее всего я...

Если смотреть в идеологии RN, NN, NR, то получается, что 4E должно быть закодировано как
Rn nR nn Rn nR nR nR n, буду думать дальше

4E 01001110, 01001001 00101010
R-означает смену полярности, N — отсутствие.

0 (предшествующий 0) RN
0 (предшествующий 1) NN
1 NR

Т.е. в данном примере, считается что перед первым байтом идет 0, в последующих учитывается значение последнего бита предыдущего.
Т.е. 4E (01001110) кодируется так
Предыдущий бит Текущий бит Код Значение
0 0 RN 01
0 1 NR 00
1 0 NN 10
0 0 RN 01
0 1 NR 00
1 1 NR 10
1 1 NR 10
1 0 NN 10

Получаем 01001001 00101010

Пока что не совсем понятно...


Так, утащил корректную табличку с гитхаба HxC
Взято тут https://github.com/jfdelnero/libhxcf...ck_generator.c

Хм... какой-то сложный у них метод.... очень мудреный, с отдельной таблицей для клока....

Вот чего нашел

In our example, the character ‘N’ is encoded this way (if the bit on the left was ‘0’):
0 1 0 0 1 1 1 0 The character ‘N’.
1 0 0 1 0 0 0 0 The MFM synchronization bits.
1 0 0 1 0 0 1 0 0 1 0 1 0 1 0 0 The resulting data, written to disk.

http://retro.icequake.net/dob/files/...H/RAWFLOPY.DOC

Т.е. получается наоборот, и используется предыдущий клок, а не последующий

по этому примеру получается что 0x4E = 0x9254, т.е. с HxC не сходится..., ну и ладно, наверное это всё-таки корректно Вроде там может быть несколько вариантов кодирования, главное чтобы последовательности шли правильно, значит так и буду составлять таблицу, т.е. положение тактирующего бита на данные не влияет вроде, главное, что все биты данных на месте. Плюс этого подхода в том, что первый бит нового значения вычисляется на основе последнего бита предыдущего значения.

Таким образом, для тех 3 последовательных байт получается
0x6E, 0x69, 0x76 = 01101110, 01101001, 1110110
DAT 0 1 1 0 1 1 1 0 |0 1 1 0 1 0 0 1 |0 1 1 1 0 1 1 0
CLK 1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0

Результат

100101000101010010010100010010010001010100010100 МОЙ (NEW)
001010001010100110101000101000100010101000101001 HFE