Попробовал на танке покататься:
https://yadi.sk/d/XLyQ-qbc_17P5w
Нужно думать как ускорять (хотя циклы вывода уже развернуты). Можно попробовать засунуть танк в ПП (заранее сдвинув спрайты).
Вид для печати
Попробовал на танке покататься:
https://yadi.sk/d/XLyQ-qbc_17P5w
Нужно думать как ускорять (хотя циклы вывода уже развернуты). Можно попробовать засунуть танк в ПП (заранее сдвинув спрайты).
Когда выезжаешь из первой комнаты, и возвращаешься, левый нижний угол комнаты портится.
Я в курсе. Этож только для прикидки делалось, чтобы ресурсоемкость определить.. танк все равно убирать придется в ПП.
Кстати в оригинале есть такая "подлость", что можно самому по запарке подстрелить свой танк (тогда начнешь все с начала), стоит ли оставлять?
- - - Добавлено - - -
О великие ГУРУ УКНЦ, спуститесь наконец с "микросхемных небес" и объясните мне тупому как быть..
(мы работаем в адресном пространстве ЦП)
Всем понятная ситуация (кто пробовал рисовать по вектору 100).. когда пришло прерывание, нужно отключить таймер чтобы не начал повторно рисовать (если не успел)..
Варианты.. попросить через терминал, свой обработчик в ПП... медленные, получаются глюки.
С отрубанием MTPS работает, но дергано и (при переходе в другую локацию)... стирает не там.. (это к сообщению Titus выше).. (успеть нарисовать за ход луча не вариант, итак уже рисуем чет-нечет, скорости разные (на единичку) чтобы в кадр попадало как можно меньше объектов)
Как бы вы справились с подобной ситуацией? (Или УКНЦ сделана для работы только с RT-11 и только для совместимости с терминалами и для работы с софтом который стырили у DEC? )
- - - Добавлено - - -
Это я к чему... если вырубить таймер то анимация будет гораздо плавнее, а не рывками с пропусками больших кусков кода по MTPS.
Классический подход при работе с прерываниями на архитектуре PDP-11 - обработчик прерывания начинает работать на уровне приоритета устройства (точнее - на том, что загрузилось в PSW из слова вектор_прерывания_+_2) и, по рекомендациям DEC, на выполнение работы у него есть с десяток команд процессора. Напоминаю, PDP-11 проектировались, в том числе, для создания систем реального времени. Если обработчик прерывания не успел сделать свою работу, то, по хорошему, должна быть очередь для обработки таких (отложенных) прерываний, соответственно, запрос на продолжение работы ставится в эту очередь и обработчик завершает свою работу. После того, как ВСЕ активные запросы на прерывания будут обработаны или поставлены в очередь - начинается выборка заданий из очереди - и доделывание работы.Цитата:
Сообщение от S_V_B
С учётом того, что твоя игрушка - по сути система реального времени (к примеру, отрисовка в обработчике прерывания заняла 2 секунды - на 2 секунды игра застыла и не реагирует, скажем, на прерывания от клавиатуры) - или хайли оптимизировать обработчик прерывания от таймера или переходить на выше описанный вариант или высчитывать синхронизацию разных действий (с очень небольшим количеством выполняемых команд) с точностью до команды.
И в третьем случае:
- это 101, а не 2 команды.Код:mov #100., r1
10$:
sob r1, 10$
- - - Добавлено - - -
в соответствии со стандартной архитектурой PDP-11 и на ней будет работать всё, что написано под эту архитектуру. Именно поэтому перенос на неё, скажем, RT-11 - тривиален, в отличии от, скажем, БКЦитата:
Сообщение от S_V_B
Это я к чему... если вырубить таймер то анимация будет гораздо плавнее, а не рывками с пропусками больших кусков кода по MTPS.
Не заметил очереди.. режет по живому :)Цитата:
Сообщение от Hunta
это находится в другом адресном пространстве.. и насколько я понял в ЦП полезных прерываний нет.. поэтому и работает при MTPS #200Цитата:
Сообщение от Hunta
Вопрос в другом как у этого "котопса" выключить быстро таймер у пса если это можно сделать только попросив кота?
- - - Добавлено - - -
Да к стати я придумал кличку для УКНЦ -"КОТОПЕС ". (ORR)
Обычно эту работу берёт на себя операционка. И по большей части этот механизм сделан для драйверов. Но в RSX есть API и для программ, но он несколько более (для программ /PR:5) или более замороченный (для программ /PR:0). И ЕМНИП, что то есть и в RT.Цитата:
Сообщение от S_V_B
Или же программа сама реализует (похожий) механизм.
Прерывание от клавиатуры и вывода на экран (177560-177566), прерывание от С2, по идее - прерывание от MZ, вектор 4, вектор 10 - это как минимум.Цитата:
Сообщение от S_V_B
MTPS #200Цитата:
Сообщение от S_V_B
Быстрее - нет. Это - логическая маскировка. Физическая маскировка (нет на УК-НЦ) -- BIC #100, @#177546. Почему маскировка. Таймер каждые 0.02 с выставляет запрос на прерывание. В этот механизм разрешение или запрет никак не вмешивается. То есть, если за 0.0000000001с до выставления запроса включить разрешение - от через 0.0000000001 с прилетит прерывание. А не через 0.02 с
Все в периферийном поцесссре.. и ни как нас не касается (КОТОПЕС)Цитата:
Сообщение от Hunta
MTPS #340 - на УКНЦ не должен работать, хотя во всех книжках пишут именно так.Цитата:
Сообщение от Hunta
Какая разница где - механизм прерываний и их обработка одинаков.Цитата:
Сообщение от S_V_B
Отработает любая команда MTPS #байт. И выставится любой приоритет процессора от 0 до 7. Просто снаружи возможен запрос только с пятым приоритетом, так что или выставить приоритет от 0 до 4 - и тогда снаружи прилетит, или от 5 до 7 - и тогда запросы снаружи игнорируются.Цитата:
Сообщение от S_V_B
Быстрее работающий ЦП.. никак не может на это повлиять... ну не верю... вы же под микроскопом смотрели... должна быть какая-то ячейка при обнулении которой таймер останавливается.. за 3 такта.. (шучу конечно)
- - - Добавлено - - -
Не забывай - два процессора - две разные машинки. :)Цитата:
Сообщение от Hunta
И ПП разрешает прерываться по 100му ЦП.