БК-11М в 21м веке

06
Май
2024

Зомби обзаводятся мозгами

После длительных разборок с видеовыводом на железный и эмулируемый блиттер, я решил пока забить на глюки и просто делать игру дальше. Первым делом обучил Зомби распознавать лестницы и добавил нужную анимацию шагов вниз по ступенькам:

 

30
Апр
2024

Накрылось видео – займусь пока звуками

Так как с выводом на блиттер возникли проблемы (подробно описанные в предыдущем посте), решил пока заняться звуками из Dave. Формат оригинальных файлов звука уже нашел, изучаю. В AZBK можно выводить звук и на AY и на 2AY и на Covox…

30
Апр
2024

Внезапные грабли

Графика в текущем проекте (Dave) выводится с помощью AZBK, а точнее с помощью одной из графических фич AZBK – блиттера. Суть “азбучного” блиттера состоит в том, что ему можно давать пакет команд, который он читает себе в буфер и потом выполняет уже самостоятельно, не отнимая процессорного времени.

Читать далее

17
Апр
2024

Среда разработки

Все очень просто:

  • Превосходный эмулятор БК11М https://gid.pdp-11.ru/
  • В нем запускаю ANDOS.
  • Код пишу во встроенном редакторе оболочки ANDOS или редакторе Vortex, если текст очень длинный.
  • Компилию старым добрым micro1103.
  • Собираю все линковщиком link Евгения Пашигорова с помощью батников.
  • Если надо перенести какие-то спрайты с PC – пишу их сразу в образ диска с помощью BKDE, а там превращаю в .obj с помощью утилиты 2obj (Е. Пашигоров)

И никаких проблем.

16
Апр
2024

Призраки и Блиттер

Наконец-то я победил эти “хвосты” при скроллинге! Можно делать игру дальше!

При больших сдвигах рулона среднего экранного слоя (где бродят Зомби) промелькивали объекты, которые должны были уже быть стерты. И борьба с ними заняла у меня три дня…

Пока я использовал блиттер в атоматическом режиме (он при этом сам стартует при каждом прерывании по вектору 100) – все было почти хорошо. Точнее, в эмуляторе было вооще все хорошо, а вот на реальном железе при глобальном скроллинге экрана иногда наблюдалось какое-то дергание экрана.  Этим, конечно же, было поручено заняться Тэду из будущего. При этом возникал вопросы о скоростном построении экрана из множества тайлов – ведь количество команд, которые можно скормить блиттеру за раз, ограничено.  А это значит, что лабиринт будет заполняться порциями, каждыя из которых будет выводиться при очередном прерывании по вектору 100 (“кадровое”). С появлением в AZBK режима ручного запуска блиттера, эта проблема ушла – выдаем блиттеру пакет за пакетом и запускаем все это сами, не ожидая милостей от вектора 100. Заодно появилась возможность сбрасывать блиттеру фоновые задачи, типа “удали старые спрайты со скрытого экрана, а мы в это время посчитаем куда какому монстру сделать шаг”. И вывод на экран стало возможно делать тогда, когда хочется, а не ожидая очередного “кадрового” прерывания. Вот тут и был подвох.

Как только я добавил Зомби, шагающих туда-сюда, потребовалось их еще и скроллить вместе с фоном, когда Дейв инициирует движение окна. При этом, когда скроллинг (вертикальный или горизонтальный) докручивался до максимума и надо было уже переключать окно, вдруг могли промелькнуть какие-то дополнительные фигуры Зомби, там, где их никак быть не могло. Я предположил, что это спрайты, которые не успели стереться, а это место экранной страницы было вытащено скроллингом на видимую область экрана.  Стало ясно, что эти вещи надо тоже теперь синхронизировать вручную – сдвиг рулонов и переключение видимой области экрана. Но когда пакет команд блиттеру ушел, то о том, что блиттер его обработал, можно судить только по биту 15 в регистре 177270. Т.е. надо ждать, когда этот бит сбросится в 0 и потом можно переключать  рулоны.

А рулоны двигаются совсем в другом месте – в подпрограмме перемещения слоев в зависимости от деятельности Дейва. Блиттер работает сам по себе где-то в фоне, а вот регистры скроллинга изменяют изображение сразу. Значит, нам в этой подпрограмме нельзя изменять сами регистры, нужно просто вычислять новые значения, чтобы применить их потом, сразу кучей, после того, как блиттер закончит стирать/выводить спрайты и все будет готово к отображению нового кадра. Причем желательно  это сделать как раз в момент обратного хода луча, чтобы было незаметно.

В итоге, я завел несколько переменных, содержащих копии регистров управления слоями экрана и движок теперь изменяет не сами регистры, а эти переменные. А перенос значений из этих переменных в сами регистры происходит в тот момент, когда все готово и блиттер завершил обработку команд.

Вот тогда призраки и были изгнаны и “дрожь земли” пропала!

Да, еще я напоролся на небольшие грабли: если пакет команд маленький, то блиттер так шустро его выполняет, что бит 15 (признак работы блиттера) и установиться не успевает. И это приводило к бесконечным ожиданиям “когда ты там начнешь команды обрабатывать??” и зависаниям.