Просмотр полной версии : К1818ВГ93
В книге “ZX Spectrum & TR-DOS для пользователей и программистов” на стр. 209 есть такой абзац:
“Чтение дорожки 11100e00
Эта команда считывает с дорожки всю имеющуюся на ней информацию, включая поля пробелов, заголовков и служебные байты. В силу некоторых аппаратных особенностей Beta Disk’а при выполнении этой команды происходит потеря синхронизации данных микроконтроллером. Таким образом, использовать команду затруднительно.”
Кто может подсказать что это “аппаратные особенности”?
если ты только отформатировал дорожку, но ничего на нее не писал, то она считается нормально...
а вот при записи сектора его начало не попадает (вернее чаще всего не попадает) точно на границу между двумя байтами записанными при форматировании и когда ты пытаешься прочесть всю дорожку, то сектор записанный со смещением даже в пол бита уже не прочитается правильно...
Возможно, я ошибусь (давно было дело), но устройство разделения данных (или как его еще называли, «ФАПЧ») производит «низкоуровневую» синхронизацию и выделение данных, вне зависимости от того, какие операции выполняет ВГ93 (чтение сектора или дорожки). Поэтому аппаратные особенности тут не при чем.
Скорее дело в том, что при чтении дорожки в ВГ93 не отключается детектор адресного маркера AM. И соответственно данные, совпадающие с форматом AM, интерпретируются именно таковыми (а не просто последовательностью байт в поле данных). Эта «особенность» ВГ-шки делала крайне сложным чтение дорожки, например, при попытке копирования «бит в бит». У других контроллеров, в частности у 8272, была возможность отключения детектора АМ при чтении дорожки.
4 Lion17
То что ты рассказал это уже следствие проблемы, а мне хотелось бы знать первопричину?
Ну я так понимаю, если команда заложена в WD1793, то она должна работать. И в принципе проблема в недоработанности сепаратора данных в схеме оригинального BDI и его клонах. А как решить данную проблему, или точнее, чем базовая схема включения WD1793 отличается от BDI?
Вообще, мне MSXовцы говорили, что у них абсолютно такой же контроллер флопа. И там чтение дорожки замечательно работает.
если ты только отформатировал дорожку, но ничего на нее не писал, то она считается нормально...
Отформатировать дорожку, ничего на нее не записывая, нельзя. При форматировании происходит также и запись данных.
Или ты имеешь в виду, что дорожка с одними нулями в области данных читается нормально?
Отформатировать дорожку, ничего на нее не записывая, нельзя. При форматировании происходит также и запись данных.
Или ты имеешь в виду, что дорожка с одними нулями в области данных читается нормально?
Нет я имел ввиду что после команды форматирования (записи дорожки) не было команд записи сектора.
4 Lion17
То что ты рассказал это уже следствие проблемы, а мне хотелось бы знать первопричину?
Ну я так понимаю, если команда заложена в WD1793, то она должна работать. И в принципе проблема в недоработанности сепаратора данных в схеме оригинального BDI и его клонах. А как решить данную проблему, или точнее, чем базовая схема включения WD1793 отличается от BDI?
Причина в том что при записи сектора его начало не попадает точно на границу между байтами. Почему она не попадает на границу - виноват ли сам котроллер, либо виновата конкретная реализация интерфеса, либо софт, я не знаю.
Команда есть и она работает - она считывает дорожку полностью. Есть команда записи дорожки, обратная команда чтение дорожки, если использовать только их все будет отлично работать (за исключением того что нельзя будет записывать служебные байты). Так же есть команды записи и чтения сектора (это более высокий уровень), они тоже работают. А вот смешивать запись высокого уровня (сектор), с чтением низкого уровня (дорожки) не получается.
Возможно, я ошибусь (давно было дело), но устройство разделения данных (или как его еще называли, «ФАПЧ») производит «низкоуровневую» синхронизацию и выделение данных, вне зависимости от того, какие операции выполняет ВГ93 (чтение сектора или дорожки). Поэтому аппаратные особенности тут не при чем.
Скорее дело в том, что при чтении дорожки в ВГ93 не отключается детектор адресного маркера AM. И соответственно данные, совпадающие с форматом AM, интерпретируются именно таковыми (а не просто последовательностью байт в поле данных). Эта «особенность» ВГ-шки делала крайне сложным чтение дорожки, например, при попытке копирования «бит в бит». У других контроллеров, в частности у 8272, была возможность отключения детектора АМ при чтении дорожки.
По моему причина как раз обратная - в том что при чтении дорожки детекторы адресных маркеров отключаются. Как известно при записи маркеров на диск пишется байт с пропущенными синхроимпульсами, и по этому факту при чтении сектора контроллер точно вычисляет границу байта записанной информации. А вот при чтении дорожки он считывает всю дорожку как один массив битов и смещенные сектора читаются совсем не так как должны. Если вдруг случайно записанный сектор попал на границу байта, то он считывается отлично вместе с адресными маркерами.
По моему причина как раз обратная - в том что при чтении дорожки детекторы адресных маркеров отключаются.Почитайте внимательно на стр.13 приведенного описания, про чтение дорожки.
Как известно при записи маркеров на диск пишется байт с пропущенными синхроимпульсами, и по этому факту при чтении сектора контроллер точно вычисляет границу байта записанной информации.И при записи сектора тоже.
А вот при чтении дорожки он считывает всю дорожку как один массив битов и смещенные сектора читаются совсем не так как должны.опять же посмотрите внимательно в описание, там сказано совсем другое.
Если вдруг случайно записанный сектор попал на границу байта, то он считывается отлично вместе с адресными маркерами."Случайно" записать такое невозможно, при записи сектора контроллер предварительно синхронизируется с данными в его заголовке. Отклонения строго нормированы. Если отклонения превышены, то это сбой.
насколко мне помнитса на 525 дискетах любая проблема с чтением
фиксировалас либо хорошей читалкой с фазовой автоподстройкой
либо уменшением длителности маркерного сигнала ( часть маркерного отверствия дискеты акуратно заклеивалас примерно на половину)
на маленких дисководах такой проблемы не встречал
Скорее дело в том, что при чтении дорожки в ВГ93 не отключается детектор адресного маркера AM. И соответственно данные, совпадающие с форматом AM, интерпретируются именно таковыми (а не просто последовательностью байт в поле данных).
Ту доку которую ты кинул, я изучал очень подробно когда писал эмулятор ВГ93. Данных совпадающих с форматом AM не может быть потому что только в адресных маркерах исключаются синхро-импульсы. Байты A1 и C2 которые встречаются среди данных не будут приняты за АМ, так как при их записи нет пропущенных синхроимпульсов.
Ту доку которую ты кинул, я изучал очень подробно когда писал эмулятор ВГ93. Данных совпадающих с форматом AM не может быть потому что только в адресных маркерах исключаются синхро-импульсы. Байты A1 и C2 которые встречаются среди данных не будут приняты за АМ, так как при их записи нет пропущенных синхроимпульсов.
Изначально вопрос был о рассинхронизации, при чтении дорожки, не так ли? При этом не шла речь, каким образом записана, отформатирована (или не отформатирована) дорожка. Записать обычной командой записи сектора, AM в его данные, разумеется, нельзя, об этом никто и не говорил. Но дорожка может быть отформатирована нестандартно, плохо читаться, или быть отформатированной наполовину. CRC, насколько я помню, при чтении дорожки не контролируется, а случайное (или умышленное) попадание последовательности аналогичной AM в поле данных, вполне возможно.
У меня чтото устойчивое подозрение что это глюки чисто отечественного характера! Кто нить юзал буржуйские аналоги вместо нашего?
Кстати какие они буржуйские аналоги существуют, я например знаю следующие:
WD1793
FD1793
MB8876/MB8877
WD2793 (вроде со встроенными цепями прекомпенсации)
Да, глюки чисто отечественные, только не в логике работы ВГ93, (которая в принципе не может отличаться от аналогов по топологии кристалла - WD1793), а в ее обвеске. Посмотрите на первые схемы отечественных Beta Disk, на их упрощенный сепаратор данных. Вспомните, какие были дисководы, и какое было качество дискет. Постарайтесь найти контроллеры, в которых реализовано несколько времен предкомпенсации (TR43) при записи. Добавьте к этому не всегда качественные блоки питания, наводки от мониторов на неэкранированные дисководы, плохо настроенные и сбоящие компьютеры. И картина станет более полной.
P.S. Тема началась с весьма неточных (правильнее сказать ошибочных) слов о том, что при чтении дорожки вся информация, включая служебную, считывается. А по факту это не так, вот и решили авторы что, мол, это кривое железо.
P.P.S. Если интересно, могу закинуть описание подключения WD1793 (схемы сепараторов там есть) и описание WD2793 (более полно и толково описаны команды, в том числе и чтение дорожки).
Да, глюки чисто отечественные, только не в логике работы ВГ93, (которая в принципе не может отличаться от аналогов по топологии кристалла - WD1793), а в ее обвеске. Посмотрите на первые схемы отечественных Beta Disk, на их упрощенный сепаратор данных. Вспомните, какие были дисководы, и какое было качество дискет. Постарайтесь найти контроллеры, в которых реализовано несколько времен предкомпенсации (TR43) при записи. Добавьте к этому не всегда качественные блоки питания, наводки от мониторов на неэкранированные дисководы, плохо настроенные и сбоящие компьютеры. И картина станет более полной.
А есть ли специальный чип обвески для WD1793 (наверняка ведь есть)? Костя может ты его марку знаешь и схему подсоединения?
А есть ли специальный чип обвески для WD1793 (наверняка ведь есть)? Костя может ты его марку знаешь и схему подсоединения?Есть WD1691 (и схема в аттачменте), но толку от него мало, ибо ему обвески самому надо очень много. Старье это все, конца 70-х. В начале 90-х еще можно было на это ориентироваться, а сейчас наверняка можно подобрать контроллер совместимый с WD1793, только включающий часть обвески (если я правильно понял намек на ATM-3).
Есть WD1691 (и схема в аттачменте), но толку от него мало, ибо ему обвески самому надо очень много. Старье это все, конца 70-х. В начале 90-х еще можно было на это ориентироваться, а сейчас наверняка можно подобрать контроллер совместимый с WD1793, только включающий часть обвески (если я правильно понял намек на ATM-3).
Именно для АТМ3! Или хотя бы сделать скажем на ПЛМ, очень грамотную обвеску с поддержкой режима 1.44!
кр1818вг93 очень хорош своей стоимостью, поэтому его менять как то не хочется!
deathsoft
03.06.2005, 19:11
а сейчас наверняка можно подобрать контроллер совместимый с WD1793
Был такойже древний контроллер WD2793 и его аналог от Texas Instrumens, который был полностью совместим с WD1793 но включал в себя аналоговый сепаратор данных и требовал снаружи только RC фильтр. Если интересует, моги кинуть даташит. Проблема в том, что на сегодня достать его видимо будет очень сложно, т.к. это раритет.
Был такойже древний контроллер WD2793 и его аналог от Texas Instrumens
У него есть и отечественный аналог вроде Т34ВГ2
Даташит на бочку! Если это так то очень рулез!
У меня даташита нету.
информацию взял из каталога Сектор электронных компонентов россия-99/Додека/1999
Максагор
04.06.2005, 01:01
Да, глюки чисто отечественные, только не в логике работы ВГ93, (которая в принципе не может отличаться от аналогов по топологии кристалла - WD1793), а в ее обвеске. Посмотрите на первые схемы отечественных Beta Disk, на их упрощенный сепаратор данных. Вспомните, какие были дисководы, и какое было качество дискет. Постарайтесь найти контроллеры, в которых реализовано несколько времен предкомпенсации (TR43) при записи. Добавьте к этому не всегда качественные блоки питания, наводки от мониторов на неэкранированные дисководы, плохо настроенные и сбоящие компьютеры. И картина станет более полной
Я в этом мало чт смыслю, поэтому если то, за вопрос не корите сильно? я так понял, что на более новых контроллерах с ФАПЧ и с современными 3.5" (или, на худой конец,5.25" от TEAC) рассинхронизации по команде "чтение дорожки" быть не должно?
Тема ушла от первоначального вопроса. А хотелось бы все-таки выяснить, почему "использовать команду затруднительно"?
Быть может для разрешения данного вопроса могла бы помочь достаточно интересная и познавательная статья о контроллерах дисководов http://zx.pk.ru/showthread.php?t=556. Если бы удалось ее найти.
Несколько лет назад, я пытался самостоятельно разрешить данный вопрос. До конца дело не дошло, но удалось выяснить, что при использовании данной команды имеет место срыв синхронизации, но информация считывается по четкому алгоритму. Выяснить алгоритм не удалось. Я считаю, что если-бы сепаратор данных перестраивался при встрече AM,а он как известно отличается по синхропоследовательности, то все работало бы нормально.
а может вы тогда эмулятор ВГшки на AVRе напишете, а ;)
а чего - воткнул такое вместо штатной ВГ, и ни проблем с +12, сразу сделать прошивку под чтение 1.44мб, вычистить все глюки ВГшки ;)
Тема ушла от первоначального вопроса. А хотелось бы все-таки выяснить, почему "использовать команду затруднительно"? Я считаю, что если-бы сепаратор данных перестраивался при встрече AM,а он как известно отличается по синхропоследовательности, то все работало бы нормально.
Подумайте вот над чем: Есть ли разница для сепаратора данных, какую операцию чтения выполняет ВГ93, сектора или трека?
А еще попробуйте записать в поле данных значение 29h а затем считать этот трек. Думаю, результаты будут интересны всем.
Подумайте вот над чем: Есть ли разница для сепаратора данных, какую операцию чтения выполняет ВГ93, сектора или трека?
А еще попробуйте записать в поле данных значение 29h а затем считать этот трек. Думаю, результаты будут интересны всем.
Кстати, может быть наконец мне кто объяснит - отличается ли формат записи адресных маркеров у ВГшки от обычных одноимённых байтов или нет? Т.е. эти байты с т.з. MFM записываются как и все остальные - или есть разница (в чём?)?
отличается ли формат записи адресных маркеров у ВГшки от обычных одноимённых байтов или нет?Отличается.
Т.е. эти байты с т.з. MFM записываются как и все остальные - или есть разница (в чём?)?Разница в том, что в A1 пропущен синхроимпульс между 4 и 5 битами, а в C2 между 3 и 4 битами (стр. 14 выложенного ранее описания (http://zx.pk.ru/showpost.php?p=15113&postcount=10)). Относительно этих "дырок" ВГ93 (не сепаратор!) находит границы между байтами.
Подумайте вот над чем: Есть ли разница для сепаратора данных, какую операцию чтения выполняет ВГ93, сектора или трека?
Вопрос конечно интересный. Но, по тому как контроллер работает видимо имеет. Возможно весь фокус в том, что при чтении трека ВГ93 все байты интерпретирует одинаково, не обращая внимания на их функциональное назначение, а при чтении дорожки интерпретация выполняется как положенно. Соответственно в режиме чтения дорожки сепаратор должен приводить все байты в единообразный формат - вставлять пропущенный синхроимпульс.
Вот только вопрос как это работало в оригинальном BDI остается открытым.
А еще попробуйте записать в поле данных значение 29h а затем считать этот трек. Думаю, результаты будут интересны всем.
А можно поинтересоваться, чем обоснован выбор именно этого значения?
Вопрос конечно интересный. Но, по тому как контроллер работает видимо имеет. Возможно весь фокус в том, что при чтении трека ВГ93 все байты интерпретирует одинаково, не обращая внимания на их функциональное назначение, а при чтении дорожки интерпретация выполняется как положенно. Соответственно в режиме чтения дорожки сепаратор должен приводить все байты в единообразный формат - вставлять пропущенный синхроимпульс.Это напоминает "веру в темные силы электричества": сепаратор подключен своими выходами ко входам ВГ-шки и даже теоретически не может управляться ею. Никакие пропущенные биты он так же не может вставлять, там простейший сдвиговой регистр. Да и не работало бы тогда ничего, ибо ВГ именно по этим пропущенным битам синхронизируется.
Вот только вопрос как это работало в оригинальном BDI остается открытым.Аналогично своему клону: там был простейший цифровой сепаратор, с которого и скопировали, схему для первых отечественных контроллерах Beta.
А можно поинтересоваться, чем обоснован выбор именно этого значения?Проведенными ранее испытаниями, результаты которых сохранились. Однако хочется, что бы кто-то этот результат проверил на своем контроллере.
Это напоминает "веру в темные силы электричества": сепаратор подключен своими выходами ко входам ВГ-шки и даже теоретически не может управляться ею.
Не согласен. К сожалению сейчас нет под рукой русскоязычной документации по ВГ93. Но помнится в FDC был вывод, кажется RSTB, назначение которого в принципе остается загадкой, так как в документации ничего вразумительного сказанного не было. А ведь он для чего то нужен, и кажется именно для этого.
Не согласен. К сожалению сейчас нет под рукой русскоязычной документации по ВГ93. Но помнится в FDC был вывод, кажется RSTB, назначение которого в принципе остается загадкой, так как в документации ничего вразумительного сказанного не было. А ведь он для чего то нужен, и кажется именно для этого.
Мы говорим о реальных схемах контроллеров и особенностях их работы, не так ли? В существующих схемах управление невозможно, даже теоретически.
Да, можно изменить схему и задействовать управление сепаратором RG(READGATE - 25 вывод ВГ93). На нем возникает высокий уровень, когда ВГ считывает поле единиц или нолей. Для аналогового сепаратора с ФАПЧ этот сигнал может использоваться, а для цифрового… скажите зачем? Гораздо правильнее задействовать /VFOE(вывод 33), как рекомендовано производителем (см. вложение).
Мы говорим о реальных схемах контроллеров и особенностях их работы, не так ли? В существующих схемах управление невозможно, даже теоретически.
Я лично пытаюсь найти ответ на вопрос, что в реальной схеме не так, и как сделать новую схему так, чтобы все оно работало.
Я лично пытаюсь найти ответ на вопрос, что в реальной схеме не так, и как сделать новую схему так, чтобы все оно работало.
Я кстати тоже очень интересуюсь этим моментом!
И еще чтение 1.44 (НД дискет)!
Нужно для будущей реализации последнего видимо спека :)
Я лично пытаюсь найти ответ на вопрос, что в реальной схеме не так,Тогда согласитесь, что для реальных схем управление сепаратором невозможно.
и как сделать новую схему так, чтобы все оно работало.Для этого надо понять, что именно и где "не работает". Если ошибка внутри ВГ93, то "плясать" вокруг обвески - бессмысленно.
Тогда согласитесь, что для реальных схем управление сепаратором невозможно.Для этого надо понять, что именно и где "не работает".Если ошибка внутри ВГ93, то "плясать" вокруг обвески - бессмысленно.
Согласен. Но, думаю в ВГ93 ошибки нет, если конечно правда то, что говорит Sonic. Но вот найти схем контроллеров дисководов MSX не удалось.
Согласен. Но, думаю в ВГ93 ошибки нет, если конечно правда то, что говорит Sonic. Но вот найти схем контроллеров дисководов MSX не удалось.Про чтение дорожки на MSX (внимательно прочитайте подчеркнутое):
Read Track
Upon receipt of the Read Track command, the head is loaded, and the busy status bit is set. Reading starts with the leading edge of the first encountered index pulse and continues until the next index pulse. All gap, header, and data bytes are assembled and transferred to the data register and DRQ's are generated for each byte. The accumulation of bytes is synchronized to each address mark encountered. An interrupt is generated at the completion of the command. The ID Address Mark, ID field, ID CRC bytes, DAM, Data and Data CRC bytes for each sector will be correct. The gap bytes may be read incorrectly during write-splice time because of synchronization.
Источник:
http://www.work.de/nocash/portar.htm#fdcdescription
а может вы тогда эмулятор ВГшки на AVRе напишете, а ;)
Начать можно и с эмулятора дисковода просто! Интересно, аттини2313 на 20 мгц потянет кодирование и декодирование инфы для/от ВГшки?
Начать можно и с эмулятора дисковода просто! Интересно, аттини2313 на 20 мгц потянет кодирование и декодирование инфы для/от ВГшки?
Ну если со всей обвеской бы уместилось - т.е. это было бы интересно! Жалко я по ВГ не специалист :)
Ну если со всей обвеской бы уместилось - т.е. это было бы интересно! Жалко я по ВГ не специалист :)
Дык я ж говорю про эмуляцию дисковода =), а не вгшки. Т.е. девайс цепляется на шлейф вместо дисковода.
А вообще сэмулить ВГшку ещё проще, наверное. Главное - разобраться, как её безваитово =) подцепить по тем же портам, что и реальная...
Да, можно изменить схему и задействовать управление сепаратором RG (READ GATE - 25 вывод ВГ93). На нем возникает высокий уровень, когда ВГ считывает поле единиц или нолей.Посмотрел в описании ВГ-шки про сигнал RG. Увы, но для даже для синхронизации аналогово сепаратора он не подходит: при чтении дорожки он неактивен.
Дык я ж говорю про эмуляцию дисковода =), а не вгшки. Т.е. девайс цепляется на шлейф вместо дисковода.
ну и нафига ?
А эмуляция дисковода+ВГ еще проще чем просто ВГ!
Там же нет глобальной задачи реального времени по отслеживанию потока с флоповода со всякими там ФАПЧ синхронизациями. а поток этот для 1.44мб, ~600 кбит/с (для 720к, ~250 кбит/с)...
А если флоп виртуальный - знай себе только обращения Z80 обрабатывай, с FDI-образа.
кстати тоже очень интересуюсь этим моментом!
И еще чтение 1.44 (НД дискет)!
Нужно для будущей реализации последнего видимо спека
сам я с 1.44 не эксперементировал, но вроде схемы такие есть. были также слухи об успешной реализации такого контроллера в недрах (c)Nemo :) который должен был выйти в составе мультикарты (вроде бы)hdd + fdd1.44 + rtc...
Делать "чтоб было правильно" - в принципе не нужно. отработанное решение на ВГ93 вполне себя оправдывает - дискеты и так уже отмирают. Но с точки зрения "как интереснее" заэмулить ВГ93 (а еще лучше вместе с внешним сепаратором - вплоть до разъема дисковода) весьма неплохая задачка ;) и результат ее решения тоже достаточно универсален в применении.
ну и нафига ?
Как нафига? Чтобы в амижные игры гамать дискетные. Чтобы на спеке ездыки дисковода не слушать и не носиться с 3 живыми 3.5" дискетами туда-сюда, скидывая их в трд и обратно. Чтоб коллекцию гам прямо с флешки юзать.
А эмуляция дисковода+ВГ еще проще чем просто ВГ!
И чё - в плату вместо ВГ втыкается? Все остальные варианты с перелопачиванием половины спека - всадд =)
Там же нет глобальной задачи реального времени по отслеживанию потока с флоповода со всякими там ФАПЧ синхронизациями. а поток этот для 1.44мб, ~600 кбит/с (для 720к, ~250 кбит/с)...
А если флоп виртуальный - знай себе только обращения Z80 обрабатывай, с FDI-образа.
Теоретик блин =)
были также слухи об успешной реализации такого контроллера в недрах (c)Nemo :) который должен был выйти в составе мультикарты (вроде бы)hdd + fdd1.44 + rtc...Интересно, а что бы делали с этим контроллером "счастливые" владельцы изуродованных (переделанных Немо из 1,44 в 720) 3,5-дюймовых дисководов?
Интересно, а что бы делали с этим контроллером "счастливые" владельцы изуродованных (переделанных Немо из 1,44 в 720) 3,5-дюймовых дисководов?
А разве 1.44 3.5" дисководы надо переделывать в 720? У меня на спеке 1.44 работает без всяких переделок... Или ты имеешь в виду, чтобы он (дисковод) не требовал заклейку дырок на дискетах, которые незаклеенными означают, что дискета 1.44 ?
Посмотрел в описании ВГ-шки про сигнал RG. Увы, но для даже для синхронизации аналогово сепаратора он не подходит: при чтении дорожки он неактивен.
А нам вобще-то это и нужно! Нужен сигнал который будет переключать режим работы сепаратора в зависимости от выполняемой команды. Когда читаем сектор сепаратор работает как и обычно, а когда читаем дорожку вставляем синхробиты в метки C2 и A1. Может я конечно заблуждаюсь, но по моему так.
В противном случае зачем тогда вобще нужен этот сигнал (RG или RSTB, кому как угодно)?
А разве 1.44 3.5" дисководы надо переделывать в 720? У меня на спеке 1.44 работает без всяких переделок... Или ты имеешь в виду, чтобы он (дисковод) не требовал заклейку дырок на дискетах, которые незаклеенными означают, что дискета 1.44 ?Нет, я вот об этом:
Open Letter #40:
4). Поставляемые [Nemo] дисководы (как 5.25", так и 3.5") принудительно, аппаратно устанавливаются в режим 720 Кб посредством аппаратной переделки.
(С) Nemo
А нам вобще-то это и нужно! Нужен сигнал который будет переключать режим работы сепаратора в зависимости от выполняемой команды.
Я наверно плохой рассказчик. Посмотрите в описании ВГ93 (ранее в теме), там есть описание событий (чтение поля нулей или единиц), когда этот сигнал активизируется (за исключением выполнения команд чтении дорожки).
Когда читаем сектор сепаратор работает как и обычно, а когда читаем дорожку вставляем синхробиты в метки C2 и A1. Может я конечно заблуждаюсь, но по моему так.
Это невозможно. Подумайте вот над чем: Как ВГ93 узнает, что в потоке читаемых бит есть байты? И тогда вы поймете назначение адресных меток или байт с пропущенными битами (C2 и А1). А так же поймете, что будет если пропущенные синхробиты «вставить». А так же оцените сложность такого хм… «контроллера обработки потока данных».
В противном случае зачем тогда вобще нужен этот сигнал (RG или RSTB, кому как угодно)?
Наверно Western Digital, тоже так подумал: зачем? И убрал его в следующих версиях контроллеров. :) Если серьезно, то в присоединенной файле (кстати, добыл специально для вас и с большим трудом), приведена схема сепаратора, где этот сигнал задействован. Если разберетесь, какую функцию он там выполняет, и расскажете, думаю, всем будет интересно.
Нет, я вот об этом:
Open Letter #40:
4). Поставляемые [Nemo] дисководы (как 5.25", так и 3.5") принудительно, аппаратно устанавливаются в режим 720 Кб посредством аппаратной переделки.
(С) Nemo
Видимо Немо на дисководе фотодиод замазывал чем нить :)
Люди, а кто знает зачем разработчик схемы HD-FDD (не помню ника) вводил сигнал с микрика - детектора плотности записи в схему контроллера? В принципе же в PC в этом нет необходимости. Я хоть алгоритм детектирования диска и не видел, но насколько понимаю работает это приблизительно так:
1. По умолчанию считаем, что диск высокой плотности (HD) и переключаем схему контроллера на работу с HD.
2. Если считать с диска информацию за N попыток не удалось, переключаем схему на DD.
3. Если считать данные опять не удалось, считаем, что диск не отформатирован и выдаем сообщение об ошибке.
Стоит ли ради такого нехитрого подхода курочить дисковод?
Люди, а кто знает зачем разработчик схемы HD-FDD (не помню ника) вводил сигнал с микрика - детектора плотности записи в схему контроллера?
отвечаю как соавтор (автор оригинальной схемы AXLR). в версии автора было совсем наоборот - микриком управлял сам контроллер (бит 7 порта #FF), что мне показалось не совсем правильным и не интересным и я сделал что контроллер переключался на нужные частоты в зависимости от выбранного дисковода (у меня HD включался только на 3,5") и вставленной дискеты. Предложеный Вами вариант конечно имеет право на существование, но вот только, если речь идет о моей статье в Adventurer#12, то там все задумывалось для реализации прозрачной поддержки. Т.е. в первую очередь не перешивать TRDOS и совместимость со старыми программами. Как например в предложенном Вами варианте запустить с HD диска какую-нибудь игрушку, использующую точку #3D13 (естественно она переделана давным давно и ее исправлять нельзя).
Люди, а кто знает зачем разработчик схемы HD-FDD (не помню ника) вводил сигнал с микрика - детектора плотности записи в схему контроллера? В принципе же в PC в этом нет необходимости. Я хоть алгоритм детектирования диска и не видел, но насколько понимаю работает это приблизительно так:
1. По умолчанию считаем, что диск высокой плотности (HD) и переключаем схему контроллера на работу с HD.
2. Если считать с диска информацию за N попыток не удалось, переключаем схему на DD.
3. Если считать данные опять не удалось, считаем, что диск не отформатирован и выдаем сообщение об ошибке.
Стоит ли ради такого нехитрого подхода курочить дисковод?
Могу ошибаться, но по-моему в PC как раз использовался стандартный путь переключения: через детектор (микрик или оптопару) в дисководе. Ничего курочить не при этом не надо. По крайней мере это внесено в спецификацию (в присоединенном файле описание 3'5-дюймового дисковода TEAC, пункт: 8.3.13).
Отличается.
Разница в том, что в A1 пропущен синхроимпульс между 4 и 5 битами, а в C2 между 3 и 4 битами (стр. 14 выложенного ранее описания (http://zx.pk.ru/showpost.php?p=15113&postcount=10)). Относительно этих "дырок" ВГ93 (не сепаратор!) находит границы между байтами.
То есть #A1 обычно кодируется как #44A9, а в случае пропуска - как #4489 ? (единица - наличие импульса, ноль - отсутствие)
Могу ошибаться, но по-моему в PC как раз использовался стандартный путь переключения: через детектор (микрик или оптопару) в дисководе. Ничего курочить не при этом не надо. По крайней мере это внесено в спецификацию (в присоединенном файле описание 3'5-дюймового дисковода TEAC, пункт: 8.3.13).
Кстати, а раз скорость вращения 3.5" не меняется в зависимости от заклеенности дырки на дискете, то почему же тогда дискеты с дыркой (под HD) после записи на спеке либо не читаются, либо читается один сектор из 10 (проверялось FUT'ом)?
Кстати, а раз скорость вращения 3.5" не меняется в зависимости от заклеенности дырки на дискете, то почему же тогда дискеты с дыркой (под HD) после записи на спеке либо не читаются, либо читается один сектор из 10 (проверялось FUT'ом)?
Может здесь играет роль другой метод записи для HD.
Может здесь играет роль другой метод записи для HD.
Какой же он другой, когда простым турбированием вгшки и сопутствующих потр(о|а)хов получается чтение и запись хд дисков на удвоенной скорости! =)
Там чего-то с аналогой схемой в дисковёрте видимо намудрено, медленная мфм (со скоростью как для ДД) то ли криво пишется, то ли криво читается, то ли и то и другое сразу - в хд-режиме.
То есть #A1 обычно кодируется как #44A9, а в случае пропуска - как #4489 ? (единица - наличие импульса, ноль - отсутствие)
А откуда взялись два байта вместо одного при кодироке (MFM)? В случае пропуска синхроимпульса при MFM кодировании, на границе двух нулей или нуля и единицы это уже не "0", вместо "1", а "дыра" в потоке.
Может здесь играет роль другой метод записи для HD.Скорее причина в аналоговой части дисковода (изменение параметров фильтрации и как следствие амплитудно-фазовые искажения). Не даром в спецификации дисковода, для HD рекомендовано максимально время предкомпенсации, при записи.
[color=black]А откуда взялись два байта вместо одного при кодироке (MFM)?
Это 16 бит, каждый из которых соответствует наличию или отсутствию импульса. Каждому исходному биту (из байта) соответствуют 2 места для импульсов, которые либо вообще отсутствуют (0 после 1), либо занимают одно из этих мест.
Это 16 бит, каждый из которых соответствует наличию или отсутствию импульса. Каждому исходному биту (из байта) соответствуют 2 места для импульсов, которые либо вообще отсутствуют (0 после 1), либо занимают одно из этих мест.А это стандартная система обозначения? Я не нашел ее описания в присоединенном документе...
А это стандартная система обозначения? Я не нашел ее описания в присоединенном документе...
http://lclevy.club.fr/adflib/adf_info.html
Именно в таком виде читается с дискеток инфа там =) Да и пишется, впрочем, тоже =)
http://lclevy.club.fr/adflib/adf_info.html
Именно в таком виде читается с дискеток инфа там =) Да и пишется, впрочем, тоже =)Там это где, в формате .ADF? В приведенной ссылке (в пункте 2.1) показана условная схема кодирования MFM (для того, что бы был понятен принцип). Кроме того, там не преобразуют биты в байты, иначе потеряется наглядность. И это конечно интересно все, но к теме (А1) не относится...
Если уж говорить про физический уровень (дискета), то там переходы между участками различной намагниченности, преобразуются (аналоговой схемой дисковода) в те самые синхробиты. И наоборот (см. описание дисковода пункт 8.3.15). Никаких промежуточных перекодирований не производится.
Видимо Немо на дисководе фотодиод замазывал чем нить :)
скорее всего :-)у меня например 5в дисковод 3.5 fujitsu так там даже optopari нету просто кнопка маленкая , я ее замкнул :-)вот и вся аппаратная переделка :-)тепер дискеты заклеивать ненадо Ч-)
Тема опять зашла в тупик. Может ли кто из владельцев реальных Speccy пролить свет на такой простой вопрос как чтение дорожки, у которой в секторе записано значение 29h?
Объясню, зачем это надо: как сказано в первом сообщении этого топика, в книге Ларченко и Родионова говорится о том, что у контроллеров Beta в силу аппаратных особенностей происходит рассинхронизация, при чтении дорожки. Однако если рассинхронизация будет происходить при чтении дорожки строго в определенном месте (при чтении значения 29h), то речь идет о внутренней ошибке в ВГ93. Очень хочется поставить точку в этом вопросе. Сам я провести данные изыскания не могу, нет рабочей машины под рукой, у Spensor-а так же проблемы с железом. Поэтому те, у кого есть возможность и желание провести данное изыскание, смело смогут называть себя первооткрывателями «багов» в ВГ93.
Что нужно: На отформатированную TR-DOS дискету, записать файл длинной 256 байт, в котором в строго фиксированном месте (где-то в середине) будет единственное значение 29h. Затем, используя команду чтения дорожки, считать этот трек (где записан файл) и убедиться в том, что данные после числа 29h искажены, либо не искажены. Далее поделиться результатом с общественностью, не забыв указать, какой тип контроллера (какой компьютер) использовался для этого эксперимента.
да, подтверждаю. в затёртом 2002-м году alco мне присылал дампы дорожек и прочую инфу по контроллеру. на дорожках были сектора со всеми байтами подряд (#00-#FF) и случайные сектора. я очень удивился, почему в обоих случаях именно после #29 идёт мусор. причём на следующем секторе синхронизация восстанавливается
сейчас достал дампы и проанализировал именно на рассинхронизацию. дополнения:
1. сбой на #29 иногда не происходит (редко).
2. очень вероятен сбой на #14, особенно если перед ним стоит байт >= #80
(а ведь похожий битовый узор, #14*2+1 = #29) кто-б ещё подсказал порядок битов, используется lbs или msb first?
2. очень вероятен сбой на #14, особенно если перед ним стоит байт >= #80
Очень интересное наблюдение. Сам при изучении данного вопроса сталкивался именно с этим траблом, но мне почему то запомнились только числа #14 и #80. Уже не помню подробностей, но именно такие байты и вызывали сбой синхронизации. Эксперементы проводились на самопальном контроллере дисковода, сделанного по схеме Nemo.
кто-б ещё подсказал порядок битов, используется lbs или msb first?lbs first
Кстати, на диаграмме в описании это тоже есть.
deathsoft
15.06.2005, 15:41
Что нужно: На отформатированную TR-DOS дискету, записать файл длинной 256 байт, в котором в строго фиксированном месте (где-то в середине) будет единственное значение 29h. Затем, используя команду чтения дорожки, считать этот трек (где записан файл) и убедиться в том, что данные после числа 29h искажены, либо не искажены.
Надо будет проверить. У меня есть рабочий скорп (там контроллер с цифровым сепаратором ФАПЧ на РТ4 (скопирован с оригинального)). Проблема в том, что комп некуда подключить (надо попробовать подключить к TV тюнеру в компе через ч.б. полный видео сигнал). Есть ли у кого прога, которая делает чтение дорожки и скидывает результат в файл? Или самому писать придется?
В дискусии с lvd был задан вопрос:
А это стандартная система обозначения? Я не нашел ее описания в присоединенном документе...
Вот ответ на него: http://en.wikipedia.org/wiki/Modified_Frequency_Modulation
В дискусии с lvd был задан вопрос:
Вот ответ на него: http://en.wikipedia.org/wiki/Modified_Frequency_Modulation Спасибо, за точную и конкретную информацию.
Кстати нашел ответ о назначении сигнала RSTB (RG)
Но помнится в FDC был вывод, кажется RSTB, назначение которого в принципе остается загадкой, так как в документации ничего вразумительного сказанного не было.
179X Application Notes 2
If the Data Separator requires synchronization during a known pattern of one's or zero's, then RG (READ GATE) can be used. The RG signal will go active when the 179X is currently over a field of zeros or ones. RG is not available on the 1795/1797 devices, since this signal was replaced with the SSO (Side Select Output) Line.
Как выянилась последовательность импульсов A1 с пропущенным синхроимпульсом не такая уж уникальная:
A1 = 10100001 = 0100010010101001
~A1 = 10100001 = 0100010010001001 (это с пропуском)
предположим что VG93 думает что это байт A1 если встречает:
10010001001
я построил все последовательности от 0 до 255 (при условии что перед ними байт заканчивался 0 битом)
вот такие байты отвечают этому ключу:
14 1010100100010010
28 1010010001001010
29 1010010001001001
50 1001000100101010
51 1001000100101001
52 1001000100100100
53 1001000100100101
94 0100100100010010
Как видим среди этих кодов старые знакомые - 14 и 29
естественно есть еще последовательности для байт последний бит перед которым был не 0, а 1, а также пары байт на пересечении которых будет встречаться эта последовательность.
При чтении секторов вслед за этой последовательностью сразу адресная метка заголовка либо данных если она найдена, то детектирование отключается. А при чтении трека при встрече в данных нужной последовательности вг сбивается с границ байтов и т.д.
В итоге можно заключить, что прав был Conan. И сбой синхронизации особенность вг93. Из-за того, что в качестве синхронизирующей была избрана неуникальная последовательность. Вот если бы выбрали последовательность в которой встречаются 4 нуля подряд (что нереально в MFM коде), дорожки бы читались без проблем :)
Есть ли у кого прога, которая делает чтение дорожки и скидывает результат в файл? Или самому писать придется?
Могу предложить для эксперементов прогу, которой пользовался сам.
Как выянилась последовательность импульсов A1 с пропущенным синхроимпульсом не такая уж уникальная:
A1 = 10100001 = 0100010010101001Спасибо Владимир, за толковое объяснение! Занимаясь изучением этого вопроса (15 лет назад), дальше нахождения числа 29h я продвигаться не стал, потому как команда чтения дорожки с таким «дефектом» практического интереса уже не представляла.
сбой синхронизации особенность вг93. Из-за того, что в качестве синхронизирующей была избрана неуникальная последовательность. Вот если бы выбрали последовательность в которой встречаются 4 нуля подряд (что нереально в MFM коде), дорожки бы читались без проблем :)Другим решением этой проблемы было бы отключение детектора адресной метки, после ее первого нахождения и синхронизации. Но, увы, ошибка запечатлена на кристаллах WD1793 и скопирована в наши КР1818ВГ93 навечно.
Хотелось бы поделиться еще некоторым «сокровенным знанием» по контроллерам Beta Disk:
1. Предкомпенсация при записи. Сначала несколько слов, зачем вообще она нужна. У большинства современных дисководов, угловая скорость носителя одинакова, а линейная различается, уменьшаясь от нулевой (внешней) дорожки к внутренним. Поскольку с уменьшением линейной скорости, увеличивается линейная плотность записи, это ухудшает амплитудно-частотные (и как следствие фазовые) характеристики записи-чтения на внутренних дорожках. Фактически для MFM это приводит к усреднению скважности (фазы) импульсов, а значит к большей вероятности ошибки. Искажения зависят так же от типа дисковода и качества магнитного материала носителя (дискеты). Для компенсации этих искажений, при записи на внутренних дорожках импульсы в MFM последовательности смещают, увеличивая расстояние между ними при переходе из «0» в «1» и из «1» в «0». Для управления смешением используются сигналы SL (Shift Left) и SR (Shift Right) контроллера ВГ93. Разделением дорожек на внешние и внутренние управляет сигнал TR43 (Track 43). Оптимальное время сдвига импульсов (предкомпенсации), зависит от типа дисковода и носителя. Как показала практика, время предкомпенсации 250нс является оптимальным для отечественных дисководов и носителей 5,25. В тоже время для дисководов 3,5 рекомендуется предкомпенсация 125нс.
Теперь о реалиях жизни. Некоторые разработчики отечественных клонов, просто не использовали схем предкомпенсации (ZX-777), наверно для экономии элементов. А некоторые включали предкомпенсацию 250нс всегда, не используя сигнал TR43 (KAY 256-1024). Большинство же контроллеров ограничивались одним временем 250нс управляемым сигналом TR43. Единственной схемой использующей два времени предкомпенсации (125/250нс) является контроллер дисковода для ZX-Next.
2. Так же часто разработчики отечественных Speccy забывали задействовать сигнал WF/DE, разрешающий поступление данных в сепаратор при чтении (рекомендация в описании WD179x).
3. Reset. На контроллерах Beta, где порт #FF аппаратно «обнуляется», при системном Reset, в режиме 128К (без инициализации TR-DOS) нажатие Magic может привести к порче диска. Это происходит из-за инициализации ВГ93 при «отпускании» Reset, во время обработки процедуры NMI в ПЗУ TR-DOS. Проблема решается просто: Reset ВГ93 (вывод 19) отсоединяется от выхода порта #FF и подключается к системному Reset.
P.S. Конечно все вышесказанное представляет сейчас больше теоретический интерес, но возможно будет кому-то интересным, как ответы на вопросы, о причинах тех или иных проблем.
Но, увы, ошибка запечатлена на кристаллах WD1793 и скопирована в наши КР1818ВГ93 навечно.
Подождите, а стоит ли говорить столь категорично. Было ли где-нибудь упоминание в зарубежных источниках о глюке в микросхеме. Может это и не глюк вовсе, или глюк отечественной микросхемы?
Подождите, а стоит ли говорить столь категорично. Было ли где-нибудь упоминание в зарубежных источниках о глюке в микросхеме. Может это и не глюк вовсе, или глюк отечественной микросхемы?
А сколько еще ждать, пока подобные контроллеры вымрут как вид ;) ? С битовыми последовательностями работает внутренняя логика ВГ93, и если ошибка возникает именно при их обработке, то где еще может быть причина?
Что касается WD1793, в моем древнем «Пентагон 48» стоял именно он. При проведении изысканий, разумеется, тестировались и наши КР1818ВГ93. Результат был одинаковым.
P.S. Микросхемы копировались переносом накристальной топологии, при этом никаких изменений в логику работы даже теоретически внесено быть не может.
С битовыми последовательностями работает внутренняя логика ВГ93, и если ошибка возникает именно при их обработке, то где еще может быть причина?
Согласен, но где bug report? Ведь WD1793 использовалась во многих компах (MSX, TRS-80) и неужели никто не столкнулся с данной проблемой? Они что, из принципа не пользовались данной командой? А как дела обстояли в более раних WD (WD1771, WD1773), ведь и они применялись на Spectrum-FDC? Неужели "жук" всплыл именно на этом чипе? И надо-же быть такими невезучими, чтобы глючный чип скопировать. Что то уж очень это все подозрительно!
И еще один вопрос - кто может перечислить всех "родственников" ВГ93? Имеются ввиду чипы с родственной системой команд.
Согласен, но где bug report? Ведь WD1793 использовалась во многих компах (MSX, TRS-80) и неужели никто не столкнулся с данной проблемой?Вполне возможно bug reports были, только Western Digital их вряд ли афишировала, да и найти их будет очень нелегко, прошло 25 лет, отсканированные описания самого контроллера и то редкость, а уж такая специфичная информация и подавно.
Они что, из принципа не пользовались данной командой?А разве хоть одна DOS под WD1793 штатно использует эту команду?
А как дела обстояли в более раних WD (WD1771, WD1773), ведь и они применялись на Spectrum-FDC? Неужели "жук" всплыл именно на этом чипе?Влад, можно всю жизнь заниматься исследованием ошибок допущенных при разработке различных микросхем, но какое отношение это имеет к проблеме топика? Например в i8272, насколько я помню, команда чтения дорожки работает нормально, и что нам с этого?
И надо-же быть такими невезучими, чтобы глючный чип скопировать. Что то уж очень это все подозрительно!
А причем тут везение или невезение? Копировали, элементную базу, а про то как ее использовать и как выполняются команды думали совсем другие люди. Например, в ГДР скопировали Z80, и что можно программно отличить UB880 от оригинала? Кстати Z80 на порядки более распространен нежели WD1793, так вот много ли фирменных описаний, где подробно рассказано обо всех неопубликованных командах? А об отличиях CMOS от NMOS версий Z80 можно, где ни будь почитать на английском? А ведь и те и другие ставились в ZX-Spectrum, и работали по-разному. Иными словами отсутствие информации в данном случае – не аргумент, а вот реальные проблемы с реальными микросхемами WD1793 (ВГ93) – факт.
можно всю жизнь заниматься исследованием ошибок допущенных при разработке различных микросхем, но какое отношение это имеет к проблеме топика? Например в i8272, насколько я помню, команда чтения дорожки работает нормально, и что нам с этого?
Все WD родственны между собой, и с большой долей вероятности их внутренние цепи совпадают, а соответственно bug должен проявляться и в других чипах. А до i8272 нам в общем-то дела нет.
А разве хоть одна DOS под WD1793 штатно использует эту команду?
Ну, а внешний софт разве никогда по это дело не писался?
А причем тут везение или невезение?
Как причем? Взять первый попавшийся чип и именно в нем должен был оказаться "жук". Тогда наверное многие WD должны быть с этим глюком. Но почему-то зарубежные пользователи других FDC на WD о подобных фокусах никогда не высказывались.
Как было сказанно выше "сбой на #29 иногда не происходит (редко)", а почему он не происходит? Может есть способ так построить сепаратор, что этот внутренний глюк будет скомпенсирован. Что это возможно подтверждает сообщение Sonic. Люди у кого есть MSX с фирменным контроллером и имеется возможность проверить команду чтения дорожки помогите пожалуйста разобраться в данном вопросе!
Все WD родственны между собой, и с большой долей вероятности их внутренние цепи совпадают, а соответственно bug должен проявляться и в других чипах. А до i8272 нам в общем-то дела нет.Кристаллы, топология и внутренние цепи у разных контроллеров различны. Внутренняя логика может быть сходной, а может и отличаться. Возможно, и в других FDC от WD есть подобные ошибки.
Ну, а внешний софт разве никогда по это дело не писался?Да писался, 25 лет назад Mr. Pumpkin писал кривой копировщик, в котором эта команда не заработала. И что было дальше? А дальше он подумал и решил, что это кривой контроллер дисковода и появились те же слова в книжке Родионова и Ларченко. Но только вот и без этой команды все великолепно обходились и обходятся. Тема слишком узкая и специфичная.
Как причем? Взять первый попавшийся чип и именно в нем должен был оказаться "жук". Тогда наверное многие WD должны быть с этим глюком.Не бачу логики. В первом скопированном микропроцессоре К580ИК80 были все те же ошибки, что и в родном i8080. Ах, как не везло отечественным копировщикам, что ни микросхема, то с "жуком", не находите? Просто злой рок, какой то. Наверно буржуины нарошно в них "жуки" встраивали!
Но почему-то зарубежные пользователи других FDC на WD о подобных фокусах никогда не высказывались.Ссылку на описание проблемы при чтении дорожки у MSX я уже приводил выше в этом топике.
Как было сказанно выше "сбой на #29 иногда не происходит (редко)", а почему он не происходит? Может есть способ так построить сепаратор, что этот внутренний глюк будет скомпенсирован.Сепаратор не имеет никакого отношения к внутренней логике побайтовой синхронизации ВГ93, и управлять ею не может. Впрочем, можете продолжать верить в чудеса.
Сепаратор не имеет никакого отношения к внутренней логике побайтовой синхронизации ВГ93, и управлять ею не может. Впрочем, можете продолжать верить в чудеса.
Может это конечно и чудеса, но ведь хоть и "редко", но чудеса происходят. Возможно фишка в том, какой байт шел до этого, а может быть - на какой фазовый сдвиг пришелся перепад импульса. Если последнее верно, то глюк устраним...
Провел дополнительные исследования:
проверил все 9 битные последовательности (512)
~A1=0100010010001001
xx0001001000xxxx - уникальна
xx000100100xxxxx,
x1000100100xxxxx,
01000100100xxxxx - встречаются 32 раза (включая 029,129)
xxx001001000xxxx,
xxx0010010001xxx - 32 раза (вкл. 129)
xxx00100100010xx - 24 раза (вкл. 129)
xxx001001000100x - 12 раз (вкл. 129)
xxx0010010001001 - 4 раза (вкл. 129)
xxxx010010001001 - 12 раз (вкл. 14,29,114,129)
xxxxx10010001001 - 20 раз (вкл. 14,29,114,129)
Под известную информацию попадают только две последних.
Но синхронизация должна обрываться при каждой встрече x29,
хотелось бы посмотреть на дампы чтения дорожек (с оригинальными
секторами), тогда можно было бы сказать более конкретно.
полный список последней последовательности:
Analize sample: 10010001001
014 101010100100010010
028 101010010001001010
029 101010010001001001
050 101001000100101010
051 101001000100101001
052 101001000100100100
053 101001000100100101
094 100100100100010010
0A0 100100010010101010
0A1 100100010010101001
0A2 100100010010100100
0A3 100100010010100101
0A4 100100010010010010
0A5 100100010010010001
0A6 100100010010010100
0A7 100100010010010101
114 010010100100010010
128 010010010001001010
129 010010010001001001
194 010100100100010010
Found 20/512
жалько я раньше тему не видел
Тем не менее, сам я пробовал сделать копировщик трек в трек, будучи начитавшись книжек про TRDOS и прямое управление ВГ93 (особенно толковый пример был в ZX Review 95 номер не помню, кажется 4).
Так вот, после записи дорожки я делал её контрольное считывание и имелись следующие результаты:
Контроллер ВГ93 САМ подстраивает синхронизацию после встречи управляющих меток (A1, C2). Это выливается в тот факт, что начало сектора (в среднем приблизительно 100 байт) считывается на ура (не проверялось специально с значениями 29, хотя вообще информация писалась совершенно разная). Далее происходит указанный сбой сихнхронизации (в битовом потоке, не в байтовом, появляются "лишние" биты), вероятность их возникновения одинаковая, однако возникают они вообще говоря где попало, поэтому КОРРЕКТНО восстановить информацию по считанной дорожке НЕ УДАВАЛОСЬ.
Т.о. если записать информацию на дискету (скажем оссмысленный текст), потом считать её командой чтения дорожки, то где то на 100м символе текста будет происходить абраказябривание текста.
На самом деле, при использовании команды записи дорожки и записи последовательностей совпадающих с управляющими метками, контроллер интерпретирует эти значения не как данные, что и выливается в то, что с самого начала НЕЛЬЗЯ записать дорожку целиком с произвольными данными, т.е. вначале надо отформатировать дорожку (просто запись дорожки) а только затем поверх писать сектора.
Значения 29 (условно его можно назвать магическим числом) я так понял в битовом представлении совпадает со смещённой меткой сектора, поэтому при попытке записать дорожку с таким значением (или с любым из значений ряда, представленного выше), происходит аналогичный сброс контрольной суммы, и ВГ начинает писать НОВЫЙ сектор, соответственно закрывая его контрольной суммой и т.д.
Я попытаюсь дома проверить указанные значения на своём Scorpion, потом доложу о том, как оно работает.
Т.о. мусор, который появляется при чтении затем такой дорожки с магическим числом УЖЕ ЗАПИСАН на дорожке, а не появляется в процессе собственно чтения.
Т.о. мусор, который появляется при чтении затем такой дорожки с магическим числом УЖЕ ЗАПИСАН на дорожке, а не появляется в процессе собственно чтения.
Вы наверно невнимательно читали предыдущие сообщения в топике, иначе не было бы так удивительно, почему этот «мусор» оказывается совершенно нормальной информацией, при чтении сектора тем же контроллером на ВГ93.:eek:
И еще более удивительно то, что эта же дорожка, совсем без «мусора» считывается в имидж копировщиком на PC.;)
P.S. Давайте уважать друг друга, и внимательно читать, что пишут другие. Если не понятно, переспрашивать. Иначе в каждом новом сообщении мы будем опять "открывать Америку". :(
#29 не сбивает синхронизацию, если установлен старший бит предыдущего байта. кому интересно посмотреть на дампы дорожек самостоятельно - вот они
Быть может для разрешения данного вопроса могла бы помочь достаточно интересная и познавательная статья о контроллерах дисководов http://zx.pk.ru/showthread.php?t=556. Если бы удалось ее найти.
Несколько лет назад, я пытался самостоятельно разрешить данный вопрос. До конца дело не дошло, но удалось выяснить, что при использовании данной команды имеет место срыв синхронизации, но информация считывается по четкому алгоритму. Выяснить алгоритм не удалось. Я считаю, что если-бы сепаратор данных перестраивался при встрече AM,а он как известно отличается по синхропоследовательности, то все работало бы нормально.
Чудом смог от сканировать журнал "Радиолюбитель. Ваш компьютер" :) статью “Контроллер дисковода. Канал чтения”
к сожалению в статье не хватает журнала №7 за 1998, может у кого нибудь есть
номера 7,11,12 этого чудного журнала за 1998 ?
http://zx.pk.ru/showthread.php?t=556
deathsoft
26.06.2005, 17:19
Провел тест на "магические числа", читал дорожку (командой чтения дорожки, прогой которую кидали в этот топик) первый сектор которой содержал 32 байта 0xAA в среди которых один байт заменялся на 0x29 ил 0x14, результат был один и тотже:
вместо байта 0x29 или 0x14 читалось всегда 0x14 а после шли нули (хотя должны были идти 0xAA), если вместо 0x29 записать 0x55 то все читается как надо.
Возник вот какой вопрос (прежде всего к уважаемым Lion17 и SMT). Поскольку с «загадочным» явлением вроде как разобрались, возможно ли использовать результаты практически? То есть, реально ли доработать существующие эмуляторы, что бы они эмулировали такую особенность ВГ93 как «сбои при чтении дорожки»?
обычно ВГшки выпускались в закрытом корпусе, но мне попадались модели с двумя овальными отверстиями в которых видна плата с дорожками - для чего ?????
обычно ВГшки выпускались в закрытом корпусе, но мне попадались модели с двумя овальными отверстиями в которых видна плата с дорожками - для чего ?????
Это экономили на пластмассе! Такие обязательно надо лаком закрашивать - а то гниют они быстро!
Я не технолог (в отличие от CHRV :wink: ), но когда-то задавался аналогичным вопросом о цели «отверстий» и «разломов» на больших корпусах ИМС. Как мне объяснили, это делалось для термокомпенсации при использовании не очень качественных смол, из которых делали корпуса микросхем. Такое решение снижало нагрузку на кристалл и разварку, возникающую при нагреве и охлаждении. Разумеется, при этом так же снижалась прочность самих корпусов и требовалась защита для оголившихся проводников (то о чем говорил Роман).
Поскольку с «загадочным» явлением вроде как разобрались, возможно ли использовать результаты практически? То есть, реально ли доработать существующие эмуляторы, что бы они эмулировали такую особенность ВГ93 как «сбои при чтении дорожки»? а смысл? HDD, MODEM, теперь ещё это... лишние навески только, никому не нужные, или нужные раз в два года, посмотреть на чудо-программу и положить её обратно на полку
а смысл?
Если это сложно и точность эмуляции не имеет значения (в данном случае), тогда конечно смысла нет: пусть остается «сокровенным знанием» и способом делать игры только для реальных машин.
Conan: как только пойдут игры, в эмулях появится поддержка, как ни крути. вариант как защита отпадает
А есть ли специальный чип обвески для WD1793 (наверняка ведь есть)? Костя может ты его марку знаешь и схему подсоединения?Случайно наткнулся на SED9420C – DATA SEPARATOR для FDD. Насколько он редкий или дорогой не знаю, но с ВГ93 совместим и внешней обвески минимум. Описание прилагаю, может пригодится в хозяйстве.
Вчера захотел начать надругательства над своим ZX-777, который пролежал в кладовке 7 лет. Так вот включил его, чтобы проверить работает он еще или нет - работает, но! :confused:
Дискетку вставляю, а TRDOS пишет, что ее нет. И так со всеми. Думаю с дисководом что случилось - поставил на PC - там дисковод работает.
Так вот что характерно, дисковод не "хрюкает" когда начинает нулевой трек искать. Такой глюк уже был, но это было давно и я не помню в чем дело.
Шлейф тоже в порядке. Замена ВГ93 результата не дало. Кто нить подскажет, в чем заключается проблема. :o
Вчера захотел начать надругательства над своим ZX-777, который пролежал в кладовке 7 лет. Так вот включил его, чтобы проверить работает он еще или нет - работает, но! :confused:
Дискетку вставляю, а TRDOS пишет, что ее нет. И так со всеми. Думаю с дисководом что случилось - поставил на PC - там дисковод работает.
Так вот что характерно, дисковод не "хрюкает" когда начинает нулевой трек искать. Такой глюк уже был, но это было давно и я не помню в чем дело.
Шлейф тоже в порядке. Замена ВГ93 результата не дало. Кто нить подскажет, в чем заключается проблема. :o
ПО умолчанию ПЦ дисковод установленный как "А" виден на спектруме как "B". И еще если не "хрюкает" проверить наличие 12в.
ПО умолчанию ПЦ дисковод установленный как "А" виден на спектруме как "B". И еще если не "хрюкает" проверить наличие 12в.
+12В есть - дисковод крутит привод диска. Дисковод и шлейф не менял - раньше он работал.
Вчера захотел начать надругательства над своим ZX-777, который пролежал в кладовке 7 лет. Так вот включил его, чтобы проверить работает он еще или нет - работает, но! :confused:
Дискетку вставляю, а TRDOS пишет, что ее нет. И так со всеми. Думаю с дисководом что случилось - поставил на PC - там дисковод работает.
Так вот что характерно, дисковод не "хрюкает" когда начинает нулевой трек искать. Такой глюк уже был, но это было давно и я не помню в чем дело.
Шлейф тоже в порядке. Замена ВГ93 результата не дало. Кто нить подскажет, в чем заключается проблема. :o
На PC дисководы устанавливаются с ID1 и далее переворачивание шлейфа делает его нулевым. Осмелюсь предположить, что если он заработал на пц имеет место неверно установленная ID перемычка.
На PC дисководы устанавливаются с ID1 и далее переворачивание шлейфа делает его нулевым. Осмелюсь предположить, что если он заработал на пц имеет место неверно установленная ID перемычка.
Да нет причина, до банальноси проста - гробанные резисторы на дисководе. Дисковод я передергивал на PC и про них забыл. А потом вспомнил - заработал. Ну и вопрос исчерпался сам собой.
deathsoft
03.02.2007, 13:29
Например в i8272, насколько я помню, команда чтения дорожки работает нормально, и что нам с этого?
Как оказалось - нет, при чтении дорожки командой "чтение дорожки" на i8272 происходят сбои синхронизации после поля GAP следующего за данными сектора (межсекторным пробелом), при этом адресный маркер следующего сектора читается неверно (все байты искажены), также происходит второй сбой синхронизации на границе адресного маркера сектора и поля данных сектора (где идет поле синхронизации из 12 нулей).
Данная ошибка принципиально отличается от того что происходит на ВГ93, т.к. на i8272 сбой синхронизации не зависит от данных в секторе, а происходит всегда на границе секторов, причем синхронизация может восстанавливаться через несколько секторов.
Из-за чего именно происходит сбой синхронизации необходимо выяснять отдельно, похоже, что вместо импульсов данных за данные контроллер принимает импульсы синхронизации (сдвиг на пол битового интервала).
У меня несколько раз были такие ситуации (не знаю, имеют ли они отношения к этой теме): после записи на дискету, происходил сдвиг таблицы файлов на один байт. И диск, конечно, переставал читаться tr-dos'ом. Но, загрузив любой редактор дисков, и сдвинув таблицу файлов на место, можно было все вернуть в зад.
deathsoft
04.02.2007, 17:01
У меня несколько раз были такие ситуации (не знаю, имеют ли они отношения к этой теме): после записи на дискету, происходил сдвиг таблицы файлов на один байт. И диск, конечно, переставал читаться tr-dos'ом. Но, загрузив любой редактор дисков, и сдвинув таблицу файлов на место, можно было все вернуть в зад.
Это совсем нето. Тут речь идет о сдвиге на половину БИТОВОГО интервала. А не байта.
MegaMyth
06.02.2007, 18:02
Насколько он редкий или дорогой не знаю
Скорее всего редкий, т.к. датащит сканеный, и в описании написано 5/25 и 8 дюймов... Ктонить ваще держал в руках 8ми дюймовый диск???
Southern Bear
06.02.2007, 18:40
Конечно держал. И даже активно пользовался.
deathsoft
06.02.2007, 20:19
Ктонить ваще держал в руках 8ми дюймовый диск???
У меня дома валяется в шкафу. Выглядит как 5.25", только размером с пол листа A4
Интересная тема, хоть и заброшенная уже. В своё время тоже натолкнулся на такую проблему с чтением дорожки. Вот сейчас поразмыслил над этим обсуждением и пришла мысль, что возможно нет там никакой ошибки и всё сделано "как надо". Проектировали же, как вы говорите, "буржуи" и для "буржуев". А у них там с незаконным копированием строго. Вот может и предназначена команда чтения дорожки только для проверки форматирования. Отформатировал - прочитал нормально. А после записи данных в сектора не прочитаешь верно. Хорошая возможность для защит, что и использовалось вроде как. Это всё мои предположения для оживления темы. :D
s_kosorev
30.08.2019, 10:51
2 сообщение (первый ответ) в этой теме, дает 100% правильный ответ, нет никакой магии или защит от копирования
дает 100% правильный ответ
Голову на отсечение даёшь, если ты не прав? А то я склоняюсь к верности про неотключение адресного маркёра. Про магию не понял.
http://info-coach.fr/atari/hardware/FD-Hard.php#False_Sync_Byte_Pattern
"Проблема в декодировании битов в байты, на этапе когда происходит
отбрасывание клоковых битов, (каждая mfm кодируется парой битов), так
вот, если происходит смещение на один бит из этой пары (на пол бита
данных), то вместо битов данных в байты начинают переводится биты клоков
и получается мусор. А проблема с C2 возникает из за того, что паттерн C2
при смещении на пол бита совпадает с паттерном данных типа 0x18 и т.п."
2 сообщение (первый ответ) в этой теме, дает 100% правильный ответ, нет никакой магии или защит от копирования
Ответ Conan'а верный, третий в этой теме.
s_kosorev
30.08.2019, 22:35
Абсолютно неверный, ВГ не может писать в то же место, так ка для это нужны следующие допущения
1. Дисковод очень равномерно крутит диск
2. Диск имеет очень жесткую структуру и не подлежит деформациям
3. Кварцевые резонаторы очень точный
Все пункты чушь, ответ Conan, который основан на не верной точке отсчета, тоже чушь
А про АМ, так читается тот маркер который на диске, а не тот который при форматировании Fx како то вызывает запись A2/C2 или как их там
А первый ответ четко и ясно, ВГ не пишет бит в бит, к тому же, что бы писать правильно битики, нужно знать последний бит предыдушего байта, так как от этого зависит ка нужно начинать писать
- - - Добавлено - - -
Голову на отсечение даёшь, если ты не прав? А то я склоняюсь к верности про неотключение адресного маркёра. Про магию не понял.
Склоняться мож как угодно, а микруха на 5тыс транзюков не в силах всякие DRM через 40 лет изобретенные юзать
- - - Добавлено - - -
Если бы адресный маркер был отключам, была бы на порядок хуже каша
Все пункты чушь, ответ Conan, который основан на не верной точке отсчета, тоже чушь
Какой ты категоричный)))
Я делал защиты, основанные на этом эффекте еще в 1995 году)
Даже делал версию игры StreetFighter, в которой не было секторов вовсе, а была одна сплошная дорожка, записываемая разом, никакой рассинхронизации из-за смещения бит там не было и быть не могло.
Разумеется, я прекрасно знал, из-за какой комбинации бит идет сбой контроллера, и просто напросто не использовал ее, потому вся дорожка читалась идеально.
Но, если тебе нравится своя, параллельная реальность ВГ93, то я спорить не буду)
s_kosorev
30.08.2019, 23:32
Почитай первый ответ. Там четко и ясно описана причина. Рассинхронизация возникает из за повторной записи поверх форматированной дорожки. Все.
- - - Добавлено - - -
Разумеется, я прекрасно знал, из-за какой комбинации бит идет сбой контроллера
Нет никакой комбинации. Есть диск вставлен не 100% как при записи из за этого индексное отверстие на несколько бит пришло раньше или позже.
Смешно же, делать защиты и не понимать как работает дисковод и контроллер.
Хочешь устойчивого чтения при любом положении, используй индексный маркер. Когда его контроллер встретит, на нем он синхронизируется. А комбинацию битов, для синхронизации, невозможно получить никак, кроме спец команда при записи дорожки
Есть диск вставлен не 100% как при записи из за этого индексное отверстие на несколько бит пришло раньше или позже.
Вообще львиная доля контроллеров плевать хотела на индексное отверстие. Оно вообще не особо нужно. На одном дисководе она в одном месте, в другом - немного на другом. Если бы все от индексного зависело, то чужие диски бы почти ни у кого не читались.
А комбинацию битов, для синхронизации, невозможно получить никак, кроме спец команда при записи дорожки
Особая синхро-комбинация битов дешифруется автоматически, все эти MFM sync bytes не видятся дальше микросхемы контроллера. Как и CRC. На уровне взаимодействия с ПО их нет потому что они не нужны. При записи эти "неправильные" синхро-биты вписываются автоматически в ходе raw-write, во время форматирования. Контроллер в последовательности байт выделяет данные, и в них не лезет, а во всех остальных областях байты #C2 / #A1 "награждаются" особым битом (маркеры IAM, IDAM и DAM). При записи отдельных секторов идет идентификация местонахождения сектора, даётся 12 байт #00 (для настройки на скорость - минимальный размер домена - ~4мс), маркер DAM, скармливаются данные сектора. Сразу за этим - два байта CRC.
https://retrocomputing.stackexchange.com/a/7845
Почитай первый ответ. Там четко и ясно описана причина. Рассинхронизация возникает из за повторной записи поверх форматированной дорожки. Все.
Рассинхронизация происходит когда raw-read используется, которому нельзя приказать непрерывно синхронизироваться исключительно по MFM меткам. В итоге при повторной записи домены могут сместиться на полубит, и индексные биты оказываются битами данных и наоборот. При перезаписи отдельных секторов идеального попадания магнитного домена с точностью до полубита - не бывает. А только что отформатированный трек гарантировано будет сихронизирован по первому маркеру.
Чтобы трек всегда читался качественно в raw-виде, необходимо чтобы контроллер мог фоново, непрерывано пересинхронизировать данные встречая синхробиты. Но у ВГ93 этого видимо не происходит (синхронизируются только до первого сектора).
Полагаю, что сами данные формата (коды 4E) по-идее всегда должны быть "в фазе". Как и адресные метки (они не перезаписываются).
s_kosorev
31.08.2019, 01:18
Рассинхронизация происходит когда raw-read используется, которому нельзя приказать синхронизироваться исключительно по MFM меткам. В итоге при повторной записи домены могут сместиться на полубит, и индексные биты оказываются битами данных и наоборот. При перезаписи отдельных секторов идеального попадания магнитного домена с точностью до полубита - не бывает. А только что отформатированный трек гарантировано будет сихронизирован по первому маркеру.
что и написанно в первом ответе? не?
что и написанно в первом ответе? не?
Там написано про индексный маркер (он же - индексное отверстие).
Хочешь устойчивого чтения при любом положении, используй индексный маркер.
От него вообще ничего не зависит.
Речь же про синхро-байты (синхро-маркеры). А не индексные.
А защиты от копирования таки были. В частности - у того же Спектрофона читалась 0я дорожка в raw формате, и в определенном месте, уже за 16 сектором (смещение #1782), где по-идее находится мусор, ищутся определенные байты (#a1,#fb,#53), то есть огрызок 17го сектора, у которого первым байтом стоит #53 ("S").
Такое ощущение, что вы тему не читали вообще, кроме первой страницы)
Советую смотреть тему отсюда https://zx-pk.ru/threads/859-k1818vg93.html?p=16970&viewfull=1#post16970
Lion17 согласился с Conan'ом)
Кстати, собрал немного статистики. Рассинхронизация хорошо заметна по гаповым вставкам (#4E). Порой они превращаются в другие байты - #9C,#21,#27,#90,#48.. В MFM #4E выглядят как [--|--|--|-|-|--] (333223), а остальные - его своеобразные вариации, смещенный влев код MFM на 1, или 2, или вправо на 1, 2, или 3 такта. После CRC, и вначале дорожки, пока синхрокод #A1A1A1 не встретился, но после встречи #A1A1A1 данные снова корректные. И это логично.
Эти области, забитые #4E, и нужны, чтобы поверху записываемые данные секторов имели некоторый геометрический люфт, учитывающий возможную разницу скорости вращения диска. И, соответственно, какая-то сбивка неизбежна, нередко после CRC остается кусок предыдущего CRC, или даже хвостик одной из прошлых версий секторов, записанных на медленной скорости.
Примечательно, что после заголовочной области гап с кодом #4E никогда не сбивается - он прописывается во время форматирования, и больше никогда не трогается.
ЗЫ: Это наблюдения чтения "в идеале", когда сбивки на байте #29 нет.
ЗЗЫ: Lion17 в своих расчётах был не прав. Синхрокод #A1 ни в каком виде нигде больше не повторяется. Он представляет собой последовательность [---|--|---|--|-] (43432)
Обычный #A1 - [---|--|-|-|--|-] (432232)
А #29 - [-|--|---|--|--|] (234331) - длительности 1 не существует, бывают только 2,3 и 4, и единичка всегда присовокупляется к следующей, то есть #292929 = 23433,33433,33433,1... в принципе 33433 отчасти похож на 43432, то есть длительности 4 и 3 достаточно близки, и наверное могли бы спутаться, но это надо еще проверить, прогнать все варианты.
ЗЗЗЫ: Совершенно железобетонно, MFM синхрокод #a1 (43432) никоим образом ни в каких других комбинациях появиться не может. Вообще сочетание (434) невозможно в MFM данных. 343 и 444 - сколько хочешь, а 434 - только в синхрокоде.
защиты от копирования таки были. В частности - у того же Спектрофона читалась 0я дорожка в raw формате, и в определенном месте, уже за 16 сектором (смещение #1782), где по-идее находится мусор, ищутся определенные байты (#a1,#fb,#53), то есть огрызок 17го сектора, у которого первым байтом стоит #53 ("S"). в последних номерах защита была чуток изменена/улучшена. подробностей не помню, вот часть переписки
"Простановка лишнего маркера A1 со сдвигом от нормального положения кроме защиты от копирования на
амиге защищает и от копирования на ВГ93 командой "чтения дорожки", т.к. в этом режиме детектор
адресного маркера всегда включен и неминуемо произойдет синхронизация по второму A1 и вместо 4E
будут декодированы байты 09"
в последних номерах защита была чуток изменена/улучшена.
Я вообще не уверен что эта защита была от Спектрофона. Тут своих умельцев хватало, перепродающих их со своими "защитами".
и неминуемо произойдет синхронизация по второму A1 и вместо 4E
будут декодированы байты 09"
ВГ93, и для процесса чтения абсолютно по барабану какие там байты в GAP-пространствах. А 4E и 09 - это одна и та ж последовательность.
4e4e - |--|--|--|-|-|--|--|--|--|-|-|-- : 333223333223
0909 - |-|-|-|--|--|--|--|-|-|--|--|--| : 2223333223331
А вот если после 4E какие-то важные внесекторные данные идут, тогда их потрековым копированием действительно не возмешь.
http://volutar.myds.me/php/mfm.php?hex=9c9c+2121+4e4e+9090+2727+4848
s_kosorev
31.08.2019, 17:31
Блин фантазеры, для начала, нужно понимать разницу между сбоем синхронизации и синхрониязации но индексной и адресной метке.
Далее, хватит верить в магию
ВГ93 это 16 битный сдвиговый регистр и счетчик битов.
Когда встречается адресный или индексный маркер, счетчик битов сбрасывается, в противном случае счтает по кругу
И при каждом проходе через 0 берет нечетные биты и складывает их в байт, все. Деревянная логика и все ваши фантазии укалываются в работу этого сдвигового регистра это раз, а то что вы не можете понять, начинаете додумывать, воображать свой мирок, это два
А сколько менторства и пафоса...
Будь проще, "гуру".
s_kosorev
31.08.2019, 18:06
Я уже не могу проще. Разве что рисовать
Такое ощущение что ты видишь тут школьников, которые не понимают что из себя представляет ВГ93 и как работает синхронизация по out-of-band кодам.
Вопрос был про то почему сбивка сихронизации на байте #29. И в этом смысле информации 0.
HardWareMan
31.08.2019, 18:17
Dexus, так то он прав. Я помню кучу случаев про NES. Например, однажды господа погромисты с НесДева "пощупали" некий аддон программно и давай разводить демагогию, что как там всё сложно устроено и куча условий надо делать. Целую портянку коллективно написали, там указаны все состояния, которые они смогли обнаружить. Я посмотрел на это непотребство своим взглядом железячника и сказал: никто 25+ лет назад не будет вам так всё усложнять в железе, там всё просто, неполная дешифрация и упрощённый вариант стандартной схемы. И даже от руки нарисовал, чтобы исключить недопонимание и ещё приложил предсказание поведения при тех условиях, которые они не проводили, но которые возможны. Налетели скептики, давай трындеть за свою квалификацию и всё такое, пока один новичок не взял и не прогнал расширенные тесты и всё совпало с моими предсказаниями. Весь гвалд мгновенно переобулся, выдвинули новую портянку на основе моей схемы, которая внезапно была проще в программной реализации и работала быстрее + учитывала все возможные комбинации, т.е. практически 100% повторяла оригинальное железо. Спасибо так никто и не сказал, впрочем как и никто и не извинился.
Я помню кучу случаев про NES
Не относится к делу.
Dexus, так то он прав.
В чём? В том с чем и так никто не спорит?.. Извините, но не увидел причину наличия сбивки после синхрокода #A1 именно на байте #29.
А то что написал Leon17 в сообщении №71 - некорректные доводы.
А то что написал Leon17 в сообщении №71 - некорректные доводы.
Почитай еще отсюда: https://zx-pk.ru/threads/15555-kr1818vg93-iznutri.html?p=373611&viewfull=1#post373611
Почитай еще отсюда:
Да, уточнение про последовательность "000101001". Каким образом оно сбивает синхронизацию-то? У FM нет синхропоследовательностей ЕМНИП. И в этой последовательности даже тайминги не укладываются в допустимые для FM (1,2), они тут (1,3).
ЗЫ: кстати, это код для 0x02C, а не 0x029, и повторяется он каждые 30 значений.
http://volutar.eu5.org/mfmcodes.txt (4мб, таблица 16битная)
Да, уточнение про последовательность "000101001". Каким образом оно сбивает синхронизацию-то? У FM нет синхропоследовательностей ЕМНИП. И в этой последовательности даже тайминги не укладываются в допустимые для FM (1,2), они тут (1,3).
А вот этого я уже не знаю или не помню)
У нас MFM, а не FM.
вот вам схема ВГшки http://dlcorp.nedopc.com/viewtopic.php?f=21&t=1468&start=0&sid=4155d0d00917bab40f19e1b245110ee5
"Схема является полной транзисторной/гейтовой схемой ВГ93 (на ней не отображена только схема ПЗУ, защитные транзисторы и генератор смещения подложки, т.к. схема ПЗУ - стандартная, дамп ПЗУ приведен в отдельном файле).
Все что относится к логике функционирования ВГ93 отображено полностью.
Размер листа со схемой 8.8м x 4.991м (м - метры), поэтому выбирайте те программы просмотра pdf, которые могут отобразить такой лист. Как пишут, adobe acrobat имеет проблемы с отображением листа такого размера, встроенный просмотрщик в chorome(chromium) показывает без проблем, foxit тоже показывает без проблем"
s_kosorev
31.08.2019, 20:05
В чём? В том с чем и так никто не спорит?.. Извините, но не увидел причину наличия сбивки после синхрокода #A1 именно на байте #29.
А то что написал Leon17 в сообщении №71 - некорректные доводы.
#29 не стработает, если в пред байте последние 2 бита были 00
HardWareMan
31.08.2019, 22:15
Размер листа со схемой 8.8м x 4.991м (м - метры), поэтому выбирайте те программы просмотра pdf, которые могут отобразить такой лист. Как пишут, adobe acrobat имеет проблемы с отображением листа такого размера, встроенный просмотрщик в chorome(chromium) показывает без проблем, foxit тоже показывает без проблем"
Это не у Акробата проблемы, а у того, кто создавал PDF. У него есть стандарт и есть те, кто его не поддерживают (специально или случайно). Данный PDF действительно "пуст" если открывать в Акробате Х, но стоит открыть в том же FoxIt'е (который при этом безбожно тормозит и постоянно норовит закрыться) и напечатать в PDF (саму печать я совершал минут 5, т.к. на каждый чих FoxIt перерисовывает туеву хучу объектов этого PDF в масштабе 3%) как всё внезапно нормально работает в Акробат Х, ИЧСХ не тормозит (в отличии от FoxIt'а)!
https://jpegshare.net/images/a1/2e/a12ea99f09f9c68dba7ba3d1fb1c5248.png
...foxit тоже показывает без проблем"
Если жуткие тормоза не считать проблемой, то да, все ОК.
PS Mozilla FireFox тоже открывает исходный PDF норм, только при увеличении все транзисторы сливаются. У Хромого так же?
https://jpegshare.net/images/74/21/74210389609033331b4b0886f6576314.png
- - - Добавлено - - -
PPS Пофикшеная версия PDF, если кому надо. (http://hwm.us.to/ftp/vg93_fixed.pdf)
- - - Добавлено - - -
А вот это может быть интересным:
https://jpegshare.net/images/af/0c/af0c8eb1e3b2707ba64525915a34baca.png
https://jpegshare.net/images/97/94/9794d961d569ab92af80d8101e9e52b9.png
И оба в режиме MFM.
А вот это может быть интересным:
Эти транзисторы в воздухе висят истоками? Т.е. их как бы и нет?
умные люди просили передать
" Умники там, пусть сделают в акробате pdf с линейными размерами как у этой схемы, там несколько метров ширина и высота. В pdf рестрикшены на размеры тянутся с древних времен и ни разу не актуальны, все нормальные вьюеры кроме акробата поддерживают любые размеры по x и y (больше тех что в pdf стандарте). У меня виндовый фоксит не тормозит, ну и акробат с таким числом объектов будет работать точно также, чудес то не бывает, линий там очень много. У чела возможно комп дохлый, на x64 никаких проблем с фокситом нету."
" со сбоем синхронизации существует 3 совершенно не связанные друг с другом проблемы. И каждый пытается доказать свой случай.
Первая проблема - это не уникальный маркер C2 (про который подробно и с картинками написано на сайте про atari), при этом даже если дорожка вся записана за 1 раз будет все равно сбой синхронизации, если такой битовый патерн со сдвигом на пол бита появится в данных. Синхронизация по C2 делается ТОЛЬКО командой чтения дорожки и только на ВГ93 (делается для того, чтобы при чтении дорожки байты от индексного отверстия до первого A1 читались нормально, а не мусором (когда вместо клоков отсеиваются биты данных, а с выхода сдвигового регистра вместо данных идут патерны клоков)).
Вторая проблема (присутствует и на ПЦ на i8272 (про то, что кононас писал, что такого на ПЦ не бывает)) - это проблема с записью секторов поверх отформатированных секторов, там из за непопадания точно в битовую ячейку может быть какой угодно сдвиг, для этого и вводятся GAP байты, но эти GAP байты будут читаться неправильно, т.к. команда чтения дорожки делает синхронизацию по A1 и по C2, а все что записано до A1 (не при форматировании, будет читаться в фазе от A1 предыдущего сектора и естественно может быть мусор, если при записи был сдвиг на пол бита).
Ну и третья проблема - не использование бита 13 в A1 и в C2 (но это может быть и не реальная проблема, а просто протравлено при снятии слоев кислотой, у меня есть только один набор фотографий, т.ч. сравнить не с чем (может еще и брак конкретно этого завода), и в импортной микросхеме WD1772 таких проблем нету, там декодер правильный и все биты используются).
Ну и таки MFM интервалы - это t, 1.5t и 2t (а не 2, 3 и 4)."
s_kosorev
31.08.2019, 23:06
Бит 13 это правильно.
Пара бит 00 в пред байте + #29, дают сигнатуру #A1, если проигнорировать бит 13
Пара бит 00 в пред байте + #29, дают сигнатуру #A1, если проигнорировать бит 13
Каким образом, цепочку всю можешь нарисовать? У меня никаким образом из #A1 не получается #29, ни в bin, ни в mfm, ни при каких сдвигах.
Ну и таки MFM интервалы - это t, 1.5t и 2t (а не 2, 3 и 4)."
Ну это совсем несерьёзный пассаж. К чему тут эти терминологические занудства? При t=2 оно и получится 2 3 и 4, и выбраны они лишь для удобства показа mfm потока как строки.
Ну и третья проблема - не использование бита 13 в A1 и в C2 (но это может быть и не реальная проблема, а просто протравлено при снятии слоев кислотой
Понятно. То есть недостоверно.
Но все-таки сбой с #29 существуют. И высказанные "объяснения" ничего толком не объясняют. Conan высказал что якобы FM ФАПЧ вторгается и переключает кодирование на FM. Каким образом? FM сигнатур-переключателей вроде не существует.
s_kosorev
01.09.2019, 10:27
Каким образом, цепочку всю можешь нарисовать? У меня никаким образом из #A1 не получается #29, ни в bin, ни в mfm, ни при каких сдвигах.
http://prntscr.com/p095w8
Чтобы это сработало не 13й бит должен игнорироваться а 12й. И #14 (1010100100010010) подходил бы еще лучше.
s_kosorev
01.09.2019, 11:26
Чтобы это сработало не 13й бит должен игнорироваться а 12й.
Ну это смотря как считать, с 0 или 1
По схеме там вообще 17 линий. И если считать с 1 (что неверно) этот висячий - 14й.
HardWareMan
01.09.2019, 13:50
Чот грустно, что никто так и не посмотрел схему. Биты там считаются от 0, в выделенном блоке нижние 16 это биты от 0 до 15 (0 - самый нижний), а верхняя линия это выбор режима.
https://jpegshare.net/images/5a/75/5a75eacd8a915b1ac570359d177f6db7.png
https://jpegshare.net/images/bf/f7/bff7059f6384e37d328312b116da9010.png
Ну вот и о том и речь, что 13й бит не делает из #29 синхрокод #A1. 12й бы делал. То есть причина не в этом.
Подцепил к дисководу анализатор, скапчурил вход RDATA. Поток очень даже красиво выглядит, всё прекрасно распознаётся, в том числе синхрокод MFM, и A1, и FB и последующие данные:
http://volutar.eu5.org/rdata1.png
Немного обескуражен тем, что дефолтовое состояние линии - 1ка (4.6в), я думал наоборот должно быть.
Замечу, что как раз в форме 43432 визуально в общей каше было очень легко найти синхрокод. MFM "код" 0x4489 распознать в этой каше, разумеется, нереально.
В нескольких местах промежутки между импульсами отличаются от стандартных 4/6/8мс: в одном месте 3мс, в разных других 10мс, 11мс. Очевидно эти аномальные дистанции как раз попадают на границы перезаписанных секторов.
s_kosorev
20.09.2019, 22:42
Немного обескуражен тем, что дефолтовое состояние линии - 1ка (4.6в), я думал наоборот должно быть.
ОК, пин шаренный между несколькими дисководами
Ну вот и о том и речь, что 13й бит не делает из #29 синхрокод #A1. 12й бы делал. То есть причина не в этом.
Я же нарисовал, игонрирование бита, может в схеме бага.
Полверить легко, последовательность
#0С#29 - сбивается
#0D#29; #0E#29; #0F#29 не должно сбиваться
ОК, пин шаренный между несколькими дисководами
Какими ещё несколькими дисководами? У меня один дисковод. Уровни INDEX и RDATA дефолтово в единичке. И импульсы идут в 0. Длительность INDEX - 3.7мс.
Я же нарисовал, игонрирование бита, может в схеме бага.
Да не важно - это бага в схеме или нет, 13й бит _вообще_ никак не влияет.
Полверить легко, последовательность
Странно, что никто так и не проверил, раз это так легко. Мне писать софт ковыряющий ВГ93 на ZX - лениво. Интереснее в сигналах и кодировании разбираться.
Из инструкции: (http://dmweb.free.fr/files/Atari-Copy-Protection-V1.4.pdf) (стр.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.
HardWareMan
21.09.2019, 06:42
Какими ещё несколькими дисководами? У меня один дисковод. Уровни INDEX и RDATA дефолтово в единичке. И импульсы идут в 0. Длительность INDEX - 3.7мс.
То, что у тебя один дисковод не отменяет того факта, что шина и контроллер рассчитаны на 4 привода на одном шлейфе. И все сигналы действительно по схеме с ОК.
Ковыряясь с интерпретацией MFM потока обнаружил, что синхрокоды "#C2C2C2" и "#A1A1A1" - симметричные. Что означает, что в потоке данных они могут возникнуть с одинаковой вероятностью, т.к. никакой.
#A1A1A1 - это 434324343243432, а #C2C2C2 - 1234342343423433 (в "импульсной" нотации).
И, кстати, обнаружил, что в дисках TR-DOS индексный маркер (который с кодом #C2) попросту не используется в ходе форматирования. Пока не нашёл дисков с #C2.
Нарисовал картинку для более наглядного представляения всех этих стандартных полей формата.
http://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й тактовый бит)
MetalliC
26.09.2019, 17:53
раз пошла такая пьянка, кто-то в курсе правильной логики работы команды прерывания D0 - DF ?
судя по тому что я вижу на схемках wd1772 и ВГ93, INTRQ взводится:
- в процессе выполнения команд
- если была получена команда Dx, по тактовому сигналу F1 (или /F1) по битам I0-3 может/будет взводиться INTRQ, снова и снова, пока не будет получена какая-то другая команда.
условия очистки INTRQ:
- запись в регистр команд
- чтение регистра статуса
всё так или я чего недопонял или где-то ошибся ?
еще остается вопрос с сигналом F1 - я не разобрался что это и как он получается с тактовой, лишь вижу что еще и зависит от входа DDEN (плотности), какой там делитель ?
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot