Портирование игры "Last Mission" на УКНЦ

[S_V_B]

Кстати в оригинале есть такая "подлость", что можно самому по запарке подстрелить свой танк (тогда начнешь все с начала), стоит ли оставлять?

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

О великие ГУРУ УКНЦ, спуститесь наконец с "микросхемных небес" и объясните мне тупому как быть..
(мы работаем в адресном пространстве ЦП)
Всем понятная ситуация (кто пробовал рисовать по вектору 100).. когда пришло прерывание, нужно отключить таймер чтобы не начал повторно рисовать (если не успел)..
Варианты.. попросить через терминал, свой обработчик в ПП... медленные, получаются глюки.
С отрубанием MTPS работает, но дергано и (при переходе в другую локацию)... стирает не там.. (это к сообщению Titus выше).. (успеть нарисовать за ход луча не вариант, итак уже рисуем чет-нечет, скорости разные (на единичку) чтобы в кадр попадало как можно меньше объектов)

Как бы вы справились с подобной ситуацией? (Или УКНЦ сделана для работы только с RT-11 и только для совместимости с терминалами и для работы с софтом который стырили у DEC? )

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

Это я к чему... если вырубить таймер то анимация будет гораздо плавнее, а не рывками с пропусками больших кусков кода по MTPS.

[Advertiser]

[Hunta]

когда пришло прерывание, нужно отключить таймер чтобы не начал повторно рисовать (если не успел)..

Классический подход при работе с прерываниями на архитектуре PDP-11 - обработчик прерывания начинает работать на уровне приоритета устройства (точнее - на том, что загрузилось в PSW из слова вектор_прерывания_+_2) и, по рекомендациям DEC, на выполнение работы у него есть с десяток команд процессора. Напоминаю, PDP-11 проектировались, в том числе, для создания систем реального времени. Если обработчик прерывания не успел сделать свою работу, то, по хорошему, должна быть очередь для обработки таких (отложенных) прерываний, соответственно, запрос на продолжение работы ставится в эту очередь и обработчик завершает свою работу. После того, как ВСЕ активные запросы на прерывания будут обработаны или поставлены в очередь - начинается выборка заданий из очереди - и доделывание работы.

С учётом того, что твоя игрушка - по сути система реального времени (к примеру, отрисовка в обработчике прерывания заняла 2 секунды - на 2 секунды игра застыла и не реагирует, скажем, на прерывания от клавиатуры) - или хайли оптимизировать обработчик прерывания от таймера или переходить на выше описанный вариант или высчитывать синхронизацию разных действий (с очень небольшим количеством выполняемых команд) с точностью до команды.

И в третьем случае:

 mov #100., r1
10$:
  sob r1, 10$

- это 101, а не 2 команды.

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

УКНЦ сделана

в соответствии со стандартной архитектурой PDP-11 и на ней будет работать всё, что написано под эту архитектуру. Именно поэтому перенос на неё, скажем, RT-11 - тривиален, в отличии от, скажем, БК

[S_V_B]

Это я к чему... если вырубить таймер то анимация будет гораздо плавнее, а не рывками с пропусками больших кусков кода по MTPS.

Если обработчик прерывания не успел сделать свою работу, то, по хорошему, должна быть очередь для обработки таких (отложенных) прерываний

Не заметил очереди.. режет по живому

игра застыла и не реагирует, скажем, на прерывания от клавиатуры)

это находится в другом адресном пространстве.. и насколько я понял в ЦП полезных прерываний нет.. поэтому и работает при MTPS #200

Вопрос в другом как у этого "котопса" выключить быстро таймер у пса если это можно сделать только попросив кота?

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

Да к стати я придумал кличку для УКНЦ -"КОТОПЕС ". (ORR)

[Hunta]

Не заметил очереди

Обычно эту работу берёт на себя операционка. И по большей части этот механизм сделан для драйверов. Но в RSX есть API и для программ, но он несколько более (для программ /PR:5) или более замороченный (для программ /PR:0). И ЕМНИП, что то есть и в RT.

Или же программа сама реализует (похожий) механизм.

и насколько я понял в ЦП полезных прерываний нет

Прерывание от клавиатуры и вывода на экран (177560-177566), прерывание от С2, по идее - прерывание от MZ, вектор 4, вектор 10 - это как минимум.

выключить быстро таймер

MTPS #200

Быстрее - нет. Это - логическая маскировка. Физическая маскировка (нет на УК-НЦ) -- BIC #100, @#177546. Почему маскировка. Таймер каждые 0.02 с выставляет запрос на прерывание. В этот механизм разрешение или запрет никак не вмешивается. То есть, если за 0.0000000001с до выставления запроса включить разрешение - от через 0.0000000001 с прилетит прерывание. А не через 0.02 с

[S_V_B]

Прерывание от клавиатуры и вывода на экран (177560-177566), прерывание от С2, по идее - прерывание от MZ, вектор 4, вектор 10 - это как минимум.

Все в периферийном поцесссре.. и ни как нас не касается (КОТОПЕС)

MTPS #200

MTPS #340 - на УКНЦ не должен работать, хотя во всех книжках пишут именно так.

[S_V_B]

Быстрее работающий ЦП.. никак не может на это повлиять... ну не верю... вы же под микроскопом смотрели... должна быть какая-то ячейка при обнулении которой таймер останавливается.. за 3 такта.. (шучу конечно)

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

Какая разница где - механизм прерываний и их обработка одинаков.

Не забывай - два процессора - две разные машинки.
И ПП разрешает прерываться по 100му ЦП.

[Titus]

S_V_B, лучше расскажи на пальцах, зачем тебе запрещать прерывания 50Гц на ЦП, и что ты делаешь с помощью этих прерываний.

[S_V_B]

На 100м векторе висит список объектов (с признаком активности)... если актвен..то рисуем..

[Titus]

На 100м векторе висит список объектов (с признаком активности)... если актвен..то рисуем..

Эта информация ни о чем.

Из нее непонятно, зачем тебе отключать это прерывание?

[S_V_B]

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

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

Из нее непонятно, зачем тебе отключать это прерывание?

Иногда объектов становится больше чем мы можем отрисовать.

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

Titus, ты кстати проверил почему "шизики" падают в твоем эмуляторе?