Мост # 3 - специализированный компьютер для чтения дискет (Страница 4 из 7)

У меня заработало нормально (MacOS 10.15, Safari).
Кнопки управления работали хорошо.
Оно прямо к реальному дисководу подключено?

Прикольно. Если двигать головой, то иногда проскакивают странные значения (или не выводится никаких):

The head on the track   9,   -2 turnovers
The head on the track  11,   -2 turnovers
The head on the track  11,   -1 turnovers
The head on the track  11,    0 turnovers
The head on the track  11,    1 turnovers, instant time 199.42 ms, average time 199.4241 ms
The head on the track  11,    2 turnovers, instant time 199.43 ms, average time 199.4261 ms
The head on the track  11,    3 turnovers, instant time 398.86 ms, average time 265.9038 ms
The head on the track  11,    4 turnovers, instant time 398.85 ms, average time 299.1401 ms
The head on the track  11,    5 turnovers, instant time 598.27 ms, average time 358.9661 ms
The head on the track  11,    6 turnovers, instant time 199.44 ms, average time 332.3781 ms

"The head on the track" - тут куда-то сказуемое пропало. "The head is on the track".

Turnover - это, кстати, не тот оборот. Это денежный оборот или пропускная способность. А здесь нужно просто turn(s). Еще можно revolution или rotation.

И вот тут странное написано "The head on the track   0, long time... no the index signal". "No" значит "никакой", "the" значит "этот, конкретный". Уже противоречие. Ну и два артикля у существительного быть не должно.

Кнопка "-" возле поля "номер" забавно себя ведет: переключает значение между 0 и 1.

И еще любопытно: "Package version 0.97 (Trollholmsund)". Это, типа внутреннее имя? Я помню, что программка для снятия дампов тоже пишет что-то по норвежски.

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

==

Зарегил лог странного сбоя, когда при движении головки первые отсчёты сбиваются.

Явно теряются события фронта/спада. Это странно, надо будет порыться на эту тему в инете.
Но почему именно при движении головки - как раз понятно: при нажатии любой клавиши фронт отсылает беку нажатые клавиши,
а автоповтор у меня - 40 знаков в секунду (Каждое нажатие - новое TCP/HTTP-соединение. У форума такой нагрузки нет :). Проц моста загружается под 80% и, видимо, дальше что-то ломается в логике GPIO-драйверов.

Заодно узнал, что сама прога Скорость грузит проц меньше чем на 1%, ещё 15% жрёт UI-server (он обслуживает экраны и клавиатуру на плате, а заодно и буферизует очередь нажатых кнопок для бэкэнда). Но зачем ему 15% - я догадываюсь: он симулирует через bitbang тот лютый протокол a'la "обгрызанный i2c", который использует контроллер дисплея и клавиатуры tm1637. Загруз, скорее всего, связан с постоянным (каждый оборот) опросом клавиатуры (десяток байт на оборот флопика). Надо будет прореживать его, на будущее... Может быть.

И ещё 15% времени уходит на разное другое общение с web-сервером (если не нажимать кнопки).
Если открыть статические страницы - эта нагрузка пропадает.

==

Мост будет доступен ещё несколько дней. Адрес у него динамический, может в любой момент соскочить, да и после выходных режим разработки будет меняться.

Сделанных разработок по web-интерфейсу на ближашие месяцы хватит, может только чуть подпиливать придётся.
Я теперь займусь плотненько вопросами обмена с семплером.
Там должна начатся самая вкуснятка :)))

Вычёсываю один из нагруженных кодов обработки: код преобразования битовой последовательности от семплера в длительности интервалов между импульсами.

Получая очередное слово (переменная v, 32 бита), его нужно проанализировать побитно в таком цикле:

  (в комментариях: приблизительный ARM-ассемблер для случая "-O0" - отключенная оптимизация компилятором)

    for (int bit = 31; bit >= 0; bit--) {

#  ifdef RAISE1
/*
        ldr     r3, [r7, #16]   @ tmp139, pv
        mvns    r2, r3  @ _4, tmp139
        ldr     r3, [r7, #20]   @ tmp140, v
        ands    r3, r3, r2      @, _5, tmp140, _4
        cmp     r3, #0  @ _6,
        bge     .L9             @,
                timedraw(PLT)
L9:
        ldr     r3, [r7, #20]   @ tmp141, v
        str     r3, [r7, #16]   @ tmp141, pv
*/

      if (v & (pv ^ 0xFFFFFFFF) & 0x80000000) {
        timereg((u_int8_t *)buf, bits_interval, out_addr);
      }
      pv = v;
#  else
/*     Raise2
        ldr     r2, [r7, #20]   @ tmp138, v
        ldr     r3, [r7, #16]   @ tmp139, pv
.LVL20:
        eors    r3, r3, r2      @, _4, tmp139, tmp138
        cmp     r3, #0  @ _5,
        bge     .L9             @,
        ldr     r3, [r7, #20]   @ tmp140, v
        cmp     r3, #-2147483648        @ tmp140,
        beq     .L10            @,
                timedraw(PLT)
L10:
        ldr
        str
L9:
*/
      if ((v ^ pv) & 0x80000000) {
        if (v & 0x80000000) {
          timereg((u_int8_t *)buf, bits_interval, out_addr);
        }
        pv = v;
      }
#  endif
      v <<= 1;
      bits_interval++;
    }

Если находим смену потока нулей на поток единиц, процедурой timereg() (макрос фактически)
регистрируем интервал (накапливается в bits_interval) от предыдущего фронта до текущего.

Два варианта алгоритма: Raise1 и Raise2.

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

Какой будет быстрее ? По асму видно, что само количество команд процессора примерно одинаковое.

Сравнил 8 вариантов: для imx6 и PC с процом E5200, для двух вариантов оптимизации кода (-O0 и -O2) и для двух алгоритмов:
Raise1:
PC: -O2 t = 0.19, -O0 t = 0.28;
arm: -O2 t = 0.82, -O0 t = 3.63

Raise2:
PC: -O2 t = 0.21, -O0 t = 0.25;
arm: -O2 t = 0.59, -O0 t = 3.19

Время в секундах ("t = ...") на обработку входного массива 8 Мб (случайные значения, немного похожие на запись 140ки).

Итого:
- Для этой процедуры важно включить оптимизацию кода компилятором (-O2)
-  Вариант с двумя IF почти всегда немного быстрее. Да, ветвление, но компиляция более сложного условия даёт примерно такой же код, но, вероятно, вынос из каждой итерации "pv = v"  (пара комманд ассемблера на -O0 и, вероятно, одна на -O2) всё таки даёт некоторый прирост скорости.

-==-

Этот код должен перемолоть на каждый трек примерно 220 Кб данных примерно в 30 Кб для дальнейших алгоритмов.
Его работа не зависит ни от чего больше (т.е. алгоритм единственный и не выбирается), важен он для любого вида чтения данных
и для любого дисковода.
Можно прикинуть, что на этот шаг уйдёт для Raise2 с -O2  где-то 0.016 секунды, что вполне терпимо.

-==-

А на "AMD Ryzen3 1200" Raise2 явно проигрывает: 0.062с против 0.045с для -O2, и 0.199с против 0.194с на -O0.

Мысль интересная, работает, но по скорости не дотягивает до Raise2.
Почему - не ясно.

При отключенной оптимизации твой алгоритм опережает мои:
PC: raise1: 0.29; raise2: 0.26; aviv: 0.21.
arm: raise1: 3.61; raise2: 3.18; aviv: 3.00.

Но на включенной оптимизации (в предыдущем сообщении для PC были ошибки):
PC: raise1: 0.13; raise2: 0.13; aviv: 0.11.
arm: raise1: 0.81; raise2: 0.59; aviv: 0.78.  Тут в лидеры выбивается raise2.

Я пытался разобраться в оптимизированном коде, но я плохо понимаю работу команды "IT" (IfThen),
а она там часто встречается. В общем, не хватает знаний по arm'овскому ассемблеру.
А код получается довольно витиеватый. Да и неплохо было бы знать тайминги отдельных команд.

Причем различия в коде касаются не только изменяющихся строк, но и соседних, в т.ч. timereg().
Компилятор явно пытается всякие сложения и инкременты тасовать ( "bits_interval + 1" использует затем в "bits_interval++" ), в то же время некоторые операции он, похоже, начинает дублировать (какой-то reorder операций?).

Твоя версия:

Raise2:

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

Попробовал. Вы будете смеятся, но нынешние компиляторы очень умные :)
Он сообразил, что число итераций не изменилось, а переменная цикла нигде не участвует и не стал вообще ничего менять в коде :)
Так-то лишних команд вроде нет: mod r2, #31 / subs    r2, r2, #1 / bne
cmp не нужна. Он счастлив вполне :)
Ожидаемо, скорости тоже нигде не изменились.

