Последний раз редактировалось EvgenRU; 21.03.2016 в 14:36.
Вот тут 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
Хм... какой-то сложный у них метод.... очень мудреный, с отдельной таблицей для клока....
Вот чего нашел
http://retro.icequake.net/dob/files/...H/RAWFLOPY.DOCIn 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.
Т.е. получается наоборот, и используется предыдущий клок, а не последующий
по этому примеру получается что 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
Последний раз редактировалось EvgenRU; 21.03.2016 в 20:15.
Да, так и есть, попутал. Тогда, вот этот вариант - 2 пина всего за 50 центов. Не знаю правда, I2C вроде бы не сложный протокол, много места в прошивке не должен занять.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Продолжаю изыскания
Закодировал еще один TRD, строка кодирования
hxcfe.exe -finput:d0011.trd -foutput:1.hfe -conv:HXC_HFE
Первые 4 байта в TDR
62, 6F, 6F, 74 (слово "boot")
01100010, 01101111, 01101111, 01110100
В HFE значения
0x2825, 0x29AA, 0x28AA, 0xA848,
0010100000100101 0010100110101010 0010100010101010 1010100001001000
По моей таблице (новой)
0x94A4, 0x9455, 0x9455, 0x9512
1001010000100100 1001010001010101 1001010001010101 1001010100010010
С учетом соседних бит
0x94A4, 0x9455, 0x1455, 0x1512
1001010000100100 1001010001010101 0001010001010101 0001010100010010
Убираем первый бит и сравниваем с HFE
00101000010010010010100010101010001010001010101000 1010100010010
00101000001001010010100110101010001010001010101010 1010000100100
Видим различия
По старой таблице
0x2949, 0x28AA, 0x28AA, 0x2A25
0010100101001001 0010100010101010 0010100010101010 0010101000100101
С учетом соседних бит
0010100101001001 0010100010101010 0010100010101010 0010101000100101
Сравниваем с HFE
0010100101001001 0010100010101010 0010100010101010 0010101000100101
0010100000100101 0010100110101010 0010100010101010 1010100001001000
Опять же есть различия...
Пока что оставлю это всё, как соберу пробное устройство, тогда и буду разбираться
Возможно в HFE есть какие-то свои маркеры...
Вот еще какая-то инфа https://en.wikipedia.org/wiki/Modifi...ncy_Modulation
- - - Добавлено - - -
С TWI не так просто работать напрямую и библиотека тяжелая достаточно, регистр сдвига или SPI в этом плане куда проще использовать.
PS: отключаюсь до четверга, работа не волк. Буду признателен за любые дельные советы за это время.
Еще несколько диаграмм напоследок, снято на 8 МГц, если несколько STEP подряд, то период между ними 3мс, у последнего степа период 16мс, потом начинается выдача данных
Последний раз редактировалось EvgenRU; 22.03.2016 в 07:38.
У atmeg-ов есть встроенный TWI и работать с ним проще, чем писать с нуля свою I2C библиотеку. Другой вопрос, что atmega8 + i2c расширитель будут стоить уже определённо дороже, чем atmega128. И места займут больше на плате. Дисплей можно взять графический - они уже SPI обычно + с графическим экраном можно реализовать гораздо более удобный интерфейс выбора файла, чем с 1602.
Тут еще идея возникла, если слать данные с помощью таймера и ШИМ, то вообще остается куча времени на чтение с SD и обработку :-D
тут есть еще одна тема для изучения, нужно ли искажать mfm что бы его смогли прочитать или чистый mfm нормально пройдет через аналоговый тракт контролера дисковода, там есть такая вещь, две подрят единицы в mfm, вторая единица будет смещена слегка вперед, ну и обратная ситуация с нолями, причем искажения в середине диска гораздо больше чем на краю, но это все аналоговые нюансы, нужно ли их учитывать при эмуляции, мне к примеру не сильно ясно
- - - Добавлено - - -
вернее речь не о двух единица а о двух рядом идущих импульсах
но с другой стороны, нормальный контролер дисковода вносит при записи искажения в сигнал, что бы компенсировать этот эффект
- - - Добавлено - - -
с таймеров тоже не все просто, на вход/выход в прерывание нужно тратить такты, это раз.
причем если основной цикл на си, то нужно еще и регистры сохранять которые в обработчике прерывания используются, на ассемблере можно предусмотреть и не трогать какие то регистры для целей ISR с си же, тут много нюансов
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)