Тоже съезжает вверх. :v2_dizzy_tired2:
- - - Добавлено - - -
Ибо нужно ещё ето.
- - - Добавлено - - -
https://media1.giphy.com/media/v1.Y2...wcUQ/giphy.gif
Вид для печати
Тоже съезжает вверх. :v2_dizzy_tired2:
- - - Добавлено - - -
Ибо нужно ещё ето.
- - - Добавлено - - -
https://media1.giphy.com/media/v1.Y2...wcUQ/giphy.gif
Ну, я предупредил, что с головы пишу :)
Вот это проверил:
Код:org $8000
entry:
ld a, 9
ld (22528),a
ld (22528+767),a
starter:
halt
ld hl, 22529-1
ld de, 22528-1
ld a, 24
scroll:
inc hl ; можно заменить на inc l
inc de
ex af, af'
ld a, (de)
DUP 31
ldi
EDUP
ld (de), a
ex af, af'
dec a
jp nz, scroll
jp starter
ret
jerri, удали EmuZWin.exe.manifest, тогда кнопки будут отображаться в винде 10 нормально.
Скорее ALKO
- - - Добавлено - - -
Ну разве что совсем чуточку, и освободим альт рег А:
Код:org $8000
entry:
ld a, 9
ld (22528),a
ld (22528+767),a
starter:
halt
ld hl, 22529
ld de, 22528
scroll:
ld a, (de)
DUP 31
ldi
EDUP
ld (de), a
inc l
inc de
ld a, $5B
cp d
jp nz, scroll
jp starter
ret
Bedazzle, спасибо, пашет.
Но я пока не уверен, как там ляжет условие в конце, где ld a, $5B.
У меня буфер 40х24, так что 960 на 256 делится с остатком, и в один байт не укладывается.
А прокручивать ты весь буфер будешь, или только видимую часть ? Насколько помню ты буфер вроде мутил тупо чтоб спрайты обрезать ))
- - - Добавлено - - -Код:; ...
ld de,Boofer
ld hl,Boofer+1
ld bc,24*31 ; 24*(размер прокручиваемой зоны-1: т.е. количество LDI ),
; т.е. 24*31 для видимой части, 24*39 для всего буфера
loop
ld a,(de)
DUP 31 ; если прокручивается только видимая часть или 'DUP 39' , если весь буфер
ldi
EDUP
ld (de),a
DUP 9 ; если крутится видимая часть или убрать обёртку 'DUP/EDUP' вокруг инков, если весь буфер
inс hl
inc de
EDUP
ld a,b
or c
jp nz,loop
; ...
Пожалуй если прокручивается видимая часть буфера, то лучше пожалуй заменить
на :Код:DUP 9
inс hl ; 6
inc de ; 6
EDUP ; (6+6)*9 = 108 тактов , 18 байт
- - - Добавлено - - -Код:push bc ; 11
ld bc,9 ; 10
add hl,bc ; 11
ex de,hl ; 4
add hl,bc ; 11
ex de,hl ; 4
pop bc ; 10 = 61 такт , 9 байт
;
Да так, как флаг p/v кроме ldi никакая команда здесь не меняет,
то можно
заменить всего лишь наКод:ld a,b
or c
jp nz,loop
Код:jp pe,loop
Да, весь. Чтоб слой плавно вылазил из-за экрана.
А уж итоговый результат обрезаю, и кидаю на реал-экран.
- - - Добавлено - - -
Ну как на той же сеге мд, реальный экран 320х224, но слои 512х512 (либо 1024х256, в зависимости от режима)
- - - Добавлено - - -
Попробовал код Bedazzle на полноценной пикче в буфере, там чёта несколько рядов пикселей рушится
Должно быть так равномерно
https://sun9-22.userapi.com/impg/a-g...540&type=album
Но тут в одном участке вот такой бугорок
https://sun9-79.userapi.com/impg/Iof...b21&type=album
- - - Добавлено - - -
Возможно, это я что-то у себя накосячил.
- - - Добавлено - - -
Ещё и микшировать слой прокрутки со спрайтами.
Можно канешн и без буфера, сразу на реал экран фигарить. Но это надо угадать с тактами, прерываниями. Я тут на элементарном спотыкаюсь. Куда уж мне до такой вышки.
А вот как бы его вправо теперь?Код:SCROLL_PLANE_L
ld hl, PLANE_A
ld de, PLANE_A-1
ld a, 24
scroll:
inc hl ; можно заменить на inc l
inc de
ex af, af'
ld a, (de)
DUP 39
ldi
EDUP
ld (de), a
ex af, af'
dec a
jp nz, scroll
;перенос результата в шырокий буфер
ld bc,960
ld de,MAIN_BUFF;
ld hl, PLANE_A; тулим слой
ldir
ret
В теории предполагаю, что
1.
ld hl, PLANE_A+(40*24)-1
ld de, PLANE_A+(40*24)
2.
DUP 39
ldd
EDUP
3.
dec hl
dec de
Но пока не проверял на практике.
Согласен, там hl уже переходила возможный инкремент h после выполнения последовательности ldi.
Но не в том дело. У меня складывается очучение что товарищ ALKO нас тонко троллит ;)
Иначе как обьяснить что выложенные процедуры он всегда переделывает в нерабочие, как например сейчас. При таком выборе адресов скрола не будет, будет заполнение :v2_dizzy_punk:
Ну вот, я же говорю троллит. У себя одно пишет, а сюда другое выкладывает :D
Адрес hl меньше de на 1. При выполнении ldi значение из (hl) заносится в (de), а затем когда hl и de увеличиваются на 1 , hl становится равным бывшему de и в новый (de) следующее ldi заносит опять то же самое значение.
А так как на анимашке совсем другое показываешь, значит там и адреса правильные стоят. ;)
Dart Alver, а хде тут у меня отсебятина?
Ну, буфер у меня шыре реального экрана (40х24).
960 байт маслает чётенько.
https://i.giphy.com/media/v1.Y2lkPTc...3LrT/giphy.gif
- - - Добавлено - - -
Это да...
Это я уже да.. Начал шаманить в правую сторону..
- - - Добавлено - - -
Внёс правки.
https://zx-pk.ru/threads/32014-tema-...=1#post1206632
- - - Добавлено - - -
Получилось настолько тонко, что я и сам самозатроллился...
- - - Добавлено - - -
И да. Проверено на практике. Всё ок пашыт в другую сторону.
какой посоветуете ассемблер z80 для командной строки, чтобы умел генерировать intel hex на выходе?
sdasz80 из SDCC
Если некритично, что в литералах обязательна решётка # , а хексы пишутся как в Си через 0x
Вложение 81570Код:ld hl, #_Klad_idx
ld a, (hl)
add a, #0x0f
а как в нем директивы использовать?
Код:; test.asm
org #0x4000
call #0xcafe
;ld (iy+0),l
;djnz $
ret
Есть ли еще какие-то варианты, которые классический синтаксис Z80 асма понимают?Код:$ sdasz80 -o build/test.rel test.asm
test.asm:2: Error: <q> missing or improper operators, terminators, or delimiters
removing build/test.rel
sjasm наверно. Но мне нравится м80.) А потом, что мешает перегнать бин в хекс?
https://shop-pdp.net/ashtml/asxs02.htm#org
.org не пробовал. Там назначением адресов по идее линкер занимается.
Без понятия.
Дело же не хексе, как я понимаю. Основные фишки в самом трансляторе. Умеет ли IRP/IRPC, REPT, ну и макросредства должны быть на уровне. По крайней мере, это важно для удобства. Опять таки, если писать чуток и не изгаляться, то без разницы. Простых ассемблеров просто куча.)
В коде несколько блоков памяти в разных местах. В один bin файл такое не сохранишь.
Пока использую z80asm который в репозитории debian. Но он только в bin сохраняет и кучу файлов ненужных генерирует. Причем нельзя укзать в какую папку их писать, приходится делать вот так:
Хотя можно было одним файлом это все сразу в hex скомпилить и смещения для сборки hex файла не нужно было бы отдельно задавать - сразу в исходнике из org брать.Код:#!/bin/bash
set -e # Exit on any error
cd "$(dirname "${BASH_SOURCE[0]:-$0}")"
mkdir -p ./build && cd build
z80asm -o jetpac-hack1.bin ../jetpac-hack.asm
z80asm -o jetpac-hack2.bin ../jetpac-hack2.asm
z80asm -o jetpac-hack3.bin ../jetpac-hack3.asm
srec_cat jetpac-hack1.bin -binary -offset 0x7345 \
jetpac-hack2.bin -binary -offset 0x737d \
jetpac-hack3.bin -binary -offset 0x739c \
-o jetpac-hack.hex -Intel
rm jetpac-hack?.bin
С другой стороны undoc инструкции вроде ld (ix+offset),l поддерживает. sdasz80 не понимает, да и с синтаксисом у sdasz80 чтото совсем плохо.
Допустим первый исходник генерирует 50-100 блоков с разными адресами. Повреждать память между этими блоками нельзя.
Если сохранять это всё в 50-100 бинарников, как предлагаете собирать все это в хекс? Ведь для каждого бинарника нужно распарсить из результатов компиляиции начальный адрес.
При компиляции в hex на выходе просто имеем hex файл который содержи все эти блоки с нужными адресами. Никаких дополнительных телодвижений не нужно.
ZXMAK, попробуйте zmac.) Он может hex на выходе. И у него много разных фишек.
В данном случае я компилировал патч для клавиатуры к jetpac. Пишется org и команды который нужно скомпилить. Далее следующий org и следующие команды. Между концом команд предыдущего org и нового в памяти лежит код, поэтому писать туда ничего нельзя.
Кстати оказалось, jetpac вполне играбельный при использовании нормальных кнопок управления QAOP SPACE. Помню с дефолтными кнопками у меня не хватало терпения даже одну ракету собрать :)
В аттачменте патч в hex файле. Использовать так - ставим точку останова на #6000, загружаем jetpack из tap, когда окажемся на точке останова загружаем hex патч. Можно играть. В аттачменте также уже пропатченый szx снэпшот.
похоже то, что нужно - понимает нормальный синтаксис Z80 асма :)
Правда есть много разных модификаций zmac.
Удивительно, насколько старый и мощный ассемблер и так малоизвестен, был написан еще в 1978 году Bruce Norskog...
Насколько понимаю последняя версия оригинала подчищенная и доработанная тут: http://www.tim-mann.org/trs80/zmac13.zip
Наиболее близкий к этой версии более современный вариант, в нём только мелкие фиксы: https://gitlab.com/jengun/zmac
Мне эта версия понравилась, на ARM64 исполняемый файл всего 80 кБ, недокументированные инструкции понимает,правда hex не умеет писать, но думаю это не проблема поправить.:)
Update: чтото я недосмотрел, оказывается в оригинале есть вывод в hex, опция -h.
Есть еще вот такой вариант: https://github.com/gp48k/zmac
В нем есть много других доработок, но мне она не нравится тем, что в неё напихали кучу всякого мусора вроде записи WAV файлов и т.п.
Я считаю таким фичам не место в ассемблере, WAV и снэпшоты можно сделать отдельными программами.
Да, я именно этот имел ввиду, как наиболее свежий. Извиняюсь что сразу не дал ссылку: http://48k.ca/zmac.html).
а поддерживает ли zmac макросы с переменным числом аргументов?
например:
можно это сделать одним макросом print_code, который при наличии v2 будет делать дополнительный вызов rst #10?Код:print_code1 macro vcode,v1
ld a,vcode
rst #10
ld a,v1
rst #10
endm
print_code2 macro vcode,v1,v2
ld a,vcode
rst #10
ld a,v1
rst #10
ld a,v2
rst #10
endm
M80 это можно делать через ifb/ifnb. Тут этого нет. Можно попробовать через if (!)nul &v2, но не уверен. Как то по каличному.)
Наверно if !nul &v2. Это я так написал "с ! или без". Или if nul &v2 exitm.
Не поленился, проверил. Работает. Только у меня rst $10 или 10h.