Вид для печати
Чот грустно, что никто так и не посмотрел схему. Биты там считаются от 0, в выделенном блоке нижние 16 это биты от 0 до 15 (0 - самый нижний), а верхняя линия это выбор режима.
https://jpegshare.net/images/5a/75/5...9d177f6db7.png
https://jpegshare.net/images/bf/f7/b...b116da9010.png
Ну вот и о том и речь, что 13й бит не делает из #29 синхрокод #A1. 12й бы делал. То есть причина не в этом.
Подцепил к дисководу анализатор, скапчурил вход RDATA. Поток очень даже красиво выглядит, всё прекрасно распознаётся, в том числе синхрокод MFM, и A1, и FB и последующие данные:
https://volutar.eu5.org/rdata1.png
Немного обескуражен тем, что дефолтовое состояние линии - 1ка (4.6в), я думал наоборот должно быть.
Замечу, что как раз в форме 43432 визуально в общей каше было очень легко найти синхрокод. MFM "код" 0x4489 распознать в этой каше, разумеется, нереально.
В нескольких местах промежутки между импульсами отличаются от стандартных 4/6/8мс: в одном месте 3мс, в разных других 10мс, 11мс. Очевидно эти аномальные дистанции как раз попадают на границы перезаписанных секторов.
ОК, пин шаренный между несколькими дисководамиЦитата:
Сообщение от Dexus
Я же нарисовал, игонрирование бита, может в схеме бага.Цитата:
Сообщение от Dexus
Полверить легко, последовательность
#0С#29 - сбивается
#0D#29; #0E#29; #0F#29 не должно сбиваться
Какими ещё несколькими дисководами? У меня один дисковод. Уровни INDEX и RDATA дефолтово в единичке. И импульсы идут в 0. Длительность INDEX - 3.7мс.Цитата:
Сообщение от s_kosorev
Да не важно - это бага в схеме или нет, 13й бит _вообще_ никак не влияет.Цитата:
Сообщение от s_kosorev
Странно, что никто так и не проверил, раз это так легко. Мне писать софт ковыряющий ВГ93 на ZX - лениво. Интереснее в сигналах и кодировании разбираться.Цитата:
Сообщение от s_kosorev
Из инструкции: (стр.32)
More generally the WD1772 is resynchronized whenever the following combination of 9 bits
“000101001” appears in a bit stream. This can happen anywhere as the with the following
byte combinations:
* $29 and previous byte even (i.e. LSB set to 0)
* $52 or $53 and previous byte divisible by 4 (i.e. the two LSB set to 0)
* $A4-$A7 and previous bytes divisible by 8 (i.e. the three LSB set to 0)
* $14 and the following byte >= 128 (i.e. MSB set to 1)
* $0A, $8A and following byte with bit 7 cleared and bit 6 set (e.g. $43)
* $05,$45, $85, $C5 and following byte with bits 7, 6 cleared and bit 5 set (i.e. $21)
Non only the controller synchronizes to the presented sequence (i.e. $29), but it stays
incorrectly synchronized and therefore all the following bytes are shifted by multiple of "half
bit", which results in mix-up of data and clock pulses, and so the decoded bytes are totally
unrecognizable.
This error occurs everywhere on track 41. The value 41 is $29 in hexadecimal and therefore
all the address fields of these tracks are read incorrectly as well as the bytes following this
incorrectly decoded header.
То, что у тебя один дисковод не отменяет того факта, что шина и контроллер рассчитаны на 4 привода на одном шлейфе. И все сигналы действительно по схеме с ОК.Цитата:
Сообщение от Dexus
Ковыряясь с интерпретацией MFM потока обнаружил, что синхрокоды "#C2C2C2" и "#A1A1A1" - симметричные. Что означает, что в потоке данных они могут возникнуть с одинаковой вероятностью, т.к. никакой.
#A1A1A1 - это 434324343243432, а #C2C2C2 - 1234342343423433 (в "импульсной" нотации).
И, кстати, обнаружил, что в дисках TR-DOS индексный маркер (который с кодом #C2) попросту не используется в ходе форматирования. Пока не нашёл дисков с #C2.
Нарисовал картинку для более наглядного представляения всех этих стандартных полей формата.
https://volutar.eu5.org/raw_fdd_track.png
Все тайминговые артифакты (промежутки между импульсами, сильно отличающиеся от стандартных 4/6/8нс) приходятся на момент начала записи сектора (конец секции Gap2), и окончания записи сектора (начало секции Gap3/Gap4b), а после CRC нередко болтается мусор - остатки предыдущих CRC кодов, или даже хвостики предыдущих секторов, если скорость вращения была сильно меньше стандартной 300об/с. Оттого совершенно не странно что #4E после секторов превращаются во что-то другое.
Впрочем, эти упражнения с рисованием не сильно прояснили, почему двоичная последовательность 9ти бит "000101001" (в MFM - это последовательность 23433) вызывает сбивку синхронизации в ходе readtrack.
А всё оказалось просто.
#C2 в MFM:
0101001010100100
Синхро-версия #C2:
0101001000100100
MFM-последовательность байта #29 с предшествующим битом 0:
1010010001001001
Видно, что это - на 1 бит сдвинутая влево версия #C2. Т.е., получается, что в ходе чтения (и сдвига) оно в определенных обстоятельствах может стать тем самым синхро-кодом #C2!
Проблема синхро-кода #C2 в том, что он не содержит внутри себя уникальной последовательности 434, и является по сути "открытым", опирающимся на соседние байты. Начинается с 0 и заканчивается 0, т.е. не завершён, и только в соседстве с самим собой он становится полноценной симметричной версией #A1, чтобы, как и задуман, использоваться в трёх экземплярах. В одиночку он не даёт уникальную MFM последовательность 434 (которая в полной мере присутствует в синхрокоде #A1). И если бы синхронизация в чипе шла не по одиночному #C2, а по серии, хотя бы #C2C2, то такая последовательность была бы неповторимой в любых других комбинациях байтов.
Но, к сожалению, синхро-код #C2 в своей двоичной форме неуникален (однако, создаёт уникальную комбинацию в связке со следующим байтом, имеющим 1 в 7м разряде).
Эта же проблема присутствует и в WD1772, и во множестве других контролеров. Обойти это какими-то ухищрениями может и можно, но тут я информацией не владею.
Добавка:
Кстати, если бы разработчики формата вместо синхро-кода #C2 взяли бы и стали использовать #85, таких бы проблем не было:
0100101010010001 - MFM код #85
0100100010010001 - синхро-код #85 (отсутствующий 4й тактовый бит)
раз пошла такая пьянка, кто-то в курсе правильной логики работы команды прерывания D0 - DF ?
судя по тому что я вижу на схемках wd1772 и ВГ93, INTRQ взводится:
- в процессе выполнения команд
- если была получена команда Dx, по тактовому сигналу F1 (или /F1) по битам I0-3 может/будет взводиться INTRQ, снова и снова, пока не будет получена какая-то другая команда.
условия очистки INTRQ:
- запись в регистр команд
- чтение регистра статуса
всё так или я чего недопонял или где-то ошибся ?
еще остается вопрос с сигналом F1 - я не разобрался что это и как он получается с тактовой, лишь вижу что еще и зависит от входа DDEN (плотности), какой там делитель ?
1. И ВГ-93, и MB8877A читают дорожку ОДИНАКОВО! Следовательно, никакого дефекта в ВГ-93 нету, либо он есть и в MB8877A.
2. Данные секторов при чтении дорожки целиком правильно читаются ЧАСТИЧНО, порядка 56-60 байт, остальное - мусор. Т.о., чтение дорожки подходит только для того, чтобы узнать её структуру, и прочитать данные с помощью команды чтения сектора. Так работает, например, программа "Unrecognized Formatting Object" от ALK/Stars of Keladan.
3. Дорожка может не читаться (мусор вместо синхрополей и данных) из-за дефекта дисковода.
4. Вангую, что, всё-таки, дело в особенностях контроллера НГМД, потому что, например, Амига читает дорожку целиком, и потом софтово парсит МЧМ-данные, а, значит эти МЧМ поступают правильно, иначе бы ничего не работало.
Оборудование:
ЭВМ:
ZX-EVO/TS-Labs config
Контроллеры НГМД:
1) КР1818ВГ93, Квантор, 9206;
2) КР1818ВГ93, Квантор, 9302;
3) КР1818ВГ93, Квазар, 9404;
4) MB8877A с "пропилом";
5) MB8877A без "пропила";
НГМД:
1) 5.25" Epson SD-600;
2) 5.25" Copal F505-6-383B;
3) 3.5" SAMSUNG SFD-321B, rev.T5 (не умеет читать дорожку целиком);
4) 3.5" SAMSUNG SFD-321B, rev.T4, адаптирован под Амигу;
5) 3.5" Nec G7FTZ 1-2 243-650385-1-2 CAV3, адаптирован под Амигу;