УКНЦ загрузка через стык С2

[form]

При абстрактной эмуляции выставления запроса IRQ на шину Q-Bus (без отдельной эмуляции запроса вектора) я учитываю (и всем рекомендую учитывать) следующие аппаратные параметры:

bool SetIRQ( 
              word uVector, 
              word uBR_Line, 
              word uBR_LinePosition, 
              bool bClearedByInit = true
           )

Если за то время, пока прерывания в процессоре были запрещены, успело поступить несколько запросов прерываний от разных устройств, то после разрешения обработки прерываний - первым обсуживается тот запрос, который пришёл по линии BR с большим номером и от того устройства, которое расположено на этой линии BR ближе к процессору.

Это уже вопросы к самой организации эмулятора, они выходят за рамки вопроса поправки C2

[Patron]

Это уже вопросы к самой организации эмулятора, они выходят за рамки вопроса поправки C2

Хорошо если так.

Для устройств, имеющих разные векторы прерываний передачи и приёма, в реальном оборудовании (как правило) задан жёсткий порядок обсуживания этих прерываний при одновременном поступлении.

Является ли "правильной" эмуляция, при которой данный порядок не соблюдается и требует ли такая ситуация учёта и "поправки" - вопрос абстрактный.

[form]

Хорошо если так.

Для устройств, имеющих разные векторы прерываний передачи и приёма, в реальном оборудовании (как правило) задан жёсткий порядок обсуживания этих прерываний при одновременном поступлении.

Является ли "правильной" эмуляция, при которой данный порядок не соблюдается и требует ли такая ситуация учёта и "поправки" - вопрос абстрактный.

Ну это все отдельная тема по организации самого эмулятора.
Для этой темы думаю нашлось бы много полезного материала.

Мне же пока нужно просто чтобы С2 в эмуляторе заработал - тогда я успокоюсь даже без починки С2 в своем УКНЦ и буду его плавно готовить к тому, чтобы сплавить нахрен

В исходники эмулятора не полезу принципиально

[Patron]

Ну это все отдельная тема по организации самого эмулятора.
Для этой темы думаю нашлось бы много полезного материала.

В тему правильной эмуляции прерываний PDP-11 глубже всего проник Боб Супник: PDP-11 Interrupts: Variations On A Theme.

[form]

В тему правильной эмуляции прерываний PDP-11 глубже всего проник Боб Супник: PDP-11 Interrupts: Variations On A Theme.

В описании E11 есть глава, посвященная эмуляции прерываний в условиях эмулируемого же железа. В двух словах кроме уже упомянутых rank, level, нужен еще параметр сколько команд cpu пропустить прежде чем приерывание сработает. Это особенно критично для DECовского софта в котором часто обработчики прерывания надеются не на приоритет процессора, а на то, что хватит времени обработать прерывание раньше чем возникнет следующее

Тамже кстати примеры есть из реальной жизни.

---------- Post added at 18:16 ---------- Previous post was at 17:53 ----------

Кстати о Супнике... Ни у кого случайно нет с ним связи?
У них там в эмуляторе RK06/07 криво запись делает. Пробовал написать на адрес на который "пишите" - это оказался список рассылки на который еще надо подписаться. Попробовал подписаться - молчание. На том и кончилась добрая инициатива по отправке им патча

[Patron]

сколько команд cpu пропустить прежде чем приерывание сработает.

Так приходится поступать (например, буферизовать принимаемые через порт символы и передавать их процессору только тогда, когда после передачи предыдущего символа процессор успел выполнить не менее 100 команд ), но это уже относится не к корректной, а к комфортной эмуляции.

Это особенно критично для DECовского софта в котором часто обработчики прерывания надеются не на приоритет процессора, а на то, что хватит времени обработать прерывание раньше чем возникнет следующее

В ядре монитора RT11SJ есть забавный баг, который приводит к тому, что если очередной символ поступает на вход порта терминала раньше, чем процессор успел выполнить 100 команд - символы заносятся в кольцевой буфер ввода в обратном порядке. Причём, это происходит (если не ошибаюсь) даже в том случае, когда при генерации монитора заказан High Speed Ring Buffer :)

Во всех остальных мониторах, кроме SJ - такого бага нет.

[form]

В ядре монитора RT11SJ есть забавный баг, который приводит к тому, что если очередной символ поступает на вход порта терминала раньше, чем процессор успел выполнить 100 команд - символы заносятся в кольцевой буфер ввода в обратном порядке. Причём, это происходит (если не ошибаюсь) даже в том случае, когда при генерации монитора заказан High Speed Ring Buffer

Во всех остальных мониторах, кроме SJ - такого бага нет.

В доке на E11 упоминается это. А также MSCP, RK05 в RSTS итд
Сказать, что это баг не совсем верно будет - ведь на живом железе оно не проявляется. Так, что это скорее кривая реализация

[form]

Кстати насчет клавиатуры в SJ. На SB не распространяется - проверил

(клавиша выдает "1234567890")

[Patron]

Сказать, что это баг не совсем верно будет - ведь на живом железе оно не проявляется. Так, что это скорее кривая реализация :)

Баг проявляется, когда терминал может запоминать последовательности символов и передавать их (в нужный момент) компьютеру со скоростью порта терминала.

При скорости порта 9600 bps процессор должен выполнять менее 100'000 команд в секунду (т.е. иметь быстродействие меньше 0.1 MIPS), чтобы этот баг проявился.

При скорости порта 57600 bps - баг проявится при быстродействии процессора менее 0.6 MIPS.

Учитывая, что минимальная тактовая частота процессора 1801ВМ1 примерно 100 КГц, а при тактовой частоте 5 МГц быстродействие 1801ВМ1 составляет примерно 0.2 MIPS - вполне можно собрать реальную конфигурацию, в которой данный баг проявится.

[form]

Учитывая, что минимальная тактовая частота процессора 1801ВМ1 примерно 100 КГц, а быстродействие 1801ВМ1 при тактовой частоте 5 МГц составляет примерно 0.2 MIPS - вполне можно собрать реальную конфигурацию, в которой данный баг проявится.

Между можно собрать и тем, что выпускалось разница огромная

; DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR  RELIABILITY  OF  ITS
; SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.

знакомы строчки?

DEC частенько даже в коментариях писал замечания вроде "не менять команды местами", "не убирать вот эти команды" итд. RT-11 правда в этом отношении бедновата на коментарии вообще - более-менее детально коментировать его начал уже Mentec.