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

Проблема с коммодором в том, что дисковод у него - это закрытая система. У дисковода свой процессор, свое ПЗУ и общается он с компом по последовательному интерфейсу специальными запросами. В результате комп ничего не знает про файловую систему и кодирование данных на диске. Официальной документации, насколько я понимаю, нет. Это типа "секрет фирмы", в отличие от Apple. Вся информация, которая есть - это то, что любители смогли самостоятельно накопать.

Основная информация по формату тут (начиная с раздела 17.3) https://vice-emu.sourceforge.io/vice_17.html
Тут есть про скорости записи https://www.pagetable.com/?p=1070
Ну и тут чуть-чуть https://www.c64-wiki.com/wiki/Commodore_1541

PS: ой, самую полезную ссылку чуть не пропустил: https://www.devili.iki.fi/pub/Commodore … OS_OCR.pdf - книжка Inside Commodore DOS

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

2 avivanov76: THANKS !!!!
за книжку Inside Commodore DOS.

В общем-то, больше почти ничего не потребовалось.
Остальное глянул, но там уже повторы.

Есть ещё пара любопытных публикаций:
https://luigidifraia.wordpress.com/2021 … ocumented/
- тут о некоем vorpal, но я не понял: это какая-то официальная или неофициальная версия железа или просто сторонний загружаемый софт ? Это другая реализация GCR для Commodore, но насколько она распространена ?

И вот тут ещё кой что стоящее:
https://luigidifraia.wordpress.com/2020 … rive-work/
Во всяком случае отсюда становится понятным, почему у них такой длиный синхроблок.

-=-

В целом всё (пока не всё, но уже достаточно, чтобы убедится, что жить будет) получилось.
Правда, я просидел всё воскресенье в раздумьях на тему "почему не похоже на то, что все объясняют в разных публикациях" ?
Потом оказалось, что всё-таки я слегка накосячил в семлрейте (поскольку он тут скользящий, я расписал условие его пересчёта от номера трека, но забыл внести поправку на скорость дисковода 360/300).

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

-=-

Надо заметить, что формат Commodore довольно любопытный.

В деталях он сильно отличается от Disk ][, но где-то в идеях, подходах, архитектуре они прилично похожи.
Тут тоже каталог где-то не в начале диска, также GCR-кодирование (хотя и совсем не похожее на Disk ][ и реализованное на другом уровне. У Disk ][ по GCR заворачивается только данные сектора, причем само кодирование не покрывается CRC,
а у Commodore наоборот: GCR покрывает все структуры и CRC оказывается уже поверх GCR.
Сходный набор данных в адресных полях, даже метка тома есть.
CRC есть для всех полей, тоже однобайтовая и считается по XOR.

Здесь используется отдельный процессор для обработки потока данных от флопика, но, как мне кажется, тут разработчики немного ... как бы... не добились своей цели. Обычно процессор ввода-вывода разгружает основной процессор от рутины, но тут получилось так, что для 6502, который используется в контроллере флопика, операции с битовым потоком довольно таки непривычны. Поэтому получилось всё равно сложно, и - всё равно - не очень быстро. Если я верно понял, было несколько вариантов накопителей, с 3 процессорами и с 1. Версия с 1 была совсем тормознутой, версия с 3, вероятно, не хуже типичного железного контроллера.... Но на трёх процессорах.

-=-

Дальше:
1) Декодирование комодора ввести в основную часть софта (сейчас только в одной из программ);
2) Взялся погонять на своих дисках всё это ПО, получилась горка образов: раз уж так вышло, надо быстренько прошерстить всё. Нового там ничего не должно быть, однако, кой какие диски можно уже объявить свободными.
3) Дальше нужно в прогу чтения дисков уже понемногу вносить вывод на дисплей и индикацию платы, а также и в файлы, которые уходят на внутренний web-сайт. Уже есть что выводить и уже примерно понятно как именно.
4) Уже пора делать супервизор настроек устройства и запуска прог с кнопок платы. Последнее время его не хватает.
5) По видимому, в управление дисплеем надо вносить какое-то прозрачное разделение между двумя приводами. Чтобы проги, управляя каждая своим дисководом, не конфликтовали за дисплей и клавиатуру.
6) Дальше доделать -12 вольт, протестить альпинс/Disk][-интерфейс и перерисовать плату (ошибки поправить) и сразу заказывать. Скорее всего, это на новогодние отложу.

И где-то между 2 и 5 воткнуть изучение атари-формата и очередную серию видео на ютуб - уже есть, что показать.

Закончил все работы по Commodore, заодно начал делать управление индикаторами на плате для проги снятия образов. Выглядит прикольно :)

Commodor'оровкий формат порядком поковырял мозги переменным битрейтом: это не было предусмотрено архитектурой прог, соответственно, ловил несколько ошибок, где всё-таки битрейт оставался постоянным.

С другой стороны: оказалось удобным наличие двух, архитектурно разных, прог для декодирования. Одна попроще и без автомата опознания формата, вторая - полный автомат. Сперва заводишь новую архитектуру в первую прогу, добиваешся нормальной работы, потом загоняешь этот же формат во вторую. И сравниваешь результаты декодирования. В итоге вторая должна дать результат чуть лучше, чем первая (она умеет работать с индивидуальными RPM по каждой дорожке, мост3 снимает микс разных скоростей, если может). В целом, результаты снятия чуть лучше на 360 RPM (чем 300).

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

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

В целом, поведение комодоровских декодеров очень похоже на агат140. Тоже легко (и даже ещё легче) возникают варианты секторов с совпавшей CRC, но разные по содержимому. У агата CRC считается через сложение, а у Commodore - исключающее ИЛИ. Похоже, суммирование тут всё-таки даёт чуть более стойкий результат.

--

Снял амиговские образы для изучения, там ожидается MFM, 160 треков, тайминги - 4, 6, 8 мкс.
Надо будет искать литературу по ней.

Изначально PC-формат был 80-дорожечный или 40-дорожечный? Если 80-дорожечный, то должны были найтись и дорожки между агатовскими.

Пусть на каждый не основной формат человеку вопрос задает. И какое-нибудь число показывает. Типа, "на диске есть 3% PC-формата, будем мучить дисковод? (Y/N)". Мало ли, что там на реальных дисках встретится. На все случаи критериями не запасешься.

В случае 48 tpi ширина головки 300 микрон, расстояние между треками 530 микрон. Остается зазор в 230 микрон, который головка не накрывает. И в этот зазор попадает нечетный трек 96 tpi.

А ширина головки в случае 96 tpi - 155 микрон. То есть, если дискета идеально отцентрирована (нет биений) и головки стоят точно по центру треков, то читаться должно отлично - там даже 75 микрон зазора остается.

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

96 tpi появились позже, так что это головка 96 tpi должна равняться на цилиндры 48 tpi. И для обеспечения совместимости (чтения 80-дорожечным дисководом 40-дорожечных дискет), было бы логично поставить голову 96 tpi по центру трека, сделанного 48 tpi головкой. Но не факт, что на 40-дорожечных дисководах головки выставлялись с такой же точностью, как на 80-дорожечных.

Чтение 840К диска на Alpins впечатлило :)
Как я понимаю, все треки с номерами, кратными 4 (0, 4, 8, 12, 16 и т.д.) выдернулись.
Нечетные не выдернулись, потому что это другая сторона, которой у Alpins быть не может.

А вот интересно с промежуточными дорожками (2, 6, 10, 14, ...). Вроде как они на той же стороне диска и могут читаться.
Но по факту ни одного трека не прочиталось.

Получается, что Alpins не может двигать голову с шагом 96 tpi?
Потому что, если бы мог, то хоть один сектор он бы увидел. А так получается, что остановка шагового двигателя в соседней фазе дает какой-то "левый" шаг.
Кстати, можно было бы провести эксперимент: после установки головы на 0 трек, сдвинуть ее не на 2 фазы, а на 3 (поставить на трек 1,5). И дальше двигать стандартными шагами по 2 фазы. Может, тогда с 840К и промежуточные треки можно будет выдернуть?

И, в связи с этим, еще вопрос: где-то я читал, что то ли на Apple 140K, то ли на Commodore такие "промежуточные" дорожки иногда использовались как защита от копирования. Поэтому какие-то "читалки" снимают с таких дисков не 35, а 70 треков.
А как с этим в мосте? Сохраняет ли он в образ "промежуточные" дорожки?

И про преобразователь еще хотел спросить: а почему там 22 пФ понадобилось для 100 КГц? Получается, времязадающий резистор килоом 300? Может, поменьше его сделать? А то 22 пФ - это как-то мало, на частоту уже может емкость монтажа влиять и прочая ерунда.

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

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

Немного опасался, что с китайцами будет общаться сложно по вопросам комплектации (да и сейчас опасаюсь, всё ли правильно ? Плата придёт - узнаю что как). Однако всё норм: отвечали очень быстро, вопросы из моего письма не пропускали, всё проверили, нашли несколько ошибок (в основном - футпринты), в общем нормально всё. spcb@spcba.cn - если кому надо.

Теперь надо немного отвлечся - гонка была приличная, особенно последние 2 недели.
Дальше буду ковырять формат AMIGA и, если к его завершению платы ещё не придут, то может быть успею ещё оболочку для автономной работы моста накидать.

