УКНЦ, ДВК-3, Ленинград-1 (48 кб)
Jarik65535, посмотри вот здесь.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Ранее уже обсуждали возможный интерфейс контроллера на шине ДВК, но недавно пришла ещё пара мыслей.
Прерывания весьма полезны, но первую версию контроллера можно сделать без них. Чтобы легко отличать версию без прерываний - можно сразу предусмотреть в CSR бит разрешения прерываний 0100, который невозможно установить у версии без прерываний.
Работу с регистрами можно сделать довольно оригинально - задавать номер одного из 8 регистров в битах 010..002 CSR, после чего читать/писать этот регистр через регистр данных, а младший бит CSR использовать для запуска выполнения. Регистр с номером 00 может одновременно содержать слово состояния контроллера и работать, как регистр для приёма команды, которая будет выполнена при записи 1 в CSR. Поэтому для выполнения новой команды надо просто записать код команды в регистр данных и затем установить бит 01 в CSR для её выполнения. Поскольку этот бит всегда читается нулём - его установка может производиться командой INC.
После сброса контроллера и с момента завершения команды - регистр 00 показывает код состояния контроллера, а с момента записи в этот регистр и с момента начала выполнения команды - регистр 00 показывает номер выполняемой команды.
Обмен данными можно организовать в стиле DW - после начала выполнения команды ЗАПОЛНИТЬ БУФЕР или ОПОРОЖНИТЬ БУФЕР - снимается бит READY в CSR и следующие 256 обращений к регистру данных попадают в 256 последовательных 16-битных ячеек буфера контроллера, причём при заполнении учитываются только циклы записи, а при опорожнении - только циклы чтения. Таким образом можно будет (например) подать команду ЗАПОЛНИТЬ и затем инвертировать содержимое буфера, подав 256 команд COM @#DATA. После 256 учтённых обращений команда завершается и устанавливается бит READY в CSR.
Завершение любой команды приводит к установке бита READY в CSR, очистке в CSR битов номера регистра 010..002 ( т.е. выбору регистра 00 для проекции в регистре данных ) и показу в регистре 00 кода завершения команды. Ошибочное завершение команды вызывает установку старшего бита CSR.
Запись в CSR при сброшенном бите READY завершает выполнение любой команды на любом этапе. Записанное слово проверяется только на бит 040000, если он установлен - производится обычный сброс контроллера, а если нет - сброс контроллера дополняется записью кода ошибки в регистр 00 и установкой старшего бита CSR. Ошибки при выполнении команд отражаются кодом ошибки в регистре 00. Включение питания, INIT шины и установка бита 040000 в CSR - сбрасывают контроллер в начальное состояние с запрещением прерываний, установкой проекции регистра 00 в регистре данных и очисткой кода ошибки.
Если область регистров не ограничена двумя адресами - можно не заморачиваться с доступом к дополнительным регистрам через регистр данных, а просто показывать дополнительные регистры в последовательных адресах, следом за регистром данных.
Последний раз редактировалось Patron; 27.07.2017 в 12:56.
С этим контроллером простор для творчества очень ограничен (в данном случае), его едва хватает на реализацию одного регистра, доступного для чтения всегда и нескольких доступных только когда не происходит обращения к карте. Что-то слишком сложно все, контроллер вполне может содержать конечный автомат любой сложности, т.е. можно реализовать просто последовательную запись в регистр данных без установки номера регистра в CSR. Я считаю, что нужно абстрагироваться от управления буферами и быть как можно ближе к ОС, например, записываем в CSR код операции, затем в регистр данных пишем последовательно номер тома, номер блока, кол-во блоков, затем собственно пишем или читаем данные, причем постоянно проверяем бит готовности в CSR перед каждым обращением к регистру. Может кто знает, что приходит на вход драйвера в RT-11? А такие вещи, как прерывание любой операции вообще вряд ли реализуемы в текущей конфигурации.
Да, драйвер HX так и работает, только при чтении система может запросить не целый блок, а только одно слово, поэтому в операции сообщается не количество блоков для передачи, а количество байтов.
Код:Mov #"CW, R0 ; Packet type = COMMAND ; Command = Cmd_WRITE_RAW Call WOs Mov R3, R0 ; Unit Call ChOs Mov R2, R0 ; Block Call WOs Clr R0 Call WOs ; 16bit Block -> 32bit Block Mov R1, R0 ; ByteCount Add (SP), R0 ; R0 = ByteCount + fill count Call WOs 1$: .IF EQ MMG$T MovB (R5)+, R0 .IFF Call @$GTBYT Mov (SP)+, R0 .EndC Call ChOs SOB R1, 1$ Mov (SP)+, R1 ; R1 = Bytes to fill BEq SkipFill ; Skip fill on full blocks Clr R0 4$: Call ChOs SOB R1, 4$ SkipFill:
Код:Mov HXCQE, R4 ; R4 -> Queue element Mov (R4)+, R2 ; R2 = Block number MovB (R4)+, R1 ; R1 = SpFun code MovB (R4)+, R3 ; R3 = Unit number BiC #^c7, R3 ; Force it to be 0..7 Tst R1 BNE SPFUN ; Is it SpFun call? Mov (R4)+, R5 ; R5 = buf addr Mov (R4), R1 ; R1 = word count Tst R1 BEq DONE ; R1 = 0 - Nothing to do BPl HXREAD ; > 0 - Read ; < 0 - Write Call HX.Write ; Make Write to HX Br CHECK ; OK? HXREAD: ; Make Read from HX Call HX.Read CHECK: ; Error? BCC DONE ; No - OK ; Else - abort HXINT: HXERR: Mov HXCQE, R4 ; BiS #HDERR$, @-(R4) ; Set ERROR bit in CSW.
Т.е кол-во томов ограничено одним байтом? И что за SpFun? И как происходит инициализация тома со стороны ОС? А то, что передается кол-во слов, а не блоков - не проблема, в библиотеке FATFS elmchan'а все это предусмотрено.
Запрос размера подключенного образа.
Через обычные запросы чтения и записи.
- - - Добавлено - - -
В обычной RT-11 максимальное количество томов 8 ( с номерами 0..7 ).
- - - Добавлено - - -
В принципе - можно реализовать упрощённый 16-битный вариант протокола HX, где в фазе передачи команды передаваемые байты расширяются до слов, а в фазе передачи данных - передаются не байты, а слова. В протоколе HX пакеты имеют контрольную сумму, возможно её использование также будет не лишним. Когда пользователь что-то криво установит - он благодаря контрольной сумме будет иметь возможность определить, получает ли драйвер правильные пакеты из регистра данных.
Последний раз редактировалось Patron; 27.07.2017 в 15:32.
Можно и даже нужно передавать слова и туда и обратно, HX заточен под байтовые операции. Вопрос по размеру, можно сделать возможность создавать любые тома (до 4 Гб или 2Гб, сколько там у FAT32 на файл) и передавать реальный размер файла, правда тогда не понятно, что делать с еще не инициализированными томами-файлами. Можно ввести в протокол команду "задать размер", например. Не уверен на счет необходимости контрольной суммы, у нас все-таки не последовательный интерфейс и ошибка на шине скорее приведет к прерыванию.
Суть протокола HX не в байтовых или словных операциях, а в том, что команда контроллера задаётся не через CSR, а через регистр данных. Работа контроллера выглядит так - контроллер ждёт запись слова в регистр данных. Если слово пришло - это команда и контроллер принимает и интерпретирует следующие слова, как аргументы этой команды. Когда все аргументы получены - контроллер при выполнении команды чтения переходит в режим передачи и выдаёт через регистр данных запрошенные данные или устанавливает бит ошибки, если аргументы команды ошибочны ( например задан номер тома, к которому не подключен образ ). При выполнении команды записи контроллер после приёма последнего аргумента начинает принимать слова данных или устанавливает бит ошибки, если аргументы команды были ошибочны.
Управлять подключением образов к приводам контроллера со стороны ДВК практически нереально. Гораздо реальнее иметь соглашение, что контроллер подключает к приводам только те образы на карте, которые имеют числовое расширение ( номер привода для подключения в формате 000..255 ). Тогда пользователь может вставить карту в ридер, добавить номера 000, 001, 002, 003, 004, 005, 006, 007 к тем образам, которые хочет иметь на приводах 0..7 и всего делов. При инициализации тома операционка ДВК не заказывает подключение образа - она запрашивает у контроллера размер уже подключенного к приводу образа и создаёт в подключенном образе файловую структуру на основе полученного ответа.
Последний раз редактировалось Patron; 27.07.2017 в 16:32.
Я только хочу напомнить (прямую ссылку можно конечно накопать с помощью поиска), что HX протокол при эксперименте с реальной УК-НЦ и загрузки через модифиц. СТЫК-С2 с т.н. HX-сервера адапт. под СТЫК-С2 УК-НЦ (напомню, что есть вариант "заточенности под СА УК-НЦ", показал, что некоторые программы через протокол не работают. Это те же ИГРОПАКЕТЫ от ИТО, вариант игры про рыцаря, после запуска загрузчика он не повисает не загружая файл .OVL, возможно какие-то ещё программы - точной и полной проверки никто не делал.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)