Контроллер псевдодиска на SD-карте для ДВК/ УКНЦ / PDP-11 original + Ethernet

[AFZ]

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

Тут другое. Пересылка блока из РД контроллера , т.е. из буфера в ОЗУ контроллера - 768 циклов шины МПИ

10$:    MOV    @R3,(R1)+
        SOB    R2,1$

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

А вот под RSX-11 или чем-то подобным прерывание, а то и ПДП будут иметь большой смысл.

Или в TSX-11. Впрочем, не системным диском единым жива операционка...

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

- - - Добавлено - - -

Да, у меня пока не все гладко с заглушкой "Думаю, прошу не мешать". Я тут почитал всякое разное и решил-таки использовать ПЛИС. Конкретно, вроде-бы, для моих целей годится ATF22V10B, я выписал их с Али и за те полтора-два месяца, пока они доползут, хочу освоить методы сочинения прошивок для них. Отписался тут (почти) рядом, задал списочек вопросов, пока молчат, как партизаны на допросе.

[Advertiser]

[Alex]

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

[AFZ]

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

А не суть важно. Оно исполняется на системном уровне при открытых прерываниях, приоритет выше, чем у всех заданий, но прерывания открыты. Примерно там же, где и .FORK.

[AFZ]

Докладываю. Добился безукоризненной работы контроллера в варианте без прерываний. Заглушку сделал аппаратную, 3 м/с: селектор адресов 177730-177736 (2764), регистр выбора контроллера по МПИ и младших битов адреса (1533ИР22) и логика сигналов выбора и выдачи К СИП Н (1533ЛЛ1, все 4 элемента). Когда подключил эту заглушку, обнаружилась ошибка в программе основного МК - я выдавал с него сигнал "Думаю, прошу не мешать" в произвольный момент времени, заглушка отключалась мгновенно (десяток-другой НС), если в это время проходит фронт (вернее, спад) К СИА Н и я его, естественно, пропускаю, итого - trap to 4. Дождался высокого уровня на К СИА Н и только после этого снял ДПНМ, и все заработало, как часы. В варианте с заглушкой на F103C8T6 заглушка отключалась долго, в результате trap to 4 возникал изредка и я грешил на общее несовершенство мира, а надо было искать ошибку в программе.

Работает очень шустро. Файл 5000 блоков с AZ0: на AZ1: копируется 44 сек, на NL: - 18 сек. Это раза в три (навскидку) быстрее, чем DW: и, вроде-бы, в 1.5 раза быстрее, чем WQ:

Сейчас размышляю на тему прерываний. Программно на STM32 это точно не получится, опять же нужен аппаратный довесок, опять огород в 3-4 м/с. Варианты:
1. Плюнуть и обойтись без прерываний.
2. Сделать это дело на рассыпухе.
3. Сделать это дело на ПЛИС.