Запилил значительно модифицированный драйвер spidev.c, разобрал ряд разных случаев его использования (как модифицированной, так и не модифицированной версии) и пришел к выводу, что есть некий потолок, связанный с архитектурой SPI в линухе, который не позволяет прыгнуть выше примерно 1 МБайт / секунду на моём железе.
Все игры с переносом между ядром и прогой и вылизыванием алгоритмов компрессии на самом деле мало на что влияют. (Да, кстати: модули ядра собираются с оптимизацией -O2, как выяснилось). Для себя составил конспект с цифрами различных скоростей в различных конфигурациях, но здесь его, наверное, нет смысла публиковать.

Самое мощное ускорение принесли пакетные запросы: это когда на уровень драйвера железа запросы на чтение скидываются не по одному (это примерно 64 байта за запрос - потолок железа), а пакетами, штук по 10 (в сумме примерно 600 байт за одно обращение к драйверу железа). И не важно: формировать ли их в драйвере более высокого уровня (уже на универсальном уровне, не связанном с конкретным железом) или же в пользовательской программе. Небольшая разница по скорости есть, но уже где-то в районе десятка процентов.

В то же время отчётливо видно, что ЦПУ не всегда загружен, т.е. пока идёт обмен, нагрузка на проц постоянно прыгает - можно использовать его в других целях. Теоретически, можно попробовать в это время как раз выполнять компрессию очередного блока данных, но оценка показывает, что это вряд ли даст офигенный прирост скорости, а вот сложности в драйвере spidev.c прибавит. Сейчас он строго синхронный, т.е. там нет никакого распараллеливания обработки и у меня нет достаточного скила для перепиливания его в многопоточный вариант.
При этом сейчас получить дорожку из семплера (и сразу сжатую внутри драйвера) стоит 0.255 секунды, из которых, по косвенной оценке:
0.238 секунды на чтение данных и 0.017 секунды на компрессию.
Т.е. выигрыш при распараллеливании составит, максимум, процентов 10. Ни о чём.

Таким образом, работу по этой части я пока считаю завершенной.

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

Фактически, я получил что-то вроде флюксы или SCP, только без PC-шной части софта.

< ....если по отладочному порту подключить Мост3 к ППИ Агата..... но тут фантазия упирается в стенку :) >

-=-=

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

А вот в выскоуровневых языках как раз как-то вроде нет примеров какого-то синтаксиса, который бы позволял указать более вероятный результат для IF, например.
https://runebook.dev/ru/docs/cpp/langua … tes/likely
? реально работает ?

Ня :) SD-формат (720k), PC

Track 9 [49649 byte(s)], spectrum maximum on point  4.00 mks [index = 32, value = 30047]:
15023/30047 -                                 *                                                                                               
 7511/30047 -                                 *                                                                                               
 3755/30047 -                                **               *                                                                               
 1877/30047 -                                ***              *                                                                               
  938/30047 -                                ***             ***                                                                              
  469/30047 -                                ***             ***                                                                              
  234/30047 -                                ***             ***             ***                                                              
  117/30047 -                                ***            ****             ***                                                              
   58/30047 -                                ***            *****           ****                                                              
   29/30047 -   *                            ***            *****           *****                                                             
   14/30047 -   *                           ****            *****           *****                                                             
    7/30047 -   *                           ****            *****          ******                                                             
    3/30047 -   *                        *******            *****          ******                                                             
    1/30047 -   *    *            *  *   ******* *         ******          ******  * *                                        *               
    0/30047 -   **   **           ****************    **   ******* *     ********  * **                               *       *               
_____/_____ - 00 mks  01 mks  02 mks  03 mks  04 mks  05 mks  06 mks  07 mks  08 mks  09 mks  10 mks  11 mks  12 mks  13 mks  14 mks  15 mks  

  Track 10 [51181 byte(s)], spectrum maximum on point  4.00 mks [index = 32, value = 35739]:
17869/35739 -                                 *                                                                                               
 8934/35739 -                                 *                                                                                               
 4467/35739 -                                **                                                                                               
 2233/35739 -                                **               *                                                                               
 1116/35739 -                                ***             ***                                                                              
  558/35739 -                                ***             ***                                                                              
  279/35739 -                                ***             ***                                                                              
  139/35739 -                                ***             ***             **                                                               
   69/35739 -                                ***             ***             ***                                                              
   34/35739 -   *                            ***            *****            ***                                                              
   17/35739 -   *                            ***            *****            ***                                                              
    8/35739 -   *                            ***            *****           ****                                                              
    4/35739 -   *                        ** ****            *****           *****                                                             
    2/35739 -   *    *             *     ** ****            *****        *  *****                                                             
    1/35739 -   *    *             *     *******         *  *****        *  ******   *                                                        
