Цитата:
Сообщение от Patron
2й запускКод:0
1
2
255
0
1
2
3
4
255
0
1
255
0
1
Код:0
1
2
253
254
255
0
1
2
253
254
255
253
254
255
Цитата:
Сообщение от Patron
2й запускКод:0
1
2
255
0
1
2
3
4
255
0
1
255
0
1
Код:0
1
2
253
254
255
0
1
2
253
254
255
253
254
255
.
Новый тест: TDW2.SAV - делает то же самое, но с предварительным сбросом контроллера.
Цитата:
Сообщение от Patron
Результаты 2го раза такие же.Код:0
1
2
0
1
2
3
4
5
0
1
2
0
1
2
.
Ситуация прояснилась - любое обращение к регистру 174006 обнуляет позицию чтения/записи в буфере DW ( это пока не эмулируется ), и только запись в регистр 174016 даёт такой же эффект ( это уже эмулируется ).
А кто-нибудь может в двух словах рассказать как выполнять I/O на DW? Причем интересует 22 bit.
А биты там по барабану - он работает в PIO-mode. То есть посылаем цилиндр в 174012, поверхность в 174014, сектор в 174006, команду чтения в 174016, разрешение прерывания в 174020 и ждем прерывания. Пока выполняются операции, все регистры, кроме 174020 недоступны, бит 15 (100000) в нем на это указывает. То есть или жди прерывания, или пропалывай (POLL) этот бит. Впрочем и в RT-11, и в ДИАМСе, получив прерывание, первым делом его проверяют, если он стоит, уходят на повтор или ошибку.Цитата:
Сообщение от form
А потом не спеша, прополкой, ждут бита готовности (200) в 174020, после чего пересылают очередное слово из 174010 в память. В RT-11 это делается на FORK-уровне. Запись примерно так же - выдают дисковый адрес, пословно пересылают из памяти в буфер DW (174010), выдают команду записи и ждут прерывания, после чего проверяют на ошибки
- - - Добавлено - - -
В принципе, почти логично - сектор изменили, значит позиция в старом секторе стала неактуальной. А то, что любое обращение, а не только запись - вероятно, или недоглядели, или были сложности в реализации. Да и нелогично делать чтение регистра служебной зоны формата посередине передачи блока...Цитата:
Сообщение от Patron
Тоже вопрос или где можно почитать (желательно на русском), как процессор узнает по какому адресу находится подпрограмма прерывания выставленного аппаратурой? Если еще точнее, то вот например, есть регистры внешнего устройства к примеру 176570 и 176574 откуда процессор узнает что нужно перейти по вектору 374? Как этот механизм на железе работает, что выставляется на шину А/Д и т.п.?
Ответ просто - он этого не узнает в принципе. Ему выставили вектор, он по нему выполнил прерывание, а была там подпрограмма обработки или нет - его не волнует :)Цитата:
Сообщение от Vamos
- - - Добавлено - - -
Можно взять например users guide по KDJ11-B (первое что на память пришло), там подробно все это расписно.Цитата:
Сообщение от Vamos
- - - Добавлено - - -
Вот здесь еще вроде было про это.
Т.е. аппаратура висящая на адресах 176570 - 176576 выставляет сигнал прерывания и на шину выставляется адрес вектора? или адрес вектор процессор читает из 176576 по сигналу прерывания? где, чем, определяется приоритет?Цитата:
Сообщение от form
Можно здесь, не очень подробно, сам механизм, мне пока не понятно.Цитата:
Сообщение от form
Загляни в книжку "Центральный процессор М2", ссылку давали недавно в теме "ДВК-УКНЦ поиск файлов". Коротко - ВП1-065 по адресу 176560, допустим, выставляет К ТПР Н, в ответ сначала выдается К ВВОД Н, по которому все подключенные фиксируют состояние своего триггера запроса прерывания и, если он установлен, перекрывают дальнейшее прохождение К ППР Н. Через несколько сотен нс выдается сигнал К ППР Н, первый по корзине с включенным триггером запроса прерывания выдаст на К ДА02-15 Н код вектора прерывания (в нашем случае - 360) и К СИП Н. Процессор считывает этот код, интерпретирует его, как адрес вектора и достает оттуда PC, потом, прибавив к нему двойку, достает приоритет. И вперед.Остальные устройства (дальше по корзине) сигнал К ППР Н не получат - наш ВП1-065 его перекрыл.Цитата:
Сообщение от Vamos