Первый вариант, в общем-то, не так и плох. Прерывания во время прополки контроллера открыты, так, что потерь быть, вроде-бы, не должно. Конечно, если в оперативном разделе FB/XM монитора запустить копирование внутри SD-шки, то фоновый раздел ляжет, но так, обычно, не делают. Для больших систем (RSX, TSX, конечно, будет похуже, но тоже не очень критично - не системным диском единым жива операционка, да и Time Sharing никто не отменял...

Второй - понятно. Огород. Сильно не хочется.

Третий. Большие ПЛИС я еще не освоил. Вроде бы, разобрался с GAL/ATF, но нет в жизни счастья - простым GAL16V8 и GAL22V10 не хватает ног и логических возможностей, чтобы запихнуть всё это, вместе с заглушкой, в одну м/с. Им даже на одну заглушку ног не хватает. Правда, двух ГАЛок на заглушку хватит, а на 3-й даже и контроллер прерываний можно, вроде-бы, сбацать, но три м/с - это тоже, в общем-то, огород. Да еще и ГАЛки как вылетели из страны отправления, так и (если верить отслеживанию Али) зависли где-то в воздухе...

В принципе, может быть, все запихнется в две ГАЛки, если одна из них будет GAL6001D, но TL866, к которому у меня есть доступ, их не шьет, в отличие от первых двух.

В общем, пока думаю...

[AFZ]

form, я тут начал заниматься прерываниями, и обнаружил проблему. У меня в процессе обмена с SD-шкой контроллер занят, и работает аппаратная заглушка "Думаю, прошу не мешать". Пока она у меня на рассыпухе, и у меня получилось сделать ее только на чтение CSR. Делать еще и запись - большой огород. Нет, когда приползут с Али ГАЛки, скорее всего, справлюсь, но они уже месяц, как ползут и, думаю, еще будут ползти с месяц. Так вот, при нормальной работе это по барабану - кончится длинная операция, придет прерывание, и все ОК. А вот при отмене текущей операции будет лажа - надо снять бит разрешения прерываний от моего контроллера, а CSR недоступен.

Я так мыслю, что мне в точке входа отмены операции надо будет подождать, пока контроллер завершит текущую операцию и снять бит разрешения прерываний. Но это место исполняется при открытых прерываниях и, если я буду дожидаться подключения CSR на запись, то ничего не успею сделать - прерывание произойдет сразу же, и черт его знает, что там сделается. ИМХО, проще всего, закрыть прерывания на время этого ожидания. Это, в общем-то, ИМХО, не фатально - аварийные завершения происходят достаточно редко. На ДВК все просто: MTPS #200, и вперед (у моей железки будет IRQ4). А если процессор "взрослый", без PSW на шине?

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

[form]

как в драйвере процессорно-независимо закрыть прерывания.

Самое простое - использовать макрокоманду .MTPS - она, не трогая регистров, вызывает подпрограмму которая или делает MTPS, или MOV ...,@#PS (код патчится во время загрузки).

Если критичны пара MOV и один JSR перед собственно командой - можно патчить код драйвера при загрузке (работает только в 5.2 и новее), опираясь на бит LSI$ в слове $CONFG в RMON.

Как вариант, просто использовать команду MTPS, забив за процы где ее нет (навскидку мне известен только один такой - Э100/25).

[AFZ]

Как вариант, просто использовать команду MTPS, забив за процы где ее нет (навскидку мне известен только один такой - Э100/25).

Если только Э-100/25, то, скорее всего, забью. Она же UNIBUS-ная? А мой контроллер только под МПИ/Q-Bus, вряд ли я стану его переделывать под UNIBUS.

[form]

Она же UNIBUS-ная?

Да.

Собственно насчет MTPS/MFPS в Э100/25 уверен не на 100%, но на 99% - память подсказывает, что я проверял, но времени много прошло. Ну а в описании команд процессора точно нету.

В любом случае если где еще нету - это наверняка все UNIBUS машины.

Команда MTPS в отличие от MOV ...,@#PS не работает в пользовательском режиме, но для драйвера это неактуально: он всегда в KM работает.

[AFZ]

Пока ГАЛки машут крылышками (я же говорил, что они вылетели из Китая и где-то зависли), решил сделать прерывания на 559ВН1. Достал из кладовки м/с, достал панельку, достал макетку, примерился и сел рисовать в любимом Оркаде DC003. Нарисовал, пригляделся к ней внимательнее и ужаснулся: у DC003 18 ног, а у ВН1 - 20!

Срочно полез искать что-нибудь, нашел 5-й том Нефедова, подписал на DC003 ножки ВН1, потом перешел на следующую страницу Нефедова и увидел, что ноги 10 и 11 не подключены! То есть, у тех наших ребят, которые цельно тянули DC003, в номенклатуре не оказалось 18-ногого кузова и они, по-простому, запихали этот кристалл в 20-ногий, бросив ноги 10 и 11, я правильно понял? Нефедов в этом месте не ошибается?

[AFZ]

Пришлось повоевать с загрузчиком. Первоначально я собирался сделать его на основе того самого приема из МПСиС с MOV -(R7),R0 - MOV -(R7),(R0)+, но всё было неотлаженным и в таком варианте было сложно понять что не так и где ошибка или недоработка, так я переиграл это дело на три ячейки регистров контроллера - поначалу, для подстраховки, с адреса 177734 выдавался код 777 (BR .), потом 775 (BR .-2), при этом с адреса 177730 в первый раз после перехода выдавался код 012700, а с адреса 177732 код 10000 - адрес расположения загрузчика в памяти (т.е MOV #10000,R0), а далее - с 177730 код 012720 и, с 177732 - код очередного слова загрузчика (MOV #<код>,(R0)+ и в конце, после передачи всего загрузчика - коды 137 и 10000 (JMP @#10000). С адреса 177734 при этом все время передавался код 775 - переход на 177730.

Все великолепно работало. На 1201.02, т.е. на ВМ2. По идее, оно должно точно так же работать на ВМ1 и на Э-60. Потом я таки вставил 1201.04 и попробовал на ней. Как говорит молодежь, "Ага, щаззз!" Во-первых, отказалась работать 2764, на которой у меня был дешифратор адресов контроллера. В общем-то, неудивительно. Удивительно, как она работала на ВМ2, ведь у нее заявлено время выборки 180 нс, тогда, как адресная часть цикла МПИ - 100 нс. Я уже было опустил руки, но тут, наконец-то, из Китая долетели Галки, конкретно - GAL16V8D и я, все забросив, сделал плату новой заглушки - на Галках, некоторое время воевал с ее подключением, добил. Заработало все, кроме загрузчика. Вставляю ВМ2 - загрузчик работает, вставляю ВМ3, загрузчик валится.

Я уже собрался просить помощи клуба, но решил сначала, все-таки попробовать тот прием из МПСиС, благо, аппарат для написания таких программ был наработан на загрузчике с ВМ2. И - о чудо! Загрузчик заработал. По всей видимости, это что-то, связанное с предвыборкой и конвейером, которые сбрасываются при прямых манипуляциях с R7 (PC) и не сбрасываются при последовательном исполнении программы.

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

- - - Добавлено - - -

У меня есть 5 макеток Q-Bus буржуйского покроя.

Нам ее пока некуда сунуть. А у тебя, вроде-бы, и переходники были? Если есть, затолкаем ее в Q-Bus через передохник.