Затестил последнюю версию.
В вкладке HT как-будто перепутаны скорости, при 250 начало читать, а при 300 отказалось.
После чтения первого дороги вылетел эксепшн:
https://yadi.sk/i/FSyqFEcJvpGrRg
- - - Добавлено - - -
При чтении в режиме TRD та-же беда, пользоваться программой пока не получается.
Тем временем в самой первой версии тоже словил баг. После рандомного чтения и попадания на HD диск, сектор и трек самопрозвольно выставились на 45 - 45
(видимо на значение последнего бэда).
Странное дело. Я у себя не нашел перепутанных скоростей.Сообщение от newart
Попробуй взять вот эту версию (там я прикрепил еще файл pdb с отладочной информацией), и если будет исключение, то выложи его полный текст здесь (скрина я думаю будет недостаточно, там обрезается часть инфы обычно).
Можешь заодно потестить новую фичу чтения кастомных форматов (она сделана еще не до конца, но уже почти до конца).
PS
Еще лучше запустить с ключом /logfile и посмотреть лог.
Последний раз редактировалось CPLx; 12.08.2020 в 13:43.
Довольно забавным образом удалось прочитать трек включая межсекторные данные благодаря особенностям формата этого трека. На одном из моих дисков оказались треки где были сектора с размерами 4, 5, 6, 7, 8 и 9. Цифра 6 означает размер сектора 8192 байта (размер всего трека - 6250 байт). Что означают остальные я даже не знаю. Тайминги между заголовками секторов указывали на то что реально их размер составляет 256 байт. Но в сами заголовки вписаны неправильные размеры. Дал команду прочитать сектор с размером 6 (8192 байта), получил ошибку 23 (ошибка CRC), и данные всего трека вместе со всеми пробелами, т.к. контроллер читая сектор размером 8192 байта в итоге выдал данные всего трека. Прочитано было порядка 8192 байта (не менее 8118, остальные там нули и трудно понять были эти нули прочитаны или были изначально в памяти). Глядя на сами данные видно что там похоже синхронизация слетает на конце трека (где стык окончания и начала, в районе индексного импульса это должно быть по идее), и вместо 4E начинают идти E4, ну и вся остальная инфа искаженная оказывается. Жаль что это сработало только благодаря ошибкам в формате и другие треки таким способом не прочитать. Ну хоть увидел структуру дорожки, впервые за 23 года наверное. Последний раз я видел такое только читая трек на ВГшке.
Размер надо полюбому и стартовый адрес. Полно одинаковых названий.
Свирепый агрессивно-депрессивный мордовец!
Не уверен - не напрягай!
Не сдавайся. Дыши?
Virtual TR-DOS
А драйвер не позволяет читать RAW содержание полной дорожки?
У драйвера есть функция чтения трека, описываемая как Raw track read: https://simonowen.com/fdrawcmd/ioctls/#cmd_read_track
Но у меня индексного импульса нет (баг железа, как я полагаю), поэтому эта функция возвращает у меня ошибку 21 (device not ready) и я не знаю работоспособна ли она в принципе. По некоторым по чужим постам можно прийти к выводу что драйвер может читать трек в сыром виде только с двумя дисководами (для этого есть другая команда: https://simonowen.com/fdrawcmd/ioctls/#raw_read_track ). Как на самом деле - не знаю.
CPLx, Понятно. Вообще конечно прискорбный факт... Получается что это какое-то искусственное ограничение...
Провел небольшое исследование на эту тему.
Сначала убедился что у меня нет индексного импульса именно из-за неисправности дисковода, а не контроллера. Потом направил на провод INDX сигнал с TR00. Это дало мне возможность имитировать наличие индексных импульсов путем перекрывания TR00 вручную. Жуткое извращение, но именно оно окончательно доказало неисправность именно дисковода. Эта самая имитация индексных импульсов (путем вставления и выстаскивания в датчик TR00 ножниц с большой частотой руками) позволила частично запустить команду чтения трека, т.к. контроллер стал видеть индексные импульсы (а она читает от индексного импульса, и без него не отрабатывает). Команда постоянно выдавала ошибку 23, но это не особо важно. Важно что она выдавала данные. Данные были какой-то кашей, которую я не смог найти на читаемом диске. Но где-то она их брала. Потом я вставил чистый диск (TR-DOS, все сектора заполнены нулями) и попробовал прочитать уже его. И тут оказалось что команда чтения трека возвращает одни нули на этом диске (по прежнему с ошибкой 23). Проверял много раз оба диска: записанный возвращает кашу, чистый возвращает нули. Никаких межсекторных данных, которые я ожидал увидеть на чистом диске более четко видными. Возвращение нулей на чистом диске навело меня на мысль что команда чтения трека читает на самом деле не трек, а содержимое секторов. Т.к. в драйвере уже был ранее мной найден один хак, то я решил проверить нет ли и тут хака.
(Хак который был найден ранее заключается в следующем. В драйвере есть команда ожидания индексного импульса. По логике кажется что для ожидания индексного импульса драйвер должен проверять значение индексного датчика, и при регистрации отверстия сигнализировать об импульсе. Но оказалось что сделано там это всё иначе. Вместо этого драйвер пытается прочитать несуществующий сектор, после чего возвращает управление. Контроллер, когда не может найти сектор, ждет 2 импульса и отвечает ошибкой что сектор не найден. Таким образом, чтение несуществующего сектора обеспечит нам попадание на индексный импульс (второй по счету при этом; т.е. один импульс мы пропустим). В ВГ93 можно было напрямую посмотреть состояние этого датчика. Но в этом контроллере - нет. В нём можно посмотреть датчик TR00 и датчик защиты от записи, но индексный датчик недоступен для прямого чтения.)
Так вот, в поисках предполагаемого хака я полез в исходный код драйвера и увидел что здесь никакого хака нет и что он честно передает команду чтения трека COMMND_READ_TRACK драйверу FDC. Дальше я полез в документацию контроллера. А там я увидел следующее:
Если я правильно понял описание, то команда чтения трека читает все сектора подряд, начиная от индексного импульса, не проверяя параметры секторов. В этом её главное отличие от команды Read Data, которая читает только сектора с указанными параметрами (номер, цилиндр, сторона, размер), и при несовпадении параметров она такие сектора игнорирует (надо сказать что ВГ93 проверяла только цилиндр и номер сектора, и точно не проверяла сторону, из-за чего существуют разные варианты форматирования верхней стороны - поэтому иногда бывает что верхняя сторона не читается на PC-шном контроллере). Чтобы прочитать ей (командой read data) сектора, надо заранее точно знать все их параметры, иначе ничего не получится. Read track же читает сектора не глядя на их параметры: попался сектор, она прочитала; попался следующий - снова прочитала. Получается что-то вроде совмещенного сканирования и чтения, всё в один проход. Но читаются именно данные секторов, а не межсекторное пространство.
Судя по документации, команды, аналогичной чтению дорожки у ВГ93, данный контоллер не имеет. Именно контроллер, а драйвер уже как следствие.
Я лично пробовал читать весь трек целиком вместе с межсекторным пространством. И именно через этот драйвер. Но использовать не стал, т.к. контроллер сбивался на синхропоследовательностях также, как на спектруме при чтении трека целиком.
А каким образом, какой командой? И были ли признаки что он выдает межсекторные данные?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием