Понемногу тестируем используя два экземпляра моста3.

Вносятся некоторые правки, в основном касающиеся web-интерфеса и немного затрагивающие программы, непосредственно работающие с дисками.

Есть пара-тройка больших достижений:

1) Дописана прога замера скорости 140кб.  Её особенность в том, что так как индекса на этом приводе нет, приходится читать магнитную запись и делать измерение по ней. Т.е. декодировать адресные поля, но сохраняя при этом первоначальные тайминги читаемого с поверхности потока. Цепочка декодеров, которая используется в остальном софте, так делать не умеет. Поэтому для 140ки я дописал сложнейший код (как я думал, поэтому долго его откладывал) размеров 80 строк и 3 процедуры. Одна процедура собирает биты из потока, вторая складывает их в байты и если находит пролог адресного поля, сразу декодирует его (там FM-кодирование), вытягивая номер трека и номер сектора. И третья процедура запускает дважды вторую, находя повтор какого нибудь адресного поля, после чего замеряет время между первой и второй копией одного и того же адресного поля.

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

3) Я покопался в коде линухового ядра, который умеет изображать USB-device. К сожалению, код, который умеет изображать накопитель данных (mass storage) завязан на понятие драйвера блочного устройства, т.е. по простому пробросить флопик через USB наружу не получится. Это надо, фактически, писать собственный блочный драйвер, который будет работать внутри ядра.
Зато удалось разобрать вопрос о пробросе IP over USB. Там куча протоколов и стандартов, которые заменялись в течение последних лет. В чём полезно для моста3: это позволит протащить web-интерфейс и его настройку через USB, минуя физический Ethernet и упростив, таким образом, подключение моста напрямую к компу (например, к ноуту на выезде). Естесно, с сохранением web-интерфейса.

2 и 3 пункты пока в процессе, но некоторые проведённые тесты обнадеживают.

==

Ошибок в коде читалок пока не находилось. До вчерашнего дня.
Ошибка интересная и я решил её описать.

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

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

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

И, наконец, я заметил совсем странное: в потоке, сразу за эпилогом шел интересный байт со значением $80.

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

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

Почему их не было ? Вероятно потому, что либо форматтер этих дисков выключал запись сразу после записи адресного поля и дисковод затирал несколько бит "по инерции" либо, в момент начала записи поля данных, также возникала пауза в битовом потоке

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

Я залез в собственные статьи по работе 140-го контроллера и обнаружил, в чём тут дело:
стандартный контроллер 140ки имеет две фазы чтения байта: чтение первых двух бит (D7 и D6) и остальных бит.
Пока он ожидает прихода D7 очередного байта он игнорирует все входящие нули (независимо от их количества).
Но когда единичка D7 пришла, остальные биты он будет хватать с дисковода независимо от их количества и значения.

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

Но именно при записи эпилога поля происходит следующее: записываются байт $DE, затем $AA, после чего в контроллер закидывается ещё один байт, после чего драйвер выключает режим записи. При этом запись последнего байта не гарантируется (а точнее - от него едва ли успеет записаться хотя бы один бит).

Второй байт ($AA) выглядит как 1010 1010 - дальше идёт неопределённость. Может быть дисковод при выключении записи дёрнет ток в записывающей головке, может быть нет. Может раньше может позже. Это не регламентируется.
Если после 1010 1010 мелькнёт ещё 11 или 01 или 10 - то мой код будет считать его нормальным новым байтом и байт $AA перейдёт от декодера 3 к декодеру 4 (который собирает из отдельных байт поля адреса и данных). Но если после 1010 1010 наступит тишина, то декодер уровня 3 увидит бесконечный ноль и просто заменит уже почти накопленный байт $AA (без одного бита) байтом $80. И уровень 4 не найдёт последний байт эпилога и забракует адресное поле.

Соответственно, я изменил логику таким образом: если накапливаемый байт не равен 0 (ноль означает, что байт уже ушел с уровня 3 на уровень 4 и мы ждём очередную единичку - т.е. байт как бы был прочитан ЦП из контроллера). то при получении бесконечного нуля на входе то, что накоплено в буфере байта, сдвигается максимально влево { while ((obuf & 0x80) == 0) obuf <<= 1; } и отдаётся из уровня 3 на уровень 4, а уже потом в поток добавляется маркер $80 и тоже отдаётся на уровень 4. Он не нужен уровню 4, но он попадёт в промежуточный .eim-файл и, при разборе инцедентов, его можно будет увидеть в редакторе RawEdit.

PS Так как мост2 использует практически оригинальную схему эпловского дешифратора потока, он этой проблемме не подвержен.
Я проверил - он эти диски снял без проблем.

==

Интересность тут в том, что на своих дисках я не сталкивался с этой ошибкой.
Возможно потому, что мост2, которым записано большинство оставшихся у меня дисков, пишет трек за раз, не выключая запись, а те старые диски, которые были записаны ещё в конце 80-х, тоже писались копировщиком ИКП, который, возможно, тоже умеет писать трек за раз.
А может быть дело в дисководах. Может быть даже в экземпляре дисководов. Выключить запись, вероятно, можно по разному или в чуть разный момент. Если контроллер успевает выставить третий байт на запись - хотя бы один бит - ошибка бы уже не проявлялась.
Это может зависеть и от драйвера.

Очень странное чувство - вот вроде сегодня вычитывал диски, но при этом комп старый (у которого есть LPT) с антресоли не доставал, столик раскладной не подтаскивал, контроллер в мост2 не вставлял, MS-DOS не загружал.... и вообще почти ничего не делал.

Это еще что. Вставляю диск, а мост, хитрец, сам определяет от какой системы диск, и начинает читать, да еще и потом перечитывать сбойные места, если такие попались.

Хожу по квартире, занимаюсь своими делами, а мост3 сам всё делает, а диски менять его научить можно? :). И дружески так подмигивает мне лампочками. Надо сказать, что мы сразу поладили.

Жаль, что нельзя определять присутствие дисководов подключенных к мосту и в случае с правым (MFM) его тип (кол-во сторон, плотность), а как это РС делает?

Суть её в том, что firefox имеет странное поведение, не совпадающее с Chrome, например.
Когда FF восстанавливает вкладки при открытии браузера (если выставлен соответствующий режим),
он восстанавливает также значения полей в формах. Но похоже, что при этом, в интерпретаторе javascript,
автоматически синтезируется событие onchange.

Получается странная коллизия: мы ещё не запросили (или не получили ответ, например, если Мост3 сейчас выключен) конфиг-файл с шаблонами и номерами имён образов, но уже вынуждены их сохранить (onchange автоматически вызывает процедуру сохранения).
Ну хорошо, допустим, FF всё вытащил из своих хранилищ и прощелкал по всем полям onchange и всё ушло на сохранение в Мост3. Но вот что интересно: текстовые поля ввода восстанавливаются и синтезируют соответствующие поля конфига в памяти JS правильно, но не поле checkbox. На него события нет. Получается, что на сохранение в устройство уходит файл без only140, который как раз является checkbox.

Тут немного обсуждают эту штуку:
https://stackoverflow.com/questions/307 … ab-restore
и даже вроде как признали это багом, пока не исправили.

А тут оказывается, что вопрос про сохранение значений checkbox пока открытый:
https://wiki.mozilla.org/Session_Restor … o_be_saved

---

А когда-то мне довелось (в другом проекте) довольно долго бороться с тем, что некоторые браузеры пытаются даже синтезировать некоторые поля форм там, где этого совсем не требуется. Однажды у меня браузер решил, что очередное поле ввода является логином пользователя. И упорно делал автозаполнение. Попытки запретить autocomplete аттрибутом поля ни к чему не привели, также как и попытки явно задать значение поля пустым.
пришлось поставить таймер на одну секунду и через секунду после загрузки страницы, когда браузер уже выполнил автозаполнение, очищать поле.

===

На этом разработка Мост3 завершена.
В первое сообщение темы добавил все ссылки на видео и user manual.

Дальнейшее покажет опытная эксплуатация.

Время измеряется подсистемой GPIO, которая в ядре линуха. Она сообщает о времени (некоем внутриядерном) изменения уровня на пине. Т.е. что-то вроде очереди событий, каждое из которых содержит таймштамп и описание события (RISING/FALLING). На первый взгляд было бы логично, если бы эти события выстраивались в какой нибудь FIFO и оттуда выгребались программой.

Но, похоже, авторы этой подсистемы решили, что FIFO - это скучно. И не ясно - какого размера его делать ? Или вообще динамически выделять память (если программа сейчас ничего не читает - на сколько может распухнуть такой стек буквально за секунды, если частота воздействия на лапку будет, например, 100 КГц  ?)
Поэтому они сделали по простому: сообщают только время последнего события каждого типа.
Т.е. не успел выгрести из очереди очередной импульс - получишь тот, который успеешь. Т.е. последний. Сколько пропустил - неизвестно.

