101 Отредактировано Voldemar0 (15-01-2023 19:21)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Удорожания практически никакого: только семплер в двух экземплярах.
Самое дорогое во всей этой работе - время на разработку. И, может быть, SoM.
А будет ли ПО работать в двух экземплярах одновременно или в одном - это сложности не добавляет, это проблемы операционки.

Если делать однопортовую схему, можно было бы немного съэкономить на буферных микрухах и транзисторах. Минус 1 транзистор (объединить вход сигнала write protect) и минус одна буферная микруха (возможно, объединив WriteEnable, WriteData, Head/Phase0, ...).
Сигналы !CS всё равно пришлось бы делить либо механически отключать один из дисководов на время работы второго.
В крайнем случае механический переключатель !CS.

Время важно тогда, когда снимаешь несколько сотен дисков. Или даже несколько десятков, но они плохо читаются.
В этом случае время растёт сильно, может до 10 минут на диск. Если это делаешь не параллельно с другими делами - будет скучно.
Если параллельно - рано или поздно отвлекаешся и забываешь о съёме и устройство простаивает - требуется ещё больше времени.

Возможно, на практике это не будет сильно помогать: например, если коллекция состоит только из 140 или 840ок.

Возможно, один из простых и эффективных способов использования двух портов будет состоять в том,
что один порт снимает диск, а второй используется для опознавания дисков (где чьи, что снимать в первую очередь, каким флопиком, есть ли вообще на флопике запись и т.д.).

Полноценное снятие - это процесс долгий, особенно если диск читается плохо. Но оценка диска - дело нескольких секунд.
Т.е. можно, например, запустить снятие заведомой 840ки, а на 140ке запустить прогу вроде спектроанализатора и, даже не выключая дисковод, просто подсовывать ему диски один за другим и, пробежав дорожек 5, сходу увидеть, что диск не записан или записан на шугарте или на тике. Для этого не обязательно его целиком вычитывать. У меня есть предположение, что пусть и плохо, но агатовская 140ка может читать запись 840ки. АЧХ подходит, а вот про ширину головы сейчас мне не совсем понятно. Потому что иногда, на некоторых дорожках, она видит очень отчётливый спектр 840ки. Так что проверить возможность декодирования этого на практике будет интересно.

Когда дело касается даже нескольких десятков дисков, предварительная сортировка - дело довольно полезное.

--

Я писал предыдущее сообщение только о том, что сама возможность работать в параллель подтвердилась. Т.е. в силу каких-то аппаратных или программных ограничений ускорить съем в один дисковод невозможно (чистая скорость всё равно ниже чем у мостов2), но хотя бы можно гонять одновременно два дисковода: проц всё равно не используется одним дисководом на 100%.

-

Запись будет в последнюю очередь.
Канал отдельный особо не нужен - семплер работает как на вход так и на выход, это зависит только от подаваемой на SRAM команды.
Буферные каскады Write Enable и Write Data предусмотрены.
Дальше дело за софтом.

102

Re: Мост # 3 - специализированный компьютер для чтения дискет

Спасибо за пояснения, usecase понятен.

103 Отредактировано avivanov76 (16-01-2023 02:15)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

У меня есть предположение, что пусть и плохо, но агатовская 140ка может читать запись 840ки. АЧХ подходит, а вот про ширину головы сейчас мне не совсем понятно. Потому что иногда, на некоторых дорожках, она видит очень отчётливый спектр 840ки.

Голова 140-ки точно шире 840-ки. Здесь https://retrocmp.de/fdd/general/48tpi-vs-96tpi.htm есть фотка со сравнением головок 48 TPI и 96 TPI.

При плотности 96 TPI треки идут с шагом 265 микрон. А ширина головки 48 TPI 300 микрон (https://patents.google.com/patent/US4771346). Так что она полностью накроет трек посередине, но микрон 30-40 не достанет до треков с боков. Но это при идеальной центровке.

При неидеальной - голова будет чаще захватывать два трека (треки занимают 60% места). И тут все будет зависеть от того, какой трек захвачен больше. Если один захвачен процентов на 80%, то он более-менее должен читаться. А вот если оба захвачены примерно на 50%, то головка будет читать кашу из смеси двух треков.

То, что трек сам в два раза уже (тоньше), приведет к тому, что с головки сигнал будет слабее. Ну и еще есть такой момент, что диск мог форматироваться разными дисководами, поэтому из интервалов между треками тоже могут читаться данные.

Короче, я про то, что это чистая рулетка. Если диск изначально был чистым, использовался с одним дисководом и голова у него стояла также как на 140-ке, то он будет читаться. А во всех остальных случаях - скорее всего нет.

104 Отредактировано Voldemar0 (16-01-2023 07:30)

Re: Мост # 3 - специализированный компьютер для чтения дискет

> Короче, я про то, что это чистая рулетка. Если диск изначально был чистым, использовался с одним дисководом и голова у него стояла также как на 140-ке, то он будет читаться. А во всех остальных случаях - скорее всего нет.

Мои рассуждения были в контексте опознания формата, а не полноценного чтения.
Нам важно хотя бы раз заметить адресное поле какого-то из известных форматов и, если это произошло, советовать пользователю попробовать прочитать диск на соответствующем формату дисководе.

Если будет много ложноположительных сработок - будем менять стратегию :)

