Сообщение от
LeoN65816
Ясно, спасибо.
1. Где-то на форуме Владимир говорил, что в паре синхросбоя вторым байтом может быть и не $FF. (0x89245555)
Да, тут либо проверять все возможные варианты, если их конечное кол-во либо писать как есть а уже потом анализировать на компьютере или на контроллере в offline.
2. Синхросбой не только перед полем данных, но и перед адресным полем.
Да, но все команды записи бейсика, которые я пробовал, пишут только кусок данных размером 269-270 MFM слов попадающий между GAP2 (почти полностью) и GAP3 (пару байт):
Код:
2.3 GAP2 5x 0xAA bytes
2.4 Desync: 0xA4, 2 ms zero level interval, 0xFF
2.5 Data field:
0x6A, 0x95 (2 byte, data field prologue),
256 Data Bytes,
CRC (1 byte),
0x5A (1 byte, data field epilogue)
2.7 GAP3 22x 0xAA bytes
Поля адреса записываются только по команде INIT или при копировании дискет копировщиком ИКП например.
3. Предкомпенсацию записи как-то обрабатываешь?
Т.к. временные промежутки между импульсами довольно легко дифференцируются, а предкомпенсация добавляет доли микросекунды, то думаю нет смысла както явно ее учитывать.
Вот пример записи в условных единицах длительности паузы между импульсами, в скобках длина паузы в тиках процессора, после стрелки кол-во импульсов с такой длиной:
Код:
[317] => 4
[343] => 41
[349] => 1
[369] => 796
[371] => 1
[395] => 2
[550] => 3
[551] => 527
[575] => 1
[577] => 164
[733] => 44
[734] => 1
[759] => 69
[783] => 1
[785] => 21
[811] => 1
Поэтому, мы можем легко задать довольно широкие диапазоны для декодирования, например: 0-450 код 10, 450-650 код 100, 650-... код 1000.
Также никто не мешает анализировать эти интервалы после получения данных и подстраивать окна автоматически на основе максимального расстояния между группами значений.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
