Нужна скоростная операция:
В HL содержится число (0..447) кратное 3.
Требуется быстро разделить HL на 3 и результат умножить на 4.
HL=(HL/3)*4
Вид для печати
Нужна скоростная операция:
В HL содержится число (0..447) кратное 3.
Требуется быстро разделить HL на 3 и результат умножить на 4.
HL=(HL/3)*4
hl=hl*155h
так?
ага
12f*155=193 9b
447/3*4=254h
447*155h=253 6b
Ситуация какая... буфер для восстановление байта на экране занимает 3 байта буфера на байт экрана (word:adr, byte:data)
А процедура восстановления жрёт 4 байта на восстановление байта экрана... Нужно расчитать точку входа в процедуру по размеру буфера...
В HL у нас размер буфера.
округлять наверное :)
считает то правильно
Подумаю ещё, может чего оптимизирую.
Пример на асме есть? мне циклы нельзя городить в процедуре
а может будет достаточно ld l,h:ld h,a:inc hl
Не совсем понял, всё таки...
---------- Post added at 03:24 ---------- Previous post was at 02:45 ----------
Может задачу иначе поставить?
Вот процедура восстановления циклом:
Поскольку буфер заполняется командой PUSH, то конец буфера фикированный, а начало в HL.
C = конец буфера.
Тормозно, но работает. 4 байта не могу в буфере хранить, нет места.
Стеком выгодно делать, если цикл развернуть... Иначе видимо нет.Код:LD SP,HL ; HL = начало текущего буфера
RES_LN POP DE
DEC SP
POP AF
LD (DE),A
LD HL,#0000
ADD HL,SP
LD A,H
CP C
JP NZ,RES_LN
А чтобы развернуть, нужно расчитать точку входа :)
Код:RES_LN LD E,(HL)
INC HL
LD D,(HL)
INC HL
LD A,(HL)
INC HL
LD (DE),A
LD A,H
CP C
JP NZ,RES_LN
может, посмотреть в сторону последовательности pop de:ldi
байты фона отдельно, адреса отдельно
?
drbars, нее
я предлагаю умножать на #155
а потом hl уже чуть корректировать.
И как ты его узнаешь? На выходе из процедуры линии у нас есть указатель стека на начало буфера и всё. Ещё мы знаем конец буфера. (Конец - начало)/3 = кол-во элементов. Зная кол-во элементов *4 можно расчитать точку ухода в мегакод восстановления.
INC L тоже рисковано делать, буфер 448 байт. Если процедура "вылетит" то запоганит память. Это подходит для инкремента кратного 2.
drbars, я к тому что у тебя максимальный размер линии 149 точек по вертикали
Игровое пространство 144 точки по вертикали.. буфер позволяет 149.
---------- Post added at 22:43 ---------- Previous post was at 22:29 ----------
Не получится наметить, я уже максимально оптимизировал. Старший адрес как раз и проверяет, закончился ли буфер.
85*3=255. Это значит что 2-ой INC HL попадает на границу. Если мы буфер на байт сдвинем, как из него выходить? L у нас может быть одинаковым 2 раза. Тут уже ничего не сделаешь.
Не забывай ещё, что буфер строится от конца к началу, а востанавливается от начала к концу.
ld sp,#7fff
выйдет только по этому адресу
#7eff на проверку не попадает, только #00 будет сравниваться с A (предыдущий же был #FD)
sp=#7fffЦитата:
ok, при размере буфера менее 2 секторов, граница переходится 1 раз, ежели наметить переход на команду ldi, тогда и оба inc hl получится заменить на inc l?
... видимо, с заменой cp h на cp l ...
...
заполнили буфер
...
a=#ff
...
ldi
cp l
jp nz,RES_LN
L при сравнении с A будет #ff только в конце.
Да, не говори, красиво вообще :)
p.s. Плюс буфер можно таскать, не обязательно именно у границы сектора заканчивать
Что-то такое придумалось, наверное можно сильнее оптимизировать:
Код:; IN:HL=VALUE
;OUT:HL=HL/3*4
DIVHL3MUL4
EX DE,HL
XOR A
LD L,D
LD H,A
ADD HL,DE
ADD HL,HL
ADD HL,HL
ADD HL,DE
ADD HL,HL
ADD HL,HL
ADD HL,DE
ADD HL,HL
ADD HL,HL
ADD HL,DE
ADD HL,HL
RLA
ADD HL,HL
RLA
ADD HL,DE
RLC L
LD L,H
LD H,A
RET NC
INC HL
RET
Robus, Ну ты просто мой алгоритм материализовал :)
а все вхождения проверил?
у тебя ошибка
LD L,D
должно быть
LD L,A
Всем спасибо) Я уже понял, что расчитывать точку вхождения в мегакод в моём случае — особое извращение. Поэтому оставил цикл. Быстрая память экстремально заканчивается, начинаю извращаться уже)