Вывод атрибутов из буфера

[ALKO]

Пытаюсь написать вывод атрибутов из буфера на видимую область.
Причём сам буфер на данный момент по ширине составляет 64х24 атрибутных пикселя на случай, если атрибутные пикчи будут вылазить за экран и чтоб не производить проверку при их рендеринге в буфер. Но вообще я бы хотел ещё и по вертикали его расширить для тех же целей. Но пока даже с горизонтальной шириной не выходит. Прога крашит. Что тут не так?

SWAP_BUF 
		Ld a, 24 ;количество строк атрибутов
		ld hl, virtbuf ;адрес буфера
		ld de, #5800 ; видимый экран
	BUF_LOOP
		
		dup 32
		Ldi 
		edup
		
		Ld bc, 32 ;(64 - 32) остаток строки буфера
		Add hl,bc
		Dec a
		Jr nz,	BUF_LOOP

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

Тока щас осенило, что возможно буфер залазит на область бейсика, из которого я провожу вызов теста... Ладно. Завтра уже проверю по адресам

[Advertiser]

[Destr]

бейсика, из которого я провожу вызов теста

А ещё подозрительно не видно RET...

[reddie]

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

[Lethargeek]

взял бы, да банально оттрассировал бы давно, чем гадать и ответов ждать

[Destr]

взял бы, да банально оттрассировал бы давно, чем гадать и ответов ждать

А ещё лучше - снапку кинул сюда. Уже ведь любопытно стало

[ALKO]

Спасбо за внимание. Всë пашет норм.

[ALKO]

У меня процедура заточена под фиксированный размер спрайтов.
Если желаю указать другой, то мне надо менять значения счётчиков (регистры BC), а также итерацию для перехода на следующую строку (в данном случае Add #55), которая имеет зависимость от ширины спрайта.
Помогите это дело автоматизировать, чтоб при этом оно не сильно просело по скорости.
Допустим, размеры спрайта будут в двух первых числах DEFB, а далее уже сами данные.

	

; расчет адреса атрибутов знакоместа на экране
; вход: h=строка экрана, l=столбец экрана
; выход: hl=адрес знакоместа на экране, b=строка экрана, c=столбец экрана
			
			ld	a,h
			rrca
			rrca
			rrca
			ld	e,a
			and	#31
			or	#246 ; умножить наааа 255
			ld	d,a
			ld	a,e
			and	#0 ; +0  получаем начало атриутной области
			or	l
			ld	e,a

			ld hl, #IDLE_PLAYER

			LD c,#10 ;высота спрайта
DRAW_SPRITE2:
			LD b,#9 ;шырина спрайта
DRAW_SPRITE1:
			ld a,(hl)
			or a
			jp z, TRANSPARENT ; пиксель просрачный?

			ld (de),a
			
TRANSPARENT:	inc de
			;dec de ;для зеркалки
			inc hl

			djnz DRAW_SPRITE1

			Ld a,e
			Add #55;#32-9; прибавл¤ем к DE 55 (64 (ширина буфера) минус ширина спрайта)
			;add 73 ; 64 (ширина буфера) плюс ширина спрайта) - для зеркалки
			Ld e,a;(low byte)
			Adc d
			Sub e
			Ld d,a;(high byte)

			DEC c
			JR NZ, DRAW_SPRITE2
			ret

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

В данном случае рисует в буфер начиная с адреса 62976

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

Ну и да, буфер шире реального экрана (64 пиксела), дабы не вычислять границы экрана при рисовании

[Bedazzle]

У меня процедура заточена под фиксированный размер спрайтов.
Если желаю указать другой, то мне надо менять значения счётчиков (регистры BC), а также итерацию для перехода на следующую строку

Перед вызовом процедуры в зависимости от ширины спрайта просто модифицируй эти значения в коде.

ld a, 10 ; height
ld (DRAW_SPRITE2-1), a
ld a, 9 ; width
ld (DRAW_SPRITE1-1), a
...
call draw_sprite

[Lethargeek]

Перед вызовом процедуры в зависимости от ширины спрайта просто модифицируй эти значения в коде.

зачем, если

Допустим, размеры спрайта будут в двух первых числах DEFB, а далее уже сами данные.

тогда проще передать в hl адрес спрайта и в коде сразу прочитать с инкрементом из (hl)
можно даже смещение для следующей строки хранить рядом с байтами размера

[Bedazzle]

зачем, если

тогда проще передать в hl адрес спрайта и в коде сразу прочитать с инкрементом из (hl)

Не понял. В hl же адрес экрана должен быть? Зачем оттуда читать?

можно даже смещение для следующей строки хранить рядом с байтами размера

Ну, это зависит можно ли раздувать память под спрайты. И оно будет медленнее, чем модифицирующийся хардкод.