Меня удивило именно то, что я вообще увидел этот спектр, причем без нахлёстывания вершин.
Был уверен, что там будет полная каша из-за считывания двух дорог одновременно.

--

Есть и ещё одна странность: даже на дискетах-140ках между фазами (т.е. в нечётных фазах ШД) спектры тоже иногда видны очень отчётливо. А иногда всё смазано. У меня пока не готов софт для определения и перебора форматов, только структуру его пытаюсь выстроить. И попутно добиваюсь стабильной работы семплера.

1) Выяснилось, что когда проги не используют SPI (т.е. устройство не "открыто"), контроллер, похоже, отключается от пинов: !CS падает вниз, линия селектора источника CLK уходит в Z-state (коммутатор это воспринимает как 0 и начинает загонять CLK от 8 МГц-генератора), в итоге микру забивает мусором. Для работы не критично, но сперва это меня сбивало с толку: заливаешь данные в RAM, потом читаешь (другой прогой) - а там мусор лезет.

2) Иногда семплер вообще не работал, после каких-то изменений в коде. А иногда - работал. Ещё пару раз перечитал мануал на SRAM, нашел рекомендацию выдавать ей команду RESET в начале работы. Воткнул RESET перед каждым массовым обращением (у меня обмен почти всегда сейчас идёт по треку: т.е. одна команда и дальше куча чтений, без повышения !CS) - стало явно лучше.

Ещё интересно, что 140ка без дискеты выдаёт довольно странный спектр шума: он состоит из явно выраженных 5-6 вершин. Если смотреть обычную осцилограмму, то это выглядит как почти всегда низкий уровень (огромные интервалы, в сотни мкс), но иногда выбрасывает по паре импульсов с короткими интервалами между ними).

А вот шум с 3.5'' не получается увидеть: чуть нажимаешь кнопку выбрасывания диска и он блокирует канал чтения. Надо будет попробовать без крышки, только головы приподнимать.

105

Re: Мост # 3 - специализированный компьютер для чтения дискет

И вот ведь что забавно: если у дискеты сделать вырез защиты записи, а затем сунуть в 140ку, то можно будет записывать данные на вторую сторону. Ну это все знали.

Но ведь если такую дискету сунуть в 840ку перевёрнутой - все ли дисководы будут ждать сигнал индекса ?
А если ждать не будут, значит можно записать странную дискету, которую далеко не все сообразят именно так засунуть во флопик, чтобы узнать ваши секретики ?...

106 Отредактировано Voldemar0 (19-01-2023 15:02)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Эксперимент показал, что 140ка вполне читает (с одной стороны, конечно) 840ки.
Причем именно все 80 дорог или почти 80. При условии, что диск хороший, больше половины можно выдернуть.

Судя по карте результатов чтения, тут играет роль какой-то эксцентриситет.
Читающиеся и нечитающиеся сектора собираются в группы, по 2-6 групп на треке.

Надо будет поизучать вопрос о плохо читающихся на родном приводе секторах и попытках их вытягивания на другом.

107

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

Надо будет поизучать вопрос о плохо читающихся на родном приводе секторах и попытках их вытягивания на другом.

О!

108

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

Но ведь если такую дискету сунуть в 840ку перевёрнутой - все ли дисководы будут ждать сигнал индекса ?
А если ждать не будут, значит можно записать странную дискету, которую далеко не все сообразят именно так засунуть во флопик, чтобы узнать ваши секретики ?..

Если такая дискета потом перешла к новому владельцу, то он с большой вероятностью мог принять ее за неформатированную и набрав format a: уничтожить все секретики :)

109 Отредактировано garnizon (20-01-2023 10:49)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Сразу вспомнил историю, как человек с ZX/PK купил "всеядную" плату для чтения дисков, типа SCP, и сортировал ей приличную стопку дисков. Отложил в сторону те, которые неформатированные. А они оказались 840, когда я их стал читать.
А сколько таких сортировщиков...


И про секретики, Андрей Кулаков же на ЛЭМЗ менял полярность на моторе привода 140 (переключатель вывел).  И записывал дискеты с своими секретиками так.

110 Отредактировано Voldemar0 (20-01-2023 11:48)

Re: Мост # 3 - специализированный компьютер для чтения дискет

> И про секретики, Андрей Кулаков же на ЛЭМЗ менял полярность на моторе привода 140 (переключатель вывел).  И записывал дискеты с своими секретиками так.

У тебя этих дисков не осталось, случаем ?

Потому что, похоже, надо будет в список параметров декодера вставлять ещё эту фичу с реверсом дорожки.