_____/_____ - 00 mks  01 mks  02 mks  03 mks  04 mks  05 mks  06 mks  07 mks  08 mks  09 mks  10 mks  11 mks  12 mks  13 mks  14 mks  15 mks  

Кажется, вертикальная шкала такого типа должна называться "логарифмическая, с основанием 2" ?

> Кто-нибудь возьмется утверждать, что у ARM упрощенный набор команд?

Против 6502 - сложный :))

> Класс! Надо запомнить, вдруг пригодится.

Учти, что likely - это макрос. Он определён в исходниках ядра линуха, но не определён в общесистемых /usr/include .
Точнее говоря: определён, но не доступен во всяких stdio.h, stdlib.h....
Причем его определения в /usr/include и в ядре немного отличаются.
Я использовал вариант из ядра:

# define likely(x)      __builtin_expect(!!(x), 1)
# define unlikely(x)    __builtin_expect(!!(x), 0)

И ещё тут интересная статья, в т.ч. комментарии к ней.
https://blog.aaronballman.com/2020/08/d … ttributes/
В комментариях, если я верно понял, говорят о том, что фича стандартная для C++,
но не стандартная для C и у GCC она реализована не так, как рекомендуется для C++.

--

> Это чего, гистограмма что ли? Свят, свят, свят!

Наверное это правильнее назвать "гистограмма спектра сигнала".

Очень легко строится (30 строк исходника) и позволяет сразу выявить некоторые особенности записи. Оценить (в сравнении двух спектров) уровень ошибок, формат записи (140 vs 840), ошибку скоростей между записью и чтением...
Я с неё начинал разработку софта для scp и флюксы.

> Какой-то "звон" отсемплировался?
Возможно, финальная сигнатура.
Она вводится для обнаружения конца захвата.
В начале дорожки тоже есть нечто подобное; наверное, уберу это позднее.

Выходные закончились, не знаю как пойдёт дальше, но за последнюю неделю успел многое.

==

a) Проработал архитектуру стека декодеров.
Декодеров 4 слоя:

1) Преобразование битового потока в массив интервалов. Сейчас сидит в драйвере spidev.c.

Для тестов также написал простой конвертор из sql3-файлов fluxengine в формат близкий к тому, что даёт spidev.c.
(есть несколько давно снятых образов; чтобы при отладке иметь хорошую повторяемость ошибок важно чтобы и данные были каждый раз одинаковыми). Слоистая структура цепочки декодирования позволяет легко менять слои.

2) Преобразование массива интервалов в массив исходных нулей и единичек MFM/GCR-кодера.
Т.е., например, для GCR: интервалы 2.0-6.0 mks - это "1", 6.0-10.0 mks - "10" и т.д.

Этот слой - самая замысловатая часть. Именно тут происходит компенсация ошибок скоростей дисководов, учёт скоростей (300/360 rpm), фазовые ошибки и всё такое.

У меня есть код для флюксы, написанный год-два назад на pascal, заточенный под offline-обработку образов флюксы на PC, широко использует плавающую точку. Этот код - не слоистый, архитектурно там "всё в одном". Я переписывал его под arm, под слои, стараясь перевести все на целочисленную арифметику.

После первоначальной отладки ещё пару дней ковырялся с финальными косяками.

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

Всё дело в том, что, в зависимости от типа ошибок (джиттер vs систематическая ошибка) алгоритмы коррекции будут противоположными. Джиттер: один импульс сдвинулся, значит, если интервал времени до него уменьшился, то после него увеличился. Если систематическая ошибка, то рост интервала до импульса показывает на то, что нужно ожидать роста интервала и после импульса.

