Вид для печати
Patron, а в эмуляторе в КМД работает вывод на терминал, если к регистру 177566 обращаются из КМД через окно? В данном случае старший адрес окна равен 177777, а обращение к регистру идет через 77566. Регистр 177564 вроде читается через окно, а вот вывод на экран не идет.
Не работает.Цитата:
Сообщение от Alex_K
Эмулятор порта терминала и эмулятор КМД выполняются в разных потоках, а обработка записи в регистры устройства из другого потока в эмуляторе порта терминала пока не предусмотрена.
Регистры читаются в режиме дизассемблера - без уведомления устройства, поэтому ( например ) при чтении регистра данных приёмника - бит готовности в регистре статуса не сбрасывается.Цитата:
Сообщение от Alex_K
Изменить содержимое регистра статуса невозможно - ячейка изменится, но эмулятор устройства уведомления не получит и записанное в ячейку слово пропадёт.
В принципе - можно добавить в API устройств PDP-11 специальные вызовы "постороннего" чтения/записи регистров DMA_IO, которые можно будет вызывать как из своего, так и из чужого потока.
Жаль. С точки зрения работы аппаратуры это обращение к шине МПИ, и устройству не играет роли, процессор к нему обращается или другое устройство через ПДП.Цитата:
Сообщение от Patron
Я вообще-то читаю регистр статуса терминала 177564 и проверяю бит готовности в цикле. Если он не будет установлен, то вывод в 177566 прерывается. Собственно всегда был установлен и вывод в 177566 проходил.Цитата:
Сообщение от Patron
При абстрактной многопоточной эмуляции это играет роль.Цитата:
Сообщение от Alex_K
После добавления новых вызовов в API устройств - КМД сможет работать через ПДП только с теми устройствами, в эмуляторы которых будет добавлена соответствующая возможность.
Но ведь через запуск программы пользователя можно заставить реальный КМД работать с любым устройством на шине ДВК. Значит, надо будет добавить поддержку новых вызовов в эмуляторы порта терминала, порта принтера, платы МС1201 ( чтобы КМД мог изменять содержимое SEL1 ), процессора ВМ1 ( для доступа к регистрам ВЕ-таймера ), контроллера MX и даже микросхемы ВП1-128 ( вдруг КМД будет подключен к шине БК-0011, где есть своя ВП1-128 ).
В принципе, можно сделать и так.
Кстати, если хочется поработать напрямую с ВП1-128 - можно прицепить её на шину ДВК вместо контроллера MX:
Код:[objects]
VP1-128 = DSK_module:VP1-128
[links]
;; bus & CPU | CpuBoard | HD | TerminalPort | PrinterPort | Booter | MX | MY
bus & CPU | CpuBoard | HD | TerminalPort | PrinterPort | Booter | MY | VP1-128
[VP1-128.ini]
MY0 = MY80_System.DSK
MY1 =
MY2 =
MY3 =
Вообще-то реальный ДВК - это конструктор. Есть корзина, в которую вставляются платы. Каждая плата имеет адреса, на которые она реагирует, играет роль место в приоритетной цепочке при обслуживании VIRQ, а также ответа на запрос ПДП. Есть другие сигналы, на которые реагируют устройства, например BS, INIT.Цитата:
Сообщение от Patron
Да пока интересно именно в составе КМД, если что программу можно загрузить и в СОЗУ с адреса 20000, что я и делал, пробовал выводить на терминал через "окно".Цитата:
Сообщение от Patron
Модульный API - точно такой же конструктур. Проблема возникает при многопоточной эмуляции, когда два потока одновременно обращаются к одному устройству.Цитата:
Сообщение от Alex_K
В принципе - может помочь введение межпоточной блокировки в обычный API обращения к устройству.
Если межпоточная блокировка решит проблему - в следующем релизе КМД сможет работать с любыми устройствами на шине ДВК.
а как такая проблема решалась на аппаратном уровне?Цитата:
Сообщение от Patron
На аппаратном уровне для захвата шины устройство выставляет сигнал DMR. После того, как процессор освободит шину, он выставляет сигнал DMG (на самом деле у устройств есть вход DMGI и выход DMGO для передачи сигнала по приоритетной цепочке). Получив сигнал DMG, устройство снимает сигнал DMR и ставит SACK, подтверждая захват шины. Процессор снимает DMG и освобождает шину. После этого, во время действия сигнала SACK, устройство может распоряжаться шиной МПИ по своему усмотрению. После снятия сигнала SACK управление шиной возвращается процессору.Цитата:
Сообщение от BYTEMAN
Активное устройство должно было "захватить" шину перед выставлением адреса. Пока активен сигнал захвата шины - все остальные активные устройства должны ждать.Цитата:
Сообщение от BYTEMAN
При многопоточной эмуляции роль захвата шины играет межпоточная блокировка. При обращении к заблокированному ресурсу поток впадает в спячку до снятия блокировки тем потоком, который раньше успел захватить этот ресурс.
Кстати, по поводу захвата шины и процессора 1801ВМ1. Читал, что при захвате шины он позволяет захватившему устройству читать регистры межпроцессорной связи и таймера. А вот как обстоит с внешними регистрами SEL2 и SEL1? Формирует ли процессор в этом случае сигналы SEL2 и SEL1, если захватившее устройство выставило адрес 177714 или 177716? Ведь обычно регистр 177716 отвечает только на сигнал SEL1 и даже не надо формировать RPLY.