Внезапно может оказаться полезным в разных непонятных/нестабильных случаях.
Кроме того, если вдруг одна из голов на двухголовом приводе косячит сильно больше другой, то, по крайней мере, опознать запись на косячной стороне можно будет перевернув диск.
Или вычитать отдельные дорожки.

Из-за сдвига голов одна другую полностью не перекроют, ... хотя, нижняя голова, возможно, будет перекрывать верхнюю. Но не наоборот.

111

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

> У тебя этих дисков не осталось, случаем ?

По идее они должны были попасться в коллекции Андрея, насколько я помню, не попались.

112

Re: Мост # 3 - специализированный компьютер для чтения дискет

Тут есть одна странность, если подумать: стирающая и пишущая головка же расположены в определённом порядке, и если сменить направление вращения движка, получится, что стирающая будет стирать новую запись?

113

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

стирающая и пишущая головка же расположены в определённом порядке, и если сменить направление вращения движка, получится, что стирающая будет стирать новую запись?

Да, именно так и будет. А что - надежно: секреты точно никто никогда не прочитает :)

Если ничего не путаю, то Андрей Кулаков был наладчиком, и должен был знать такие вещи. Так что у меня две мысли по этому поводу: 1) это такая шутка юмора была; 2) может, переделка и была в природе, но она была существенно сложнее, чем просто переключение полярности движка.

Опять же, если подумать, возможны даже два варианта такой переделки:
1) головка стирания отключается, берется чистая, специально размагниченная дискета и на нее задом наперед пишется целиком диск. Почему целиком? Потому что потом ничего исправить на нем будет нельзя: без стирания нельзя убрать старую информацию, но при включенном стирании нельзя записать новую информацию.
2) головка переворачивается на 180 градусов. Но в этом случае привод всегда будет писать только задом наперед. Кстати, это довольно реалистичный вариант - ведь мог встретиться бракованный ЕС-5088 с неправильно установленной головой.

114

Re: Мост # 3 - специализированный компьютер для чтения дискет

>  Кстати, это довольно реалистичный вариант - ведь мог встретиться бракованный ЕС-5088 с неправильно установленной головой.

Голова как будто бы одна деталь ? Т.е. сама катушка + пластиковая рамка, бегающая по направляющим.
Причем в паспорте явно указано, что она - японская.
Или от японцев там только сам магнитопровод с керамикой, а их уже болгары вклеивали в пластик ?

115

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

Голова как будто бы одна деталь ? Т.е. сама катушка + пластиковая рамка, бегающая по направляющим.

В мануале к SA400 то, что ездит по направляющим, считается сборкой.

Voldemar0 пишет:

Причем в паспорте явно указано, что она - японская.

В ТО на ЕС5088.02 написано, что головка болгарская ГФД237, но вместо нее могут устанавливаться головы от Data Magnetics, SANKYO и CANON.

Voldemar0 пишет:

Или от японцев там только сам магнитопровод с керамикой, а их уже болгары вклеивали в пластик ?

Обычно головка - это магнитопровод с катушками. Часто в металлическом экране. Пластик - это уже держатель головки, который зависит от конкретной модели дисковода и способа перемещения головки. Даже у SA400 было два варианта держателя, потому что был еще вариант с электромагнитом прижима.

Вот на фотке вроде как следы клея видно вокруг восьмиугольника. (И то я подозреваю, что голова на самом деле круглая, а восьмиугольник - вспомогательная деталь.)

Кстати, вот головки продаются http://rt22.ru/viewtopic.php?f=30&t=24923 Можно посмотреть, как они сами по себе выглядят.

Post's attachments

EC-5088_head.jpg, 35.93 kb, 480 x 480
EC-5088_head.jpg 35.93 kb, 43 downloads since 2023-01-21 

116 Отредактировано Voldemar0 (23-01-2023 14:26)

Re: Мост # 3 - специализированный компьютер для чтения дискет

> Кстати, вот головки продаются http://rt22.ru/viewtopic.php?f=30&t=24923 Можно посмотреть, как они сами по себе выглядят.

Интересно. Не ожидал, что они так отдельно коробочками продаются.
У меня пара приводов ес-ок есть, у которых чтение выше середины диска идёт очень плохо, подозреваю, что дело в головах.
Младшие треки нормально читаются.
Правда, есть шанс, что эти приводы уже погнили в печальных условиях хранения.
Да и не факт, что эти головы туда встанут. А работающих приводов ещё несколько штук есть. Даже почти отлично работающих.

Если у кого есть контакты с продавцом, я бы штуки 4 купил.

====

Пока до готовности софта далеко, но постепенно отдельные его части вырисовываются, заодно из них делаю утилитку для offline-обработки нового формата Eim3. Ну и сам формат дополняю.

1)
Внезапно выявилось интересное: 3.25'' двигает голову на нулевой цилиндр, но затем переход на цилиндр 1 срабатывает не всегда (хотя щелчок в моторе слышен!). Следующий переход на 2 срабатывает уверенно. Причем в одной проге так (всегда всё надёжно), в другой - этак (через раз).

Получается двухкратное чтение нулевого цилиндра, а 79, соответственно, читается не всегда.

Для читалки вроде это и не критично: если расчётное положение головы не соответствует тому, что есть в полях адреса,
то корректируем положение в соответствии с полями. Так все агатовские драйвера поступают.

Но - с другой стороны - так не должно быть. При форматировании диска, например, на поля адреса расчитывать не приходится.

Для моста это тоже плохо: мост должен читать нестандартные форматы, а чудеса с удивительными адресными полями уже мне встречались. Т.е. мост не должен корректировать положение головки от адресного поля. Если есть предположение, что голова не на месте, он корректируется относительно нулевого трека.

Попробовал цеплять 5.25'' (впервые!!!) - там всё нормально. Ставлю опять 3.25'' - косячит.

Проги используют общую библиотеку управления приводами, да и вызовы везде простые.

Ясно, что у флопика есть счётчик фаз, ясно, что если у него датчик нуля сработал, он вроде как должен блокировать мотор.
Но, похоже, счётчик фаз в каких -то случаях может продолжать считать. Т.е. положение ротора не соответствует счётчику фаз
и на импульс перехода на цилиндр 1 он пытается перейти, условно, с -1 на 0. И остаётся в нуле.

Почему ? А я так и не знаю. Но помогло уменьшение импульса step. В доках на Агат упоминается 1 мкс. У меня была 1 мс, плюс ещё 8 мс - ожидание после снятия сигнала step.  В мост2 формированием этого импульса занимался агатовский контроллер.
Уменьшил сперва длительность step до 100 мкс - всё заработало. Поставил тогда 10. Ниже 10 смысла нет снижать - у линуха на этом проце не то разрешение таймеров, чтобы с микросекундами играть. Оно болтается где-то от 10 до 100 мкс. На получение данных (типа Index) ещё можно интервал между импульсами поточнее оценить, а что-то другое делать - неа.

/*
Нестандартные номера треков в адресных полях: например, копировщик КПОН этим балуется (не копировщик, который в составе ИКП, а инсталятор КПОН, который на новый диск его записывает). На треках с нулевого по, примерно, 6 поля правильные - там сам копировщик. А на следующем треке номер 0, потом номер 1 и т.д. - там лежит КПОН со всеми своими адресными полями.
С одной стороны - такой диск фиг скопируешь адекватным софтом, с другой -  копировщику удобно: он берёт очередной трек и лепит его на копию сразу со всей служебкой, только голову сместив на 6 треков к краю. Я не копал сильно глубоко этот код, возможно, задумка
там была в чём-то другом, но эти адресные поля хорошо запомнил.
*/

2)
Когда-то давно рассказывал про удивительный флопик ес5323.01 (возможно, на zx.pk.ru). По всем описаниям он 96 tpi должен быть, но у меня он 48tpi.
К делу не пристраивался ни разу, но, похоже, состояние хорошее.

Добыл, включил. Крутится, читает че-то. Думаю его к чтению 140ок приспособить.

Но тут возникает вопрос: если привод подключен на интерфейс 840ок - то обычно ожидается, что он 96tpi.
А если он 48 - там же соответствие физических треков и логических будет не такое как у мс5088.
Смешно, но как раз 5088 по счётчику треков - 96 tpi.

И ещё: судя по спектрам - 5088 явно лучше читает 840ки чем этот хитрый 5323.
Опять возвращаемся к вопросу о головах: могут они быть обе на 48tpi, но у 5088 при этом размер уже чем у 5323 ?

А всё это вместе плавно приводит к тому, что в eim3 неплохо бы записывать фактические характеристики приводов, а не только используемый интерфейс.

Но если приводы можно так легко заменить, то неплохо бы перед каждым съёмом узнавать параметры конкретного привода.
Скорость замерить можно быстро - 2-3 оборота и есть цифра.
А как замерить tpi ? Гоним головку на цилиндр 100, потом возвращаем к датчику нуля, считаем импульсы.
Занимает пару секунд. Но рычит громко, привод перегружен.

Или делать это один раз по запросу пользователя (если он не забудет) и сохранять в файлике-конфиге ?

Ещё вопрос: если уж этот привод неплохо читает 140ки (а это уже проверено), то вообще, для случая снятия 140ки на приводе с двумя головами, на интерфейсе 840, нужно ли читать сторону B? Младших четырех треков там не будет, но вдруг они уже прочитаны на другом приводе и вопрос только в том, чтобы дочитать, например, что нибудь в хвосте ? Чтобы дочитать, все средства хороши. Но если речь просто о съёме (когда диски 140 есть, а привода 140 нет) - то вроде как бы и не надо ?

Или читать всё сразу, а потом дискету перевернули и дочитали A- головой 4 младших трека B- стороны ?