Систематическая ошибка на дисководах довольно незначительная: 1-2%, полная ошибка (если пишущий дисковод имеет ошибку противоположную читающему) - 2-4%. Это почти незаметно и легко компенсируется тем, что, фактически, каждый новый импульс восстанавливает синхронизацию между устройством записи и устройством чтения. Джиттер же гораздо существеннее и именно его должен компенсировать умный алгоритм восстановления интервалов. Но джиттер случаен. А есть ещё фазовые искажения: один импульс "убегает" от другого на коротких интервалах или "притягивается" к другому на длинных. Это должно частично устраняться предкомпенсацией записи, но она работает с 2-3 зонами (у 840ки агата их три, у PC-совместимых - две, вроде бы), внутри зоны каждая соседняя дорожка немного отличается от предыдущей, а значит, если даже какая-то одна дорожка будет идеальной, то соседние всё равно будет иметь более или менее заметные фазовые искажения.

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

140ка имеет бОльшие интервалы, чем 840ка, и большее окно захвата очередного бита. В результате, она практически нечувствительна к фазовым искажениям (они заметно меньше окна захвата), не требует предкомпенсации записи, но отказ от последних 5 дорожек (35-40) в 140ке, вероятно, как раз и вызван тем, что там уже проще было не хранить данные, чем накручивать сложности для борьбы с фазовыми искажениями. Соответственно, она требует только борьбы с джиттером. Всё в угоду снижению ценника. Итог: 4.00 кб / дорожку.

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

Для меня всё равно ещё не всё прозрачно в этой теме, я уже пару раз брался за съёмки сцены для ролика, где пытался объяснить все эти сложности, каждый раз заходя в логические тупики.

Но сейчас я хотя бы понял, почему вообще к 140ке и 840ке лучше подходят разные алгоритмы коррекции ошибок.

Вторая проблема отладки слоя 2 была в отказе (точнее, вынесении "за скобки") арифметики с плавающей точкой. Там тоже пришлось повозится, чтобы выловить все потери точностей. В pascal-версии все интервалы времени считались в mks, теперь же все характерные времена заранее пересчитываются в тики задающего генератора семплера
и дальше вся математика работает с ними.

3) Слой 3 уже проще: тут из нулей и единиц, полученных от слоя 2 собирается изначальный байтовый поток дорожки. Если в слоях 1 и 2 алгоритмы не отличаются для различных форматов записи (140/840/PC-совместимые), меняются только настройки для слоя 2, то слой 3 - это уже разные алгоритмы, в зависимости от формата записи.
840 и PC похожи, различие в синхросимволах и их интерпретации. 140ка - сама по себе.
В этом слое и кода меньше и он устроен однозначнее, чем в слое 2.
Слой 3 может на выходе синтезировать старый eim-формат, использовавшийся в Мостах 2.
Для PC-формата слой 3 тоже выдаёт что-то вроде старого eim, но, вряд ли имеет смысл сохранять его в таком виде файлах, он будет использоваться только для передачи данных слою 4.

4) Слой 4 - это уже формирование DSK-образа для любого из форматов. Алгоритмы разные для разных форматов, но тоже однозначные. Можно как синтезировать DSK, так и только получить отчёт о корректности CRC или более развёрнутый отчёт (сколько раз встречались сектора, насколько успешно их удалось прочитать, были ли расхождения (многократные успешные чтения с совпадением CRC, но при этом с разными данным - такое бывает на 140ках)).
Отчёт о корректности без создания dsk важен для читалки: мы можем снимать образ в Eim3 (массивы интервалов времени - то, что снимают и флюкса и supercardpro), но при этом уже зная, что данные прочитались успешно.

Фактически, я тут честно тырил собственный код из RawEdit - программы для Мостов2, которые интерактивно работают со старыми eim. Тырить очень приятно, потому что rawedit - штука старая и хорошо вылизанная. Формально, читать образцовую дискету не сложно, но, в случае ошибок, этим алгоритмам есть где запутаться (Например: нашли поле адреса, за ним поле данных успешно прочиталось. Всё хорошо ? Нет. Возможно, нужное поле данных имеет повреждённый пролог, также повреждено и следующее поле адреса. А мы успешно прочитали поле данных другого сектора. Нужно было проверять расстояния между полями). Так что готовый код - это много готовых подсказок.

Для тестов сохранял из слоя 3 образы Eim, потом прогонял их через rawedit и через свеженаписанный 4 слой декодеров и сравнивал финальные dsk. Наловил несколько хитрых багов в новом коде (что-то вроде: что будет если аппартный индекс пройдёт строго между синхросимволом и прологом поля адреса или поля данных), но это всё быстро исправлялось. В самом rawedit ошибок вроде не нашлось :)

