Это для ВМ2. На ВМ1 разница есть, не приснилось же мне =)Сообщение от Titus
Но тема про ВМ2, чего я не учёл, так что соглашусь.
Это для ВМ2. На ВМ1 разница есть, не приснилось же мне =)
Но тема про ВМ2, чего я не учёл, так что соглашусь.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
это сильно ограничивает по памяти. относительно спектрума графика спрайтов займет х2 тайлов х3
сколько там памяти всего 256+64=320 - ну маловато.
лучше запихивать паками по 8-16 экранов.2) Если оставить живой систему - то да, будет возможность подгружать например что-нибудь. Минусы такие - останется меньше памяти (навроде 40кб в основном процессоре и что-нибудь типа 15кб в периферийном, я не помню точные цифры, но сильно урежет память). Учитывая что только один фреймбуфер в периферийном процессоре - 7кб (14кб в основном проце) - там останется с гулькин нос. И подгрузка с диска уже будет как медвежья услуга (переходишь на другой экран в игре и дисковод начинает раскручиваться вжжж... начинает читать.. найс
как вообще устроена RT11? можно как-то ее минимизировать или она прибита гвоздями где удобно авторам?3) Код для периферийного проца придется писать перемещаемым. То-есть изначально не знаешь по какому адресу будет запущен код. Для ассемблера dec это не прям жуть, он специально даже можно сказать "заточен" для таких вещей (относительная адресация), но радости мне это не сильно добавляет ибо привык к абсолютным адресам.
С уважением,
Jerri / Red Triangle.
Но в УКНЦ только ВМ2. Поэтому все остальные процессоры не имеют значения)
Ну немного прибита гвоздями, но дело даже не прямо в ней. Система сидит в ОЗУ центрального процессора и даже пусть она выдаст 45 килобайт - уже вполне себе пойдет.
Но тут есть момент. В УКНЦ есть второй проц. И система эта RT-11 его использует и как "эмулятор контроллера дисковода", и как "эмулятор терминала", и как наверное еще что-то. Вообщем из-за того что второй проц все это дело эмулирует - дефолтно у него занято ОЗУ довольно сильно. Память у обоих процов своя и получив нормальный кусок памяти в первом процессоре, но не получив ничего во втором - я обломаюсь ибо:
1) Чтобы получить 8 цветов - второй проц нужно заюзать на полную (там придется хранить часть графония с одним битовым цветовым планом.
2) Также только периферийный проц может издать какие-либо биперные звуки (а они нужны тоже) - соответственно кусман кода/данных еще и на звуки в него надо запихать.
3) Также желательно чтобы он рисовал текст. Ибо опять - только он и может нарисовать условно говоря белым цветом. А это значит что шрифты хранить тоже в его ОЗУ (можно использовать ПЗУшные, но мне хочется 6х8, а не 8х8.. тут правда есть способ подрезать и сделать из 8-ми пиксельных 6-ти пиксельные.. однако изврат)
Если-же во втором проце выбросить всю левоту из памяти и под свои нужды заюзать где-то 30кб (32кб минус таблица прерываний/стек/таблица строк экрана) - то уже становится намного веселей.
Продолжу насчет игрухи. Вообщем взяв у manwe & ivanq компрессию с БКшки - получилось накропать лоадер который все скомпилированные куски памяти с диска сначала грузит в видеопамять, а затем распаковывает по четырем местам: ОЗУ центрального процессора, ОЗУ периферийного процессора, видеопамять планы 1,2 и видеопамять план 0.
Распаковка из видеопамяти в видеопамять это однако вышел тот еще изврат. Ладно фиг с ним с распаковкой по одним адресам. Но там еще и другое - видеопамять планов 1,2 адресуется сразу по слову, а алгоритм распаковки использует байты. Например нужно взять текущую позицию байтовую минус N байт. А адресовать можно лишь словами.. фууу УКНЦ чортова зараза такая
Сейчас думаю что сделать с вот таким:
Скриншот косяка
[свернуть]
Смысл кажется понятен - вся карта вся сделана тайлами 16х16. Персонаж лопатой может там копать (не все блоки) а-ля болдер даш. Разумеется выглядит это все криво с обрезанными гранями. Тратить кучу тайловой памяти на "обгрызание" по всем возможным вариантам одного лишь тайла - неразумно. (16 вариантов-же). Накладывать постоянно во фреймбуфер маску с обгрызанием поверх - затратно по процессору (и так 5-6 спрайтов еле осиливает, тайлы конечно побыстрее, но тоже не айс). Пока просто накидаю сверху неровностей если пустой кубик ну хоть нижнюю заполненную грань разнообразит.
BlaireCas, не надо болдер даш. болдер дашей много.
сделай платформер.
вот например
С уважением,
Jerri / Red Triangle.
А кэш завести -- не? Commander Keen выруливает по скорости как раз за счёт специально организованного кэша. Ну, УКНЦ -- это не PC+EGA, но всё же?
- - - Добавлено - - -
Болдердашей, да, до пня. Но зато -- это простая игра, на ней можно хотя бы двигло обкатать. Ну а там -- пусть будет платформер. А то, глядишь, и метроидвания вообще!
подробнее и с картинками:
https://retrocomputing.stackexchange...commander-keen
Нет, особо там ничего не прибито, можно конфигурировать и перепиливать, не вопрос. Проблема в том, что минимизировать её особо некуда, она и так зверски ужата. Когда работает пользовательская программа, то обязательно только присутствие RMON -- "Резидентного монитора". Который и есть ядро ОС. Ну и драйверов диска(ленты) и терминала, они небольшие.
Это реально минимум, дальше резать уж некуда. Разве что изобретать свою сверхпростую файловую систему. Ну терминал-то ладно, он для графической игры не нужен, но для УКНЦ его драйвер -- по сути пустышка, всё делает ПП.
Это определенно не самый лучший вариант для укнц.
Игры со скроллом карты не для такой организации экрана.
С уважением,
Jerri / Red Triangle.
Вот и вопрос можно ли оставить только ту часть ос что находиться в основной памяти.
С уважением,
Jerri / Red Triangle.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