Проблема в том, что в зависимости от того, какая страница включена на OLED, отрисовка идёт либо в память ui_server либо отправляется ещё и на физический OLED. Ну и, возможно, какой-то ещё вывод на интерфейсы требует некоторого времени. Плюс опрос клавиатуры на плате (которая не умеет работать по прерываниям). В сумме это занимает где-то те же 200 мс. Т.е. иногда импульсы просто терялись.

Решение: сперва запрашиваем новые события без ожидания. Если ОС сразу вернула что-то, то ставим флаг enable_io = 0 и выполняем всю математику и учёт, но всевозможные printf предваряем конструкцией "if (enable_io)".

Если же ОС ничего не вернула по запросу, тогда уже повторяем запрос, но с разрешенным ожиданием события в 250 мс. И сразу ставим enable_io = 1.

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

И оно заработало нормально :)

В моём случае я использовал sigprocmask(). Это маскировка сигналов, причем пришедший сигнал не отбрасывается, он запоминается как необработанный. Как только маскировка снимается, сигнал будет обработан (в моём случае - обработчиком по умолчанию).

Т.е. полностью f1() у меня выглядит так:

void ui_client(char * msg_in, char * msg_out, int msg_out_max) {
  int r;

/* Так как вход в этому процедуру закрывается семафором, не следует допускать возможность её прерывания.
   Иначе семафор не будет открыт, а повторый вызов этой же функции из процедур группы atexit() приведёт чему нибудь плохому */
  sigset_t curset, oldset;
  sigemptyset(&curset);
  sigaddset(&curset, SIGINT);   // Ctrl-C, # 2
  sigaddset(&curset, SIGTERM);  // kill, # 15
  r = sigprocmask(SIG_BLOCK, &curset, &oldset);
  fatal(r, "UI client: sigprocmask set");
    
  r = pthread_mutex_lock(&io_mutex);
  fatal(r, "UI client: lock semaphore");

  ui_client_int(msg_in, msg_out, msg_out_max);
  
  r = pthread_mutex_unlock(&io_mutex);
  fatal(r, "UI client: unlock semaphore");

  r = sigprocmask(SIG_SETMASK, &oldset, NULL);
  fatal(r, "UI client: sigprocmask restore");
}

-----

Когда оставлял на выходные мост в доступе, предупреждал, что диск в 840ке долго обрабатывается.
Я думал дело  в тормозящей флешке, но проанализировал снятые образы и нашел причину:
позиционер флопика иногда пропускал шаг головки (причём только от края к центру, как правило где-то в районе нулевого трека). Странно, он это любит делать при недостатке питания, но сейчас он был воткнут напрямую в БП, даже минуя плату моста.

Дальше было так: всё это мост пытается декодировать, но получает от декодера ошибки. Соответственно, логика управления декодерами пытается перебирать параметры, настройки. Трек же не прочитался нормально, а что именно ненормально - её не беспокоит (обычно 1-2 сектора, залетевшие с чужого трека, особенно на 140-ке, особенно при программном "покачивании" головки - явление вполне привычное).

Но где-то в районе 30 цилиндра, по программе, есть обязательная рекалибровка. После неё голова встаёт на своё место и дальше все треки декодируются быстро. А поскольку после пробега от 0 к 160-му цилиндру идёт ещё пробег обратно, то младшие цилиндры читаются снова на обратном проходе. Логика декодеров видит, что они прочитались успешно и, следовательно, обзорного прохода достаточно.

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

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

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

---

Доделал последний кусок в web-интерфейсе: удаление снятых образов. Заодно там же сделал возможность скачать образ или группу сразу в виде zip-архива. Не быстро (проца не хватает, чтобы быстро), но где-то 1 МБайт/секунду качается (компрессия налету, самая лёгкая, примерно 3:1). По FTP можно без компрессии можно забирать где-то 10 МБайт/секунду.

Речь об этом ?

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

Мне кажется, стоит попробовать sigaction https://stackoverflow.com/questions/338 … gterm-in-c

Возможно, в C++ ставится свой обработчик сигнала в RTL, который может позволить выполнится finally, а уже после этого завершает программу. Т.е. сперва он прерывает текущий код, потом, используя какой-то стек текущих finally, передаёт управление на них и потом уже завершает прогу.

> Я просто не представляю, как обработку управления ресурсами делать без try finally.

f2() {
  action1();
  if action2() < 0 then return; // сбой на каком-то этапе
  action3();
  // успешно всё выполнили
}

f1() {
  allocate(что нибудь);
 f2();
  free(что нибудь)
}

Речь об этом ?

И вот тут возникала коллизия:
если сигнал прерывает процедуру обмена с ui-server остаётся заблокирован семафор обращения к ui-серверу.