3)
Нашел в заначке одного японца, который не имеет ни одного джампера кроме ds0/ds1 и крутит всегда 360 rpm.
Но если ему на пин 2 менять уровень, то АЧХ у него явно меняется. Сломно что -то?
По старым заметкам на этот привод говорится, что сама плата мотора на какой-то свой крайний контакт скорость меняет.

4)
У одного тика, хорошо работавшего раньше, сейчас чтения нет. Спектр шумовой.
Головки подключены. С одной головы что-то идёт, на спектре вершины видны, но дальше очень пологие склоны, сливающиеся друг с другом. На втором вообще плоскость, понемногу спадающая к более низким частотам.

Головы вроде чистые, но совсем сбоку, у края головки, на керамике, мелкая тёмная точка, диаметром не больше 1/4 мм.
Думал, что -то что-то технологическое. Но на всякий случай потёр спиртовой ваткой.
Используется фонарик, зеркальце (без рамки, только стекло), фонарик.
Иначе и нижнюю голову едва видно, а верхнюю не видно вообще.

Стал читать нормально.

Резюме: если для 5088 грязь видна как здоровый комок и она слегка мешает чтению, то для более тонких приводов даже мелкий кусочек, хоть чуть приподнимающий голову над поверхностью - уже полностью обнуляет шансы что-то вытащить.

Это видно и по попыткам поднять головы: если у 5088 убрать прижим, что-то ещё будет пытаться читаться, спектр при подъёме меняется плавно. У более тонких приводов почти сразу спектрограмма уходит в шум.

5)
Ещё один японский привод, головы отмыты, читает почти никак. Но если головку слегка прижать - читает нормально, даже - можно сказать - хорошо.

Пружинка на максимуме, но её не хватает.
Возможно, погнута пружинистая подвеска головы.
С учётом того, что разбирать блок голов - дело практически верно ведущее к мороке по последующей юстировке,
а даже просто снять блок голов без сдвига датчика нуля - тоже дело может быть не простое, пока отложил этот привод.
Можно ли, не разбирая блок, на просвет, попытаться восстановить углы положения головок ?
Или это только на стапеле ?

6)
Собрал, наконец, индикатор читаемого сигнала.
Просто датчик наличия ВЧ-переменки на входе чтения.
Схема примитивная: усилитель на полевике, кондёр на несколько десятков пф и усилитель на цифровом транзисторе, затем светодиод.

Работает довольно занятно: 140ка светится всегда, когда привод включен, но без дискеты - слабо.
К сожалению, не имею не записанных дискет, а то можно было бы поглядеть как она светит на чистой поверхности.

На 840ке светится всегда, кроме случаев, когда дисковод закрывает канал чтения.
мс-ки, как я понял, не закрывают его никогда, японцы - при любом удобном случае.
Голову ли подвигал или шпиндель притормозил или что нибудь ещё - всегда норовят выключиться.

Один японский привод без микрухи шагового мотора (lb1656). Так он вообще не включает канал чтения.
Микруха с него была снята для ремонта другого привода (лучше читавшего), так что всё остальное там должно быть в порядке.
Но даже если голову руками на нулевой трек отогнать, всё равно нет данных чтения.

Микру можно на али купить, пара штук за рублей 200-300. Или взять полностью привод на авито за 1000р с этой микрой.
Но вроде приводов и так пока хватает.

7)
Контакт 2 должен менять скорость привода, но также и АЧХ усилителя чтения.
Но, судя по спектрограммам, каждый производитель видит это слегка по разному:
срезы в верхней части спектра очень резкие, но граница у разных приводов находится в разных местах:
pin2 = LO: 1.3 .. 2.5 mks, 300 rpm.
pin2 = HI: 0.8 .. 1.1 mks, 360 rpm.

117 Отредактировано avivanov76 (22-01-2023 17:37)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

Когда-то давно рассказывал про удивительный флопик ес5323.01 (возможно, на zx.pk.ru). По всем описаниям он 96 tpi должен быть, но у меня он 48tpi.

Была такая модель ЕС5324, 2 стороны, 40 дорожек, 360К. Может, кто-то взял шасси от ЕС5323 и поставил на него плату от ЕС5324? Тогда, кстати, и плохое чтение объясняется - усилитель чтения настроен на другую головку.

Voldemar0 пишет:

Нашел в заначке одного японца, который не имеет ни одного джампера кроме ds0/ds1 и крутит всегда 360 rpm.
Но если ему на пин 2 менять уровень, то АЧХ у него явно меняется. Сломно что -то?

У меня Panasonic JU-475. Вроде двустандартный, и по описаниям должен на 2 пин реагировать. Но... не реагирует. Скорость не меняет. Возможно, прошивка контроллера в дисководе другая.

Voldemar0 пишет:

Контакт 2 должен менять скорость привода, но также и АЧХ усилителя чтения.
Но, судя по спектрограммам, каждый производитель видит это слегка по разному

На мой взгляд, эта гистограмма хотя и похожа на АЧХ, но не совсем АЧХ.