Код rawedit и "слоя4" не совпадают 1:1. RawEdit немного более сложен. Например, он очень подробно учитывает сигнал индекса (рисует его прямо над дампом дорожки), который для "слоя4" пока вообще не нужен. О некоторых особенностях дорожки "слой4" сообщает в лог и не хранит затем эту информацию, в то время как rawedit собирает подобную информацию и может, например, быстро гонять курсор между разными полями, экземплярами дорожки и т.д.

Слой 4 пока не закончен, есть только 840ка. Нужно ещё 140ку и PC-формат.

==

b) Собрал на плате RTC; всё таки убедился, что на плате неправильно подключено посадочное место для holder'а  батарейки (+/- перепутал). Вроде часики отзываются, надо будет батарейку воткнуть и погонять.

Собрал индикаторор читаемого трека: двухцветные светодиоды. Чтобы ровно запаять их все, привлёк супругу: у неё глазомер отличный и руки не дрожжат. Она смотрит сверху на диод и позиционирует его, я смотрю сбоку. Ей хорошо видно положение диода, а мне хорошо видна точка пайки. Так вдвоём всю линейку собрали довольно быстро.

Написал прикольную короткую демку и поддержку линейки в ui-server'е.
/*
Когда только начинал осваивать электронику, мечтал о переключателе гирлян для ёлки.
Первая конструкция в школьном радиокружке - простые бегущие (перемигивающиеся) огни.
Я мало понимал, как это работает, но увидел весь стек разработки: от простой схемы мультивибратора на бумаге
до законченного устройства. Две печатные платы: диодный мост+кондёр и сам мультивибратор с релюшкой на выходе. До сих пор люблю всякие бегающие огоньки :))
*/

Собрал интерфейс 140: семплер и силовые части. Но пока не проверял.

==

Дальше надо закончить слой 4 для 140ки и PC.

Проверить интерфейс 140ки и дописать управление этим приводом, включая всякие хитрые алгоритмы управления его головой.

И самое-самое: процедуру/библиотку автоопределения формата записи.
Декодеры L4 могут сообщать о том, похожа ли дорожка на известный им формат.
Также они сообщают, сколько секторов удалось вытащить при данном запросе и кумулятивно по всем попыткам.

Теперь нужно продумать decoders suites, как -то их описать в виде массива и вокруг этого выстроить перебор вариантов.
Комбинаций немало: (форматы 140+840+PC) x (скорости флопика 300/360) x (битрейты SD/HD для PC) x (таблицы ФАПЧ слоя2 - 5 штук) x (мелкая подстройка под скорость флопа: 0.96, 0.97, 0.98, 1.0, 1.02, 1.03, 1.04 - иногда внезапно это помогает, причём перебирать нужно не по порядку, выгоднее как-то так: 1.0, 0.97, 0.98, 0.96, 1.03, 1.02, 1.04...).

Перебирать нужно тоже не совсем по порядку: сперва грубо понять с каким исходным форматом имеем дело, потом уже подгонять детали. Исходить из того, что suitе, которая успешно прочитала предыдущую дорожку, скорее всего прочитает и следующую.

Можно накапливать долговременную статистику внутри устройства: какие suit'ы чаще всего успешно читали разные дорожки на разных приводах. И исходить из неё. Такой себе ИИ.

Не совсем ясно, что выгоднее: несколько раз перечитать дорожку или сменить suite ? Один оборот, проверка с текущей цепочкой, ещё оборот, опять пробуем текущую, затем ещё два оборота и пробуем перебор разных цепочек для всех 4 оборотов ?...

Данные не обязательно прогонять через весь стек для каждого формата: сперва слой 1 - универсальный для всех форматов. Потом слой 2 - отдельные настройки для 140кб, отдельные настройки для 840кб и PC/SD (т.е. можно для этих двух форматов не повторять вызов слоя 2, но это не всегда прокатит: небольшая поправка на то, что у 840ки битрейт немного сдвинут из-за вариантов кварцев, иногда заметно улучшает результат чтения), отдельные настройки для PC/HD. Но отдельные обращения к слою 2 в зависимости от скорости вращения флопика.

Кроме того у PC-совместимых может быть разное количество секторов даже в рамках одной плотности записи.
И разный размер сектора.

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

Поскольку, софт пишется как набор отдельных библиотек-слоёв, то где-то как-то это должно позволять заменой самого нижнего слоя (т.е. источника массива интервалов) использовать весь стек не только для декодирования данных с Моста 3, но и для офлайновой работы, в т.ч. с другими устройствами захвата.