Хм. А код на чистом C написан? Я просто не представляю, как обработку управления ресурсами делать без try finally.
Когда есть блок finally, то он в любом случае выполняется и в нем можно разблокировать все ранее заблокированное.
Но для этого нужен C++.

Вроде есть какие-то костыли для эмуляции try catch https://stackoverflow.com/questions/105 … ments-in-c, но сам я этого не пробовал.

Тоже любопытный программный случай.

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

Но если прога зависла, мы идём в Диспетчер Программ и там нажимаем "завершить". В этом случае сперва программа также получает мягкое предупраждение, но затем ОС может закрыть её и принудительно.

В *NIX этот механизм я знаю немного лучше. Там есть понятие "Сигнал" - это некое асинхронное сообщение, которое одна программа или ядро ОС может передать другой программе. Но отличие "сигнала" от прочих механизмов в том, что ещё до запуска программы операционка (или LibC ?) уже предоставляет программе обработчики сигналов. Причем некоторые сигналы программа не может игнорировать совсем, а на другие может повесить свой обработчик. Больше половины обработчиков по умолчанию завершают работу программы.

Это немного напоминает агатовский УПР-СБР: по умолчанию его проигнорировать сложно, но можно попробовать сменить заранее вектор, тогда шанс есть.

Есть довольно любопытные сигналы, например SIGSTOP - полностью приостанавливает программу. Совершенно не спрашивая её согласия :) Потом можно вновь разрешить работать, послав сигнал SIGCONT. Мне в винде этого, порой, не хватает (Какой-то процесс выжрал все рессуры, но закрывать его не хочется, а нужно вот сейчас сделать другую работу. Что делать?).
А ещё SIGKILL - классный сигнал безусловного мгновенного закрытия программы. Программа не может его игнорировать.

Так вот в Мосту3 есть два способа завершить программу:

1) Нажать на плате большую кнопку старт-стопа или в web-интерфейсе нажать 'Q'. Это мягкое завершение - программа получает сообщение о том, что пользователь просит её завершится и завершает работу, когда   ей будет удобно и как ей будет удобно.

2) Нажать в web-интерфейсе кнопку запуска проги. Если прога уже запущена, ей будет отправлен сигнал завершения SIGTERM. Это сигнал мягкий - прога может его игнорировать. Но, по умолчанию, обработчик этого сигнала завершает программу. Этот вариант нужен, например, на случай зависания программы.

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

И вот тут возникала коллизия:
если сигнал прерывает процедуру обмена с ui-server остаётся заблокирован семафор обращения к ui-серверу. Он должен разблокироваться при завершении процедуры, но её прервали и код завершения не выполнен. А atexit нужно обратится к ui-server'у, чтобы сообщить о завершении проги. И он лезет в ту же процедуру, попадает на закрытый семафор и .. всё зависает. Открыть семафор некому.
В процессе поиска истоков проблемы я поменял тип семафора, чтобы в такой ситации он не блокировал всё, а сообщал об ошибке. Но саму проблему это не решает: сообщение о завершении работы пользователю не отправлено.

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

Пришлось засесть за статьи по менеджменту сигналов. Важно не просто запретить прерывание обращения к ui-server, но и не запретить его во всех остальных случаях. Прога же может попасть в какой-то бесконечный цикл в декодерах, где-то ещё, она не будет проверять при этом мягкие просьбы из п1. И важно, чтобы хотя бы по п2 её можно было завершить.

"? глюки у дисплейчика ?"

Мелкий дисплейчик на плате начал подглючивать: картинка иногда ломалась. Сперва лениво кивал на глюки самого дисплейчика, но сейчас на тестах две платы и когда глюки стали стабильными, причём на обеих платах, пришлось занести это в ToDo.

Сперва поискал вопрос об аппаратном сбросе, нашел его на плате дисплейчика, но он не выведен на гребёнку. Просто на плате есть RC-цепочка сброса и всё. А программного сброса в даташите не нашлось (ssd1306).
Но раньше же глюков не было ?

Поиски начал со здорового электролита, напаянного прямо на ноги дисплейчика. Не помогло.
Потом осцилографом порылся по шине i2c - там вполне прямоугольники, да и частота шины не высокая - 92 КГц примерно.
Потом был логический анализатор шины. Тут бага и нашлась. Но какая!

Контроллер дисплейчика умеет принимать растр либо команды по шине.
Чтобы отличать одно от другого имеется префиксный байт. Четыре варианта: команда в один байт, растр в один байт, команды до условия I2C-STOP, растр до этого же условия.

В драйвере (самописном) есть три процедуры: отправить растр (несколько байт), отправить команду (1 байт), отправить команду (массив). Команды бывают как из одного байта так и из нескольких.