С дисковода ведь идет не просто усиленный сигнал с головки, квантованный по уровням ТТЛ. Там после усилителя идут дифференциатор и два одновибратора. Дифференциатор определяет: напряжение с головки растет или падает?
В этот момент мы уже теряем информацию об уровне сигнала - мы видим только в какую сторону он меняется.

Если начать снижать уровень сигнала на какой-то частоте, этого не будет видно до определенного момента. А вот когда сигнал упадет настолько, что начнут влиять шумы усилителя, то тут мы увидим "размывание" пика и снижение его высоты.

Кстати, дифференциатор может сделать заметными нелинейные искажения. Если с усилителя пришел сигнал с очень большим уровнем третьей гармоники, то можно легко вместо одного импульса получить три.

На выходе дисковода есть одновибратор, который формирует выходной импульс. Интервал короче, чем вырабатывает этот одновибратор, мы просто не увидим никогда.

Второй одновибратор, как я понимаю, отвечает за минимальный интервал между выходными импульсами. Может, усилитель видит сигнал в 3 МГц, но одновибратор это все обрежет по уровню 1 МГц (потому что до окончания импульса он заново не запустится).

Короче, мы видим на гистограмме какое-то распределение длительностей импульсов, но на это распределение влияет еще куча факторов кроме самой АЧХ.

118

Re: Мост # 3 - специализированный компьютер для чтения дискет

Мож кто знает и подскажет:
как на вг93 -совместимых форматах считается crc полей ?
В доках на i8272 нет подробностей, в доке на вг93

                      15    12    5
                 A = X   + X   + X  + 1

и тоже ни слова больше. В исходниках флюксы полином 0x1021 и считается CRC16,
но судя по вики, если старшая степень 15 - то и crc15 должна быть?
Я тут плаваю сильно :(

Вот для примера адресные поля (CHRN и два байта CRC, как они прочитались с дискеты):
  char x1[] = { 0x00, 0x01, 0x09, 0x02, 0x74, 0xf6 };
  char x2[] = { 0x00, 0x01, 0x02, 0x02, 0xa8, 0x0c };
  char x3[] = { 0x00, 0x01, 0x03, 0x02, 0x9b, 0x3d };
  char x4[] = { 0x00, 0x01, 0x04, 0x02, 0x02, 0xaa };
  char x5[] = { 0x00, 0x01, 0x08, 0x02, 0x47, 0xc7 };
Но я их как ни считаю, у меня не совпадает:
в первой строке у меня получается crc  = 0xADEA . Что по этой ссылке
http://www.sunshine2k.de/coding/javascr … rc_js.html
что используя процедуру из флюксы.

119

Re: Мост # 3 - специализированный компьютер для чтения дискет

x^15 - 100% опечатка. В даташите на WD179X правильный полином: x^16 + x^12 + x^5 + 1

Число после слова CRC - это число бит в контрольной сумме. Можно хоть 13 бит сделать, но зачем?

Алгоритм называется CRC-16/CCITT-FALSE. Кстати тут http://forum.agatcomp.ru//viewtopic.php?pid=6188#p6188 есть его реализация под Агат :)

Что касается расчета полей, то, в общем, в даташите на WD179X почти все написано :) На дисках в режиме MFM при записи адресного поля пишутся 3 байта 0xA1 и один 0xFE. Генератор контрольной суммы инициализируется при записи первого байта 0xA1. Все эти значения байтов участвуют в расчете CRC. Поэтому считать надо вот такие массивы:

  0xa1, 0xa1, 0xa1, 0xfe, 0x00, 0x01, 0x09, 0x02 => 0x74f6
  0xa1, 0xa1, 0xa1, 0xfe, 0x00, 0x01, 0x02, 0x02 => 0xa80c
  0xa1, 0xa1, 0xa1, 0xfe, 0x00, 0x01, 0x03, 0x02 => 0x9b3d
  0xa1, 0xa1, 0xa1, 0xfe, 0x00, 0x01, 0x04, 0x02 => 0x02aa
  0xa1, 0xa1, 0xa1, 0xfe, 0x00, 0x01, 0x08, 0x02 => 0x47c7

То же самое с данными.

120

Re: Мост # 3 - специализированный компьютер для чтения дискет

Во, спасибо!
Так работает хотя бы с процедурой из флюксы. Но там используется алгоритм с двумя вложенными циклами.
Надо будет покопаться, вроде бы должен быть табличный алгоритм с одним циклом.

121 Отредактировано Voldemar0 (25-01-2023 21:51)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Че-то я с этими байтами 0xA1 погрузился в пучину полного непонимания.
Это же специальный синхробайт, содержащий две битовых цепочки, одна из которых или обе сразу не будут корректны с точки зрения декодера MFM. Заметив это, он должен как-то синхронизоваться: по номеру бита в декодированном байте и по фазе data/sync.

В агате всё просто: любая некорректная цепочка сбрасывает счётчик бит и меняет фазу декодера. Соответственно, любая первая цепочка даёт неправильную синхронизацию data/sync (либо, если декодер уже в неправильной синхронизации, он не увидит тут ошибки), а вторая срабатывает гарантированно, возвращая фазу в правильное положение и обнуляя счётчик бит. Дальше начинается уже синхронизованный байт.

А тут получается наоборот: вторая цепочка как раз стоит неправильно. Если по ней декодер сменит фазу, то дальше он уже ничего не прочитает правильно. А если не сменит - то по какому условию? Как он поймёт, что именно тут сейчас у него правильный синхробайт со специальной неправильной синхронизацией?

1) Если он накапливает байт имея правильную фазу data/sync, то у него ещё нет младших бит, есть только 5 полученных + 6й с убитой синхрой. Ну допустим он понял что байт правильный - тогда всё хорошо.

2) А если у него неправильная фаза, то он получит синхросбой уже на 3-м бите приёма. И что делать дальше ?

Возможно из-за этого пишутся именно 3 байта синхро - чтобы иметь больше гарантированно определённых бит.

Но вот сколько их надо ?
Как происходит синхронизация на синхробайте 0xC2 ?

Я порылся по коду флюксы, там всё сделано в лоб: берётся сигнатура (включая и синхробиты и биты данных) для всех трёх байт - итого 48 бит и ищется в битовом потоке. Это клёво, но я сомневаюсь, что на самом деле так работают железные контроллеры.

Но пока я не встречал подробного описания: во всяких темах про вг93 и совместимые микры просто говорится, что эти синхробайты есть, а как микруха их вылавливает - не объясняется.

122 Отредактировано avivanov76 (26-01-2023 01:16)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Я тут нашел потранзисторную схему ВГ93 (http://dlcorp.nedopc.com/viewtopic.php?f=21&t=1468) и понял её так. Есть детектор адресных меток (AM detector). Это сдвиговый регистр на 17 разрядов (ВГ93 использует динамическую логику, поэтому сдвиговый регистр - это просто цепочка инверторов и проходных транзисторов).

По сдвиговому регистру детектора непрерывно ползут биты синхронизации и данные. Сначала бит синхронизации, потом бит данных. У регистра от каждого разряда есть прямые и инверсные отводы. Они заводятся на большой элемент И, который и ловит адресную метку. Байт 0xA1 вместе с битами синхронизации и инвертированным битом синхросбоя образует значение 0x4489. Как только оно обнаружено - дергается триггер и разрешается прохождение битов в регистр данных. (Ну, вроде как, там схема - черт ногу сломит.)

Что касается расчета контрольной суммы - то у ее генератора есть специальные входы предустановки. Причем, генератор КС загружается так, будто он уже посчитал два байта 0xA1. То есть, ожидается, что из трех байт 0xA1 в регистр данных попадет только последний.

123 Отредактировано Voldemar0 (26-01-2023 09:26)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Как говорила Шахерезада: - Если даже этой истории не случилось на самом деле, её стоило выдумать :))

Ну да, если там реально наколбасили 17 разрядов памяти и большой элемент И, то почему бы и нет.
Но то, что в расчёт КС воткнута предустановка на предыдущие 2 байта, явно подсказывает нам, что даже если первых пары байт не было, то они всё равно есть. И это тоже полезно знать.

Значит так и попробую всё сделать.

Интересно только, на кой им тогда целых три байта ? Если диск настолько плох, что из трёх байт выживает только один, то нафига такая дискета вообще нужна.
Могло ли это быть связано с поддержкой FM-формата? Или это какое-то ещё легаси ?

И ещё: получается, что контроллер не мог опознать ошибки синхронизации в процессе чтения последующих полей?
Т.е. если он нашёл любимый A1, то дальше у него гейт приёма открыт и он просто выщёлкивает биты синхро, а оставляет только биты данных и остальное ему безразлично ? Впрочем, при 16 битах КС, скорее всего, ловля синхросбоев уже бы не была особенно эффективна как детектор ошибок.

124 Отредактировано Voldemar0 (27-01-2023 07:55)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Заработала ! :))

В общем, закончил прогу для конвертации eim3- в dsk трех форматов: 840, 140 и PC.

/* Не, ну "закончил" - это вряд ли, скорее - "реализовал основной функционал". Наверняка потом ещё буду регулярно что-то менять. */

Под PC тут понимается любой подвид этого формата: разные объёмы дисков + разные размеры секторов + разная плотность записи. Не стал делать поддержку FM-режима для PC.

При этом проги для снятия eim3- пока нет :)
Прога, которая читает дорожки для спектроанализатора, закидывает их и в eim3, не проверяя ничего - т.е. один оборот на дорожку.
Но тот десяток дисков, на которых я экспериментирую, при этом почти полностью удаётся декодировать.
В том числе прога сразу разбирает для двухголовочных флопиков обе стороны 140ки (без 4 начальных треков на B side).

