Descent - демо игры с 8-цветными спрайтами для УКНЦ

[BlaireCas]

Дошел до интересного момента. Начал части данных пытаться переносить в область видеопамяти. Поскольку использую разрешение 320х288 - часть видеопамяти пустует и пора уже озаботиться как туда что-то понапихать, а не ждать когда в CPU при компиляции закончатся его 56кб).
Обнаружил что виндовый порт макро-11 вполне компиляет (делает листинг) по адресам выше 177777 что сильно порадовало.
Но теперь сам этот момент: Я допустим собрал "снапшот" всей памяти 0-377777(8) CPU + "снапшот" 0-177777(8) всей памяти PPU... И... а как их загрузить-то??
Разумеется все будет грузиться средствами RT-11 и саму себя она затереть не должна пока загружает (после полной загрузки конечно-же затрется вообще всё). Пока-что мысли осваивать компрессию, грузить жатое в видеопамять, разжимать уже в обычную+видеопамять. Целиком таким образом все ОЗУ компьютера не загрузить конечно, но прям вообще всё и не нужно.

Вообщем пора ознакамливаться со сжатиями/распаковками... К счастью тут есть уже темы по ним и готовый код тоже.
Второй вариант - писать свой кастомный кусок считывания с дискеты/винта.. но это какая-т жесть будет уже.

Кстати, думаю, что не нужно именно для спрайтов делать отдельную ветку без сдвига.

Ну в общем случае верно. Однако мне поможет и отдельная.
Некоторые спрайты, скажем предварительно размещенные на уровне предметы, а возможно даже и выпавшие "из вон той крысы" будут изначально по смещению 0 пикселей. Также допустим паук, который по паутине лазает только вверх/вниз, разумеется аналогично изначально будет запланирован на нулевое смещение. Вылезающие из-под земли колья.. Да одним словом можно много чего придумать прибитое гвоздями по координате Х.

[Titus]

Второй вариант - писать свой кастомный кусок считывания с дискеты/винта.. но это какая-т жесть будет уже.

Зачем кастомный?
Я с RT-11 не работал в плане загрузки файлов с определенной позиции, но наверняка она есть чисто системными средствами. Надо у спецов спросить.

Грузишь в буфер кусок файла, перебрасываешь в теневую память, и так по кругу, пока все не загрузишь.

[jerri]

Дошел до интересного момента. Начал части данных пытаться переносить в область видеопамяти. Поскольку использую разрешение 320х288 - часть видеопамяти пустует и пора уже озаботиться как туда что-то понапихать, а не ждать когда в CPU при компиляции закончатся его 56кб).
Обнаружил что виндовый порт макро-11 вполне компиляет (делает листинг) по адресам выше 177777 что сильно порадовало.
Но теперь сам этот момент: Я допустим собрал "снапшот" всей памяти 0-377777(8) CPU + "снапшот" 0-177777(8) всей памяти PPU... И... а как их загрузить-то??
Разумеется все будет грузиться средствами RT-11 и саму себя она затереть не должна пока загружает (после полной загрузки конечно-же затрется вообще всё). Пока-что мысли осваивать компрессию, грузить жатое в видеопамять, разжимать уже в обычную+видеопамять. Целиком таким образом все ОЗУ компьютера не загрузить конечно, но прям вообще всё и не нужно.

уверен ли ты что убивать RT-11 обязательно?
сколько оно весит то?

раз уж есть ОС может использовать её для подгрузки ресурсов, например для разных мест игры?

[BlaireCas]

уверен ли ты что убивать RT-11 обязательно?

А даже и не знаю на самом деле.
1) Хочется сделать самодостаточную игрушку. Как бы это понятнее сказать.. как .TAP наверное в спеке (возможно ошибаюсь). Которая после загрузки больше ничего не просит. Загрузил (хоть с магнитофона) и вперед.
2) Если оставить живой систему - то да, будет возможность подгружать например что-нибудь. Минусы такие - останется меньше памяти (навроде 40кб в основном процессоре и что-нибудь типа 15кб в периферийном, я не помню точные цифры, но сильно урежет память). Учитывая что только один фреймбуфер в периферийном процессоре - 7кб (14кб в основном проце) - там останется с гулькин нос. И подгрузка с диска уже будет как медвежья услуга (переходишь на другой экран в игре и дисковод начинает раскручиваться вжжж... начинает читать.. найс
3) Код для периферийного проца придется писать перемещаемым. То-есть изначально не знаешь по какому адресу будет запущен код. Для ассемблера dec это не прям жуть, он специально даже можно сказать "заточен" для таких вещей (относительная адресация), но радости мне это не сильно добавляет ибо привык к абсолютным адресам.

Если бы я не хотел 8 цветов и звуковые эффекты - вот тогда да, самое простое это будет выгрузить максимально всякие драйвера с RT-11 для увеличения доступной памяти и работать только в центральном процессоре. Стандартный режим программок для УКНЦ.

[grf]

А даже и не знаю на самом деле.
1) Хочется сделать так-сказать самодостаточную игрушку. Как бы это понятнее сказать.. как .TAP наверное в спеке (возможно ошибаюсь). Которая после загрузки больше ничего не просит. Загрузил (хоть с магнитофона) и вперед.

Так в чем проблема? RT-11 позволяет открыть файл и читать его частями, ну так и прочитать большие файлы частями и распихать в память. Потом выкинуть RT-11, если совсем не нужно, и сделать на ее месте буферы или распаковать туда какие-то данные. Это ж не ЕМТ 36 на БК, где только одним куском файл прочесть можно.

[reddie]

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

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

[Titus]

А главное - перемещаемый код работает медленнее абсолютной адресации

Вообще-то адресация по абсолютному адресу и относительная по PC работают с одинаковой скоростью.

[Reobne]

перемещаемый код работает медленнее абсолютной адресации.

А может можно самомодифицированием подправить адреса-константы в коде?
Если да, то код не будет отличаться от абсолютного.

[reddie]

Вообще-то адресация по абсолютному адресу и относительная по PC работают с одинаковой скоростью.

Уж насколько я нуб в PDP, но даже не глядя в справочники по растактовке, по строению команды понятна её работа. Инструкция с абсолютной адресацией берёт аргумент и сразу работает с ним; относительной же приходится ещё и разницу (смещение) от РС высчитывать. Да, по размеру команды одинаковые, а вот быстродействие различается. Не буду сейчас лезть по справочникам и цитировать, ибо с телефона неудобно, но точно помню, что разница есть, и не в пользу относительной.

может можно самомодифицированием подправить адреса-константы в коде?
Если да, то код не будет отличаться от абсолютного

Почему бы нет... на БК и вообще PDP это вряд ли распространено ввиду наличия мощной относительной адресации, но на Спектруме широко применялась и применяется модификация кода (адресов) для его релоцируемости. Например, любой музыкальный редактор при компиляции плеера запрашивает его адрес, и по заранее составленной таблице модифицирует код, после чего уже плеер готов к работе с заданного адреса. Можно либо сделать так же, либо анализировать код и на лету корректировать абсолютную в относительную. Это потребует больше времени, но избавит от таблицы.

[Titus]

Уж насколько я нуб в PDP, но даже не глядя в справочники по растактовке, по строению команды понятна её работа. Инструкция с абсолютной адресацией берёт аргумент и сразу работает с ним; относительной же приходится ещё и разницу (смещение) от РС высчитывать. Да, по размеру команды одинаковые, а вот быстродействие различается. Не буду сейчас лезть по справочникам и цитировать, ибо с телефона неудобно, но точно помню, что разница есть, и не в пользу относительной.

Читать отсюда.