Контроллер дисковода для УКНЦ, работающий с образами на micro-SD карте.

[Jarik65535]

Пока нет, вот и спрашиваю здесь, что нужно реализовывать?
Пока так:
1. ожидаем готовности на каждом шаге.
2. в регистр данных заносим код операции
3. номер тома
4. номер блока в томе (мл.слово)
5. номер блока в томе (ст.слово, 0 для RT-11)
6. кол-во слов (16-бит хватит всем, а в случае с RT-11 - даже 15 бит)
7. здесь можно прочитать предварительный результат операции из регистра 2.
8. читаем/пишем данные
9. читаем результат операции из регистра 2.

Я пока ничего не делал, так что предложения принимаются.

[Advertiser]

[Patron]

1. ожидаем готовности на каждом шаге.
2. в регистр данных заносим код операции
3. номер тома
4. номер блока в томе (мл.слово)
5. номер блока в томе (ст.слово, 0 для RT-11)
6. кол-во слов (16-бит хватит всем, а в случае с RT-11 - даже 15 бит)
7. здесь можно прочитать предварительный результат операции из регистра 2.
8. читаем/пишем данные
9. читаем результат операции из регистра 2.

1. На каждом шаге проверяем бит завершения и если он установлен - контроллер завершил выполнение команды.
2. Если код операции ошибочный - контроллер установит биты ошибки и завершения.
3. Если к указанному номеру тома не подключен образ - контроллер установит биты ошибки и завершения.
4,5. Если номер блока больше размера образа - контроллер установит биты ошибки и завершения.
6. Если количество слов больше имеющегося в образе места от номера блока до конца образа - контроллер установит бит ошибки, но прочитает/запишет всё имеющееся место.


Коды команд контроллера:

000 - CHECK - Контроллер возвращает в старшем байте регистра данных номер тома последней операции, а в младшем - код состояния ( код ошибки последней операции ).
001 - READ
002 - WRITE
004 - SIZE - Номер Тома - Контроллер возвращает два слова размера подключенного образа ( мл.слово-ст.слово ). Если образ не подключен - контроллер сразу ставит биты ошибки и завершения.


Коды ошибок:

IS_SUC = 0001; // нет ошибки
IE_OFL = 0277; // устройство offline (образ не подключен)
IE_BLK = 0354; // выход за пределы устройства
IE_WLK = 0364; // попытка записи на защищённое устройство
IE_VER = 0374; // неустранимая ошибка (например внутренняя ошибка контроллера)
IE_IFC = 0376; // неверная команда

[AFZ]

Кстати, забыли о том, что диски в наших системах имеют блочную структуру. Если отправить на запись кусок произвольной длины, то в последнем блоке, в "хвосте", может остаться мусор. Я на эти грабли уже наступал, но у меня, в качестве мусора, было последнее переданное по DMA слово, в итоге, сохраненный исходник при загрузке в EDK показывал в конце текста множество пустых строк, если последним словом было 005015 (<ВК><ПС>, длина занятой части файла четная) да, в придачу еще и как-то неадекватно себя вел, если последнее слово было 000012 (<ПС>0, длина нечетная). А здесь в RT-11 возможны вообще всяческие чудеса.

Далее, определяемся с регистрами. Как я понял, основной, всегда доступный регистр состояния - 176560, т в нем бит Д7 (0200) - готовность к обмену через 176562, так? Еще какие-то адреса есть? Вроде бы загрузчику из сети требовались еще 176564 и 66, они дальше используются? Какие еще биты есть или планируются в 176560?

[Jarik65535]

Кстати, забыли о том, что диски в наших системах имеют блочную структуру. Если отправить на запись кусок произвольной длины, то в последнем блоке, в "хвосте", может остаться мусор. Я на эти грабли уже наступал, но у меня, в качестве мусора, было последнее переданное по DMA слово, в итоге, сохраненный исходник при загрузке в EDK показывал в конце текста множество пустых строк, если последним словом было 005015 (<ВК><ПС>, длина занятой части файла четная) да, в придачу еще и как-то неадекватно себя вел, если последнее слово было 000012 (<ПС>0, длина нечетная). А здесь в RT-11 возможны вообще всяческие чудеса.

Это баг или фича? Нужно повторять такое поведение? Сейчас еще раз глянул исходники FatFS, там неполный сектор предварительно считывается.

Далее, определяемся с регистрами. Как я понял, основной, всегда доступный регистр состояния - 176560, т в нем бит Д7 (0200) - готовность к обмену через 176562, так? Еще какие-то адреса есть? Вроде бы загрузчику из сети требовались еще 176564 и 66, они дальше используются? Какие еще биты есть или планируются в 176560?

176564 повторяет значение 176560 при чтении. Я хотел исполбзовать 176566 для чтения кода ошибки, но patron предлагает через команду CHECK.

[AFZ]

Это баг или фича? Нужно повторять такое поведение?

Баг, вестимо. Положено недописанный остаток блока заполнить двоичными нулями.

176564 повторяет значение 176560 при чтении. Я хотел исполбзовать 176566 для чтения кода ошибки, но patron предлагает через команду CHECK.

А 176562 - регистр команд/данных?

Какие биты определены в 176560? Кто из них аппаратный, а кто эмулируется программой Кортекса?

Когда Кортекс занят длительной операцией (прочитать или записать сектор SD-шки) и не исполняет программу эмуляции программных регистров, что видно и что можно записать в РС ? (обращение к РД, как я понимаю, вызовет TRAP TO 4)

[Hunta]

Если отправить на запись кусок произвольной длины, то в последнем блоке, в "хвосте"

Насколько мне не изменяет память, контроллеры аналоги RK05, RK06 и 20-ти мбайтный DP (не помню, чей аналог) добивали сектор нулями до 512 байт при записи не полного сектора

[Patron]

Я хотел исполбзовать 176566 для чтения кода ошибки, но patron предлагает через команду CHECK.

Если есть лишний регистр - лучше использовать его, а не команду CHECK.

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

Для битов ошибки и завершения можно использовать младшие биты 176560 ( 01 == DONE ; 02 == ERROR ). Тогда опрос регистра может выглядеть так:

1$:	MOV	@#176560, R0
	BPL	1$
	ASR	R0
	BCS	DONE
	.......
DONE:	ASR	R0
	BCS	ERROR

[Jarik65535]

В 176560 определен только бит 0200, в старшем байте возвращается 1 - номер станции, но только когда контроллер не занят и только при обращении непосредственно к адресу 176561. УКНЦшный загрузчик делает именно так.
176560 и 176564 - аппаратные, но только по чтению, причем это один регистр просто на двух адресах для эмуляции сетевого адаптера. Эти регистры видны всегда.

Я думаю вопрос с хвостами нужно решать в драйвере, т.к. ухудшить всегда можно.