Прога автоматом перебирает ряд параметров декодеров пока не сможет декодировать все сектора. Но пока в ней нет автоматического определения формата. Нужно явно указать его и можно дополнительно указать хинты: количество секторов на дорожке для PC, количество голов дисковода, rpm, tpi... Вся эта инфа будет храниться в Eim3, в дальнешем, возможно, прога будет брать всё оттуда, но пока вручную.

У меня привод 140ка иногда дуркует со скоростью: слышно что мотор отключается и тут же снова заводится. Процесс хаотичный, полных остановок не бывает и происходит это редко, может несколько раз за одно чтение диска. Удавалось вытянуть даже такие сбои, заодно выяснилось, что скорость успевает упасть почти на 20%.

Так что специально не ремонтирую привод :)

--

Теперь остаётся несколько мелких задач и одна крупная.
Крупная:

- Надо делать полный автомат управления параметрами декодеров. Т.е. чтобы он мог сперва определить формат, а затем подгонять параметры и затем перечитывать несколько раз дорожку, возможно, с перекалибровкой и/или шевелением головки.

Мелкие:

- Внедрять сигнал индекса в массив интервалов дорожки. Это не очень просто, надо будет в момент запуска семплера запускать также ожидание индекса и следить за временем.

- Прога Скорость для 140ки. Фактически, декодер L4 (это последний этап декодирования), по ходу своих дел, подсчитывает количество raw-бит за один оборот, а так как таймслот бита известен, то можно скорость вычислить. Но в случае, например, прохождения синхросимволов может возникать некоторая ошибка, так как некоторые биты выпадают в момент синхронизации декодеров L3. Мост2 решал это запуская железный таймер и налету декодируя адресные поля, но здесь как раз "налету" не работает в силу архитектуры железа. Варианта два: либо делаем вид, что ошибка не существенная либо нужно делать какой-то отдельный вариант цепочки декодеров (пусть максимально простой), которая сможет протащить информацию о времени от самого низа (где ещё все интервалы времени присутствуют) до верха (где уже декодируются адресные поля). Пока не решил, что выбрать. Видимо, сперва буду довольствоваться тем, что есть, а там можно и дописать более точную измерялку.

- Регулируемый уровень журналирования для декодеров. Сейчас прога декодирования eim3 валит до сотни Мб логов. Там всё обо всём, хотя тут даже не рассматривается побитовый уровень. Она докладывает только о найденных адресных полях и полях данных, об используемых параметрах декодеров, об итогах каждой попытки разбора дорожки, с таблицей информации о каждом секторе, о спектрах дорожек. Если подкрутить параметры компиляции, декодеры L2 начнут ещё сообщать обо всех найденных битах и параметрах сдвига окна приёма, декодеры L3 - обо всех синхросбоях и синхросимволах ... в общем, там будут уже Гб логов. Двух уровней, регулируемых только перекомпиляцией, уже не хватает.

- Перенести поддержку формата flux в основной код декодера eim3 (сейчас это - отдельная прога, но основанная на тех же библиотеках).

- Для PC dsk сейчас сбойный сектор заполняется константой 0xBD (как для агата), но, наверное, для PC это не удачный подход.

- Нет поддержки формата DOS3.2 (13 секторов на дорожке). Однажды я видел такой диск :) Есть даже версия rawedit для этого формата.

--

На текущий момент загрузочный код всех модулей весит 100 кб (без символов отладки), прога декодирования eim3 - 65 кб.
Исходники: прога - 15 кб (500 строк), модули - 130 кб (4500 строк) (w/o headers). Всего около 20 модулей.

125 Отредактировано Voldemar0 (27-01-2023 11:29)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Сейчас ещё обдумываю одну мысль:

Если мы читаем PC-шный формат, то сколько там должно быть секторов на дорожке?
Да и сколько треков тоже ? Можно же форматнуть и 80й цилиндр и 81й - я сам таким занимался в 90-е.

Например, на треке 0 распознано 9 секторов, на треке 1 - 10 секторов.
Это 0 трек недочитался и это формат 80x10 или это 1 трек остался от предыдущего форматирования, а на самом деле последний формат - 40x9 ?

Похоже, это приводит к тому, что надо сперва быстро просмотреть весь диск на дефолтных настройках декодеров и оценить его формат сперва. А уже потом вчитываться в то, что - судя по подобранному формату - недочиталось.

И тут возникает вторая мысль: если этот же подход применить к агатовским дискам, то можно сперва читать трек 17 и изучать каталог. Если в нём не крупных ошибок, то пристально вычитывать только сектора, на которые есть ссылки из vtoc или сектора, объявленные занятыми в tls. А полностью въедливо вычитывать диск только при недоступности служебных структур или при каких-то странных особенностях.

Имеет ли смысл с таким подходом лезть и анализировать boot-сектор для pc- пока не ясно. Если там fat - то вроде бы да, но тогда нужно быть уверенным, что это именно fat, а не что-то похожее на него.