Просмотр полной версии : Чтение и запись дисков нестандартными способами.
Насчёт использования KryoFlux для чтения дисков FM (MX).
Для раскодирования битов FM в байты нужно синхронизироваться с дорожкой (т.е. определить, какой из принимаемых битов начинает последовательность байта). Контроллер MX использует синхропоследовательность [ 0000000000000000000000000000000011110011] для обозначения границы байта - там (после индекса) где кончаются нулевые биты и начинаются "четыре единицы" ( это при условии, если MX пишет младшие биты первыми, если нет, то синхропоследовательность будет такой: [ 0000000000000000000000000000000011001111] ) - там находится граница байта для всей дорожки.
Это типовая схема ?
KryoFlux сможет сам синхронизироваться с дорожкой MX и раскодировать биты в байты ?
MD оперирует байтами, в отличии от MX. MX оперирирует словамиMY тоже оперирует словами, но пишет и читает их как пару байтов, перворачивая при этом каждый байт "задом на перёд".
А как MX пишет слово?
Как 16 битов подряд или как MY ?
читаемые битики сдвигаются влевоКогда MX пишет слово - какой бит будет записан первым ?
Старший бит старшего байта или старший бит младшего байта ( как у MY ) ?
FM - самосинхронизирующийся метод модуляции. Поэтому теоретически ему не нужна синхропоследовательность.M X специальные синхропоследовательности не использует - с битами он синхронизируется непрерывно. Есму нужна только синхронизация со словами, которая достигается выявлением в сдвиговом регистре первого слова 0363 после индекса.
про использование лог. анализатора. А смысл? Как писал автор MXonPC делается это гораздо более простым кабелёчком. Кстати, MXonPC умеет делать побитовый дамп дорожки.Эмулятор ДВК уже работает (в тестовой конфигурации) с байтовыми образами дорожек и скоро будет работать с битовыми.
Но где все эти реальные битовые и/или байтовые образы дорожек, которые я мог бы "скормить" эмулятору ???
Чем "чисто теоретизировать" - давно бы уже сдампили пару дисков ДВК и Немиги !
Чем "чисто теоретизировать" - давно бы уже сдампили пару дисков ДВК и Немиги !
Опять у Вас какие-то претензии на пустом месте. Наоборот, мне очень интересны Ваши практические опыты с логическим анализатором и ручной раскруткой диска. У меня просто нет на них времени, поэтому я купил KF. Он в пути.
MX оперирует словами!!!!Тогда Вас наверняка не затруднит ответить на простой вопрос:
Когда MX пишет слово - какой бит будет записан первым ?
Старший бит старшего байта или старший бит младшего байта ?
и скоро будет работать с битовыми.
И в каком формате планируете использовать FM битовый образ диска?
Обычно используют по-трековые образы, а как их слепить в образ диска тема не проработана....
Обычно используют по-трековые образы, а как их слепить в образ диска тема не проработана....Ну да, потрековые - я неточно выразился. Побайтовый текстовый TRK-образ эмулирует только один тип записи на всю дорожку ( или вся дорожка FM или вся MFM ), а побитовый MD-образ просто содержит в текстовом виде отсчёты сигнала RDATA с интервалом 1 мкс ( одна текстовая строка, представляющая отсчёты с одной дорожки в виде символов ' ' и '#' занимает в MD-файле 200000 байтов ).
Но где они - эти массивы реальных отсчётов RDATA..
Тогда Вас наверняка не затруднит ответить на простой вопрос:
Когда MX пишет слово - какой бит будет записан первым ?
Старший бит старшего байта или старший бит младшего байта ?
Очень приятно когда тратишь время на написание "многа букав", а тебе не то что спасибо за ответы не скажут, а еще и прочитать эти буквы не хотят.
Я писал "читаемые битики сдвигаются влево". Неужели Вы думаете что при записи последовательность бит не такая как при чтении?
Раз мы при чтении первым читаем старший бит слова, то трудно предположить что при записи мы начнем не с него же.
Причем здесь байты Вы так и не объяснили.
---------- Post added at 21:08 ---------- Previous post was at 21:07 ----------
Но где они - эти массивы реальных отсчётов RDATA..
Опять я Вас не понял. У Вас же есть логический анализатор, Вы его фото показывали. В чем проблема с массивами отсчетов??
И я ведь специально (я бы даже сказал исключительно) для Вас написал что MXonPС умеет делать эти массивы.
Раз мы при чтении первым читаем старший бит слова, то трудно предположить что при записи мы начнем не с него же. Причем здесь байты Вы так и не объяснили.Байты при том, что 1801ВП1-128 тоже пишет и читает сразу целыми словами, но последовательность битов слова при этом выглядит на дорожке так: [ 07 06 05 04 03 02 01 00 15 14 13 12 11 10 09 08 ]. Так же, насколько я понимаю, выглядит последовательность битов слова на дорожке и при его записи контроллером Немиги ( и вообще - большинством контролеров ).
А у MX, значит - всё наоборот и первым пишется не младший байт слова, а старший.
Тогда не буду пока релизить TRK-эмулятор контроллера MX, вдруг это действительно так - надо дождаться реальных FM-дампов.
Это отлично видно из 16 листа паспорта на MX.Точно.
Ведь схема контроллера MX общедоступна - если там сдвиговый регистр без затей укладывает биты слова на дорожку от старшего к младшему - действительно, вариантов быть не может.
---------- Post added at 21:27 ---------- Previous post was at 21:25 ----------
Получается, что при работе с дисками MX - драйвер Немиги попарно меняет байты местами.
Получается, что при работе с дисками MX - драйвер Немиги попарно меняет байты местами.
Как я уже писал в небезизвестной теме (надо уже сокращение придумать, а то как будто ту тему никто не читает), у меня нет MX.sys для Немиги, хотя он точно был в природе.
---------- Post added at 22:49 ---------- Previous post was at 22:45 ----------
Точно..... вариантов быть не может.
Так а я про это и толкую. И очень удивляюсь Вашим вопросам: и в теме все обсуждали, и описания есть, и схемы. А Вы все про какие-то байты....
Прям как Воланд, будто бы я ценнейшую инфу зажал и не хочу делится тем, что на каждом углу написано. При этом вместо "спасибо за Ваши ответы", я получаю "кончай тут писать всякую фигню (о которой тебя только что просили), и бегом дампы делать, при чем чтобы именно логическим анализатором!"
"бегом дампы делать, при чем чтобы именно логическим анализатором!"Главное - результат. Если есть материнская плата PC с контроллером FDD, который может дампить FM-дорожки "по приказу" MXonPC - ничего лучше и не надо.
Но не у всех такая ситуация. Если кто-то из обладателей логического анализатора сдампит дорожки с разрешением 1 мкс - это может быть весьма познавательно.
В принципе - можно сделать универсальный адаптер дампов, который будет приводить к единому виду файлы дампов дорожек, сделанные любым способом.
Главное - результат. Если есть материнская плата PC с контроллером FDD, который может дампить FM-дорожки "по приказу" MXonPC - ничего лучше и не надо.
Любой комп с поддержкой 5.25" в биосе умеет то что нужно.
Мне более интересен процесс записи дискет. Его я сейчас прорабатываю.
---------- Post added at 23:48 ---------- Previous post was at 23:45 ----------
Если кто-то из обладателей логического анализатора
Так у Вас-то он есть? Я не врубаюсь...
Если есть - в чем вопрос????? Не накинуть на флоп два проводка????
Так у Вас-то он есть?У меня нет.
---------- Post added at 23:16 ---------- Previous post was at 23:14 ----------
Любой комп с поддержкой 5.25" в биосе умеет то что нужно.Вот кому нужно помочь советом:
А можно нужную половинку этой мифической микросхемы и заодно остальной шлейф так публично повыводно распинить, что бы не текстом как в оригинальной инструкции (кто я в терминологии MXonPC, я и так прекрасно знаю), а вот так что бы я не сидел и фантазировал что и куда паять? (ну реально цейтнот)
Вот кому нужно помочь советом:
Это Вы намекаете что он-то точно спасибо скажет, а не претензии вывалит? Дак это я (про него) в курсе.
Кстати, мне почему-то кажется что если кто-то длинно и развернуто отвечал на вопросы в форуме, а ему никто даже кнопку "thanks" не нажал, не говоря уже о простом спасибо, то получается что ответы никому не нужны и "писатель" напрягался зазря. Это мне кажется или это на самом деле так?
Как сказал на соседнем форуме один очень уважаемый человек, выкладывая очередную порцию наинтереснейшей документации, "Не забывайте шумно восхищаться, а то очень лениво сканировать пыльные бумажки без обратной связи." Я пока, конечно, совсем не столь уважаемый, но спасибо, я думаю, заслужил.
Но если не заслужил, значит зря писал и написанное зря занимает место в базе форума. Так тому и быть.
Так тому и быть.Ещё один вопрос - про то, как ведёт себя контроллер MX, когда при чтении выходит на неразмеченный участок в конце дорожки.
Он продолжает каждые 128 мкс выдавать в регистре данных несуществующие нулевые слова до тех пор, пока диск не сделает полный оборот и опять не появится разметка или реагирует как-то иначе ?
Дело в том, что драйвер MX при форматировании пишет служебную информацию в начале каждой дорожки перед "синхропоследовательностью". Прочитать эти слова на первом обороте невозможно. А чтобы прочитать их на втором обороте - нужно "преодолеть" неразмеченный участок.
Patron, Вы меня с каждым разом всё больше поражаете.
1) "что драйвер MX при форматировании пишет служебную информацию в начале каждой дорожки перед "синхропоследовательностью""
2) "Как ведёт себя контроллер MX, когда при чтении выходит на неразмеченный участок в конце дорожки"
Если Вы знаете от пункте 1 и так уверенно о нем говорите, то логично предположить что Вы смотрели исходник (легко всем доступный) mx.sys
Почему у Вас тогда вопрос по пункту 2????
Я в эти исходники не смотрел (DECовские мнемокоды мне не близки), но исходя из логики и описанной мной ранее "типовой схемы" готов поспорить, что заранее зная размер дорожки мы именно столько и читаем, а дальше просто читать перестаем. Опять же, буфер под считанную дорожу мы имеем ограниченного размера, соответственно больше чем заранее заложено размером буфера мы просто не можем читать (конечно можем, но класть-то куда). Соответственно, ответить на Ваш вопрос можно так: Драйвер читает только то, что ему надо, и при этом на неразмеченную область после окончания данных мы не выходим.
---------- Post added at 16:24 ---------- Previous post was at 16:08 ----------
Да, всё-таки уточню что за такую служебную информацию драйвер пишет в нечитаемую область?
Драйвер читает только то, что ему надо, и при этом на неразмеченную область после окончания данных мы не выходимДрайвер точно пишет в "недостижимую" область, но вряд ли оттуда читает ( кстати, для чтения служебной информации буфер драйверу не нужен - ДВК обращается к регистрам быстрее, чем к памяти, и драйвер успевает использовать регистр данных MX, как ячейку данных ).
Но вопрос не про драйвер, а про то, идут ли в контроллере MX импульсы на сдвиговый регистр, когда на входе схемы синхронизации пропадают синхроимпульсы с диска.
Важен сам принцип - выдаёт ли контроллер слова данных при выходе в режиме чтения за конец разметки или "всё замирает" и сдвиговый регистр останавливается до появления на входе схемы синхронизации импульсов синхронизации с диска.
логично предположить что Вы смотрели исходник (легко всем доступный) mx.sysЭто я только сейчас пытаюсь делать. Сначала я просто сдалал эмулятор контроллера и посмотрел, что пишет на дорожку драйвер при форматировании и последующем использовании в системе.
Первыми двумя словами каждой дорожки пишутся какие-то неконстантные значения ( от записи к записи значения этих слов могут меняться ! ), смысл которых я пока не понял.
Всего драйвер MX использует на дорожке 1433 слова из 1562.
Если первое слово дорожки считать за №1, то "синхрослово" 0363 будет №11, номер дорожки будет в слове №12, затем 11 блоков по 129 слов ( 128 слов данных и одно слово контрольной суммы ), а последние два записанных слова будут №1432 и №1433 - в них тоже пишется какая-то служебная информация.
что за такую служебную информацию драйвер пишет в нечитаемую область?Поначалу я думал, что это константы, как-то связанные с тем, что на двух сторонах дорожки MX размещает 22 блока по 128 слов ( т.е. 11 блоков по 512 байт ), но только что обнаружил, что от записи к записи эти значения могут изменяться..
>Драйвер точно пишет в "недостижимую" область, но вряд ли оттуда читает
Спрошу конкретнее: Откуда инфа и что он туда пишет
>идут ли в контроллере MX импульсы на сдвиговый регистр, когда на входе схемы синхронизации пропадают синхроимпульсы с диска.
Я уже рекомендовал 16 лист паспорта на контроллер МХ. Там это написано.
>Первыми двумя словами каждой дорожки пишутся какие-то
...
>последние два записанных слова будут №1432 и №1433 - в них тоже пишется какая-то служебная информация.
Не знаю, я так в MX не разбирался. Тут лучше в тексте драйвера смотреть о чем речь.
Может контрольная сумма дорожки в конце трека?
Достаточно просто сравнить два последних слова соседних треков при отсутствии информации на этих треках (после формата)
Откуда инфа и что он туда пишетИнфа из образа диска, в который пишет контроллер. Но что он туда пишет, пока озвучивать остерегусь - вдруг это я где-то напортачил.
Я уже рекомендовал 16 лист паспорта на контроллер МХ. Там это написано.Я этот паспорт читаю непрерывно ( со стр.12 по стр.18 ) уже два дня, но понять на основе написанного, останавливается ли сдвиговый регистр при выходе в режиме чтения на неформатированный участок дорожки или нет - не могу.
Если Вы смогли это понять из описания - расскажите.
Тут лучше в тексте драйвера смотреть о чем речь.Да, вроде, всё уже работает - RT11 v5.7 не грузилась из-за неточности в загрузчике MX - я его исправил и успешно загрузился в эмуляторе с MX ( и с пульта по команде 'X0' - тоже грузится ). При загрузке - дальше слова №1432 драйвер не читает. Что он конкретно пишет в начале дорожки - честно говоря лень разбираться.
Важнее точно знать не что и почему пишет драйвер, а как работает контроллер.
Может контрольная сумма дорожки в конце трека?В конце массива дорожки дважды пишется константа 0x83NN, где NN = [удвоенный номер дорожки]+[номер стороны].
Эта информация от записи к записи не меняется.
>останавливается ли сдвиговый регистр при выходе в режиме чтения на неформатированный участок дорожки или нет - не могу.
А с чего он должен останавливатся? Если синхроимпульсы есть, если генератор работает (а куда он денется), значит на сдвиговый регистр все приходит.
И, опять же, как он остановится сам по себе, если он же задействован в детектировании маркера?
Но это все мои домыслы, правильнее по схеме посмотреть.
>Что он конкретно пишет в начале дорожки - честно говоря лень разбираться.
;-)
>В конце массива дорожки дважды пишется константа 0x83NN, где NN = [удвоенный номер дорожки]+[номер стороны].
Спасибо.
как он остановится сам по себе, если он же задействован в детектировании маркера?Маркер не может появиться без синхроимпульсов.
Другое дело, что если при чтении используется та же схема формирования, что и при записи, а сигналы синхры с диска (при их наличии ) используются только для подстройки фазы - то тогда за пределами разметки чтение будет продолжаться без остановки, выдавая по нулевому слову каждые 128 мкс.
В любом случае, если не останавливать чтение в конце массива данных - можно непрерывно читать хоть сто оборотов.
Ведь контроллер сам из режима чтения выйти не может - правильно ?
Он может только остановить или не остановить сдвиговый регистр на время отсутствия синхры.
>Он может только остановить или не остановить сдвиговый регистр на время отсутствия синхры.
По какому признаку? А если у нас диск до этого был отформатирован FM на другой машине без привязки к индексу (к примеру), то синхра вообще всегда будет.
Согласен, тут ключевой момент используется ли синхра с чтения для сдвига, но это надо схему смотреть. Сегодня я уже не готов
Хотя по паспорту на запись и чтение одна схема формирователя ТИ и СИ.
синхра вообще всегда будетЕсть ещё один аспект - число битов на дорожке FM принципиально не кратно 16-ти, поэтому, даже если на том же контроллере прописать всю дорожку синхрой "без зазора" - сигнал индекса всё равно должен запускать схему опознавания стартового слова ( а эта схема умеет блокировать копирование сдвигового регистра в регистр данных и установку бита готовности ).
Но если схема опознавания умеет блокировать копирование сдвигового регистра в регистр данных - почему бы этого не делать и схеме синхронизации.
Ведь если во время чтения выключить дисковод - ситуация будет полностью аналогична выходу на неразмеченную часть дорожки.
Какой практический смысл в копировании сдвигового регистра в регистр данных, если из 16-ти обязательных синхроимпульсов за 128 мкс не было принято ни одного ???
...
P.S. Как я и предполагал - самым первым словом на дорожке мой эмулятор контроллера писал то содержимое сдвигового регистра, которое было в нём до загрузки слова данных (т.е. всякую фигню). Судя по описанию контроллера - загрузка слова данных в сдвиговый регистр при записи происходит только через 16 синхро-тактов после начала записи. В описании не сказано, что происходит при этом с предыдущим содержимым сдвигового регистра. Но вряд ли это принципиально, ведь как уже ясно - схема опознавания должна запускаться на каждом обороте, поэтому считывание данных, расположенных на дорожке между "точкой появления индекса" и словом 0363 принципиально невозможно.
>число битов на дорожке FM принципиально не кратно 16-ти,
Откуда инфа?
>сигнал индекса всё равно должен запускать схему опознавания стартового слова
И так делает это. Но какая связь с кратностью 16ти?
Контроль на маркер делается каждый бит, а не раз в 16 бит
>Какой практический смысл в копировании сдвигового регистра в регистр данных, если из 16-ти обязательных синхроимпульсов за 128 мкс не было принято ни одного ???
А какой смысл тормозить сдвиговый регистр? Он кому-то мешает?
Я вообще не очень понимаю вот чего: если мы не читаем из контроллера, какая нам разница что там делает сдвиговый регистр?
Если есть желание - всегда можно взять схему и на 100% ответить на вопрос что там делает сдвиговый регистр.
> Но вряд ли это принципиально, ведь как уже ясно - схема опознавания должна запускаться на каждом обороте, поэтому
Не совсем так - сигнал индекса запускает поступление читаемых данных на сдвиговый регистр (и, как следаствие на схему опознавания маркера). В какой момент входная дверь для данных захлопывается - надо смотреть схему
Откуда инфа?Продолжительнсть стандартной дорожки 200 мс, продолжительность стандартного слова 128 мкс.
Контроль на маркер делается каждый бит, а не раз в 16 битДля обсуждаемого вопроса это значения не имеет. Главное - отключает ли сигнал индекса выдачу данных в режиме чтения. Если да ( а это обязательно должно быть так ) - то прочитать данные между индексом и стартовым словом невозможно в принципе.
А какой смысл тормозить сдвиговый регистр? Он кому-то мешает?Никому не мешает. Вопрос лишь в том, продолжают ли выдаваться данные с установкой бита готовности, если в процессе чтения выключить дисковод.
В какой момент входная дверь для данных захлопывается - надо смотреть схемуРечь не о входной, а о выходной двери. В режиме чтения - содержимое сдвигового регистра не копируется в регистр данных до обнаружения стартового слова. Логично предположить, что при непрерывном чтении - на каждом обороте выдача данных будет прекращаться после индекса и до обнаружения стартового слова.
Мне кажется Вы ставите все с ног на голову.
1) как раз совсем не важно сколько физически влезает бит на дорожку и кратно ли это 16 бит
2) как раз ПРИНЦИПИАЛЬНО ВАЖНО, что контроль на маркер делается каждый бит. Поэтому даже если мы потеряли несколько бит в синхропоследовательности - мы найдем маркер. Если бы мы искали маркер только раз в 16 бит, начиная от индекса - мы бы легко пролетали: и битики в синхре можно потерять, и задержка по началу чтения после индекса у разных дисководов может быть разная.
>Речь не о входной, а о выходной двери.
..
>Логично предположить, что при непрерывном чтении - на каждом обороте выдача данных
Мы опять как слепой с глухим. Вы можете предполагать всё что угодно. Это Ваше право и достоверность Ваших предположений на уровне кратности или не кратности дорожки 16 битам даже при наличии арифметических "доказательств".
Но я то Вас отсылаю к схеме конкретного контроллера. Из неё видны ответы на все Ваши вопросы. Из того что я успел разглядеть - от индекса зависит имеено ВХОДНАЯ "дверь" (конкретно элемент ИЛИ-НЕ, на которых подаются данные с дисковода). Дальше надо разбираться в схеме - мне лень.
И еще просьба: если Вам интересна дискуссия, было бы крайне приятно, чтобы Вы свои доводы, например, нижеуказанный, хоть как-то обосновывали или писали что это из такого-то источника. Иначе я просто за Вами не поспеваю.
>тключает ли сигнал индекса выдачу данных в режиме чтения. Если да ( а это обязательно должно быть так )
Почему это обязательно должно быть так?????
Почему это обязательно должно быть так?????Потому что после индекса - соответствие битов словам не гарантировано до обнаружения стартового слова. Только после опознавания стартового слова можно синхронизировать читаемые биты с границами слов, а до того нет никакого смысла выставлять бит готовности и копировать текущее содержимое сдвигового регистра в регистр данных ( поэтому контроллер этого никогда и не делает ).
...
Дальнейшие исследования дали дальнейшие результаты:
1. Программа TSTMX форматирует дорожку от индекса до индекса, размещая стартовое слово в позиции № 9 и не размещая сразу после секторов порядковый номер поверхности от начала диска.
2. Старый драйвер MX прописывает всю дорожку от индекса до индекса, размещает стартовое слово в позиции № 31, а сразу после секторов пишет два слова с порядковым номером поверхности от начала диска.
3. И старый, и новый драйвера MX без проблем читают дорожку, отформатированную TSTMX, значит номера поверхности, которые пишутся ими в конце дорожки - им самим для работы не нужны.
Потому что после индекса - соответствие битов словам не гарантировано до обнаружения стартового слова.
А причем здесь индекс?
Данные можно выдавать после получения маркера.
Пример: по началу старта дождались индекса, потом дождались маркера и читаем данные. Почему второй индекс ДОЛЖЕН отключать сигнал выдачи данных?
Еще раз Вас процитирую:
Главное - отключает ли сигнал индекса выдачу данных в режиме чтения. Если да ( а это обязательно должно быть так )
А теперь Вы отвечаете мне почему индекс ВКЛЮЧАЕТ подачу данных (это и так понятно, чтобы найти именно маркер в начале дорожки, а не что-то в середине, похожее на маркер.
Почему второй индекс ДОЛЖЕН отключать сигнал выдачи данных?Потому что битовая длина дорожки не кратна слову, а значит - содержимое сдвигового регистра после сигнала индекса каждого оборота чтения точно так же не имеет однозначного смысла, как и сразу после запуска режима чтения.
Ну вот, Вы опять вернулись к Вашему непонятному допущению и на его основе делаете выводы. Схему смотреть Вам, как я понимаю, тоже лень.
Мой вопрос и был в том что "обязательно должно быть так" совсем не обязательно, а Вам так кажется разумным.
ВКЛЮЧАЕТ подачу данныхМы здесь разное имеем в виду.
Под подачей данных я имею в виду обновление содержимого регистра данных с установлением бита готовности.
Если это не подача данных - тогда уточните, как это следует правильно называть.
---------- Post added at 17:04 ---------- Previous post was at 17:00 ----------
"обязательно должно быть так" совсем не обязательноВ смысле - не заложено в железной логике схемы..
Это да.
Если схема допускает формирование новых данных в регистре данных после запуска схемы опознавания стартового слова, но до опознавания стартового слова - тогда, конечно, обязательное окажется на деле совсем не обязательным, а просто разумным и желательным.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot