151

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

"BASIC-11/RT-11 ( GRAPHIC FOR DWK-3 )"

Вроде разобрал формат ДВК-MX :)))
На zx-pk он немного не до конца описан: нет ничего о том, как контроллер синхронизуется по фазе бита и по слову.

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

Ещё надо до НГ разобрать формат Commodore и январь-февраль - Amiga.

152 Отредактировано avivanov76 (30-11-2023 23:29)

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

Voldemar0 пишет:

Commodore 64: такое впечатление, что это немного по другому сделанный GCR (отличается от Disk][), но плюс к тому он ещё и имеет разный битрейт на разных дорожках.
Нет ли ссылки на подробное описание этого формата?

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

153 Отредактировано Voldemar0 (01-12-2023 21:09)

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

Ага, сенкс, зафиксировал ссылки, кой что ещё нашел, поиграем.

-=-

Несколько слов про формат MX от ДВК. Очень странное решение. Ладно бы рессурсы экономили, но контроллер MX размером с половину агатовской материнки.

Тут его лучшее и единственное найденное мной описание:
https://zx-pk.ru/threads/20541-kontroll … rammy.html
Описание достаточно полное, хотя у меня и осталось немного вопросов и их пришлось разбирать на примерах.

Итак:
Формат основан на самом простом алгоритме кодирования - ЧМ - т.е. тут на поверхности чередуются синхробиты (всегда "1")  и биты данных (любые значния). Этот же тип кодирования использован в Микроше, но там всё сделано хорошо и удобно, а что здесь ? Здесь странно и неудобно:

1) Тут оперируют не байтами, но словами по 16 бит. Вроде бы логично для 16-битной архитектуры, но не для контроллера: если однокристальные 8-битные регистры найти не сложно, то 16-битные я не припомню.

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

2.5) После сигнатурного слова есть ещё слово номера цилиндра. Слова головки, в общем случае, нет.
У меня два диска, записанных на одной ДВК. Один использовался в верхнем дисководе (a'la системный), второй - в нижнем (рабочий). Сегодня выяснил, что на одном номера цилиндов идут подряд (80 штук), на другом - через 1 (40 штук). Почему - самому интересно :)

3) Отсюда получается, что GAP-полей на треке нет, только между началом и концом дорожки.

4) Отсюда получается, трек - это один большой сектор.

5) Зачем-то его разделили на 11 частей по 256 байт. У каждой части своя CRC. (Может быть чтобы иметь побольше надёжность работы CRC?).

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

Чем это всё плохо для моста3:

1) Нужно читать либо 2 оборота либо от индекса. И то и другое замедляет процесс.

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

Чтобы сделать чтение в 2 оборота надо будет немного подкрутить настройки ядра, где драйвер SPI. Иначе не хватает запланированного год назад объёма буфера.

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

3) Опознавание формата. Всё, что известено: в начале дорожки несколько нулей и слово-сигнатура (16 бит).
Ну так себе... В общем, оказалось, что если сделать реверс дорожки, то тоже несложно найти после индекса эти 16 бит ... ну, где нибудь после индекса :))
<а реверс - дело обычное для чтения "перевёрнутых" дисков на двухголовочных дисководах>.

Пробовал проверять сигнатуру и слово номера цилиндра - но это тоже так себе проверка. Ненадёжная.
Т.е. более-менее надёжное решение - проверять CRC первого сектора. Если совпала- наш формат.

Но реверс для этого формата пока исключил из настроек декодера.

154

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

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

155 Отредактировано Voldemar0 (15-02-2024 07:54)

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

Совершенно верно - track-at-once.
Вопрос только - зачем так делать ?

--=--

В итоге всё-таки поправил пару констант в spidev.c и теперь могу читать примерно 210% дорожки.
К индексу привязки чтения нет, но сигнал индекса есть на среди данных.
Оба диска, которые у меня есть, прочитались после этого с первого раза без единой ошибки.
{
  На самом деле интересно были их увидеть. Прошло почти 35 лет, кой что забывается уже.
  Хотя некоторые детали помню хорошо. В этом графическом бейсике была команда SYS -
  разные нестандартные для этого бейсика функции. Например a$ = SYS(1) - это аналог агатовской
  GET A$.
  Формат файловой системы не знаю, но хорошо помню, что файлы там хранятся без фрагментации.
  Есть утилитка SQ (squeeze), которая дефрагментирует диск.
  Поэтому можно просто находить куски текста прямо в DSK.
  Кстати, в UNIX'ах для этой цели есть утилита strings. Анализирует бинарный файл и находит в нём
  разные текстовые строки.
}
На этом и оставим MX формат, перейдём к Commodore.

156 Отредактировано Voldemar0 (15-02-2024 07:54)

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

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 воткнуть изучение атари-формата и очередную серию видео на ютуб - уже есть, что показать.

157

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

Voldemar0 пишет:

- тут о некоем vorpal, но я не понял: это какая-то официальная или неофициальная версия железа или просто сторонний загружаемый софт ? Это другая реализация GCR для Commodore, но насколько она распространена ?

Нашел такую тему: https://www.lemon64.com/forum/viewtopic.php?t=26279
Полное название Epyx Vorpal Utility Kit. Я так понял, это софт, который содержал набор утилит плюс быстрый загрузчик. Видимо, со своим форматом.

Voldemar0 пишет:

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

Были версии дисководов "для бизнеса" и бытовые. В бизнесовых было три процессора, нормальная скорость работы и до двух дисководов в одном корпусе.
Модель 1541 считалась бытовой, и, видимо для удешевления, процессор оставили один. Что интересно, в этой модели обмен с компом по последовательному порту сделали программно. Говорят, была какая-то проблема с 6522, но я подозреваю, что сделали из жадности :) Не хотели, чтобы была конкуренция с бизнесовыми моделями. В результате скорость обмена там что-то около 300 байт в секунду, практически на уровне магнитофонного порта.

158 Отредактировано Voldemar0 (15-02-2024 07:54)

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

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

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

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

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

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

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

--

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

159 Отредактировано Voldemar0 (03-01-2024 20:04)

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

Набросал стыки интерфейсов : web + прога-снималка образов + UI платы.

Не идеально, но для начала неплохо.

Хотел выставить на web (сделать доступ для всех), но пока не уверен, что оно сильно надо.

--==--

Прога умная, читает на двухголовом приводе 140-ку, находит формат агат 140 на стороне A, потом на стороне B, а потом ещё 10 дорожек в PC-формате (сразу за 35-м треком 140ки).  И пытается вытащить ещё и PC со всего диска. Л - логика. Естесно, PC нигде кроме этих последних дорожек нет. Ну а вдруг....

Надо какой-то критерий вводить, чтобы не мучилась в такой ситуации.

-==-

Запаял преобразователь +12 в -12в. Работает. Одна ошибка в расчёте была, преобразователь запустился на 100 Гц вместо 100 КГц. Кондёр один заменил с 22 нф на 22 пф - всё ок. Нагрузочная способность небольшая, но дисководу хватает. Проверил: при отключении преобразователя явно ухудшается качество чтения, а при включении - улучшается. Ну то есть всё норм, преобразователь с дисководом дружит, всё работает. Разъём для Disk ][ тоже запаял - -12в только туда нужно.

Но выяснилось, что есть спецмикруха для этого дела, где-то записал название, но уже забыл - где.
У меня преобразовайка на 555-м таймере. Хотя, в общем-то, и на этой микре обвеса совсем немного.

При 3.5 ма потребления выдаёт где-то 2.0 ма. Ну так себе КПД, но пойдёт. На холостом ходу берёт где-то 0.9 ма.

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

160

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

Voldemar0 пишет:

Прога умная, читает на двухголовом приводе 140-ку, находит формат агат 140 на стороне A, потом на стороне B, а потом ещё 10 дорожек в PC-формате (сразу за 35-м треком 140ки).  И пытается вытащить ещё и PC со всего диска.

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

Voldemar0 пишет:

Надо какой-то критерий вводить, чтобы не мучилась в такой ситуации.

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

161 Отредактировано Voldemar0 (05-01-2024 10:07)

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

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

На это мост и расчитывает. Но это не совсем так: у 5088 головка же шире должна быть, она же на 48 tpi.
И она подтирает нечётные треки. И оставляет там не очень хорошую, но свою запись.

Кроме того, мне так до конца и не ясно: головка 48tpi должна идти своим центром по центру чётных цилиндров 96tpi или между чётным и нечётным цилиндром 96tpi ?

Такое ощущение, что, на практике, были плюс-минус были оба варианта и всё в промежутке между ними.

162

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

Voldemar0 пишет:

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

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

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

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

Voldemar0 пишет:

Кроме того, мне так до конца и не ясно: головка 48tpi должна идти своим центром по центру чётных цилиндров 96tpi или между чётным и нечётным цилиндром 96tpi ?

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

163

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

https://youtu.be/XP1bVp4F9FA
7-я часть видео: программа чтения образа диска

164

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

Чтение 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 пФ - это как-то мало, на частоту уже может емкость монтажа влиять и прочая ерунда.

165 Отредактировано Voldemar0 (10-01-2024 13:54)

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

Альпинс имел интерфейс Disk][, я думаю он повторяет и механически sa-400. Промежуточные положения у него есть, его мост2 рулил точно так же как и 5088, но голова, наверное, 48 tpi.

> Как я понимаю, все треки с номерами, кратными 4 (0, 4, 8, 12, 16 и т.д.) выдернулись.
Я особо не вникал, по идее, всё подряд он не сможет читать. Но я не первый раз вижу, что нулевой трек 840-ки читается на 140-ке. А вот дальше - как повезёт.
Мне вообще не совсем понятно, почему он на обзорке не прочитал то, что стало сниматься легко на досъёме.
Это бы надо было поизучать, но результат вряд ли откроет резко какие-то новые горизонты :) В лучшем случае какую нибудь ошибку у себя найду.

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

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