Амига
По справочникам там используется MFM, по факту он там и есть, причем даже синхросимвол также устроен, как и в PC. Казалось бы - ну придумали бы там свои форматы полей и ладно. Так нет: форматы полей там свои, но есть ещё одно отличие, которое опять ломает всю картину мира.

Как в Агате, так и в PC MFM-кодирование делается аппаратно. Вся прелесть этого кодирования как раз в том, что кодеру нужен совсем небольшой контекст и аппаратный кодер или декодер получаются довольно простыми (не нужно хранить много данных). Но в Амиге, похоже, кодер сделан либо программный либо используется какая-то механника (blitter), которая предназначена не для дисководного дела, а для чего-то другого. Например, для обработки графики.

Чтобы угодить этому подходу, данные сперва готовятся к записи (примерно как в Apple ][ GCR-кодировке). Берётся очередное слово, делается его копия, потом копия сдвигается на 1 бит (влево, например). Теперь в оригинале и в копии можно все чётные биты отдать под тактовые/синхро-биты MFM. А в нечётных останутся исходные данные. Получатся два слова - с чётными битами исходных данных и с нечётными. А чтобы было весело, эти два слова мы раскидаем по разным частям сектора. Причем разные слова раскидаем на разные расстояния.

Обратная сборка при чтении выглядит примерно так: data = (evenword & mask) | ((oddword & mask ) >> 1)

Размер слова можно взять любой, реально в амиге используют минимум 32 бита.

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

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

Декодеры получились очень аккуратные, короткие и, наверняка, более быстрые чем декодеры Агат- и PC-форматов. Если обычно между L3 и L4 ходит поток, очень похожий на байты, которые драйвер записывает в контроллер, то здесь обмен происходит сразу готовыми структурами, так как уже на L3 декодер вынужден понимать, что именно он сейчас декодирует (поле адреса, поле данных, GAP...), так как от этого зависит - куда какие биты расставлять при разборе MFM-потока. В итоге L4 просто сортирует по номерам секторов полученные на вход структуры и делает ещё несколько формальных проверок. Даже CRC здесь проще считать на L3, хотя у остальных форматов это происходит на L4.

Что ещё: Амига пишет трек в TAO - целиком. За счёт этого у неё почти нет GAP-полей и на диск стандартной плотности они впихивают больше 900 кб. Если бы сделали ещё и плавающий битрейт, как в Commodore - может до мегабайта бы дотянули.

Но, в отличие от ДВК MX, тут всё-таки синхрополя есть у каждого сектора, так что при ошибке чтения ломается только один сектор, а не весь хвост трека.

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

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

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

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

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

Главное, чтобы можно было легко понять, какая прога сейчас захватила экран.

Я уже забыл, а по сети будет виден только web-интерфейс или содержимое карты памяти тоже?

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

На тестах выявляются косячки, например: шелл (причём там два потока исполнения) и прога, обслуживающая дисковод, при одновременном запуске выявляют проблемы в UI-SERVER - некоторые из внутренних "драйверов" не умеют работать в несколько потоков. Расставляю для них семафоры из pthread.

Одновременно полировка бекэнда веб-интерфейса.

Тут в чём особенность: и шелл и web- должны уметь одинакого запускать проги снятия образов и прочие программки.
Для всех программ очень важно ведение лога. Чтобы потом можно было не гадать, что где и почему упало на очередном диске.

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

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

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

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

Чтобы всё было максимально синхронно, оба интерфейса должны уметь лазить в списках процессов операционки, находить "свои" программы, запускать их или останавливать.

Этот процесс полировки и притирки идёт параллельно с разработкой шелла.

--

Ещё одна мелкая печалька: контроллер дисплея, который одновременно является контроллером клавиатуры, немного туповат и работает только по запросу. Он не умеет, например, дёрнуть лапкой при нажатии кнопки. В итоге приходится периодически лазить к нему и спрашивать - не нажато ли что нибудь?
Для дисководных прог это не проблема - они проверяют нажатия только между завершением обработки одного трека и перехода к другому треку. Т.е. где-то раз в 0.5-3 секунды, а зависимости от текущего состояния.

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

--

И мелкий косорезик: у линуксового ядра есть возможность посадить на любую лапку светодиод, который будет моргать при обращениях к SD-интерфейсу. Удобно, прикольно - примерно как моргает светодиод HDD на десктопах.
Я поставил пару диодов: один для SD и второй для USB. А вот тут облом: перерыл инет и доки на ядро линукса - для USB нет аналогичной функции :(((( Есть только возможность включить светодиод при подключении устройства (т.е. он постоянно будет гореть при подключенной флешке, к примеру). Хм.. Ну это и так можно сделать: следить за событими hotplug- подсистемы - там отображаются все подключения-отключения.... А вот так, чтобы именно в моменты отправки-получения данных что-то моргало - такого пока не нашел :(.