Многие команды имеют размер 1 байт. Я их все отправлял процедурой отправки однобайтной команды.
Но когда был реализован основной функционал, я добавил команду управления яркостью дисплейчика. Она содержит два байта. И по привычке я их отправлял как две однобайтовых команды (copy-paste ж). И - что интересно - контроллер дисплея это вполне переваривал, несмотря на то, что в таком случае два байта (опкод + уровень яркости) приходили в отдельных I2C-транзакциях.

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

Но, когда дело шло к завершению разработки, я внёс запуск шелла в автозагрузку. И получилось следующее: рисуется заставка, экранчик плавно зажигается до максимума и затем плавно снижает яркость до минимума (но картинку ещё видно). Ещё до того, как игры с яркостью завершились, уже запускается шелл и начинает рисовать меню.
И вот тут команды управления курсором (от шелла) начинают смешиваться с командами управления яркостью (из скриптов ЛОГО): ЯРКОСТЬ.ОПКОД ... КУРСОР.КООРДИНАТА  ... ЯРКОСТЬ.ЗНАЧЕНИЕ.

Естесно, контроллер дисплея сходил с ума - координата становилась яркостью, яркость - недокументированным опкодом.

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

to (у которого куча значений направления, включая и "для")

To еще используется для обозначения результата действия или процесса. У for такого значения нет.

Я вот думаю - это все какие-то расплывчатые формулировки: "успешное", "хорошее". Может, указать конкретный результат, типа "образ создан/не создан"?

Немного выбивается из общего стиля. В остальных фразах местоимений нет, а тут вдруг "Я".
Предлагаю так:

The disk image has not been created. The main format could not be detected.

И остальные фразы (passive voice тут обязателен, потому что не "формат определил", а "формат был определен"):

The disk image has been created. The main format was detected and read without errors.
The disk image has been created. The main format was detected, but %d error(s) were encountered while reading.

It is successfull final.
Я имел ввиду: "Это успешное завершение."

В программе есть ещё два варианта:
It's final. But I couldn't detect a main format :((
It is successfull final. The main format detected and read without errors.
It is good final. The main format detected, but %d error(s) encountered while reading.

--

По прогам:

> Config variable only140 not found !

Это мне пару раз встречалось - ошибка странная, я пока не понял, в каких случаях она возникает.
В файле конфига нет одной переменной (или почему-то её не находит процедура поиска).
Надо чинить.

Workaround: щёлкнуть галочку "Использовать такой же шаблон для образов 840кб дисков:"
Само значение галочки не важно, но при её изменении этот параметр пересоздаётся.

> Снятие образа 140К ведет себя так же.
Прога одна и та же (снятие 840 и 140), переменная тоже одна. Т.е. это та же ошибка.

> "примерная скорость"

Это такая величина, которая измеряется при запуске привода 840 (для 140ки она - константа) и при смене уровня Density. Измеряется по сигналам индекса, но используется не для программы "скорость", а для сохранения в eim3-файл, чтобы потом декодеры могли понимать, какую поправку на скорость чтения делать. Важно, что эта величина может быть только либо 300 либо 360.
Примерно так: if RealSpeed > 330 then speed = 360 else speed = 300.

А дальше уже играет эта проблема:

> The head is on the track   0,   36 turn(s), instant time <b>398.94</b> ms, average time 210.5529 ms

И вот откуда эта штука возникает - я пока не понял. Выглядит так, как будто пропущен один index.
Вроде бы, это бывает не с любыми дисководами. Это надо будет проверять и искать причину.
Сейчас подключен привод 3.25'', но бОльшую часть отладки я вел на разных 5.25''. Вроде бы там не было этой проблемы.

> Ошибка подключения к статусу 840кб

Это не совсем ошибка, тут причина вот в чём:
журналы и статусы - это просто файлы на RAM FS.
Т.е. после перезагрузки ОС они теряются. Пока не запустишь какую нибудь программу, журналов нет.
После запуска любой из прог журнал появляется.
Каждый новый запуск прог журнал переписываются.

{
...можно создавать пустые журналы при запуске ОС...
Или с какой нибудь фразой, вроде "Информации пока нет"....
}

0.042 ms for move the head to the zero track

Тут нужен предлог to: 0.042 ms to move

It is successfull final.

Тут пропущен артикль, плюс в слове successful только одна буква l. Но главное - фраза какая-то странная. Не понятно, а что тут по-русски должно было быть? Final - это последняя серия в сериале, последняя игра в турнире. А тут финал чего?
Если имелось в виду "Обработка завершена успешно", то можно было написать "Processing completed successfully".