Вообще, на агате на 140ке я видел только один раз защиту, она просто проверяла, что 36-й трек отформатирован.
Ей было достаточно найти любой сектор оттуда, ничего больше не проверялось.

Поэтому треки выше 35 мост3 читает, но без анализа.

Нечётные треки не читаются, потому что это дополнительное время , а вроде бы как для темы агата не нужное.
Наверное, это может быть актуальным, если внезапно найдётся дисковод с честной головой на 96 tpi и с интерфейсом disk][. Теоретчески, таким приводом можно и 840ку в два захода снять (с переворотом диска).

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

--

Преобразователь: именно так: 330 к + 22 пф.
Могу поменять, я сейчас платой занимаюсь как раз.
Можно поменять на 33 к + 220 пф. Наверное, так будет лучше.

> А то 22 пФ - это как-то мало, на частоту уже может емкость монтажа влиять и прочая ерунда.

Может, но незначительно. Во первых - дорожки короткие, во вторых - само значение частоты не очень важно.
Тут запас всё равно большой, плюс-минус километр.

В кварцевых генераторах десяток пф - вполне типичные ёмкости, однако же это работает и особо от помех не страдает :)

166 Отредактировано Voldemar0 (24-01-2024 19:53)

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

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

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

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

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

167

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

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

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

168 Отредактировано Voldemar0 (19-02-2024 13:17)

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

Амига
По справочникам там используется 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, тут всё-таки синхрополя есть у каждого сектора, так что при ошибке чтения ломается только один сектор, а не весь хвост трека.

169 Отредактировано Voldemar0 (24-02-2024 20:40)

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

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

С ethernet была пара ошибок на старой плате, исправлял их на новой версии, но, как выяснилось, одно исправил, другое - нет. Там в подключении светодиодов была ошибка, исправлял её, но не там, где надо. Так что на новой плате всё равно пару проводников пришлось закинуть коротеньких.

Сейчас ещё один из семплеров не проходит самотест. Тоже буду завтра разбираться.

Но интересный случай вышел с часиками. На борту микруха pcf8523. Пару дней с ней ковырялся. Схема не менялась с прошлой платы. Только battery holder неправильно был нарисован, но это на новой плате уже исправлено.

Но часики на новой плате упорно не работали: драйвер сообщал об ошибке. Но без подробностей: не могу прочитать часы и всё тут. Микруха часов с I2C-интерфейсом, на I2c висит также OLED и он как раз работает. Осцилограммы на шине красивые, даже ACK от микрухи часов видны. Но логический анализатор видит перед фронтами импульсов мелкий звон, причем не каждый раз, а довольно редко. Звон очень высокой частоты, единицы нс. Тактовая на шине - 100 КГц.

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

Вдруг заметил, что если батарейку часов выдернуть - драйвер об это явно сообщает при загрузке системы 8-() !
Он откуда знать об может, как не с шины ? Выходит, шина живая и обмен идёт ?
А что тогда ему не нравится ?

Полез осцилографом смотреть что нибудь на кварце.
Реально "что нибудь" - потому что даже на выходе исправного OSC-O ничего похожего на более-менее заметный сигнал нет. Ну я думал, что осцилограф глушит его, но вроде же и частоты невысокие...
В итоге на максимальной чувствительности, среду шумов (осцил сам шумит порядочно) нашёлся почти синусоидальный сигнал в районе 32 КГц. У него амплитуда меньше вольта, причем на OSC-O сигнал даже чуть меньше, чем на OSC-I.  Возможно, это какой-то вид энергосбережения, что резонатор раскачивают много меньше, чем до напряжения питания.

Ну а дальше просто: оказалось, что на новой плате генерации нет вообще. Заменил кварц - всё заработало. Главное: я пару лет назад мешок с кварцами гонял на другой микрухе (ds1307 ?) и проверял все ! Тогда всё работало.

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

А сегодня ещё pl2303 (UART-USB) странно спалил. Искрануло немного в питании (КЗ в +12 - оно крокодилами подключено), БП отключился просто, в целом плате пофигу, проц без проблем перезагрузился, но pl2303 отлетела. Хотя она вообще на другой стороне платы. А странно то, что старая плата моста уже сколько месяцев живёт и ничего на ней не сдохло.
Хотя тоже, наверное, всякое бывало. Я и не обращаю внимания обычно на такие мелочи.

170 Отредактировано Voldemar0 (25-02-2024 12:55)

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

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

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

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

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

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

171 Отредактировано Voldemar0 (Вчера 16:56)

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

1) Несколько видеостраниц для индикаторов на плате

Откладывал до последнего, но момент сейчас наступил.

Есть два порта флопиков и на простых операциях они - нисколько не снижая скорости - могут работать в параллель. Это проверено уже. Например, посмотреть спектрограмы треков. Можно попробовать и съём данных.

Так вот вопрос: кто рулит индикаторами/дисплеями платы в это время?
Разрешение индиков небольшое, делить их между двумя прогами - совсем будет тяжко.
Поэтому сделал так: весь вывод буферизуется в ui-server и отдельной кнопочкой можно переключиться между отображением статуса одной и другой проги.
При запуске проги "видеостраница" переключается на неё. Т.е. если используется только один порт - то руками можно ничего не переключать. Только если две проги сразу может быть полезным переключать картинку. Ну и тут не только с картинкой, кнопки управления тоже работают только с той прогой, которая сейчас видна на экранах. Но не все, есть кнопки-исключения, которые связаны с конкретным портом дисковода - они доступны всегда.

Это я сделал. Пару дней правил свои драйверочки (они userland - являются частью ui-server'а) и встраивал в них что-то типа собственного видеоозу (до этого весь вывод они сразу слали в контроллеры устройств).

--

2)
Шелл-оболочка для управления прогами и настройками прямо с платы (когда работаем без внешних компов и web-интерфейсов).

Это предстоит сделать, причём как-то так, чтобы это могло уживаться с web-интерфейсом.
Т.е. чтобы любые настройки, запуски программ - всё можно было делать и с платы и с web-.

Сейчас набросал такой примерный список того, что можно делать с интерфейса платы:

    главное меню:
снятие образа
имя образа 140
имя образа 840
скорость
настройки
спектроанализатор

    настройки:
dhcp / static
ip (редактируемый или нет)
mask
gateway
устройство сохранения:
 usb  / внутренн память / sd
date/time (запуск внешней проги или встроенная процедура ?)

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

Это предстоит сделать следующим шагом.

--

3)
Сетевой интерфейс, режимы:

  a) Статический адрес (myip/маска сети/роутер по умолчанию). Всё задаётся вручную с кнопок платы. Тут всё понятно, этот режим нужен.

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

  c) Адрес статический, но плюс к нему в устройстве работает DHCP-сервер и выдаёт адрес тому компу, который напрямую подключен к мосту (т.е. это для случая шнурка, который связывает только два устройства). Тут только важно, чтобы мост не объявлял себя роутером сети по умолчанию. Иначе по ошибке можно и выход в инет сломать.

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

Ещё одно: можно объединить режимы a и b: выдавать сперва статический адрес, но если DHCP-клиент получил ответ из внешней сети, то свой статический адрес подменять вновь полученным (только для текущего сеанса).

Стоит ли так делать ? Пока не решил.