Edge Grinder для ZS GMX

[reddie]

Двойная защита карты только для третьей части из четырёх. На турбо на неё попадает прерывание, а на не турбо как повезёт )

А это можно тоже на бордюр выводить, кстати =) Прямо в выходе из обработчика дописать пару команд, там только регистр A нужен, который все равно портим.
То есть там, где идет push-pop из BC, до них или после них поставить зеленый/белый/какой еще, а на входе в обработчик после сохранения регистров - черный.
Если "попались" на SP,IY- бордюр моргнет. Только тогда нужно убрать все остальные выводы в порт.

[izzx]

А это можно тоже на бордюр выводить, кстати =)

А я просто точку останова поставил в эмуле. Изредка, но попадает на push bc: pop bc в обработчике. Значит, не зря старались.

Какие идеи по отлову бага? Может я не знаю чего. После зависания захожу в отладчик, а там регистр PC уже далеко уехал, история на экране затёрлась. Как найти точку сбоя? Методом перебора или исключения пока не подловил.

Да, ещё мысль: получается, можно целиком экран за два прерывания выводить. Но ни на что другое времени не останется. Думаю, может видео ролик можно склепать на 7 секунд со скоростью 16 кадров из 120 страниц памяти, без всякого сжатия. Это в порядке баловства.
upd. Или 25 кадров.

[reddie]

получается, можно целиком экран за два прерывания выводить

В турборежиме - да. Еще и время остается на что-нибудь. Маленькое.
Но в игре лучше ограничиться тем окном, что уже есть =)

По поводу бага... хз, даже не смотрел еще версию с последними изменениями.
Можно попробовать тот же метод с бордюром: зарезервировать для каждой части кода свой цвет.
То есть 8 цветов в наличии, черный - вывод карты, синий - вывод спрайтов, красный - музыка,
зеленый - блок логики и так далее. Таким образом визуально отсечь проблему.
Дальше уже дробить на более мелкие "кусочки" исследуемый код.
В обработчике прерываний, естественно, бордер не трогаем, да и красным не мигаем (когда 16 фпс).
Кстати, а как именно оно виснет? Музыка продолжает играть или тоже вешается с воем?

[izzx]

Кстати, а как именно оно виснет? Музыка продолжает играть или тоже вешается с воем?

Когда как. Чаще продолжает играть.
Наставил цветов бордера в разных местах - на разных цветах виснет ). Убрал вывод карты совсем - тоже виснет.
Интересно. Буду думать. Где-то страница, наверно, не та включатся.

[reddie]

Где-то страница, наверно, не та включатся.

Если глюки начались после работ по переделке вывода - скорее всего, что да, нужно копать в перемещенных процедурах.
Либо не та страница врубается, либо код не полностью "перемещен", либо что-то убивается на прерываниях.
Но последний вариант маловероятен, для этого нужно не сохранять какую-то регистровую пару.
Скорее всего, перемещенный код вызывает что-то по прежним адресам, а там уже пусто. Точнее, вывод экрана.

[izzx]

Порядок. Виновата процедура печати счётчика кадров. Если счётчик не включать, то не виснет. Но почему так - не знаю ). Потом разберусь.
Чуть погонял не в турбо режиме - в одном месте карта попортилась. Но это ничего, так задумано.

[Advertiser]

[izzx]

Отловил глюк со счётчиком. Выложил текущую версию. На железе выдаёт 25 кадров, иногда сваливается в 16, когда на границе экрана 2 и более спрайта. Потому что вывод целых спрайтов идёт быстрым способом, а на границе экрана, когда видна часть спрайта, медленным.
Думаю, есть ещё резервы для оптимизации.
Используется примерно 89 страниц памяти из 128.

[reddie]

а на границе экрана, когда видна часть спрайта, медленным способом

Вот тут стоит покопаться =)) По идее, наоборот, кусок спрайта должен выводиться быстрее, чем целый.
Бегло порыл список файлов в исходниках, вроде как вывод частичного спрайта - файл EG_Sprites_Partial.asm только это уже Спектрум или еще Амстрад? =)
Толком не разбирался, но параметры такие: высота спрайта, кажись, 10 "пикселей", если байт нулевой - пропускаем. Иначе затираем байт атрибутов целиком, а не половинки по маске (как я думал).
Далее, после каждого впечатанного байта идет конструкция ex de,hl: and a: sbc hl,bc: ex de,hl - при таком пересчете, естественно, вывод будет жрать кучу времени.
Если правильно понял - спрайты выводятся вертикально, по столбцам. Хуже может быть только вывод крест-накрест =)) Желательно переделать на нормальный, построчный, вместе с форматом спрайтов.
После каждой линии пара DE загружается из адресуемой через IX таблицы - тоже прожорливо. Точнее, это получаются не линии, а столбцы, раз выводим вертикально, а 10 - это ширина.

PrnSprLoopL5
	push bc
	ld bc,80
	
    ld e,(ix+0)
    inc ixl
    ld d,(ix+0)
    inc ixl

Но если выводим вертикально - зачем брать следующий адрес из таблицы? Достаточно сохранить-восстановить DE из стека и увеличить на 1.
Сам вывод можно развернуть в коде, благо, свободная память имеется. Конструкциями вида LD (HL),NN:INC L, либо сразу INC L, если байт пустой.
Потребуется свой кусок кода для каждой "частичной" фазы, как и для целого спрайта, но вывод будет пошустрее.
И намного пошустрее, если выводить линиями (горизонтально), ибо для перехода на следующую будет достаточно сделать ADD HL,BC (ВС=80-ширина спрайта, что-то типа того)

[izzx]

вывод частичного спрайта - файл EG_Sprites_Partial.asm

Да. Там для каждого случая свой раздел. Вывод слева по 1,2,3,4,5 столбиков, то же для правой части. И сверху-снизу тоже часть умеет выводить. Адреса хранятся для каждой пары строк. Высота 21 строка - значит 11 адресов на спрайт.
Вот так я писал:
Спрайт занимает 126 байт, 6 байт ширина, 21 высота, занимаемое место округляется до 128
Выводится в таком порядке байт:
01 03 05 07 09 11
00 02 04 06 08 10
13 15 17
12 14 16 18...
А последняя строчка по порядку 120 121 122 123 124 125.
Причём нули пропускаются, не выводятся. Поэтому не надо маски.

Вот переделывать формат спрайтов мне меньше всего охота было )
При быстром выводе через ld (NN),hl хитрый формат спрайта почти не влияет на скорость. Там по строчкам выводится всё равно.
А тут да, очень криво выходит.

[reddie]

Причём нули пропускаются, не выводятся. Поэтому не надо маски.

Но тогда получается, что затираем сразу два "пикселя" экрана (карты), даже если один из них пустой в спрайте. Или там у спрайтов все "пиксели" по два шириной?

Вот переделывать формат спрайтов мне меньше всего охота было )

А надо бы =)) Ибо вертикальный вывод плюс еще пересчет адресов строк сжирают кучу времени.

При быстром выводе через ld (NN),hl хитрый формат спрайта почти не влияет на скорость

Не, это другие команды. LD (NN),HL подходит для переброса карты через стек по 2 байта сразу, а вот спрайты без стека и побайтово, через LD (HL),N - стек не трогается.
То бишь каждый спрайт развертывается в кусок кода. Например, спрайт (условно) 4х4 пикселя, пустой байт - ноль, заполненный (1) - FF. Сам спрайт такой:

0110
1111
1001
0110

Код вывода для него развертывается вот в такой кусок:

	INC	L		;0
	LD	(HL),#FF	;1
	INC	L
	LD	(HL),#FF	;1
	INC	L		;0, INC для корректного пересчета HL
	ADD	HL,BC

	LD	(HL),#FF	;1
	INC	L
	LD	(HL),#FF	;1
	INC	L
	LD	(HL),#FF	;1
	INC	L
	LD	(HL),#FF	;1
	ADD	HL,BC

	LD	(HL),#FF	;1
	INC	L
	INC	L		;0
	INC	L		;0
	LD	(HL),#FF	;1
	ADD	HL,BC

	INC	L		;0
	LD	(HL),#FF	;1
	INC	L
	LD	(HL),#FF	;1
	RET			; последний INC уже не нужен,
				; если код развертки это обработает

Для перехода вниз на строку достаточно одной команды ADD HL,BC. Усеченные спрайты (по ширине) будут выводиться еще быстрее.
В данном конкретном примере #FF можно было бы заменить на регистр, но в реальности там будут разные значения, потому - числами.
Согласен, переделывать формат и вывод - занятие не на полчаса, но если уж делать, то делать =))