Программирование на ассемблере

[ivagor]

Хорошо бы конечно иметь сборник статей по разным аспектам программирования для вектора (и для других компов с 8080) на современном уровне. Но мне не очень хочется его писать. Многие вещи были упомянуты/разобраны на форуме, только найти эти упоминания со временем все сложнее. Самый злостный катализатор, популяризатор и каталогизатор процедур для вектора наверно svofski. Он старается по результатам разборок разных тем как-то финализировать и сделать более-менее понятным при последующем возвращении.

[Advertiser]

[svofski]

Я люблю позаписывать иногда, но делаю это недостаточно последовательно и часто неопрятно. Вот неплохо получились рыбы из прекрасма -- текст, линия, мандрилл -- я почти каждую новую поделку начинаю с одной из них. С тех пор накопилось еще много интересного и оно сидит в разной форме где попало. Есть текст 512, который заодно служит ориентиром по использованию режима 512 вообще. Разные виды вывода спрайтов. Музыка на AY и ВИ53. В общем неплохой набор из чего можно сделать что угодно, но как ivagor верно подметил, быстро теряется и искать нелегко.

Книга, даже если это просто большая шпаргалка, подразумевает пояснительный текст и иллюстрации. Ясно излагать -- это надо уметь и любить. У меня обычно получается только запутать. Технически GitBook несложный. Можно начинать просто с того, что сделать репу, настроить GitBook, добавить файлы с фрагментами кода, а лирику и картинки добавлять потом. Все пишется в маркдауне прямо в веб-редакторе с превью. Целиком запускающиеся примеры можно держать в той же репе.

[ivagor]

Пользуясь случаем хочу высказать пожелание внести в grad.asm на гитхабе последние правки, чтобы не потерялись.

[KTSerg]

У двухбитпланового стекового варианта есть серьезный недостаток - несовместимость с методом Медноногова, нельзя использовать при разрешенных прерываниях. Исправление этого недостатка + небольшое ускорение:
...
;(88+100)/4=47 тактов/байт

Ндас... при такой скорости, практически теряется смысл пытаться упаковывать алгоритм в двух-байтную (24 такта на байт) команду (в ПЛИС-процессоре).
Если только совмещать её с автоматическим сдвигом (маски и спрайта).

[ivagor]

Если говорить о задаче вывода спрайтов (и тайлов) на экран, то стоит оценить предельный возможный вариант. Ограничивающий фактор - скорость шины вектора, 4 такта/байт. В идеале вся пропускная способность должна идти только на пересылки, без выборки команд. Вижу 2 способа обеспечения этого (речь о замене только процессора в стандартном 06Ц):
1. Добавление развитого контроллера DMA (DMA-сопроцессора). Он должен "знать" о строении экрана вектора, и в нем должна быть куча регистров с параметрами спрайтов, чтобы их (параметры) не вдавливать туда кучей outов. Ядро 8080 в этом случае только дает команду - вывести 1й спрайт сюда, 2й сюда и т.д.
2. Частичный разгон ядра 8080. Можно реализовать вывод спрайтов программно, но нужно некоторое количество быстрого озу внутри проца (или кеш). С этим озу проц пусть работает на 48 или 96 МГц, а снаружи опять видны только пересылки байтов.
Можно немного усугубить, использовав часть внутреннего озу по крайней мере для части спрайтов (подходит и для 1 и для 2). Это еще уменьшает нагрузку на шину вектора.
Не могу призывать реализовать какой-то из этих вариантов (все упрется в малую распространенность и программную поддержку, вернее в ее отсутствие), но при оценке промежуточных вариантов стоит учитывать не только имеющиеся процедуры, но и предельные возможные варианты.

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

Для примера вывод 15-цветного спрайта 16x16. 15 потому что без отдельной маски, ее можно получить по "ИЛИ" 4х байтов спрайта разных плоскостей. Минус 1 цвет (0й цвет - прозрачный), зато минус выборка (и хранение) маски.
Чтение 2*16*4=128 байт спрайта. Чтение 3*16*4=192 байт из VRAM. Запись 3*16*4=192 байт в VRAM. Итого (128+192+192)*4=2048 тактов/такой спрайт. Если хранить спрайт во внутреннем озу, то (192+192)*4=1536 тактов/такой спрайт.

[svofski]

Пользуясь случаем хочу высказать пожелание внести в grad.asm на гитхабе последние правки, чтобы не потерялись.

Спасибо, что напомнил. Я это сделал сразу, но забыл пушнуть.

[ivagor]

Если хранить спрайт во внутреннем озу, то (192+192)*4=1536 тактов/такой спрайт.

Хочу все же дожать до предела. В плисине можно хранить не только спрайты, но и копию экрана вектора. Если плисина жирная, то прям графическую копию. Если не очень жирная, то можно ориентироваться на тайловый экран. Пусть 256 шестнадцатицветных тайлов=8 кб, плюс килобайт под "тайловый экран". Так или иначе это позволяет отказаться от чтения VRAM, остается только запись и ранее приведенный пример уменьшается до (192)*4=768 тактов/спрайт. Это абсолютный максимум скорости (или минимум тактов), быстрее для 06Ц при замене проца никак не получится.

[KTSerg]

Хочу все же дожать до предела.
...
ранее приведенный пример уменьшается до (192)*4=768 тактов/спрайт. Это абсолютный максимум скорости (или минимум тактов), быстрее для 06Ц при замене проца никак не получится.

Грубо говоря, получается, это вывод на экран около 60 полноцветных спрайтов 16х16 с маской, за интервал между прерываниями... ?

[ivagor]

312*192/768=78 спрайтов за прерывание. Но это без учета логики игры, без восстановления фона, без звуков, ну и без низкоуровневого управления спрайтами (куда какой вывести). А самое главное - при 16 цветах 06Ц не может обеспечить двойную буферизацию, значит придется ограничить время вывода спрайтов невидимыми областями, чтобы без миганий. Или ограничить число цветов до 8 или 4, тогда с двойной буферизацией хоть весь экран (или полэкрана для 8 цветов) в спрайтах.

[nzeemin]

Книга, даже если это просто большая шпаргалка, подразумевает пояснительный текст и иллюстрации. Ясно излагать -- это надо уметь и любить. У меня обычно получается только запутать. Технически GitBook несложный. Можно начинать просто с того, что сделать репу, настроить GitBook, добавить файлы с фрагментами кода, а лирику и картинки добавлять потом. Все пишется в маркдауне прямо в веб-редакторе с превью. Целиком запускающиеся примеры можно держать в той же репе.

Если это будет на гитхабе - это форки/пулл-реквесты и кто-то должен майнтейнить. Мне больше нравится формат вики. Я пока попробую подсобирать ссылки и фрагменты кода на emuverse, например:
http://www.emuverse.ru/wiki/%D0%92%D...BD%D1%8B%D1%85