Просмотр полной версии : Программирование
parallelno
30.06.2022, 09:08
Привет!
Полезные ссылки по программированию под Вектор 06ц.
Документация
Описание архитекстуры и общие сведения:
http://emuverse.ru/wiki/%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80-06%D0%A6
Секреты "Вектора"-1992г. Лебедев А.
https://raw.githubusercontent.com/wiki/svofski/vector06cc/VectorSecrets_by_Lebedev.md
ТЕХНИЧЕСКОЕ ОПИСАНИЕ ПК "ВЕКТОР-06Ц"
https://github.com/svofski/vector06cc/wiki/Technical_Description
Порты (доступтные устройства довключенные к портам зависят от конктерного экземпляра, но можно смело расчитывать на 2 квазидиска, дисковод, музыкальный сопроцессор)
https://zx-pk.ru/threads/34359-vektor-06ts-porty-vvoda-vyvoda-i-zhelezo-na-nikh-sidyashchee.html#post1152257
https://code.google.com/archive/p/vector06cc/wikis/Technical_Description.wiki
Справка по командам i8080 (теже что у Вектора06ц)
https://pmd85.borik.net/instrset/instuction-set.html
Тайминги команд процессора КР580ВМ80
MOV 8
MVI R,_ 8
MVI M,_ 12
LDAX / STAX 8
LDA / STA 16
LXI 12
LHLD / SHLD 20
SHLD 20
POP 12
PUSH 16
SPHL 8
XCHG 4
XTHL 24
CMC / STC / CMA / DAA 4
RRC / RLC / RAL / RAR 4
INR/INX/DCR/DCX R 8
INR/DCR MOV 12
ADD / SUB / ADC / SBB / ANA / ORA / XRA / CMP R 4
ADD / SUB / ADC / SBB / ANA / ORA / XRA / CMP M 8
ADI / SUI / ACI / SBI / ANI / ORI / XRI / CPI R 8
DAD 12
NOP 4
EI / DI 4
HLT 8
IN / OUT 12
PCHL 8
JMP / J* 12
CALL 24
C* /Y 24
C* /N 16
RET 12
R* /Y 16
R* /N 8
RST 16
http://emuverse.ru/wiki/%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80-06%D0%A6/Instruction_Timings
https://github.com/svofski/vector06cc/wiki/Instruction_Timings
Среды разработки
Настройка среды программирования и запуск примера
TASM ассемблер + Visual Studio Code среда разработки, Emu80 эмулятор
Retro Assembler + Visual Studiop Code, v06x эмулятор
https://github.com/parallelno/Vector06c
https://enginedesigns.net/download/retroassembler.html#Assembler
Pretty Assembler.
Online редактор и примеры
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1068781&viewfull=1#post1068781
Программы, игры и сканы старых журналов
Каталог програм и игр
http://sensi.org/scalar/categories/all/
Категория sourcecode
http://sensi.org/scalar/categories/37/
Дополнительная документация
http://sensi.org/scalar/categories/41/
Копия сайта sensi.org
http://tenroom.ru/scalar/recent20/index.html
Советы по программированию и примеры
Современный биперный движок phaser1
https://zx-pk.ru/threads/28132-bipernaya-muzyka-na-vektore-06ts.html?p=1130092&viewfull=1#post1130092
Про палитры
Самая быстрая установка палитры по версии ivagor
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1136880&viewfull=1#post1136880
Самая быстрая установка палитры по версии Improver
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere/page22.html#post1136855
Установка палитры читаемой с квазидиска при разрешенных прерываниях
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1160854&viewfull=1#post1160854
Совет по установке палитр
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere/page22.html#post1119119
Про мультиколор
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page4.html#post1069994
квазидиск
Квазидиск имеет объем 256kB который разбит на 4 банка по 64kB.
включение:
mvi a, CODE
out $10
отключение:
xra a
out $10
CODE это управляющий байт с битами E8ASXXYY.
bitS=1 включить квазидиск как стек. Операции со стеком будут использовать банк xx квазидиска. bitS=0 отключить.
bitsXX, номер банка для доступа через стек.
bitA=1 включить квазидиск как ОЗУ. Операции с памятью (не операции со стеком) будут использовать область $A000-$BFFF банка yy квазидиска. bitA=0 отключить.
bit8=1 включить квазидиск как ОЗУ. Операции с памятью (не операции со стеком) будут использовать область $8000-$9FFF банка yy квазидиска. bit8=0 отключить.
bitE=1 включить квазидиск как ОЗУ. Операции с памятью (не операции со стеком) будут использовать область $E000-$FFFF банка yy квазидиска. bitE=0 отключить.
bitsYY - номер банка для использования квазидиска как ОЗУ.
Управляющие биты bit8, bitE работают только с квазидиском с модификацией А.Баркаря.
https://www.radioman-portal.ru/magazin/radiolubitel/1995/11.php
Интересная особенность. Если квазидиск включить как ОЗУ, и выключить как как стек, то он будет включен как ОЗУ и как стек на банк указаный битами для ОЗУ для адресов которые замаплены как ОЗУ. То есть если адреса стека совпадают с адресами для ОЗУ то стековые операции будут обращаться к квазидиску несмотря на то что квазидиск выключен как стек.
Прерывания
Перед возвратом из
подпрограммы необходимо обратно восстановить дисплейный режим и значения
портов, определяющих номер верхней строки, цвет рамки, режим 256*256 или
512*256 и т.п. Также необходимо разрешить прерывание, т.к. аппаратное
прерывание сбрасывает программный триггер.
Прерывания происходят 50 раз в секунду. Между прерываниями 59904 такта процессора. В течение этого времени растеризатор линию за линией отрисовывает фрейм на экране монитора начиная с левого верхнего угла.
Фрейм включает в себя видимую область (данные из видеопамяти) окруженную областью бордюра. Верхние 22 линии бордюра включает в себя область сихнхронихации.
Всего фрейм содержит 312 строк. В каждой строке первые 64 пикселя это бордюр. Затем отображаются 256 пикселей из видео озу, и завершается строка 64 пикселями бордюра. Для режима 512 значения удроенные. Таким образом 40 строк * 192 = 7680 такта до начала рисования первой видимой строки.
// 312 scanlines:
// vsync: 22 lines
// vblank (top): 18 lines
// vertical resolution: 256 lines
// vblank (bottom): 16 lines
// 384 pxls (192 cpu cycles / 768 clock cycles of 12 Mhz) per scanline
// hblank (left): 64 pxls
// horizontal resolution : 256 pxls
// hblank (right): 64 pxls
На бордюре удобно оборажать длительность процедуры. Это работает только если основной цикл приложения уладывается в длительность фрейма.
https://zx-pk.ru/threads/34480-programmirovanie.html?p=1159402&viewfull=1#post1159402
Вывод спрайта
от jerri
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page29.html#post1075371
от KTSerg
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page27.html#post1075256
от ivagor
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page28.html#post1075277
Музыка и звуковые эффекты
плеер gigachad16 нужен буфер чуть меньше 4К (14 буферов распаковщика + 14 стеков). perf 1,6% - 8%
https://zx-pk.ru/threads/29679-szhatie-dannykh.html?p=1159612&viewfull=1#post1159612
https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/f41ec5939d75b69bd7a2933f81489df1/raw/a04c31d08124503cfa6799c45f7dd86658a2a10d/gigachad16.asm
плеер из "Полета навигатора" STC формат perf 11,9% - 16%
https://zx-pk.ru/threads/34480-programmirovanie.html?p=1159770&viewfull=1#post1159770
https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/19aeb8641cbcce4fa56fa79f3400fca4/raw/309a487e1dd20ae1f782706a54e307a06441792f/p4kplayer.asm[.url]
плеер от DemonId7 STC формат
https://zx-pk.ru/threads/8378-pk8000-soft-staryj-i-novyj.html?p=938887&viewfull=1#post938887
плеер от DemonId7 STC формат оптимизированный svofski. perf в среднем ~ 9,6%, периодически проседает до 14,4%, а один раз поймал на 18,6%."
https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/19aeb8641cbcce4fa56fa79f3400fca4/raw/9932eef3415cabe3caf7b85655450555ec4dcb01/stcplay-demonid7.asm
плеер от Mick STC формат
https://zx-pk.ru/threads/8374-pk8000-podklyuchenie-k-kompyuteru-ay-(ay-3-8910).html?p=150239&viewfull=1#post150239
конвертирование музыки для плеера gigachad16
1. скачать музыку в например от сюда
https://zxart.ee/spa/music/top-100/
2. скачать
Ay Emulator v2.9
https://vtrd.in/pcutilz/AYEM2932.zip
3. открыть в ней плейлист по кнеопке PL
4. сохранить в пормате AY6
5. прогнатать через скрипт
https://github.com/svofski/v06c-arzak/blob/master/tools/ym6break.py
описание фомата AY6
https://documentation.help/AY-3-8910.12-ZX-Spectrum/ay_e04vt.htm
Описание музыкального сопроцессора AY-3-8910 "R-SOUND"
http://tenroom.ru/scalar/ware/766/index.html
Описание трех-канального таймера встроенного в Вектор
Начинается раздел со строки: "Теперь о программировании звука:"
https://raw.githubusercontent.com/wiki/svofski/vector06cc/VectorSecrets_by_Lebedev.md
база музыки для AY-3-8910 sound chip
https://zxart.ee/spa/music/top-100/
Мелодия из игры Arkanoid на Векторе-06ц без AY-3-8910 sound chip
; Тонгенератор: Иван Городецкий, Уфа
; Мелодия: Вячеслав Славинский, С.-Петербург
; 2019
https://svofski.github.io/pretty-8080-assembler/?arkmus
Редактор звуковых эффектов AY Sound FX Editor + примеры взуковых эффектов для AY-3-8910 sound chip
https://github.com/Threetwosevensixseven/ayfxedit-improved
web версия с чуть меньшим функционалосм
[url]https://github.com/Threetwosevensixseven/ayfxedit-improved
Псевдо случайное число
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page33.html#post1076189
PrettyAsm в Tasm
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere/page20.html#post1068786
Отладка
Отладка в VVector эмуляторе
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page8.html#post1072925
Отладка в Emu, Emu80 эмуляторе
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB/page25.html#post1075182
TASM
Передача параметром в TASM через макросы
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB.html?p=1157180&viewfull=1#post1157180
Линковка файлов данных к коду)
https://zx-pk.ru/threads/31954-pishu-shedevr-dlya-%C2%ABvektora-06ts%C2%BB.html?p=1157162&viewfull=1#post1157162
как приложить файл к сообщению
Расширенный режим -> Управление вложениями
Справка по командам i8080 (теже что у Вектора06ц)
Альтернативный вариант (https://pastraiser.com/cpu/i8080/i8080_opcodes.html)
И для 8085 (https://pastraiser.com/cpu/i8085/i8085_opcodes.html) (для ПК-6128Ц)
На emuverse есть также Техническое описание двух версий, инфа про джойстики, тайминги: http://emuverse.ru/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D 1%8F:%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80-06%D0%A6
Для тех кто предпочитает нотацию Z80, могу показать как подружить TASM и pasmo в одном проекте, например: https://github.com/nzeemin/vector06c-asteroids
В параметрах pasmo нужно указывать опцию --w8080, чтобы команды недоступные для ВМ80А давали варнинги.
Стоит упомянуть "прекрасный ассемблер" от svofski - для тех кому нравятся онлайн-редакторы - http://sensi.org/~svo/i8080/
Стоит упомянуть "прекрасный ассемблер" от svofski - для тех кому нравятся онлайн-редакторы - http://sensi.org/~svo/i8080/
Это старый ассемблер, он уже не такой прекрасный. Лучше пользоваться вот этой ссылкой:
https://svofski.github.io/pretty-8080-assembler/
parallelno
30.06.2022, 20:30
Спасибо за ссылки!
Дополнил первый пост и залил на гитхад примеры.
Эмуляторы:
b2m emu Дмитрия Целикова
Emu80 от Pyk - https://emu80.org/
v06x от svofski - https://github.com/svofski/vector06sdl
Virtual Vector (VV)
- - - Updated - - -
Алгоритмы сжатия - вообще, тема https://zx-pk.ru/threads/29679-szhatie-dannykh.html
В частности - можно использовать LZSA, упаковщик тут: https://github.com/emmanuel-marty/lzsa, распаковщики тут: https://github.com/ivagorRetrocomp/DeLZSA/tree/main/8080
Кстати о примерах. В Прекрасме, если кликнуть на рыбу, можно выбрать заготовки примеров рисования мандрилла, линии, окружности, дуги, эллипса и музона из Арканоида.
Лучше пользоваться вот этой ссылкой:
https://svofski.github.io/pretty-8080-assembler/
Смотрю, у тебя там мой PR уже почти 3 года висит. Прими плиз или сам поправь, если будет будет время, а то слегка битые wav-файлы формируются и с обрезанными последними сэмплами (хотя тем не менее много где успешно грузятся). Не помню уже подробности, но при необходимости постараюсь вспомнить, в чем там проблема...
Pyk, извини, я не со зла. Просто перенести фокус внимания в старый код бывает тяжело. Спасибо, что напомнил.
parallelno
01.07.2022, 19:37
Кстати о примерах. В Прекрасме, если кликнуть на рыбу, можно выбрать заготовки примеров рисования мандрилла, линии, окружности, дуги, эллипса и музона из Арканоида.
A есть консольная версия прекрасма? И где почитать его документацию? Поделись пожалуйста.
Ну она так, условно есть:
https://github.com/svofski/prettyasm/
Я не советую, потому что мне это просто интересно было повозиться, а как продукт он может не особо-то прочный. У онлайнового фича, что можно быстро набросать тестик или какую-то идею и обкатать ее перед тем, как заводить проект посерьезней. Но если уж есть проект и все равно что-то запускается в консоли, tasm ничем не плох.
Документации нет. Там нечего документировать.
parallelno
02.07.2022, 01:43
svofski,
Если навести курсор на метку в прекрасном ассемблере, то появляется хинт с адресами везде где она используетя. Было бы супер класно видель там еще и количество тактов с этой метки до всех последующих JMP, J*, RET, R*. Если сможешь, добавь пожалуйста, будет очень полезно.
- - - Добавлено - - -
Не не так, а то слишком много мусора будет. :)
Нужно показывать такты для заселекченного кусочка. И кстати есть дополнительный бенефит, будет что указать в мануале. :)
Идея прикольная, но у меня вон три года PR от Pyk-а висит, а тут такое. С тактами еще такая тонкость, что они машинно-зависимые. На Векторе количество тактов в каждом машинном цикле округляется вверх до кратного четырем (mov r,r = 8 тактов). На других машинах не так. Векторовские такты вызывают досаду своей тормознутостью, но зато их на самом деле очень легко запомнить.
На такты при отладке мне нравится смотреть в отладчике VV.
parallelno
02.07.2022, 03:00
ok.
Я пытаюсь поспользоваться макросами в TASM.
Например вот это кусочек кода положить в макрос:
LHLD SPRITE_COUNTER_ADDR
_loop:
LXI B, spriteData01
LXI D, SPRITE_SCR_ADDR+23
PUSH H
CALL DrawSprite_ivagor
POP H
INX H
LDA STOP_TIMER_FLAG_ADDR
ORA A
JNZ _loop
SHLD SPRITE_COUNTER_ADDR
LXI D, RES_SCR_ADDR_4
call DrawResult
и заменить конкретные параметры на макрос параметры - DrawSprite_ivagor -> DrawSprite, SPRITE_SCR_ADDR+23 -> spriteScrAddr, RES_SCR_ADDR_4 -> resScrAddr
никак не могу побороть. Может быть кто-то сможет привести пример такого макроса? Заранее спасибо!
Так а если допустим написать в тексте CALL DrawSprite, а при вызове tasm указывать -DDrawSprite=DrawSprite_ivagor, не получается?
parallelno
02.07.2022, 05:08
Забыл указать что я просто хочу сделать макро функцию чтобы не дублировать код много раз.
что то типа как доках TASM
#DEFINE ADD(xx,yy) clc
#DEFCONT \ lda xx
#DEFCONT \ adc yy
#DEFCONT \ sta xx
но немного посложнее
Если честно, то у меня даже стандартный пример не заработал. Не хочет компилиться. :(
Если хочется удобной компоновки с бинарниками, продвинутых макросов и дополнительных директив препроцессора то можно расширить область поиска трансляторов ассемблера:
1. CP/Mные трансляторы. Для кросскомпиляции понадобится еще эмулятор cp/m типа такого (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=970016&viewfull=1#post970016)
2. Вот такой вариант (https://zx-pk.ru/threads/26805-paket-dlya-i8080-winasm-studio-fasm-g.html) (правда для 8080 я его не пробовал, но для x86 fasmом пользуюсь)
3. Перейти на сторону синтаксиса z80 и тогда станут доступны продвинутые асмы для этого проца.
Подобные вопросы уже возникали в теме (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html), стоит там посмотреть.
Если ты исполнен отваги пользоваться препроцессором, в принципе обычный сишный препроцессор можно использовать с чем угодно, даже с TASM, потому что TASM поддерживает разделители в виде бекслеша. Попробовал по быстрому, вот как это выглядит.
$ cat tets.asm
#define ADD(xx,yy) clc \\
lda xx \\
adc yy \\
sta xx
ADD(foo,bar)
$ cpp -P tets.asm
clc \ lda foo \ adc bar \ sta foo
Привет всем...
А есть примеры программ на ассемблере?
Процедуры или вся программа?
Про комп - Вектор-06Ц...
Комп был проблемный...
Программ на него у нас в городе - даже купить было негде...
Книг по программированию, конкретно под Вектор, не было...
У меня с компом шло 3 книжки -
Монитор, Бейсик и книжка со схемой...
Пробовал что то написать на Бейсике - даже и получалось...
Что то простое...
Программы наши - писать не умели...
Даже сюжета особого в играх не было...
???
Кишинев - тупо готовое переделывал...
Что то японское по-моему...
От Taito, Namco и тд...
Наши клоны - обычно писали...
Клон игры Йети, Клада и подобных...
Штук 20 - 30 наберется...
А есть примеры программ на ассемблере?
Процедуры или вся программа?
В заголовке этой темы было - Категория sourcecode http://sensi.org/scalar/categories/37/
Также свои могу упомянуть -
https://github.com/nzeemin/vector06c-desolate
https://github.com/nzeemin/vector06c-asteroids
https://github.com/nzeemin/vector06c-dangerick
Рива Рейд от svofski - https://github.com/svofski/incursiondelrio
parallelno
02.07.2022, 23:36
ivagor
Если хочется удобной компоновки с бинарниками, продвинутых макросов и дополнительных директив препроцессора то можно расширить область поиска трансляторов ассемблера:
1. CP/Mные трансляторы. Для кросскомпиляции понадобится еще эмулятор cp/m типа такого
2. Вот такой вариант (правда для 8080 я его не пробовал, но для x86 fasmом пользуюсь)
3. Перейти на сторону синтаксиса z80 и тогда станут доступны продвинутые асмы для этого проца.
Подобные вопросы уже возникали в теме, стоит там посмотреть.
Спасибо. Пока не готов. Ещу не доконца освежил мнемонику 8080, поэтому пока не. Но все равно спасибо, может когда нибудь дойдут руки
svofski
Если ты исполнен отваги пользоваться препроцессором, в принципе обычный сишный препроцессор можно использовать с чем угодно, даже с TASM, потому что TASM поддерживает разделители в виде бекслеша. Попробовал по быстрому, вот как это выглядит.
Код:
$ cat tets.asm
#define ADD(xx,yy) clc \\
lda xx \\
adc yy \\
sta xx
ADD(foo,bar)
$ cpp -P tets.asm
clc \ lda foo \ adc bar \ sta foo
О! Вот это купер круто. Спасибо!
- - - Добавлено - - -
Заметил неприятную особенность TASM.
Максимальная длинна метки 32 (с учетом символа окончания строки). Но если используется директива .MODULE то максимальная длинна всех локальных меток уменьшается на длинную moduleLabel
т.е код ниже не скомпилируется изза того что максимальная длинна локальных меток для этого модуля будет 32-22=10, а длинна _restoreSP = 11
.MODULE DrawSprite_Jerri_orig
DrawSprite_Jerri_orig:
MVI a,12
;
LXI h,0
DAD sp
SHLD _restoreSP+1
Спасибо. Пока не готов. Ещу не доконца освежил мнемонику 8080, поэтому пока не. Но все равно спасибо, может когда нибудь дойдут руки
О! Вот это купер круто. Спасибо!
- - - Добавлено - - -
Заметил неприятную особенность TASM.
Максимальная длинна метки 32 (с учетом символа окончания строки). Но если используется директива .MODULE то максимальная длинна всех локальных меток уменьшается на длинную moduleLabel
т.е код ниже не скомпилируется изза того что максимальная длинна локальных меток для этого модуля будет 32-22=10, а длинна _restoreSP = 11
.MODULE DrawSprite_Jerri_orig
DrawSprite_Jerri_orig:
MVI a,12
;
LXI h,0
DAD sp
SHLD _restoreSP+1
Попробуйте ассемблер SJAsm
он умеет i8080
parallelno
03.07.2022, 21:11
Спасибо. Jerri. вы предпочитаете на вы общаться?
Кстати Serg скидывал ссылки на SJAsm. Если вы следите за его развитием, насколько глючный он по вашему ощущению?
https://zx-pk.ru/threads/447-sjasmplus-z80-kross-assembler.html?p=903878&viewfull=1#post903878
https://zx-pk.ru/threads/447-sjasmplus-z80-kross-assembler.html?p=904360&viewfull=1#post904360
Спасибо. Jerri. вы предпочитаете на вы общаться?
Кстати Serg скидывал ссылки на SJAsm. Если вы следите за его развитием, насколько глючный он по вашему ощущению?
https://zx-pk.ru/threads/447-sjasmplus-z80-kross-assembler.html?p=903878&viewfull=1#post903878
https://zx-pk.ru/threads/447-sjasmplus-z80-kross-assembler.html?p=904360&viewfull=1#post904360
а нее. это не переключился после работы. так чего по sjasmу?
последние версии такто причесали.
parallelno
06.07.2022, 12:10
Решил попробовать retro assembler. Из интересного по сравнению с Tasm, макросы по прокаченее, инклуды бинарей. Подсветка синтаксиса команд хоть и не всех. Из минусов. Не очень удобная работа с локальными метками. Изредка не отлавливает ошибки и компилит. Местами необычный синтаксис. Например метка текущего адреса *, а не $.
Например метка текущего адреса *, а не $.
Может быть точка еще работает?
parallelno
06.07.2022, 12:34
Только если недокументированно. Доки говорят только про *.
Current Memory Address
Another kind of label that's worth mentioning is the "*" (asterisk) character.
"*" gets replaced by the current memory address, like $0813 during expression evaluation.
Please note that the "*" character is also used in multiplications, so the assembler tries to determine the context where the "*" character is used in, and acts accordingly.
Кстати все забываю сообщить что в мобильном хроме не работает онлайн эмулятор на сайте картотеки
Кстати все забываю сообщить что в мобильном хроме не работает онлайн эмулятор на сайте картотеки
Истек сертификат на www.sensi.org, увы, пока ничего не могу с этим сделать. На десктопе в ФФ можно добавить исключение.
parallelno
08.07.2022, 12:35
Есть ли хорошие упаковщики картинок с возможностью вывода данных на экран без большого буфера?
- - - Добавлено - - -
Это нужно для вывода больших картинок аля заставки.
Так как картинка будет всегда одном месте экрана, первое что пришло в голову это хранить в данных картинки адрес экрана для каждой линии и кодировать все чанками аля количество повторов байта и сам байт.
кодировать все чанками аля количество повторов байта и сам байт
То есть RLE. Но если есть возможность подождать четверть секунды пока заставка распаковывается, может быть ее можно упаковать zx7mini ? Посмотри в треде про сжатие данных. И скорее всего уже есть что-то еще более компактное, ivagor никогда не сидит сложа руки.
Есть у меня старый потоковый распаковщик для zx7, у которого настраивается размер буфера (от 256 байт и больше). Но у него 2 недостатка - он очень медленный и это zx7, который резко потерял актуальность после появления zx0/zx1/zx2/zx5. Поэтому я его не выкладывал и теперь оптимизировать и выкладывать смысла нет. На базе zx0 можно сделать подобную штуку (при условии упаковки salvadorом), надо будет заняться, если кто-нибудь не сделает раньше.
zx7mini хорошая для своего времени штука, но там есть недостатки. Если устраивает небольшая степень сжатия, зато будет маленький буфер и сравнительно простой распаковщик (т.е. все чем был интересен zx7mini), то рекомендую взять здесь (https://github.com/antoniovillena/zx7b) saukav.exe, это обобщенный zx7, который опциями можно превратить в подобие zx7mini, только лучше.
parallelno
08.07.2022, 13:24
Время подождать есть. А zx7mini умеет писать в буфер экрана на нужные для картинки адреса?
Время подождать есть. А zx7mini умеет писать в буфер экрана на нужные для картинки адреса?
Думаю, что если картинка не расположена в памяти без разрывов, то есть например занимает только часть экрана, потребуются модификации. Но там распаковщик очень простой. Кстати, я его переводил на Си однажды (https://gitlab.com/svofski/zpu8080/-/blob/master/examples/startrek/dzx7mini.c). С другой стороны, если это заставка и можно потерпеть, что неиспользуемая часть экрана затирается нулями, может быть лучше так прямо и упаковать монолитом -- упакованные нули не займут очень много места, а проще -- это всегда проще.
parallelno
08.07.2022, 22:25
О, отлично! Когда напишу свой rle с разрывами сравню скорость распаковки и сжатие и напишу сравнение.
parallelno
25.07.2022, 00:54
Почему когда я опрашиваю клавиши после установки цвета бордюра и вертикального скролинга кодом ниже, цвет бордюра не устанавливается корректно?
LXI H,palette_sprites+15 ; ЗАПИСЬ ПАЛИТРЫ.
LXI D,$100F
INIT1: MOV A,E
OUT 02
MOV A,M
OUT $0c
OUT $0c
OUT $0c
OUT $0c
OUT $0c
DCX H
OUT $0c
DCR E
OUT $0c
DCR D
OUT $0c
JNZ INIT1
NWRPAL:
MVI A,$88
OUT 00
mvi a, 1 ; УСТАНОВКА ЦВЕТА БОРДЮРА.
ANI $0F
OUT 02
mvi a, 255 ; УСТАНОВКА ВЕРТИКАЛЬНОГО ПОЛОЖЕНИЯ ЭКРАНА.
OUT 03
MVI A,$8A ; ПРОВЕРКА НАЖАТИЯ НА ЛЮБУЮ КЛАВИШУ
OUT 00 ; МАТРИЦЫ КЛАВИАТУРЫ 8*8 (КРОМЕ УС,СС,РУС/ЛАТ).
XRA A
OUT 03
IN 2
STA anyKeyPressed
MVI A,$FE ; ПРОВЕРКА НАЖАТИЯ НА КЛАВИШИ ИГРОВОГО РЯДА.
OUT 03
IN 02
STA keyCode
но когда я опращиваю клавиши до бордюра и скроллинга, то все равботает как нужно?
LXI H,palette_sprites+15 ; ЗАПИСЬ ПАЛИТРЫ.
LXI D,$100F
INIT1: MOV A,E
OUT 02
MOV A,M
OUT $0c
OUT $0c
OUT $0c
OUT $0c
OUT $0c
DCX H
OUT $0c
DCR E
OUT $0c
DCR D
OUT $0c
JNZ INIT1
NWRPAL:
MVI A,$8A ; ПРОВЕРКА НАЖАТИЯ НА ЛЮБУЮ КЛАВИШУ
OUT 00 ; МАТРИЦЫ КЛАВИАТУРЫ 8*8 (КРОМЕ УС,СС,РУС/ЛАТ).
XRA A
OUT 03
IN 2
STA anyKeyPressed
MVI A,$FE ; ПРОВЕРКА НАЖАТИЯ НА КЛАВИШИ ИГРОВОГО РЯДА.
OUT 03
IN 02
STA keyCode
MVI A,$88
OUT 00
mvi a, 1 ; УСТАНОВКА ЦВЕТА БОРДЮРА.
ANI $0F
OUT 02
mvi a, 255 ; УСТАНОВКА ВЕРТИКАЛЬНОГО ПОЛОЖЕНИЯ ЭКРАНА.
OUT 03
проверял в Emu80 и VV
- - - Добавлено - - -
Вот тестовая программа для Pretty Asm
.project helv06c.rom
.tape v06c-rom
.org $100
StartInit:
DI
; dismount a quasi-disk
XRA A
out $10
; set entry points of a restart, and an interruption
MVI A, 0C3h
STA 0
STA 38h
LXI H, StartInit
SHLD 1
LXI H, Interruption1
SHLD 38h + 1
; stack init
LXI SP, 8000h
EI
HLT
; clear the screen
CALL CLEAR
Start: JMP Start
CLEAR: DI
PUSH H ; СОХРАНИТЬ ИСПОЛЬЗУЕМЫЕ РЕГИСТРЫ.
PUSH B
PUSH D
PUSH PSW
LXI H,0000H ; ПОДГОТОВИТЬ HL ДЛЯ ВЗЯТИЯ ЗНАЧЕНИЯ SP.
DAD SP ; ВЗЯТЬ ЗНАЧЕНИЕ SP ПУТЕМ СЛОЖЕНИЯ С HL.
LXI SP,0000H ; НАЧАТЬ СТИРАНИЕ С АДРЕСА 0FFFFH.
LXI D,0000H ; В DE - ЗНАЧЕНИЕ, КОТОРЫМ БУДЕТ СТЕРТ ЭКРАН.
LXI B,0800H ; В BC - СЧЕТЧИК.
CLEAR1: PUSH D ; НАЧАТЬ СТИРАТЬ ЭКРАН ПУТЕМ "ОПУСКАНИЯ" СТЕКА.
PUSH D ; ВЫПОЛНИТЬ 8 ОПЕРАЦИЙ "В ЛОБ" ДЛЯ СКОРОСТИ.
PUSH D
PUSH D
PUSH D
PUSH D
PUSH D
PUSH D
DCX B ; УМЕНЬШИТЬ СЧЕТЧИК И
MOV A,B ; ПРОВЕРИТЬ ЕГО.
ORA C ; КОНЕЦ СЧЕТА?
JNZ CLEAR1 ; ЕСЛИ НЕТ - ПРОДОЛЖАТЬ СТИРАНИЕ.
SPHL ; ВЕРНУТЬ ПРЕЖНЕЕ ЗНАЧЕНИЕ SP И
POP PSW ; ВСЕХ РЕГИСТРОВ.
POP D
POP B
POP H
EI
RET
anyKeyPressed: .db 0
keyCode: .db 0
palette_sprites:
.DB 01001010b, 00000001b, 01011100b, 00011010b,
.DB 11100100b, 11111101b, 01110111b, 01011111b,
.DB 01000010b, 01001011b, 01001100b, 11111111b,
.DB 11111111b, 11101011b, 00001010b, 01011011b,
;----------------------------------------------------------------
; Common interruption sub
Interruption1:
PUSH PSW
PUSH B
PUSH D
PUSH H
; common interruption logic
LXI H,palette_sprites+15 ; ЗАПИСЬ ПАЛИТРЫ.
LXI D,$100F
INIT1: MOV A,E
OUT 02
MOV A,M
OUT $0c
OUT $0c
OUT $0c
OUT $0c
OUT $0c
DCX H
OUT $0c
DCR E
OUT $0c
DCR D
OUT $0c
JNZ INIT1
MVI A,$88
OUT 00
mvi a, 1 ; УСТАНОВКА ЦВЕТА БОРДЮРА.
ANI $0F
OUT 02
mvi a, 255 ; УСТАНОВКА ВЕРТИКАЛЬНОГО ПОЛОЖЕНИЯ ЭКРАНА.
OUT 03
MVI A,$8A ; ПРОВЕРКА НАЖАТИЯ НА ЛЮБУЮ КЛАВИШУ
OUT 00 ; МАТРИЦЫ КЛАВИАТУРЫ 8*8 (КРОМЕ УС,СС,РУС/ЛАТ).
XRA A
OUT 03
IN 2
STA anyKeyPressed
MVI A,$FE ; ПРОВЕРКА НАЖАТИЯ НА КЛАВИШИ ИГРОВОГО РЯДА.
OUT 03
IN 02
STA keyCode
; end common interruption logic
POP H
POP D
POP B
POP PSW
EI
RET
end
Из даташита 8255:
"All of the output registers, including the status flip-flops, will be reset whenever the mode is changed"
Код цвета бордюра -- это не отдельный регистр, а прямо выход 8255. Поэтому бордюр надо записывать после опроса клавиатуры.
parallelno
25.07.2022, 02:10
Прикольно. Спасибо. А есть подробная информация по работе с портами?
Я обычно заглядываю в Техническое описание (https://github.com/svofski/vector06cc/wiki/Technical_Description) и в даташиты. Но чаще всего можно списать домашку откуда-нибудь.
parallelno
25.07.2022, 04:37
О, спасибо большое. Добавлю в первый пост
- - - Добавлено - - -
Списать то можно, но иногда получается как у меня. Несколько часов поиска несуществующего бага :))
- - - Добавлено - - -
Нашел вот такую инфу в технической документации:
https://github.com/svofski/vector06cc/wiki/Technical_Description
Программа, работающая по прерыванию, производит программирование ВВ55
на режим, позволяющий опросить клавиатуру. Поэтому перед возвратом из
подпрограммы необходимо обратно восстановить дисплейный режим и значения
портов, определяющих номер верхней строки, цвет рамки, режим 256*256 или
512*256 и т.п. Также необходимо разрешить прерывание,
но в секретах не востанавливается дисплейный режим.
...
LDA IndRus ;взять признак включения индикатора "РУС/LAT"
MOV B,A ;временно поместить в регистр "B"
LDA Rele ;взять признак включения реле из ячейки "Rele" и
ORA B ;об'единить с признаком включения индикатора "РУС/LAT"
OUT 01 ;вывести сигналы управления индикатором и реле в порт 01
POP PSW ;вернуть все регистры из стека
...
Насколько это критично? и нужно ли всегда программировать порт 01 как в примере выше?
но в секретах не востанавливается дисплейный режим.
MVI A,88h ;установить режимы портов 02-вывод, 03-вывод
OUT 00 ;мл. 4 бита порта 01 - вывод, старшие 4 бита - ввод
LDA Border ;взять цвет бордюра ячейки "Border" (матем. код) и
OUT 02 ;установить цвет бордюра на 4-х младших битах порта 02
LDA Scroll ;взять из ячейки "Scroll"вертикальное положение экрана
OUT 03 ;и установить в порт 03
LDA IndRus ;взять признак включения индикатора "РУС/LAT"
MOV B,A ;временно поместить в регистр "B"
LDA Rele ;взять признак включения реле из ячейки "Rele" и
ORA B ;об'единить с признаком включения индикатора "РУС/LAT"
OUT 01 ;вывести сигналы управления индикатором и реле в порт 01
POP PSW ;вернуть все регистры из стека
parallelno
25.07.2022, 12:34
ivagor,
Я имел ввиду разрешение экрана. Или я что-то упустил и оно устанавливается?
ivagor,
Я имел ввиду разрешение экрана. Или я что-то упустил и оно устанавливается?
Если я ни чего не путаю, то разрешение экрана устанавливается одновременно с установкой цвета бордюра...
Да, четыре младших бита - цвет бордюра/номер цвета палитры, следующий бит - видеорежим. svofski только недавно навыкладывал много примеров в теме про 512 точек, вот один из них (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/099593d2d2dbcab6b44b2034747e8d96/raw/d6cd95876f68dfe65d4e51326fcc5af01e1f0b4f/text512v+reverse+color.asm).
Да, четыре младших бита - цвет бордюра/номер цвета палитры, следующий бит - видеорежим. svofski только недавно навыкладывал много примеров в теме про 512 точек, вот один из них (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/099593d2d2dbcab6b44b2034747e8d96/raw/d6cd95876f68dfe65d4e51326fcc5af01e1f0b4f/text512v+reverse+color.asm).
Я вот смотрел его, хотел на него указать, но не нашел там команд "OUT" , кроме "out 10".
; включить режим 512 точек
mvi a, $10
out 2
parallelno
25.07.2022, 14:01
А оффсет по вертикали тоже нужно каждый кадр устанавливать?
А оффсет по вертикали тоже нужно каждый кадр устанавливать?
Да, потому что при записи любого управляющего слова в 8255, его выходы сбрасываются в 0. Точно то же самое, что было с бордюром.
parallelno
25.07.2022, 22:09
svofski, интересно почему оффсет для не сдвинутого положения экрана 255, а дефолт 0. :)
parallelno, дефолтное значение на выходе порта 0 -- это особенность 8255. А дефолтное значение для несдвинутого экрана 255 -- это особенность схемы Вектора.
parallelno
28.07.2022, 08:43
у нас примерно 60К тактов между прерываниями. как я помню после HLT формирование экрана закончено и начинается рисоватся новый. Сколько времени тратиться на отрисовку бордюров сверху и сниху и на сам кадр?
59904 такта, 312 строк по 192 такта. VV показывает счетчик тактов в кадре, а emu80 -- еще и строку и пиксель в строке.
У меня где-то записано так: 22 строки vsync, 18 строк верхний бордюр, 256 строк растровой развертки, 16 строк нижний бордюр.
- - - Добавлено - - -
Кстати по касетельной. Не случилось ли со времен 8-битной улитки нового плеера pt2/pt3 адаптированного для Вектора? Вчера провел больше времени, чем рассчитывал, перелопачивая абсолютные ссылки в плеере из улитки с целью сделать его релоцируемым. В принципе получилось (https://gist.github.com/svofski/19aeb8641cbcce4fa56fa79f3400fca4), но все равно осталась куча непонятных мест, которые портят память в более-менее случайных местах. Ничего такого, чего нельзя поправить еще парой усидчивых часов, надеюсь. И все равно это меньше труда, чем выдирать очередной плеер из других демок. Но все же..
К слову, жутчайший код, не знаю отчего он такой. На полторы тыщи строк ассемблерного кода там наверное сотни три переменных. Как вообще такое можно было написать? Может это последствия рекомпиляции с z80?
Если очень надо pt3, то можно перевести в psg и упаковать, но для компактной демы это не подойдет.
Если очень надо pt3, то можно перевести в psg и упаковать, но для компактной демы это не подойдет.
По крайней мере можно попробовать. К слову сказать, этот чудо-плеер занимает 3068 байт, что наводит на мысли о том, что большинство регистровых дампов будут покомпактней, чем pt2+этот плеер. К тому же, насколько я понимаю, он ограничен pt2. Кстати, если любопытно, можно по быстрому собрать мой пример из предыдущего сообщения и глянуть на него в Базыре. Он там весь просто сияет всеми своими килобайтами. Жуткий код.
А есть примеры как pt3 переводится в psg и потом проигрывается?
как pt3 переводится в psg
Сам пользовался AY_Emul (https://bulba.untergrund.net/emulator.htm), там в списке проигрывания (playlist) правый клик на файле и "Конвертировать в ..." выбираем psg. Размер psg будет больше раз в 8. Если упаковать psg, то размер будет больше оригинала в 2-4 раза (смотря чем паковать). Формат psg очень простой, я даже без описания как-то проигрывал (если кто-то подскажет где описание - я только за). Но возможно до проигрывания не дойдет и все закончится на первом этапе, когда станет понятен размер.
Чего-то мне не везет с AY_Emul, все ссылки в какой-то мрак, антивирусы ругаются, собрать самому из того фарша что там в исходниках не светит. Ладно, будем искать...
metamorpho
28.07.2022, 14:38
Чего-то мне не везет с AY_Emul, все ссылки в какой-то мрак, антивирусы ругаются, собрать самому из того фарша что там в исходниках не светит. Ладно, будем искать...
Когда-то давно похоже я здесь качал
https://bulba.untergrund.net/emulator.htm
..........
А невнимательно я - поспешил, вижу ivagor уже дал эту ссылку.
Сейчас malwarebytes говорит, что помойный сайт. Может это false positive, но осадочек остался. Нашел некий aylet-0.5. В нем фичи дампа нет, но прикрутить ее на первый взгляд несложно. Правда, если действительно прогнозируемый объем 8х, прям не знаю..
Описание формата psg есть в help к AY_Emul, но с учетом проблем вероятно стоит поискать в другом месте
Я нашел некий Arkos Tracker, который может сохранять файлы .ym, которые насколько я могу судить суть ровно то же самое -- дамп всех регистров (он может их группировать по фреймам и по регистрам, на выбор). Размер разумеется получается совершенно слонопотамский, но на вид сжимаемо. Вот думаю, для zpu8080 я делал поддержку dezx7 в виде потока. Может быть можно сделать плеер из ym-дампа с поточной распаковкой на лету?
- - - Добавлено - - -
Просто для лулзов, 61кб пофреймовый .ym файл zx0 ужался в 4.5кб. Прикидываю себе размер распаковщика + регистропихателя еще байт 100-200 и результат может случиться более компактным и кто знает, может быть более быстрым, чем оригинальный файл + адский плеер.
Чего-то мне не везет с AY_Emul, все ссылки в какой-то мрак, антивирусы ругаются, собрать самому из того фарша что там в исходниках не светит. Ладно, будем искать...
Привет всем...
Ay Emulator v2.9 на vtrd.in...
https://vtrd.in/pcutilz/AYEM2932.zip
59904 такта, 312 строк по 192 такта. VV показывает счетчик тактов в кадре, а emu80 -- еще и строку и пиксель в строке.
У меня где-то записано так: 22 строки vsync, 18 строк верхний бордюр, 256 строк растровой развертки, 16 строк нижний бордюр.
Правильно я понимаю, что прерывание возникает в момент начала обратного хода луча?
И тогда получается, что после начала прерывания есть 40 строк * 192 = 7680 такта до начала рисования первой видимой строки.
nzeemin, вроде бы так, да. Если что-то вверху экрана без теринга надо нарисовать, лучше это делать за этот промежуток времени. Или уж наоборот, ближе к концу кадра.
Удобно добавлять в основной цикл чего-нибудь типа mvi a, 1 \ out 2 ... <длинный код 1> mvi a, 2 \ out 2 ... <длинный код 2> ... mvi a, 0 \ out 2 -- и по бордюру смотреть, если что-то съедает больше времени, чем планировалось.
parallelno
28.07.2022, 19:00
Копался в инете и нашел книгу некого американского металурга по I8080 / z80. Понравилось что он рассматриваем оба проца и показывает какие-есть альтернативы для I8080 чтобы заменить недостающую часть.
https://worldofspectrum.net/pub/sinclair/books/123/8080-Z80AssemblyLanguage-TechniquesForImprovedProgramming.pdf
(это не имеет даже косвенного отношения к сжатию данных, поэтому я продолжаю тут)
А можно программу не самомодифицирующуся в квазидиске выполнять или хотя бы читать с квазидиске когда все 4 экранных плоскости заняты под видимую графику?
parallelno, видео квазидиск не видит, поэтому можно какую угодно программу исполнять прямо в квазидиске. Но в стандартном квазе отображается только 8кб на адреса 0xa000-0xbfff, если не изменяет память. Остальное доступно только через стек.
Этим пользуется "улиточный" плеер, он сидит в адресах 0xa000. Он прячется в квазидиске и именно по этой нелепой причине улитке для звука требуется кваз несмотря на то, что памяти свободной там вагон. Сейчас я его частично от этой беды вылечил, но только частично.
8кб на адреса 0xa000-0xbfff
16 (A000-DFFF)
Посмотрел описание к квази-диску. Н-да.
Если подключать в адреса A000-DFFF - это значит, ограничить себя одной цветовой плоскостью (E000-FFFF) или двумя (плюс ещё 8000-9FFF). Но и использовать из квази-диска получится только 4 x 16K = 64K.
Так что по любому нужно писать процедуру перекидывания данных с квази-диска через стековые операции.
Плюс ещё нужно будет его как-то наполнять - видимо, чтением с диска?
Improver
02.08.2022, 16:06
Если подключать в адреса A000-DFFF - это значит, ограничить себя одной цветовой плоскостью (E000-FFFF) или двумя (плюс ещё 8000-9FFF).Не обязательно так. Можно вынести процедуры обработки изображения в область 0000-7FFF, а всё остальное держать на КД в подэкранной области, и при этом иметь все 32 кб на экран. Ну а ко всему остальному объёму кваза обращаться через стек, как это делают МДОСы.
Пусть меня поправят реальщики, но у меня сложилось впечатление, что у большинства сейчас квазы поддерживающие доработку Баркаря (номер журнала с описанием здесь (http://www.sensi.org/scalar/ware/785/)). Он позволяет перекрывать до 4х экранных плоскостей и, соответственно, использовать до 128 Кб без стека. В эмуляторах (не помню насчет v06x) это конечно поддерживается. Ну и недавно неожиданно получило популярность подключение к реалам двух квазов. Для emu есть такой конфиг.
- - - Добавлено - - -
Плюс ещё нужно будет его как-то наполнять - видимо, чтением с диска?
Есть несколько примеров, когда кваз (частично) заполняется при старте игрушки/демонстрашки. Туда или распаковываются данные или "предсдвигаются" спрайты и т.п.
v06x в Баркаря умеет, но я скептически отношусь к "реальности" этой модификации. Хотя конечно вся реальность сейчас немного размытая.
Если подключать в адреса A000-DFFF - это значит, ограничить себя одной цветовой плоскостью (E000-FFFF) или двумя (плюс ещё 8000-9FFF).
Необязательно так строго. Их можно включать для моментального использования и выключать обратно. На содержимом экрана это никак не отразится. Например, туда можно выгрузить плеер и песенку. Или держать там какие-то алгоритмы, которые нужны, но не обязательно связаны с непосредственной модификацией параллельных областей экранной памяти.
я скептически отношусь к "реальности" этой модификации
Все новодельные квазы поддерживают. И даже есть "старые" которые поддерживают. Поэтому я считаю, что сейчас проще найти работающий кваз с поддержкой расширений Баркаря, чем без них.
Выколупывание все-таки не самое мое любимое занятие, но вот плеер из "Полета навигатора" (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/19aeb8641cbcce4fa56fa79f3400fca4/raw/309a487e1dd20ae1f782706a54e307a06441792f/p4kplayer.asm).
Компактненький, 1400 байт примерно. По времени 37-50 строк. Осталось разобраться, что за формат файла он играет.
- - - Добавлено - - -
Ага, методом перебора нашел, что это формат STC. Попробовал другой музон в этом формате, работает. Не самый популярный формат. Не знаю, как обстоят дела с конвертацией pt3 -> stc, но подозреваю, что никак.
Upd: ссылка на оригинальный музон DOCZak1 by DOC'NEONSOFT (https://zxart.ee/spa/autores/d/doc/doczak01/). Интересно, что в polet4k имя автора затерто.
parallelno
02.08.2022, 22:05
Спасибо за инфу! Очень полезно.
получило популярность подключение к реалам двух квазов. Для emu есть такой конфиг
Если что, в Emu80 тоже уже поддерживается...
Еще исходники плееров для 8080 (1 (https://zx-pk.ru/threads/8374-pk8000-podklyuchenie-k-kompyuteru-ay-(ay-3-8910).html?p=150239&viewfull=1#post150239), 2 (https://zx-pk.ru/threads/8378-pk8000-soft-staryj-i-novyj.html?p=938887&viewfull=1#post938887)). Вроде еще были, кажется Mick выкладывал, не могу вспомнить.
Ну где ж ды был с этими ссылками до этого? =)
В общем это все плееры STC, то есть более-менее то же самое.
- - - Добавлено - - -
Вообще удивительно как много усилий требуется для проигрывания музыки. У нас сейчас есть две противоположности -- модуль + плеер, где вся обработка делается в плеере vs полностью декодированный модуль в виде регистрового дампа. Оба варианта далеки от идеала. Плеер требует вычислений в 2+ раза больше, чем распаковка 14 потоков регистровых дампов в условиях, приближенных к RTOS, а распаковщик регистровых дампов требует вагон памяти. Ну и тоже не совсем бесплатный по времени.
Плеер я не изучал детально, но видно, что там выполняется много движений для доступа к неудобно расположенным данным в таблицах типа чего-нибудь со смещением 7, лукапы по 16-битным ссылкам и тому подобное. Такие вещи как нарочно придуманы чтобы обидеть 8080, которому все это дается со скрежетом зубовным.
Может быть можно сделать иначе -- пережевывать модуль заранее во что-то промежуточное, что и не модуль удобный для редактирования, но еще не совсем регистровые дампы? Или они и так уже достаточно низкоуровневые и ничего принципиально изменить тут нельзя? Или там в принципе все и так норм, просто надо написать плеер думая как 8080, а не как z80, и все будет хорошо?
- - - Добавлено - - -
Проверил плеер DemonID7 - тут (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/19aeb8641cbcce4fa56fa79f3400fca4/raw/9932eef3415cabe3caf7b85655450555ec4dcb01/stcplay-demonid7.asm). (Upd: убрал "эквалайзер"). Большинство фреймов ~ 30 строк, периодически проседает до 45, а один раз поймал на 58.
А сколько максимально строк или тактов для плеера допустимо?
Многопоточный распаковщик на мой взгляд отличная штука, но в текущем виде не особо удобная для использования. Я пытался улучшить инициализацию, но в идеале надо еще дожать.
ivagor, у меня сейчас в проекте, который я пока не хочу показывать, инициализация улучшена -- не обязательно с точки зрения числа тактов, но проще для использования -- песня загружается из массива указателей на потоки и их легко переключать.
lxi h, song_0
call gigachad_init
...
; песенка
song_0:
dw song_00, song_01, song_02, song_03, song_04, song_05, song_06
dw song_07, song_08, song_09, song_10, song_11, song_12, song_13
Сами данные подготавливаются скриптом, так что на самом деле проблем в настройке и использовании минимум. Ну разве что приходится конвертить музыку в ym, что может быть немного занудно.
Сколько строк допустимо -- это зависит от ситуации. У меня сейчас так удачно сложилось, что с моим многопоточным плеером получилось засунуть звук туда, где я был уверен, что его вообще не будет. Вообще немного детерминизма плеерам не помешало бы, а то ты думаешь, что он отрабатывает за 35, а тут врдуг бах 58. Это конечно существенно только в случае, когда нужна жесткая привязка к развертке. Если ее нет, то в общем все это не так уж важно.
Простая инициализация - это приятно.
Насчет плеера я не совсем понял - не хватает времени на него в худшем случае или хватает, но проблема в плавании длительности? Если второе, то делим на "вычисление" очередной порции и выдачу в порты. Вычисление ставим в конец фрейма, в оставшееся время, а выдачу в порты (фиксированной длительности) где-то в начале.
Вычисление ставим в конец фрейма, в оставшееся время, а выдачу в порты (фиксированной длительности) где-то в начале.
Можно и так, но настолько большой размах, чтобы было заметно на слух, вряд ли достижим. Небольшое плавание есть у любого плеера в компиленном формате редактора (stc, pt и так далее), но даже у древнего плеера от st на Спектруме, где размах был довольно заметен (при визуализации на бордюр), это не ощущалось "ушами". Если по теме, наибольший эффект даст именно переделка плеера конкретно под 8080 с учётом отличий от Z80 ( если речь о переделке), ну или написание с нуля, подразумевающее свой, новый, оптимизированный формат модуля, где "размах" будет сведён к минимуму. В своё время писал компилер и плеер для STPro (Спектрум), и пришлось вдумчиво расставлять переходы и процедуры в плеере, зато размах в итоге был максимум в две строки бордюра, насколько помню, и то это теоретически достижимый потолок, на деле вряд ли встречающийся. А когда новая нота (позиция в паттерне) не извлекалась, стояла искусственная задержка для минимизации "плавания".
Короче, много слов, по итогу - написание грамотного плеера есть наилучший вариант.
Так и сделано в polet4k, например. Но это не решает проблему примерно никак особенно. Если основная логика и плеер вместе не помещаются в кадр, значит уже нет кадровости и приходится делать полукадровость. Причем плеером жертвовать нельзя, потому что ему обязательно быть вызванным 50 раз в секунду и все тут. А если делать что-то такое сложное, то хорошо знать заранее, когда на что сколько времени потребуется. Типа вот плееру надо 60 строк один раз в 50 кадров -- ок, не проблема, если это известно заранее -- можно спланировать дему-игру так, что это пройдет незаметно. А если это неизвестно, то либо приходится резервировать время всегда по худшей планке, а его столько просто нет, или нарываться на срывы периодически.
Про разбиение на вычисление и вывод -- в чем смысл, если и то и другое обязательно делать каждый кадр и все равно мы не знаем, сколько суммарно времени на это уйдет? Максимум что это дает -- убрать джиттер в примерно 1мс (считаю как примерно 1/20 экрана в 1/50 секунды) от того, что плеер вызывается чуть раньше или позже. Это правда слышно?
В моем конкретном случае сейчас -- времени на все хватает, потому что я пользуюсь gigachad16 :) Я изучаю что бывает и рассуждаю больше за вообще, на будущее.
- - - Добавлено - - -
Можно и так, но настолько большой размах, чтобы было заметно на слух, вряд ли достижим.
Вот, я именно об этом. Наверняка есть какие-то особенные случаи, когда можно услышать этот размах, но не всегда требуется идеал. Иногда надо средненькое, но стабильное.
- - - Добавлено - - -
В своё время писал компилер и плеер для STPro (Спектрум), и пришлось вдумчиво расставлять переходы и процедуры в плеере, зато размах в итоге был максимум в две строки бордюра, насколько помню, и то это теоретически достижимый потолок, на деле вряд ли встречающийся. А когда новая нота (позиция в паттерне) не извлекалась, стояла искусственная задержка для минимизации "плавания".
Короче, много слов, по итогу - написание грамотного плеера есть наилучший вариант.
А что значит "компилер и плеер". Я понимаю плеер, а что в данном случае подразумевается под компиляцией?
что значит "компилер и плеер"
Посмотри как на вектор портировали (http://www.sensi.org/scalar/ware/607/), там есть компилятор
Посмотри как на вектор портировали (http://www.sensi.org/scalar/ware/607/), там есть компилятор
Насколько я понял, компилятором там называется программа, которая из текстового файла делает бинарник для плеера.
Насколько я понял, компилятором там называется программа, которая из текстового файла делает бинарник для плеера.
Примерно так, если грубо. Спектрумовские редакторы сохраняют музыку в двух вариантах: "исходник" (нечто вроде текста с нотами, плюс данные орнаментов и сэмплов), всё это запаковано своими встроенными паковщиками в подобие архива, а второй вариант - компилировпнный модуль с плеером/без плеера, где данные уже идут в максимально оптимизированном для вывода формате. И вот разработка этого компиленного формата, а также плеера - самая ответственная задача для кодера. Каждый лепил, на что хватало мозгов, ну и с течением времени оптимизировались сами плееры компиленных модулей. Компилеры, как правило, были встроены прямо в редактор.
Мой формат модуля (для STPro) не был оптимален по размеру компилируемых модулей, но в плане быстродействия и формат, и плеер близки к идеалу. В нём один "поток данных" для нот всех каналов, плюс своя процедура обработки каждого канала, что прилично раздуло код, но по итогу плеер вышел довольно быстрым и относительно компактным, 1868 байт, насколько помню. Вот архив с редактором на vtrd https://vtrd.in/system/STPROFIX.ZIP
Если не изменяет память, внутри трдшника есть отдельно демонстрационный Бейсик-плеер с замером на бордюре, и видно, что времянки почти не дергаются, настолько ровно подогнан код. Пардон за неВекторную тематику, но кому-то, возможно, будет интересно.
Кстати, раз уж вектор, то задачу выравнивания (если не нужна точность до такта) можно решить с использованием таймера.
reddie, очень даже интересно. И приблизительно понятно. Мое предложение делать дополнительное промежуточное пережовывание общепринятых трекерных форматов для удобства плеера по-моему совпадает по духу с этой идеей.
Я не закапывался глубоко в форматы трекерных модулей, но чуть чуть удивлялся тому, как там все высокоуровнево для такой низкоуровневой штуки. Имеющиеся плееры выходит совсем неплохо справляются с такой сложной задачей. А ведь по идее на целевой платформе нам не нужны ни паттерны, ни ноты и даже не частоты, а нужны уже просчитанные значения регистров. Орнаменты итд это для музыканта, а для плеера-чипа это все просто меняющиеся параметры. Но так легко дойти до того, что выходит, что регистровый дамп -- это лучшее, что можно придумать.
В общем вывод такой: для того, чтобы получить плеер лучше тех, что уже есть, придется включить голову и найти в ней мозг.
дополнительное промежуточное пережовывание общепринятых трекерных форматов для удобства плеера по-моему совпадает по духу
да. вопрос лишь в степени пережеванности =) тут прямая зависимость: чем сильнее пережевать, тем, по идее, быстрее плеер.
Орнаменты итд это для музыканта, а для плеера-чипа это все просто меняющиеся параметры
именно, однако в те далекие времена кодерские технологии не дошли до PSG, вернее, до упакованного в разумные размеры формата. Отдельные кусочки дампа регистров использовались в критичных местах (одновременная загрузка с дискеты, например), но чтоб весь трек в PSG загнать, понадобилось много лет. Так-то да, дамп по скорости воспроизведения - лучший вариант. Но упаковать его в те годы подобным образом не представлялось возможным, особенно сразу на целевых платформах. Поэтому треки компилировались в некую смесь из дампа паттернов и сэмплов-орнаментов по отдельности, а на плеер возлагалась задача все это выкидывать в регистры чипа, и желательно побыстрее. Тут уже решала квалификация кодера, суметь провести оптимизацию по скорости (или, что намного реже, размеру). В ход шли всякие трюки и учет особенностей AY. Например, слайд сэмпла вверх-вниз в редакторе изображен как в плюс, так и в минус, но плеер делает только сложение регистровых пар, старшие незначащие биты высоты звука при этом игнорируются чипом, и т.д.
для того, чтобы получить плеер лучше тех, что уже есть, придется включить голову и найти в ней мозг
Абсолютно верно. И лучше писать с нуля сразу под 8080 - в теории это даст наилучший результат, если программист хорошо разбирается в своем деле.
parallelno
08.08.2022, 08:39
Подскажите пожалуйста быстрый RND. я пока использую байтовый счетчик в прерывании, но хочется иметь чтото получше. Может можно читать из какогото порта какойнить мусор или часто меняющиеся данные?
Подскажите пожалуйста быстрый RND. я пока использую байтовый счетчик в прерывании, но хочется иметь чтото получше. Может можно читать из какогото порта какойнить мусор или часто меняющиеся данные?
Я использовал вот такой: https://github.com/nzeemin/vector06c-desolate/blob/master/desolcoda.asm#L797
На порты полагаться сложно, тем более в эмуляторах.
Можно инкрементировать seed, пока игрок не нажмёт Старт в меню - даст хорошее начальное значение.
parallelno
09.08.2022, 09:42
Спасибо, nzeemin!
Покопавщись в интернетах нашел чуть более быстрый. но конечно не факт что качественее. Но для моих нужд самое то.
; 8-bit Xor-Shift random number generator.
; Created by Patrik Rak in 2008 and revised in 2011/2012.
; See http://www.worldofspectrum.org/forums/showthread.php?t=23070
; period 2^32-1.
; out:
; a - 8-bit pseudo-random number
Rnd8:
push h
push d
@rnd:
lxi h, 0xA280 ; seed must not be 0
lxi d, 0xC0DE ; xz -> yw
shld @rnd+4 ; x = y, z = w
mov a, l ; w = w ^ ( w << 3 )
add a
add a
add a
xra l
mov l, a
mov a, d ; t = x ^ (x << 1)
add a
xra d
mov h,a
rar ; t = t ^ (t >> 1) ^ w
xra h
xra l
mov h, e ; y = z
mov l, a ; w = t
shld @rnd+1
pop d
pop h ; 204
ret
push b ... pop b - может push d ... pop d?
- - - Добавлено - - -
И, кстати, если оставить push h ... pop h, то не будет hl - 16-bit pseudo-random number
- - - Добавлено - - -
Хотя лучше убрать комментарий про "hl - 16-bit pseudo-random number", эта процедура рассчитана на генерацию 8 битных случайных чисел.
parallelno
09.08.2022, 11:30
ivagor, ага, спасибо. поторопился. :)
Спасибо, nzeemin!
Покопавщись в интернетах нашел чуть более быстрый. но конечно не факт что качественее. Но для моих нужд самое то.
Качество рандомайзера можно проверить выводом точек по случайным координатам. Или хотя бы прямо рандомные числа писать подряд в экран. И смотреть, не получился ли на экране паттерн.
parallelno
09.08.2022, 12:09
nzeemin, ага. Так и проверяю. :)
Кстати, нашёл, вот тут я тестировал два рандомайзера:
https://zx-pk.ru/threads/32499-portirovanie-desolate-na-vektor-06ts.html?p=1091958&viewfull=1#post1091958
parallelno
09.08.2022, 12:57
покумекав для себя вывел вот такой псевдо рандом для байтоых значений
Random:
@mainCodeAddr:
lxi h, $100
@rnd:
sbi 1
rrc
xra m
cma
inr l
sbb m
shld @mainCodeAddr+1
sta @rnd+1 ; 84
ret
рандомайзит вполне пригодно для меня. ну и побыстрее чем то что нашел.
https://pic.maxiol.com/images2/1660066042.3326747235.rnd.png
- - - Добавлено - - -
lxi h, адресс кода основной программы используется как сид. используются только 256 байт
- - - Добавлено - - -
nzeemin, проверь если сможешь в своих проектах насколько универсальная или не универсальная штука получилась. :)
Вспомнил что ещё недавно разбирал код на Z80 имеющий 16-битный рандом.
Это из Scuba Dive для ZX Spectrum:
NextRandom
LD HL,(RANDOM) ; get current Random
LD D,H
LD E,L
ADD HL,HL ; x2
ADD HL,HL ; x4
ADD HL,HL ; x8
ADD HL,HL ; x16
PUSH HL
ADD HL,HL ; x32
EX (SP),HL
OR A
SBC HL,DE ; HL = x15
POP BC ; BC = x32
ADD HL,BC ; x47
ADD HL,HL ; x94
ADD HL,HL ; x188
ADD HL,HL ; x376
ADD HL,DE ; x377
ADD HL,HL ; x754
ADD HL,HL ; x1508
ADD HL,DE ; x1509
LD DE,$0029
ADD HL,DE
LD (RANDOM),HL ; (RANDOM) := (RANDOM) * 1509 + 41
RET
parallelno
09.08.2022, 13:24
___
И ещё один вариант рандомайзера, на этот раз 8-битный, из Highway Encounter, с виду довольно быстрый:
; Псевдослучайное 8-битное число с периодом 256 по отношению: X[1] = X[0] * 5 + 7
; I: -
; O: A=RND
; M: HL, AF
Rand: lxi h,RndVal
mov a,m
add a
add a
add m
adi 7
mov m,a
ret
parallelno
09.08.2022, 13:46
nzeemin, Хороший результат.
https://pic.maxiol.com/thumbs2/1660041712.2285140750.rndn.png
эта процедура рассчитана на генерацию 8 битных случайных чисел.
Частично сдам назад. Для 8-битных обеспечивается заявленный период и в таком варианте, как пишет автор, генератор почти прошел статистические тесты. Но если обеспечение заявленных характеристик не обязательно и надо просто сгенерировать "что-то псевдослучайное 16-битное", то можно взять HL, только для этого нужно вызывать rnd8 по два раза для получения нового значения HL! На мой взгляд все же лучше брать генератор нужной разрядности с предсказуемыми характеристиками.
parallelno
09.08.2022, 22:25
нашел еще парочку интересных псевдо рандомайзеров
; 16-bit xorshift pseudorandom number generator
; returns hl = pseudorandom number
; corrupts a
; http://www.retroprogramming.com/2017/07/xorshift-pseudorandom-numbers-in-z80.html?m=1
Random:
lxi h, 1 ; seed must not be 0
mov a,h
rar
mov a,l
rar
xra h
mov h,a
mov a,l
rar
mov a,h
rar
xra l
mov l,a
xra h
mov h,a
shld Random+1 ; 116
ret
; Fast RND
;
; An 8-bit pseudo-random number generator,
; using a similar method to the Spectrum ROM,
; - without the overhead of the Spectrum ROM.
;
; R = random number seed
; an integer in the range [1, 256]
;
; R -> (33*R) mod 257
;
; S = R - 1
; an 8-bit unsigned integer. 256 period
; http://www.z80.info/pseudo-random.txt
Random:
mvi a, 34
mov l, a
rrc
rrc
rrc
xri $1f
add l
sbi 255
sta Random+1 ; 64
ret
; returns pseudo random 8 bit number in A. Only affects A.
; By Lee Davison. 256 period
; https://philpem.me.uk/leeedavison/z80/prng/index.html
Random:
mvi a, 1 ; get seed. must not be zero
ani $B8 ; mask non feedback bits
stc ; set carry
jpo no_clr ; skip clear if odd
cmc ; complement carry (clear it)
no_clr:
lda Random+1 ; get seed back
ral ; rotate carry into byte
sta Random+1 ; save back for next prn ; 72
ret
; By Lee Davison. 256 period
255
sta Random ; save back for next prn ; 72
sta Random+1
Но вобще эта процедура в основном является иллюстрацией, что если неэффективно реализовать неэффективный вариант конфигурации LFSR, то получится неэффективно.
parallelno
10.08.2022, 09:04
ivagor, спасибо поправил
чуть ускорил одну из предыдущих процедур. все тф же последовательность в 256 байт, но на 4 такта быстрее :)
RndVal .byte 34
Random:
lxi h, RndVal
mov a, m
rrc
rrc
rrc
xri $1f
add m
sbi 255
mov m, a ; 60
ret
parallelno
17.08.2022, 08:02
обновил первый пост про палитры и добавил раздел про музыку
- - - Добавлено - - -
Я нашел некий Arkos Tracker, который может сохранять файлы .ym, которые насколько я могу судить суть ровно то же самое -- дамп всех регистров (он может их группировать по фреймам и по регистрам, на выбор). Размер разумеется получается совершенно слонопотамский, но на вид сжимаемо. Вот думаю, для zpu8080 я делал поддержку dezx7 в виде потока. Может быть можно сделать плеер из ym-дампа с поточной распаковкой на лету?
- - - Добавлено - - -
Просто для лулзов, 61кб пофреймовый .ym файл zx0 ужался в 4.5кб. Прикидываю себе размер распаковщика + регистропихателя еще байт 100-200 и результат может случиться более компактным и кто знает, может быть более быстрым, чем оригинальный файл + адский плеер.
Скачал Arkos Tracker2 отсюда https://www.julien-nevo.com/arkostracker/index.php/download/
но что-то он не понимает форматы pt3, pt2, и STC
Подскажи в каком формате ты ему скормил музыку?
Скачал Arkos Tracker2 отсюда https://www.julien-nevo.com/arkostra....php/download/
но что-то он не понимает форматы pt3, pt2, и STC
Подскажи в каком формате ты ему скормил музыку?
Arkos умеет читать .vt2, это текстовый формат Vortex Tracker II. А Vortex Tracker может читать pt3. Но тут получается, что Arkos не очень нужен, потому что если у тебя есть VT и AyEmul, вот уже и полный комплект, который умеет больше форматов. Польза Arkos в кроссплатформенности и наверное в нем есть какие-то привлекательные фичи, но я их пока для себя не открыл. Для себя я в итоге делал так -- искал музон, допустим нашел что-то на zxart.ee. Открыл его в Vortex Tracker-е. Может быть отредактировал -- убрал задержку в конце или отрезал какой-нибудь паттерн, в общем ремикс по месту. Сохранил и превратил в .ym через AyEmul. Дальше уже заправил в gigachad16 и готово.
parallelno
22.08.2022, 20:18
Сталкнулся с интересным багом. Virtual Vector 7.03 и Emu80 4.0.420/qt по разному эмулируют мою игру. В Emu80 игра зависает, в VV играет. В игре явно баг, но вот такое разное поведение эмуляторов пока в диковинку. :)
Если кто-то из решит посмотреть в чем дело, то вот ром
https://github.com/parallelno/Vector06c/blob/main/Vector06c_Dev/_Projects/GameNoname/rom/GameNoname.rom
там на странице нужно нажать кнопочку Download чтобы скачать rom.
parallelno, проверь ещё в эмуляторе v06x - https://github.com/svofski/vector06sdl/releases
parallelno
22.08.2022, 20:29
Под словом "играет" я имел ввиду что не зависает. :D
Только рисуются тайлы уровня для отливки бага.
В v06x на глаз идентично emu80v4. Судя по Базырю идет какая-то работа с квазом -- если это расширения Баркаря, то в v06x они пока не поддержаны.
parallelno
22.08.2022, 20:46
Должен использоваться только стек доступ к квазу. Но что-то идет не так. Непонятно :)
Ну что ж, в emu80 замечательный отладчик. Должно быть относительно нетрудно вычислить момент, когда действительное начинает расходиться с ожидаемым.
parallelno
22.08.2022, 20:56
Если включать код полностью, монстров, героя, музыку, то зависает и в VV тоже.
- - - Добавлено - - -
Ага, нужно дебажить. Классно было бы иметь дополнительные фичи для отладки например брейк проиты на доступ к памяти, call stack, проигрывание до следующего halt, перемотку назад. Это бы сильно облегчило отладку :)
- - - Добавлено - - -
А и ещё иметь возможность видеть что в видео памяти нарисовано.
Можно побороть симптом - записать С9 вместо C3 по адресу 0000.
Проблема в том, что emu80 на третий раз странно выполняет
0259 CALL 023A
Вместо 23A почему-то вызывает 0000
У меня тоже есть программка, которая виснет в emu80, но с ней пока не разбирался.
Ага, нужно дебажить. Классно было бы иметь дополнительные фичи для отладки например брейк проиты на доступ к памяти, call stack, проигрывание до следующего halt, перемотку назад. Это бы сильно облегчило отладку
Это все есть в v06x через gdb, но разбираться с тем, как этим пользоваться, особенно если ты не настоящий сварщик, довольно хардкорно. Я сам предпочитаю или почереповать, или, когда череп сдает, в теплом ламповом emu80.
parallelno
23.08.2022, 00:20
Это все есть в v06x через gdb, но разбираться с тем, как этим пользоваться, особенно если ты не настоящий сварщик, довольно хардкорно. Я сам предпочитаю или почереповать, или, когда череп сдает, в теплом ламповом emu80.
Я дебажил немного через консоль когда-то давно, это тот ещё экспириенс. Не скажу что мне это доставляло удавольствие. :) поэтому настоящим сварщиком не стал.
Но то что ты сделал это для эмулятора, круто! Вот бы это прикрутить к vs code! :) Чтобы прям с него визуального дебажить... Круто было бы! :)
Но то что ты сделал это для эмулятора, круто! Вот бы это прикрутить к vs code!
gdb-z80, который у меня прикручен, основан на допотопной версии gdb, которую сейчас даже собрать не получается современными компиляторами. Ну и мнемоники z80 для отладки 8080 -- это не мое. А вообще идея интеграции с vscode интересная. Кстати IDA вроде умеет цепляться к ремотному gdb серверу.
parallelno
23.08.2022, 03:40
IDA вроде платная или я что-то путаю?
IDA вроде платная или я что-то путаю?
Да, и я ей не пользуюсь.
parallelno
23.08.2022, 07:06
Можно побороть симптом - записать С9 вместо C3 по адресу 0000.
Проблема в том, что emu80 на третий раз странно выполняет
0259 CALL 023A
Вместо 23A почему-то вызывает 0000
У меня тоже есть программка, которая виснет в emu80, но с ней пока не разбирался.
Попробовал так сделать. Теперь вместо call 23a PC убегает аж в FD00. Потом возвращается по RET в нулевом адресе. Дикость какая. :)
Попробовал так сделать. Теперь вместо call 23a PC убегает аж в FD00. Потом возвращается по RET в нулевом адресе.
Вероятно зависит от того, как именно реализовать правку. Я грубо хакнул и игрушка запустилась в emu80, но т.к. это было всего лишь лечение симптома, то при отличающейся правке тот call может начать чудить иначе.
А с моей программкой проблема вероятно в работе с диском. Причем с диском работаю не напрямую, через дос, но в emu80 виснет.
parallelno
23.08.2022, 08:46
ivagor, вроде в emu какой то баг связанный с контроллером НГМД чинили в последнем билде.
А с моей программкой проблема вероятно в работе с диском. Причем с диском работаю не напрямую, через дос, но в emu80 виснет.
Пришли как будет возможность - посмотрю.
- - - Добавлено - - -
вроде в emu какой то баг связанный с контроллером НГМД чинили в последнем билде.
Кстати, да. Убедись, что в версии v4.0.422 работает. Был баг в команде Read Address ВГ93, в этой версии исправлено.
Про починку околодискового бага я читал, поэтому пробовал в нескольких версиях (в т.ч. в последней), везде виснет. Присылать наверно пока смысла нет, возможно исправление странного бага с call поможет.
ivagor, вроде в emu какой то баг связанный с контроллером НГМД чинили в последнем билде.
Не в emu, а в emu80. Есть ещё мой эмуль, исторически называется emu.
- - - Добавлено - - -
Вот бы это прикрутить к vs code!
Да прикольно было бы. Но нужна отладочная информация. В принципе, листинг выдаваемый ассемблером подходит, но в разных ассемблерах они разного формата, предназначены для человека, а не для программы.
parallelno
23.08.2022, 11:53
Не в emu, а в emu80. Есть ещё мой эмуль, исторически называется emu.
Прости пожалуйста. не знал про твой эмулятор.
Да прикольно было бы. Но нужна отладочная информация. В принципе, листинг выдаваемый ассемблером подходит, но в разных ассемблерах они разного формата, предназначены для человека, а не для программы.
Мне очень в последнее время нравится retro assembler. Былио бы здорово иметь возможность отлаживать с его синтаксисом .
возможно исправление странного бага с call поможет
Попробуй при возможности, выложил исправленную сборку в теме эмулятора.
Попробовал, к сожалению не помогло. Там проблема даже не с кодом моей программы. Если она в конце образа дискеты, то дос ее не может нормально загрузить и запустить. Если в начале - загружает и запускает, но там уже спотыкается на загрузке основного файла. Вероятно проблема в работе с образом, надо трассировать дос, но не хочется.
parallelno
25.08.2022, 08:15
как я могу узнать в программе в каком режиме сейчас подключены квазидиски?
Мне нужно это делать в прерывании. я переключаю в прерывании квазидиск на нужный мне режим, и потом мне нужно востановить прежний режим.
Сейчас я делаю это через глобальную переменную в основной программе:
mvi a, _command
sta ramDiskMode
out $10
В прерывании когда мне нужно востановить режим я считываю ramDiskMode и записываю в out $10. Но ramDiskMode не гарантирует что квазидиск уже в этом режиме когда прерывание произошло между sta ramDiskMode и out $10.
Есть мысли сделать две глобальные переменные, одну до и одну после OUT или пытатся читать из порта 10, но для начала решил узнать у вас можеть есть способ лучше/проще.
Заранее спасибо!
Но ramDiskMode не гарантирует что квазидиск уже в этом режиме когда прерывание произошло между sta ramDiskMode и out $10.
Ну и что, намерение то установить именно режим записанный в ramDiskMode. Если между sta и out случится прерывание, то по выходу из прерывания уже будет ramDiskMode и следующий out его просто продублирует. Сильно заморачиваться этим вопросом имело бы смысл для некоей гипотетической супернавороченной операционной системы, а для игрушки и так вполне нормально. Чтение из 10h в квазах, насколько я знаю, не реализовано (в современных могли бы реализовать для той самой гипотетической ОС).
parallelno
25.08.2022, 09:16
ivagor, вот я и руководствуясь этой логикой сделал так, но что-то идёт не так и спустя время начинают портится данные то в квизидиске, то в основной памяти.
Возможно просто не туда капаю.
Improver
25.08.2022, 16:36
пытатся читать из порта 10Чтения конфигурации нет ни у одного из вариантов квазидисков, в том числе на комбодевайсах и ERAM.
можеть есть способ лучше/прощеНаиболее простым будет запрет прерываний до обращения к КД и разрешение после, тем более при подключении квазидиска в режиме "стек" и срабатывании прерывания данные на нём будут гарантировано испорчены, т.к. при вызове прерывания в стек пишется адрес возврата.
ramDiskMode не гарантирует что квазидиск уже в этом режиме когда прерывание произошло между sta ramDiskMode и out $10
В общем случае перед sta ramDiskMode нужно прерывания запретить, а после out $10 - опять разрешить.
parallelno
25.08.2022, 22:58
Чтения конфигурации нет ни у одного из вариантов квазидисков, в том числе на комбодевайсах и ERAM.
Наиболее простым будет запрет прерываний до обращения к КД и разрешение после, тем более при подключении квазидиска в режиме "стек" и срабатывании прерывания данные на нём будут гарантировано испорчены, т.к. при вызове прерывания в стек пишется адрес возврата.
С восстановлением стека при чтении с квазидиска я справился, спасибо ребятам с этого форума.
- - - Добавлено - - -
В общем случае перед sta ramDiskMode нужно прерывания запретить, а после out $10 - опять разрешить.
О, спасибо ! Попробую.
Но было бы здорово понять в какой момент идёт порча данных. Чуть попозже выложу больше информации что у меня происходит.
- - - Добавлено - - -
А если в момент прерывания они запрещены, то вызов откладывается до следующего ei, или вообще пропускаются?
Если второе, то музыка в прерывании будет чудить и другие штуки завязанные на прерывание.
А если в момент прерывания они запрещены, то вызов откладывается до следующего ei, или вообще пропускаются?
Если второе, то музыка в прерывании будет чудить и другие штуки завязанные на прерывание.
Запрос прерывания держится недолго. Никакой специальной памяти прерваний нет. Если запрещать их как попало, то прерывания будут пропускаться.
parallelno
26.08.2022, 08:47
Спасибо за инфу. А недолго это сколько ?
- - - Добавлено - - -
В общем случае перед sta ramDiskMode нужно прерывания запретить, а после out $10 - опять разрешить.
Это помогло. Спасибо. Но вот очень хочется понять почему такое происходит.
Если кто-то поможет найти ошибку, заранее большое спасибо!
Ниже эээто код прерывания
Interruption2:
; get the return addr which this interruption call stored into the stack
xthl
shld @return + 1
pop h
shld @restoreHL + 1
; store psw as the first element in the interruption stack
; because the following dad psw corrupts it
push psw
pop h
shld STACK_INTERRUPTION_ADDR-2
lxi h, 0
dad sp
shld @restoreSP + 1
; restore two bytes that were corrupted by this interruption call
push b
; dismount ram disks to not damage the ram-disk data with the interruption stack
xra a
out $10
lxi sp, STACK_INTERRUPTION_ADDR-2
push b
push d
call GCPlayerUpdate
INTERRUPTION_MAIN_LOGIC()
pop d
pop b
pop psw
mov l, a
; restore the ram-disk mode
; ramDiskMode doesn't guarantee that a ram-disk is in this mode already. that mode could be applied only after the next command in the main program
lda ramDiskMode
out $10
; restore A
mov a, l
@restoreHL: lxi h, TEMP_ADDR
@restoreSP: lxi sp, TEMP_ADDR
ei
@return: jmp TEMP_ADDR
.closelabels
все места в основной программе где используется квазидиск обернуты вот такими вставками:
mvi a, _command
sta ramDiskMode
out $10
...
xra a
sta ramDiskMode
out $10
Последний билд можно взять тут.
https://github.com/parallelno/Vector06c/blob/main/Vector06c_Dev/_Projects/GameNoname/rom/GameNoname.rom
call GCPlayerUpdate это плеер gigachad16 который начинает глючно играть вконце трека.
INTERRUPTION_MAIN_LOGIC() это код для опроса клавиатуры и прочего
; interruption logic
mvi a, PORT0_OUT_IN
out 0
xra a
out 3
IN 2
inr a
sta anyKeyPressed
mvi a, $fe
out 3
IN 2
sta keyCode
mvi a, PORT0_OUT_OUT
out 0
lda borderColorIdx
out 2
lda scrOffsetY
out 3
lxi h, interruptionCounter
inr m
Глюк влияет на музыку. Ее данные в основной памяти. После нескольких повторов трека, она становится все более поломанной. И только один раз я заметил что спрайты скелетов стали покарапчены. Их данные в квазидиске.
Эти глюки происходят только если игра не синхрониизированна с прерываниями, т.е не имеет hlt в основной цикле. то есть прерывание может прервать основную программу в любом месте.
Если добавить di/ei как посоветовал Pyk, то чинится.
Пытаясь починить баг, я попробовал записывать 0 в регистры AY, очищать буфер музыки по окончанию трека, перенес инициализацию и эти очистки в основную программу чтобы не делать прерывание слишком долгим, но это не помогло.
Буду очень благодарен если кто-то поможет найти багу! Заранее спасибо!
Про время удержания запроса прерывания боюсь соврать. Надо в схему заглянуть, но там не всегда очевидно.
Код в Interruption2 выглядит странно, но я может быть не разобрался. То есть я понимаю: мы аккуратно складываем состояние в переменные, чтобы не запортить еще больше стека. Но что такое push b и как он помогает restore two bytes that were corrupted by this interruption call ? Это видимо знаменитый "метод Медноногова", или что-то типа того? Я с ним незнаком, но выходит, что в паре bc тут каким-то образом находятся заветные восстановительные данные. А они там правда есть? Всегда-всегда? Как можно это гарантировать, если прерывания случаются вообще в любой момент?
parallelno
26.08.2022, 12:16
svofski,
Если главная программа читает данные из стека для например рисования на экране или любых других случаев когда sp указывает не на стек главной программы, а на некие данные мы всегда читаем так pop B. Это гарантирует что bc можно использовать в прерывании для восстановления стека. Если же прерывание случилось когда главная программа использовала обычный стек, то push b в прерывании ничего не делает полезного, но и ничего не портит.
Не помню чей именно это метод изначально, но впервые я прочитал о нем от Jerry на этом форуме.
Кажется я нашел в чем была проблема. После того как в основной программе я делал xra a, out $10, я восстанавливал стек lxi sp, xxxx. Если прерывание происходило после out $10, то стек указывал на адрес в квазидиске где-то в районе 4k, это как раз попадало на музыку в основной памяти.
Поменял местами восстановление стека и выключение квазидиска и все стало работать как нужно. Можно двигаться дальше :)
- - - Добавлено - - -
Лечение не идеальное, так как прерывание будет корраптить данные квазидиска в этот момент и восстановить не получится, но в моем текущем случае это не страшно так как стек основной программы находиться в диапазоне $7ff80-$8000 и по эти адресам ничего полезного в квазидиске нет.
- - - Добавлено - - -
Лучше всего наверное использовать квазидиск для стека в основной программе. Это наверное упростит инициализацию данных после старта если программа будет больше 32к. Можно будет не боятся что стек запортит основную программу.
- - - Добавлено - - -
Если программа запускается из под операционной системы, может ли она менять данные ниже $100? Или они зарезервированы под систему?
- - - Добавлено - - -
Про время удержания запроса прерывания боюсь соврать. Надо в схему заглянуть, но там не всегда очевидно.
Было бы интересно узнать, но не супер важно сейчас, так как основная программа не делает di
push b в прерывании ничего не делает полезного, но и ничего не портит
То есть на то место где обычно лежит адрес возврата, кладет содержимое bc. Ну что ж, наверное действительно в большинстве случаев это приемлемо. Все равно стремно как-то ;) Особенно при том, что еще и банки памяти щелкаются постоянно. Отлаживать такое можно рассудок потерять.
parallelno
26.08.2022, 12:52
То есть на то место где обычно лежит адрес возврата, кладет содержимое bc. Ну что ж, наверное действительно в большинстве случаев это приемлемо. Все равно стремно как-то ;) Особенно при том, что еще и банки памяти щелкаются постоянно. Отлаживать такое можно рассудок потерять.
Да, именно так. Ну вы ребята опытные, я надеюсь что выручите советом если опять что-то забарахлит. Было бы классно получить больше функций отладки, это поможет тоже. :)
- - - Добавлено - - -
svofski, я до сих пор под впечатлением от gigachad16. Наверное ничего сложнее в игре уже не будет :)
Наверное ничего сложнее в игре уже не будет
Парадокс в том, что он на порядок проще любого другого плеера и писать его было легко и чуть-чуть прищурившись можно даже прочитать. Просто переключает задачки, а задачки -- тот же dezx0, который и так уже все видели и в который я вникал лишь минимально (и спасибо ivagor-у за такой классный dezx0!). Все крайне регулярное, никаких семиэтажных ветвлений, все управляется только данными.
Ну и кстати, имея ядро можно не ограничиваться использованием его только для проигрывания музыки. Как раз ему приходится пропускать два фрейма вхолостую. Можно туда добавить две другие задачи (им можно указать другой размер стека, побольше). В общем хоть всю игру можно так забацать.
- - - Добавлено - - -
А недолго это сколько ?
Заглянул в схему. Все упирается в форму F50Гц, это шина 6.28, прямой выход D8.2. Понять длительность импульса без осциллографа я тут не в состоянии, а мой Вектор сейчас в собранном виде.
Насколько я понимаю, длительность F50 не влияет, по фронту взведется D26.2, и если INTE=0 (вход 10), то запрос INT сбросится.
Угу. Я просто почему-то был не уверен за то, как обрабатывается выход из сброса при поднятом клоке у D26.2.
Но в любом случае лучше программировать не надеясь на глюки микросхем.
parallelno
26.08.2022, 19:15
Подскажите пожалуйста по адресам $80-$ff. Если там держать стек, будет ли это портить данные операционок на векторе?
- - - Добавлено - - -
И вопрос про квазидиск Баркаря. Его режим переключения на подмену памяти с $8000-$ffff как то по особому включается или всегда такой? Если ли возможность как то в программе определить какой тип квазидиска установлен?
Если ли возможность как то в программе определить какой тип квазидиска установлен?
сделать как на спеке (проверять ячейку памяти до и после переключения) ?
Ребят, допустим я запускаю на Векторе Z80 какой-то .rom файл. Нужно ли делать какую-то специфичную инициализацию вначале, именно специфичную для Z80 Вектора?
В общем случае можно ничего специального не делать.
parallelno
27.08.2022, 08:29
ivagor,
...
И еще замечание. В описании сказано, что при выполнении команды EI поступивший в это время запрос на прерывание будет блокирован, пока не выполнится следующая за EI команда.
Но судя по схеме, EI (равно как и DI) просто блокирует разрешение записанное в IFF1. А следовательно, если будет выполнятся цепочка из команд EI, то прерывание не сработает, пока все EI не выполнятся.
...
Не вижу противоречия, просто каждый следующий EI в свою очередь откладывает реакцию на прерывание, 8080 работает аналогично.
я правильно понимаю что на Векторе если прерывание попало на EI, то прерывание не пропускается, а откладывается до выполнения следующей после EI команды? то есть прерывание никога не сможет быть вызвано сразу после EI, так?
На векторе, если между фронтом F50 и проверкой запроса прерывания в проце прерывания запрещены, то прерывание пропускается.
parallelno
27.08.2022, 10:00
ivagor, извини, но честно говоря не понял о чём ты пишешь.
на Векторе если прерывание попало на EI, то прерывание не пропускается, а откладывается до выполнения следующей после EI команды?
Н.Н. Щелкунов, А.П. Дианов. Микропроцессорные средства и системы. М.Радио и связь, 1989, стр. 61-62
"При условии INT*INTE=1, которое проверяется в последнем такте каждого командного цикла (за исключением команды EI), МП должен перейти к процедуре обслуживания запроса".
С учетом того, что я написал выше - пропускается, не откладывается (уточню, что речь о стандартном 06Ц с ВМ80).
прерывание никога не сможет быть вызвано сразу после EI
да
parallelno
27.08.2022, 11:44
Спасибо!
Я это уточнял потому что эта информация объясняет починку бага командами ei/di которые посоветовал Pyk. Там лечилось похоже не из-за того что прерывание не могло быть вызвано до out $10, а из-за того что следующая за ei команда гарантированно выполнялась сразу после ei. Это была lxi sp,
Все зависит от задач. Если, например, нужно играть фоновую музыку по прерываниям, то не надо использовать ei и di. В этом случае надо так изменять sp, чтобы ничего не повредить.
Не могу найти подручного беззнакового умножения 8x8 -> 16. Ни у кого не завалялось?
Не могу найти подручного беззнакового умножения 8x8 -> 16. Ни у кого не завалялось?
А тебе медленно или быстро? Если быстро, то через таблицу квадратов четвертушек, 512 байт. Если медленно, то вообще в чём вопрос? Двоично в столбик. Как в школе.
А тебе медленно или быстро? Если быстро, то через таблицу квадратов четвертушек, 512 байт. Если медленно, то вообще в чём вопрос? Двоично в столбик. Как в школе.
Медленно норм. Просто не всегда хочется делать все самому. Мне кажется, что такие вещи должны быть готовыми. И раньше как-то находились, а тут оказалось, что что-то как-то нет.
Так, наверное, потому, что это тривиально ...
Если устраивает совсем медленно, то просто последовательным сложением. Один аргумент в A, второй в DE, нулим HL, и увеличиваем его командой DAD количеством раз, которое в регистре A. Это даже 8x16, между прочим.
Если множитель большой, где-то больше шести, то побитово в столбик. Множитель умножаем на два через XCHG: DAD H: XCHG
parallelno
03.09.2022, 02:35
svofski, если не сложно, поделись пожалуйста. Я помню только в документации к векторовскому ассемблеру были описаны рутины умножения и деления кажется. Но сам код уже не помню.
Конечно, правда я уже забыл откуда сам списал.
; hl = h * l
mul8x8:
mov A,h ; Multiplier (-1) to A Register
mov e,l ; Multiplicand (127) to D,E Registers
MVI d,000h
LXI H,000h ; Clear H,L Registers to initialize Partial Product
MVI B,008h ; Iteration Count (8) to B Register
m88LOOP: DAD H ; Shift Partial Product left into Carry (H&L)
RAL ; Rotate Multiplier Bit to Carry
JNC m88NEXT ; Test Multiplier at Carry
DAD D ; Add Multiplicand to Partial Product (D&E)
; if Carry =1
ACI 000h ; (Add Carry Bit)
m88NEXT: DCR B ; Decrement Iteration Counter
JNZ m88LOOP ; Check Iterations
ret
Но вот правда же, была где-то страничка с хорошим сборником всевозможной арифметики для 8080.
правда я уже забыл откуда сам списал
Такая процедура (начиная с lxi h,0) есть в Vector-user 1. Только там в описании упущено, что AHL=A*DE. Если старший (третий) байт произведения не нужен, то можно убрать подхват переноса в A.
Если все же достаточно 8*8=16, то компактнее и быстрее (и без порчи A) так:
;HL=H*E
mul88:
mvi l,0
mov d,l
mvi b,8
mul88_1:
dad h
jnc mul88_2
dad d
mul88_2:
dcr b
jnz mul88_1
ret
Да, у меня 8х8. Отличный мул у тебя.
parallelno
04.09.2022, 12:32
Подскажите пожалуйста как включать квазидисковый режим Баркаря? Или он включается всегда если такой квазидиск используется?
компактнее и быстрее
Еще чуть компактнее и быстрее (портим A вместо B)
;HL=H*E
mul88:
xra a
mov l,a
mov d,a
cma
mul88_1:
dad h
jnc mul88_2
dad d
mul88_2:
add a
jm mul88_1
ret
Похоже на самое компактное умножение 8*8=16 для 8080. Или нет?
Про Баркаря можно почитать в журнале Радиолюбитель 95/11 (https://www.radioman-portal.ru/magazin/radiolubitel/1995/11.php)
- - - Добавлено - - -
Upd: И еще на 4 такта быстрее.
parallelno
04.09.2022, 22:04
Добавил раздел про работу с квазидиском.
- - - Добавлено - - -
Добавил раздел про тайминги команд.
Не могу найти подручного беззнакового умножения 8x8 -> 16. Ни у кого не завалялось?
Была у меня книжка: Злобин В. К., Григорьев В. Л. Программирование арифметических операций в микропроцессорах. М.:1991
В Сети скан находится без проблем. Сейчас посмотрел - есть несколько алгоритмов и для умножения 8x8->16 на ВМ80. Не было сейчас времени вникнуть, насколько они хороши, но может на будущее пригодится...
есть несколько алгоритмов и для умножения 8x8->16 на ВМ80
Программа 2.5 самая компактная, но, понятно, и очень медленная при больших значениях A. Программа 2.6 опять хорошо подходит для не самых больших значений A, когда много старших бит=0. И там есть Программа 2.7 (которая в Vector-user 1) с полным правильным описанием.
Иногда надо маленький диапазон псевдослучайности -- 11-битный LFSR:
; выход:
; HL - число от 1 до 2047
rnd11:
lxi h,1
mov a, h
rrc \ rrc
xra h
ani 1 ; bit 10 xor bit 8
dad h
ora l
mov l, a ; lsb = bits 10 xor 8
mvi a, 7
ana h
mov h, a
shld rnd11+1
ret
Сделал ему Мандрил-тест (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/2f87bd9056d2b93ea9367e7332b51a1c/raw/829f277b6f2f6f8ac4f3779c67852229cfbaf160/mandrill11.asm).
Конфигурация Галуа все же эффективнее Фибоначчи при программной реализации, даже в таком не очень удобном случае
rnd11:
lxi h,1
dad h
mvi a,1000b
ana h
jz rnd11exit
xra h
mov h,a
mvi a,5
xra l
mov l,a
rnd11exit:
shld rnd16_1+1
ret
Не помню, почему взял тот полином в rnd16, возможно чтобы картинка проявлялась помедленнее. Но скорее всего просто прошляпил. Если заменить mvi a,00000001b на mvi a,2Dh, то дальше можно убрать 3 команды относящиеся к h.
Добавил раздел про работу с квазидиском.
- - - Добавлено - - -
Добавил раздел про тайминги команд.
Ссылки которые содержат номер страницы - не работают, если у вас в настройках форума другой размер страницы.
Речь про ссылки вида
Самая быстрая установка палитры по версии Improver
https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere/page22.html#post1136855
parallelno
06.09.2022, 21:43
Ссылки которые содержат номер страницы - не работают, если у вас в настройках форума другой размер страницы.
Речь про ссылки вида
По идее не должно зависеть от формата страницы так как в линке id поста. Но кто знает как это на самом деле работает. Я поговорю с овнером форума. Спасибо что заметил.
svofski напомнил про LFSRного мандрила, и я подумал, что надо бы полнее раскрыть потенциал - даешь 16 цветов!
Два варианта:
bab16pix - медленный (10 секунд) пиксельный (можно немного быстрее, но я подумал, что лучше сохранить читаемость исходника)
bab16byt - быстрый (менее секунды) байтовый
Чтобы все уместилось в памяти уменьшил ширину картинки до 248 точек. Конверсия картинки оптимизирована для палитры emu. Надеюсь авторы и пользователи других эмуляторов меня простят, тем более можно сделать альтернативную конверсию или взять другую картинку. Еще можно упаковать и сделать rom. zx0 сжимает до 24 килобайт, rip до 23.5 (это без распаковщиков).
Полноцветные картинки на Векторе это приятно. То, что нет памяти под полную картинку -- это вот Вектор такой Вектор..
C дизером вряд ли много можно выгадать, пытаясь паковать слои по отдельности. Я так думаю, что zx0 тут чего-то вытягивает в основном благодаря насыщенной красноте носа.
Как тебе такая идея для байтового варианта: упаковать картинку не плашмя, а выбирая байты "по маршруту" LFSR. Распаковывать ее прямо на экран с тем же LFSR-ом. И эффект получится и место останется для чего-нибудь еще красивого.
- - - Добавлено - - -
Кстати как насчет ordered dither-а? Он не будет лучше zx0-иться?
parallelno
08.09.2022, 20:59
Как вариант можно распаковать на квазидиск и рисовать от туда.
Как тебе такая идея для байтового варианта: упаковать картинку не плашмя, а выбирая байты "по маршруту" LFSR. Распаковывать ее прямо на экран с тем же LFSR-ом. И эффект получится и место останется для чего-нибудь еще красивого.
Можно, но такое сжатие будет неэффективным, один байт в одном конце экрана, другой - в другом и между ними 0 корреляции.
Кстати как насчет ordered dither-а? Он не будет лучше zx0-иться?
Опять же, когда байты рядом, ordered должен быть лучше, а когда далеко - уже не уверен.
Есть компромисс - LFSRить и упаковать по блокам, типа как ты сделал недавно, только лучше квадратные сравнительно небольшие.
Меня нехватка 8 точек в ширину не сильно напрягает, это разве что в деме для голого вектора можно было бы попробовать удивить зрителей.
один байт в одном конце экрана, другой - в другом и между ними 0 корреляции
Да вот в случае рассеяной ошибки корреляция тоже только у нас в глазах. В Базыре хорошо видно -- нос и щеки еще туда-сюда, а так вообще там мало регулярности. Ну и картинки бывают разные, не все они про мандриллов. Не попробуешь - не узнаешь.
Нехватка 8 точек в ширину по-моему ничего страшного. Но если будет еще память, можно чего-нибудь добавить. Музон и все такое.
zx0ябельность разных дизеров все равно было бы интересно проверить, без LFSR-а тоже. У меня не хватает инструментария. Надизерить я могу, а разбить по плоскостям итд чтобы именно сравнить с твоим способом это запара.
А вот еще идея №2:
завернуть картинку с прогрессивной детализацией. Первый уровень 32х32, потом 64х64 (на каждый квадратик +3 субквадратика), потом 128х128, потом 256х256. Картинку надо заворачивать по пикселям. Кстати по пикселям корреляция может быть местами получше, чем по байтам. Будет медленно, но мы же любим смотреть, как компьютеру тяжело.
Долго тупил, не мог понять как у тебя получается такой непонятный размер файла. Потом дошло, что ты просто отрезал один столбец одного слоя. Допилил немного свои скрипты до еще одного формата и пошло-поехало..
Оказывается найти упорядоченную (порядочную!) дизерилку не так-то просто. Я надеялся на ImageMagick, но там чего-то всё совсем не то. Нашел вот такую:
https://seansleblanc.itch.io/ordered-dither-maker
Очень стильно выходит диагональный дизер: presets -> diagonals, steps 3 или 4, pixel scale 1.
Попробовал много разного
http://sensi.org/~svo/b/mandrill/dithers.zip
(Мандрила тоже пробовал, но он и так мандрил, кто его не видел).
Арзак единственный в этой коллекции с обычным Флойдом-Стейнбергом, но это потому что у него ручная штриховка.
Что до сжатия, жмется чуть чуть получше рассеянного дизера, зависит от картинки разумеется.
А вот еще идея №2:
завернуть картинку с прогрессивной детализацией. Первый уровень 32х32, потом 64х64 (на каждый квадратик +3 субквадратика), потом 128х128, потом 256х256. Картинку надо заворачивать по пикселям. Кстати по пикселям корреляция может быть местами получше, чем по байтам. Будет медленно, но мы же любим смотреть, как компьютеру тяжело.
Хм. Коды Адамара-Уолша по битпланам?
Хм. Коды Адамара-Уолша по битпланам?
Я первый раз про такие слышу. Может быть если бы я где-то нашел про них на уровне eli5, я смог бы прокомментировать. В том, что я предложил, никакой зауми нет.
Я первый раз про такие слышу. Может быть если бы я где-то нашел про них на уровне eli5, я смог бы прокомментировать. В том, что я предложил, никакой зауми нет.
Э, ну тут мне даже как-то неловко. Широкоизвестная вещь. https://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_%D0%A3% D0%BE%D0%BB%D1%88%D0%B0
по пикселям корреляция может быть местами получше, чем по байтам
Я бы даже сказал, что она практически везде лучше (как минимум не хуже), чем по байтам
Оказывается найти упорядоченную (порядочную!) дизерилку не так-то просто.
Мандрила я неупорядоченно дизернул этой утилитой (https://zx-pk.ru/threads/32400-dadither-eshche-odna-programka-dlya-dither-ga-kartinok.html?highlight=dadither). Твои примеры позже посмотрю.
завернуть картинку с прогрессивной детализацией
Над вейвлетами применительно к вектору я не думал, но почему бы и нет. Правда у меня нет серьезных планов по сжатию картинок, вроде и востребованности особой нет, всех более-менее устраивают имеющиеся решения.
Над вейвлетами применительно к вектору я не думал, но почему бы и нет. Правда у меня нет серьезных планов по сжатию картинок, вроде и востребованности особой нет, всех более-менее устраивают имеющиеся решения.
Это не столько ради сжатия, скорее ради эффекта проявления изображения. Если рандом, упаковать по маршруту, если прогрессивно, то и сохранять прогрессивно.
Но интерес обсуждать тут это у меня пару сообщений назад почему-то пропал.
Ordered дизерилку и твои примеры глянул. Признаюсь, что диагонального варианта до сих пор не видел, он своеобразный, возможно где-то подойдет для художественного эффекта. А в общем случае я все же за Байера.
Что касается проявления полноэкранной картинки, то есть еще варианты, например типастеганография. Если полутоновое изображение (для ч/б ТВ, с 16 оттенками) то можно саму программу скромно расположить в младшем бите изображения в уголке. Если подобрать картинку, то будет не очень заметно. С цветными сложнее, разве что очень повезет с картинкой и палитрой.
Ну и совсем дубовый вариант и тоже не всеподходящий. Программу максимально компактируем, рисуем напрямую там где не пересекаемся с кодом, а туда, где пересекаемся, в конце распаковываем остаток картинки.
Я не могу отдать предпочтение какому-то одному способу дизера на все случаи жизни. Но диагональный интересный. Напоминает журнальный принт, при этом прикольно выглядит даже при таком невысоком разрешении, особенно некоторые удачные сочетания цветов.
востребованности особой нет, всех более-менее устраивают имеющиеся решения
Это скорее непочатый край. Никто особенно и не думает -- покажу ка я Вектором картинку. Ну просто практическая ценность этого невелика из-за непропорциональности объема памяти. Если ты например делаешь демку и нарисовал к ней какой-нибудь графоний, получается, что у тебя вот и вся демка. Совместить упаковку и интересный эффект это одновременно и способ немножко сместить баланс памяти в чуть более выгодную сторону и прикрыть тормознутость чем-то, на что может быть интересно смотреть, особенно если жужжит ви53 и все вокруг кричат амига.
Вот например, очень часто встречающийся эффект -- большая картинка, то есть высотой больше одного экрана, вертикально скроллится. Отличный кейс для вертикального скролла и распаковки на лету. Правда из-за столбцовой организации памяти не получится пользоваться самой картинкой как буфером, это вот очень жаль.
Зато мы можем сделать 128 (32*4) параллельных dzx0 с буферами прямо на скроллящемся экране. Эх, не ту вещь я назвал гигачадом.
- - - Добавлено - - -
Мандрила я неупорядоченно дизернул этой утилитой.
Да, я тоже пробовал этой сначала. Прикольно, что есть заточка на специфические палитры и компы и даже Вектор не забыт. Я пытался загрузить твою палитру, но чего-то не задалось. Кроме того там пока нету упорядоченных дизеров, надеюсь еще будут. Пока мне проще довести картинку до требуемого пиксельформата в IrfanView, сохранить в png и остальное уже сконвертить скриптом. Не знаю, чем ты получал свой pic и pal, но подозреваю, что тоже какой-то самодельной штукой.
Это скорее непочатый край.
Да, я скорее о малой востребованности, а не о наличии очень хороших упаковщиков/распаковщиков картинок для вектора, которые окончательно закрывают этот вопрос.
Кстати про байты vs пиксели. Количественно можно оценить сжав для сравнения bmp - он сжимается лучше и zx0 и особенно ripом. А если еще порядок обхода сменить с построчного на поблочный, то будет еще лучше.
Насчет прогрессивной детализации самый простой и приземленный вариант мне видится так - делим картинку на четные и нечетные столбцы. Четные пакуем, нечетные можно не паковать. Выводим нечетные, потом на их место распаковываем четные и тоже выводим. Полета фантазии тут нет, но схема рабочая.
Гигачад128 даже немного пугает, я бы пожалуй в описанном случае предпочел (для простоты) построчную распаковку в буфер.
- - - Добавлено - - -
чем ты получал свой pic и pal, но подозреваю, что тоже какой-то самодельной штукой.
Да, состряпал преобразование rmb->pic, а pal - это просто первые 16 байт rmb. DaDither хорошая утилита, но там, кончено не все есть. Привлекает простота использования, а то мне не очень хотелось сдувать пыль со своих старых матлабовских дизерилок, вспоминать как ими пользоваться и подбирать параметры.
Из всего озвученного, как ни странно, гигачад128 это чуть ли не самое простое, потому что по сути надо просто изменить параметр n_tasks и прописать адрес первого буфера $8000. Процедуру записи в AY можно оставить для устрашения :)
Четные пакуем, нечетные можно не паковать. Выводим нечетные, потом на их место распаковываем четные и тоже выводим.
Это конечно же способ. Не знаю насчет зрелищности, но наверное с минимумом накладных расходов.
Про байты vs пиксели: твой пример с проявлением мандрила по пикселям можно считать потолком пиксельной производительности. Там можно оптимизировать итд, но любой алгоритм себе потребует еще больше, так что для оценки норм.
твой пример с проявлением мандрила по пикселям можно считать потолком пиксельной производительности
Увы, но скорее всего это так, сделать быстрее 10 секунд сложно. Для сравнения мой старый выводильщик bmp полноэкранную картинку выводит за 13 секунд.
Так к слову сказать, полноэкранная цветная картинка с половинным горизонтальным разрешением может смотреться вполне себе очень даже. На C64 "multicolor bitmap mode" тому пример.
Можно вспомнить и более близкий пример - роббо sunami с атариевской графикой. Кроме нижней строки статуса все в половинном разрешении, смотрится и на векторе нормально. Для полного счастья не хватает только такого аппаратного режима графики, чтобы памяти в 2 раза меньше занимал.
Раз уж атари, то всегда вспоминается Montezuma's Revenge. Знаю знаю, Амбал очень крут и я согласен. Но он не играет кукарачу и вот как-то не то.
- - - Добавлено - - -
Еще один дизерятник, тоже со своими забавными пресетами, но не поддерживает диагоналей: https://doodad.dev/dither-me-this/
Конверсия картинки оптимизирована для палитры emu. Надеюсь авторы и пользователи других эмуляторов меня простят
А под какой aspect ratio сделана картинка, можно поинтересоваться?
PAR вектора я в данном случае не учитывал (при конверсии PAR был принят=1:1).
старый выводильщик bmp полноэкранную картинку выводит за 13 секунд
Эта цифра мне не понравилась, сделал более быстрый выводильщик - полноэкранный bmp за 3 с половиной секунды (попиксельный вывод заменил на табличнобайтовый). Но надо 1 килобайт под таблицу.
Зачем за 13, если можно за 20?
http://sensi.org/~svo/b/mandrill/fille-diag.rom
http://sensi.org/~svo/b/mandrill/lena-diag.rom
Тут совсем без оптимизаций. И так путаница. Переделывать dzx0 на нормальные вызовы мне хронически лень, поэтому для картинки получился очередной гигачад, правда попроще, потому что он один.
Картинки получаются процентов на 15-20 больше порождающего PNG. Если не полениться, можно было бы подобрать две картинки в один 32к ром с музыкой (в картинках дизера поменьше, музыка покороче). Мегадемо практически.
Здорово, мне весьма понравилось! И ведь в принципе все это было возможно уже в 88 году.
И ведь в принципе все это было возможно уже в 88 году.
Графика все же страшно тормозит, но музыка все меняет (да простят меня авторы оригинальных композиций). Наверное сочетание звука и графики перегружают обычный барьер индифферентности и начинает казаться, что это что-то такое ух. Гештальт. Или синкопа.
Все же в 88 такое сделать было непросто.
Все же в 88 такое сделать было непросто.
Музыки для AY тогда конечно было намного меньше и она была попроще. Не было такого упаковщика/распаковщика, но опять же можно было написать что-нибудь простое или адаптировать из cp/m. И графику можно было конверснуть (да, надо найти графику и конвертилку, или написать конвертилку). Очень нужна была нормальная кросс-машина, на самом векторе долго и сложно.
Полноцветные картинки были, по-моему в основном в виде слайдшоу, может быть со скроллером. Клоуны и девушки, почему-то такое сочетание. Правда скорее в 98, чем в 88, и понятно, что это все уже стало просачиваться с писишек. А в 88 даже на писишке было трудно найти клоуна и девушку (хотя помню какие-то чудеса под CGA на бейсике). Ладно, к программированию это мало отношения имеет.
С этим примером я наверное успокоюсь, когда смогу запихать две картинки в один ром. Или найдя музон покороче, или задизерив картинку потуже. Так-то с ним делать особо нечего.
Да, но вот все-таки сделать поточный dzx0, в котором getbyte не был бы как штаны через голову надевать, это много где могло бы пригодиться по-моему.
две картинки в один ром
Я бы пошел по легкому пути - или 8 цветов или не на полный экран.
Я бы пошел по легкому пути - или 8 цветов или не на полный экран.
Компрессия расширяет тут возможности -- если фон однотонный, он очень хорошо уходит в ничто. Обрезать края -- это практически то же самое. Что до цветов -- у меня сохранение попиксельное -- по два пикселя на байт. Уменьшать количество цветов это хорошо если по слоям.
Цвета можно и без слоев уменьшить, хотя и не очень удобно. Один поток - двухбитный (4 точки в байте), второй - однобитный (8 точек в байте).
Цвета можно и без слоев уменьшить, хотя и не очень удобно. Один поток - двухбитный (4 точки в байте), второй - однобитный (8 точек в байте).
Ну не, хватит мне тут потоков и так =) Не хочешь сделать "прямой" dzx0?
Что нужно спрямить в dzx0? Ты писал (https://zx-pk.ru/threads/34480-programmirovanie.html?p=1162829&viewfull=1#post1162829) про поточный, но я не совсем понял, ты же уже сделал поточный и я там какие-то мелочи дошлифовывал.
Что нужно спрямить в dzx0?
Сейчас dzx0 -- это от начала до конца один цикл. Если я хочу что-то делать с данными по частям, то есть пока этот цикл не завершился, мне приходится встревать в него разными зверскими способами.
Было бы удобно, если бы дополнительно существовал вариант dzx0, который устроен так, что можно вызывать из основной программы типа "call dzx0_stream_getbyte" когда надо. А он бы внутри себя декодировал очередную порцию по мере надобности. В картинках у меня сейчас именно так и сделано, но методом выворачивания цикла наизнанку. Почти так же, как в гигачаде, но попроще, потому что один поток. У этого есть недостатки -- плохая читаемость, необходимость запрещать прерывания пока стеки подменяются, оверхед на все это тоже может быть больше, чем если бы был прямой вызов.
Предполагаемый API такой:
dzx0_stream_init: -- инициализация: d=адрес откуда читаем, b=адрес буфера
dzx0_stream_getbyte: -- очередной байт (допустим Carry=1, если конец потока)
dzx0_stream_getbyte внутри себя вызывает dzx0_decode_chunk, когда исчерпываются данные в буфере
Все это разумеется применимо только к варианту с ограниченным размером буфера. 256 показал себя хорошо.
d=адрес откуда читаем
de?
Побайтно можно, но сравнительно неэффективно. Может по 256 байт?
de?
Побайтно можно, но сравнительно неэффективно. Может по 256 байт?
de, bc (хотя bc будет выровнен по 256)
Алгоритм внутри себя будет декодировать порциями в любом случае. Можно сделать фиксированный размер порции 256 байт. getbyte в обычном случае будет просто брать очередной байт из циклического буфера, если данные уже декодированы, и обращаться к алгоритму за очередной порцией когда буфер истощен.
Для смелых пользователей, кому важна эффективность и не хочется вызывать getbyte для каждого байта, останется возможность вызывать dzx0_decode_chunk напрямую.
256 байт хороший размер с точки зрения эффективности. Но чтобы не блокировать исполнение юзерского когда слишком на долго, хорошо иметь возможность рулить размером порции. Можно условной компиляцией 16/256, например. Или вообще по размеру порции в LDIR-е, правда это усложнит getbyte.
Пока для пробы сделал распаковщик чанками по 256 байт. GetByte можно сделать внешним, как с файловыми буферами: берем байт из буфера, если буфер пуст - распаковываем следующий чанк.
lxi b,dzx0_Buffer
;DE - откуда
;HL - куда
;BC - буфер
MovLoop2:
push h
call dzx0
pop h
jnc LastMov
MovLoop1:
ldax b
mov m,a
inr c
inx h
jnz MovLoop1
jmp MovLoop2
LastMov:
inr c
dcr c
jz Start
mov e,c
mvi c,0
LastMov1:
ldax b
mov m,a
inr c
inx h
dcr e
jnz LastMov1
jz Start
Забыл в файле написать - на выходе из dzx0
CY=0 - закончили распаковку
CY=1 - еще не закончили
- - - Добавлено - - -
Отмечу, что учитывая самомодификацию распаковщик однопоточный.
- - - Добавлено - - -
Один чанк распаковывается в среднем за 35000-45000 тактов. Крайние значения, которые видел - от 20000 до 50000 тактов.
Upd 18.09.2022: Примерно на 3% быстрее, сохраняет BC между распаковкой чанков (если убрать сохранение BC, то будет на 7 байт короче).
ivagor, спасибо! Попробовал, работает. Для моего случая годно. По-моему backwards тут не имеет смысла, под себя заменил макросы, потому что prettyasm в них не умеет. Ко всем меткам приставил stream_, чтобы не было конфликтов. А зачем нужна часть, которая подменяет точку входа, почему не просто отдельно инициализация и отдельно распаковка?
Ну что, на этом можно и успокоиться, правда 144 байта еще осталось http://sensi.org/~svo/b/mandrill/progdemo.rom
Ты опять сумел удивить, три картинки (пусть и не полноэкранных)! И музычка хорошо подобрана.
А зачем нужна часть, которая подменяет точку входа, почему не просто отдельно инициализация и отдельно распаковка?
Личное предпочтение, чтобы упростить вызов. Понятно, что это можно вынести наружу, возможно для гитхаба я так и сделаю, надо еще подумать.
Насчет размера чанков. Степени двойки (2-128) можно получить добавив по паре команд перед jnz dzx0_ldir1_3 и jnz dzx0_ldir2_3
mvi a,Mask
ana c
Mask=(16-1) для 16 и т.д.
- - - Добавлено - - -
Ну и для простоты лучше сжимать файлы с размером кратным чанку, тогда хвосты не надо отдельно обрабатывать.
Да ладно, тут я всего-то взял все твои штуки и склеил в одну. Работа редакторская -- подпилить музон под ви53 (vt2 гениальная штука, можно редактировать в vim-е, как нормальный человек), подобрать дизер. А, ну правда тормозная прогрессивная загрузка -- это мое. Надо бы что ли задержку небольшую между картинками вставить.
Про способ вызова -- я быстро адаптировался, потому что сейчас в теме. Но так с ходу это может показаться непонятным.
Размеры чанков 16/256 у меня так и были сделаны. Сейчас, когда декодер не запрещает прерывания, для этой конкретно демы это стало не нужно. Но возможность управлять размером чанка иметь хорошо -- будет другая ситуация, где все будет наоборот.
Немного ускорил вывод и замедлил промежутки между картинками. Выкладываю как есть.
https://github.com/svofski/v06c-progdemo
http://sensi.org/scalar/ware/920
Upd: Забил буфера львом.
rom целиком с -w256 сжимается до 26 с половиной килобайт. Мне кажется, что некоторые резервы есть, пусть и не на 6 килобайт.
- - - Добавлено - - -
Часть ответа нашел. При -w256 сильно ухудшается эффективность сжатия последовательностей одинаковых байт (по крайней мере для absinthe-diag и fille-diag), увеличение хотя бы до -w512 заметно улучшает ситуацию. Альтернативный вариант - обрезать пустоту по бокам и сжать без нее.
BlaireCas
17.09.2022, 12:42
Выкладываю как есть.
Посмотрел на эмуляторе. Красиво смотрится и музыка радует. Зачотно. Даже напомнило времена когда джипеги на диалапе загружались подобным образом (понемногу улучшая видимость).
Примерно 4К этого резерва -- это буфера гигачада, которые тут оказываются посередине файла -- можно без особых дополнительных ухищрений впихнуть в них одноразовую заставку, которая будет показываться один раз при запуске, потом затираться. Надо придумать, чего бы можно было туда втиснуть. Тигрлев в джунглях Руссо мне нравится, может быть если обрезать джунгли немного и уменьшить, он поместится.
Картинку произвольного размера было бы прикольно уметь. Может быть не для этой демки, а для вообще реюзабельности для чего-нибудь еще. Подумал типа кому нафик нужны такие тормозные картинки 7 Но если они будут маленькими врезками 64х64 или около того, они будут совсем не такие тормозные и это могло бы для чего-нибудь прийтись и кстати.
- - - Добавлено - - -
музыка радует
Это респект музыкантам (https://zxart.ee/spa/autores/s/spark/monty2/).
Примерно 4К этого резерва -- это буфера гигачада
Здесь хватит 11*256=2816 байт (6 - частоты, 1 - микшер, 1 - старший байт огибающей, 3 - громкости), т.е. еще килобайт резерва.
- - - Добавлено - - -
Все же на громкости 3 байта в данном случае расточительство, можно свести в 1 байт. Или даже приплюсовать к микшеру вместо шума.
ivagor, сейчас остается возможность одним движением включить AY, если вдруг захочется (хотя музон немного пережеван для ви53, но совсем чуть-чуть, не так сильно, чтобы совсем испортиться). Или даже сделать неприятный хорус (tm).
Если оставить возможность перенаправить на AY, то есть еще вариант. Композиция довольно компактная, думаю если пережать с -w128 она не сильно увеличится, а буферы сразу в 2 раза меньше.
Кстати, некоторое время пользуюсь сальвадором 1.40, он иногда на 1-2 байта лучше сжимает, мелочь, а приятно.
ivagor, забил буфера львом (вдавил). Пока я об эту демку достаточно потешился, но ты добро пожаловать ускорять, ужимать и добавлять еще конечно ;)
Ссылки те же.
Мне пришлось бы приложить немало усилий, чтобы откомпилировать эту дему, но в принципе потенциал развития есть, тема интересная.
- - - Добавлено - - -
На примере льва хорошо видно, что ограничение размера картинки еще и сильно ускорило бы.
Да, там занудненько так распаковывается и рисуется много-много черных пикселей. Но добавление еще и размера картинки -- это непомерное, непосильное усложнение.
Собрать проще, чем ты думаешь. У тебя python3 стоит? Виндовый.
pip3 install pypng lhafile -- это все зависимости
winbuild.bat
[здесь был первый черновик winbuild.bat, который сейчас в репе (https://github.com/svofski/v06c-progdemo/)]
Ассемблер ты все равно будешь пользовать tasm, поэтому тут про него ничего нет. Для конверсии льва в db у тебя тоже наверняка есть любимый инструмент. Ну или можно исхитриться и обойтись тем же copy/b, но там надо аккуратно подогнать выравнивание, чтобы основной блок картинок не затерся буферами.
Сходу тасм не откомпилирует, надо немного править. Но это не важно, дема интересная и вдохновляющая, появились новые идеи.
Сходу тасм не откомпилирует, надо немного править. Но это не важно, дема интересная и вдохновляющая, появились новые идеи.
Это главное. Но я все равно немного доделываю скрипты, чтобы упростить батник и обойтись без xxd/awk. Вдруг пригодится.
ivagor, залил версию, собирающуюся tasm-ом вместе с проверенным батничком winbuild.bat
(ох и цаца этот ваш тасм, строчки ему длинные..)
P.S. пустился во все тяжкие и сделал поддержку обрезанных картинок. Ширина должна быть кратна 16, высота кратна 8. Ссылки все те же.
Ну ты крутой. Под влиянием положительного примера постарался проявить сознательность и убрал тупизну из чанкового распаковщика (https://zx-pk.ru/threads/34480-programmirovanie.html?p=1162868&viewfull=1#post1162868), стало немного лучше.
Присовокупил dzx0v2, работает, все обновил-перезалил. 3% из одного только распаковщика на глаз конечно не заметишь, но все вместе бесспорно стало как-то бодрее и веселее.
Кстати там просто прорва неиспользованных байт -- 256 это буфер dzx0, который может быть использован один раз при запуске, и 443 в конце. Ну и это без учета того, что это даже не r0m.
- - - Добавлено - - -
P.S. не учел, что bc теперь можно не сохранять, но один раз на 256 байт это совсем не критично.
- - - Добавлено - - -
P.P.S. если убрать push / pop b из picstream_fetch, к концу стрима что-то не так заворачивается. Лень разбираться, пока оставил push/pop, даром, что это ни на что не влияет.
Поздравляю, ты заставил меня откомпилировать прогдему :)
При выходе из dzx0 между чанками c=0, а в последний раз c=индекс последнего байта в буфере+1. Можно убрать push b и pop b из picstream_fetch, если добавить перед picstream_gb_L1 mvi c,0
Поздравляю, ты заставил меня откомпилировать прогдему
Вот это настоящее событие! :)
Надеюсь это была самая последняя версия с уже вставленным новым dzx0v2.
Оставалось немного места и я заполнил его setpixelями. Выигрыш от 2 до 3.5%
- - - Добавлено - - -
Upd: 4-5.5%
BlaireCas
18.09.2022, 16:36
Кажется побыстрее стало (субъективно конечно, там нет ведь замеров скорости.. ну и добавилась картинка какого-то кошака вначале). А это будет демка такая?
BlaireCas, это уже как бы демка такая спонтанно самообразовавшаяся. Не всем демкам суждено звать себя продами и релизами. Бывают же и просто сны (tm). Кошак, кстати, это деталь из "Сна" Анри Руссо ;)
ivagor, спасибо, я попозже сегодня посмотрю и соберу.
Оставалось немного места и я заполнил его setpixelями. Выигрыш от 2 до 3.5%
Upd: 4-5.5%
Стало прям летать бешено круто. Всё перезалил.
Хорошо бы придумать что-то побыстрее, но для вывода отдельных цветных точек это пока похоже на предел (или близко к нему). "Медленный вектор" и все такое.
Все здорово, но желательно бы доработать очистку экрана:
1. Или гасить палитру, потом стирать, потом новая палитра
2. Или очищать как-нибудь не по порядку адресов. По строкам, или чересстрочно и потом навстречу или спиралью и т.п.
- - - Добавлено - - -
Кстати, можно очищать и LFSRом по точкам
LFSR-ом по байтам лучше. И не совсем резко и не надо ждать полчаса. Еще можно фейдить палитру в черное.
Upd: сделал через три строки, получилось просто и симпатично.
По моему впечатлению так лучше.
Что касается предельности сетпикселя. Не обязательно пытаться прошибить лбом этот порог, можно обойти. Нам известна вся картинка, поэтому можно кодировать не абсолютные значения точек, а изменения относительно уже имеющегося в данной позиции цвета. Ускорение за счет того что:
1. Не будет спарок ora c\ xra c, максимум xra c
2. Можно пропускать неизменные плоскости (это главный выигрыш)
Вопрос в том, сожмется ли такой вариант не хуже абсолютного.
Если записывать значение, с которым надо поксорить чтобы получить очередной пиксель, это может получиться. Предсказать про сжатие не могу, но есть опасение, что будет сжиматься заметно хуже.
Опасение подтвердилось, сжимается заметно хуже.
- - - Добавлено - - -
Но я все-таки смог срезать 4 такта на setpixel1 :)
parallelno
20.09.2022, 02:25
А если картинки сжимать не по пикселям, а по байтам будет хуже сжиматься?
Как известно, одна голова - хорошо, а две - некрасиво. Зато есть эффект.
setpixel1:
push d
rrc \ rrc \ rrc
mov b, a ; b = saved a, c free
ani 11110b
sta setpixel1setjmp+1
mov a, e
sub m
mov e, a ; update pixel addr
inx h ; hl -> pixel mask
mov c, m ; c = set mask
inx h ; hl -> next in tile sequence
push h ; save hl
setpixel1setjmp:
lhld setpixel1tab
ldax d
ora c
pchl
- - - Добавлено - - -
Если поменять знак у смещений возьмужек, то еще -4 такта за счет замены
mov a,e
sub m
на
mov a,m
add e
parallelno, картинки заворачиваются в прогрессивную последовательность пикселей-полубайт. Полубайты объединяются в байты, а байты уже потом сжимаются.
parallelno
20.09.2022, 20:47
svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?
Байты битпланов сжимаются хуже, чем байты с парами пикселей.
Что касается сжатия pic2.pic
w256 - 23620
w512 - 22705
w1024 - 21265
w2048 - 20780
Видно, что до 1024 включительно выигрыш от сжатия растет быстрее, чем пенальти от увеличения буфера. Распаковка и getbyte конечно будут медленнее, но если расположить буфер впритык к 8000h, то не сильно медленнее (проверяем знак). Надо ли это делать - не уверен, но если что - резерв по сжатию есть.
svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?
Значит я не понял твоего вопроса. Что значит сжимать побайтово? С моей точки зрения все уже и так сжимается побайтово.
- - - Добавлено - - -
Надо ли это делать - не уверен, но если что - резерв по сжатию есть.
256 все-таки хороший компромисс. Но если dzx0 в принципе через условную компиляцию будет поддерживать разные размеры буферов -- это дело хорошее. Не только ведь картинки сжимать, и не только прогрессивные и не только полноцветные. А если чисто для этой демки, смысла нет, тут уж получилось что получилось по-моему.
parallelno
21.09.2022, 02:43
svofski, я имел ввиду данные картинки в том виде в котором она лежит в видеопамяти сжать как линейный кусок памяти от $8000 до $ffff.
- - - Updated - - -
ivagor уже ответил что так хуже сжимается.
parallelno, понятно. Да, так хуже. Кроме того тут не только упаковка, но и эффект.
Обновил все файлы с последними мегаспидапами от ivagor-a. Тут конечно можно разворачивать циклы и все такое, но заметного прироста это не дает.
Мозолят глаз всевозможные push-pop-ы, но я думаю это все от лукавого. Без них только если совсем радикально как-то все менять.
CodeMaster
21.09.2022, 08:11
svofski и ivagor, вопрос не по теме как таковой, т.к. я далёк и от железа и от математики, но вы сейчас тут походу одни кто считает такты ;-) Если представить гипотетический однотактовый процессор, которую любую арифметическую и логическую операцию над 1-2 байтами выполняет за 1 такт, а над последовательностью байт за количество байт тактов. То вся ваша аппаратная оптимизация потеряет смысл и перейдёт в плоскость математической оптимизации?
Насчет терминов - я бы все же назвал эти два аспекта "оптимизация реализации" и "оптимизация алгоритма". Оптимизация реализации имеет смысл и для RISC-подобного конвеерного процессора. Пусть базовые команды выполняются в идеале за такт, но с учетом конвеера там возникают конфликты по доступу к исполнительным устройствам. И даже без конфликтов конвеера (или для гипотетического неконвеерного процессора) выбор конкретных команд важен (смотря еще какие команды). Ну а оптимизация алгоритма, или выбор более удачного алгоритма - это как правило более действенное средство, если такие алгоритмы существуют или их можно разработать.
CodeMaster
21.09.2022, 09:16
Оптимизация реализации имеет смысл и для RISC-подобного конвеерного процессора.
Я про гипотетический процессор, где любая команда выполняется за так, без всяких конвейеров.
parallelno
21.10.2022, 08:52
Хочу порекомендовать Retro assembler. Очень много возможностей, встраивается как плагин в VS Code.
https://enginedesigns.net/retroassembler/
Документация
https://enginedesigns.net/download/retroassembler.html
Проект GameNoname написан на нем. Если есть желающие могу рассказать подробнее как и что в нем есть.
Посмотрел слегка. Не увидел IRP/IRPC... грустно.( У меня был проектик в начале 2000-х, 36000 строк, на m80 (1981г!) под CP/M небезизвестного Б.Гейтса. Попытки перевести на что то более другое (современное) не возымели успеха! Многие вообще сыпались на таком объёме (Zilog в т.ч.), у многих не хватало требуемых директив... В общем, забил и успокоился.(
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot