Если все же достаточно 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=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. Отличный мул у тебя.
Подскажите пожалуйста как включать квазидисковый режим Баркаря? Или он включается всегда если такой квазидиск используется?
Еще чуть компактнее и быстрее (портим A вместо B)Цитата:
Сообщение от ivagor
Скрытый текст
Код:;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
- - - Добавлено - - -
Upd: И еще на 4 такта быстрее.
Добавил раздел про работу с квазидиском.
- - - Добавлено - - -
Добавил раздел про тайминги команд.
Была у меня книжка: Злобин В. К., Григорьев В. Л. Программирование арифметических операций в микропроцессорах. М.:1991Цитата:
Сообщение от svofski
В Сети скан находится без проблем. Сейчас посмотрел - есть несколько алгоритмов и для умножения 8x8->16 на ВМ80. Не было сейчас времени вникнуть, насколько они хороши, но может на будущее пригодится...
Программа 2.5 самая компактная, но, понятно, и очень медленная при больших значениях A. Программа 2.6 опять хорошо подходит для не самых больших значений A, когда много старших бит=0. И там есть Программа 2.7 (которая в Vector-user 1) с полным правильным описанием.Цитата:
Сообщение от Pyk
Иногда надо маленький диапазон псевдослучайности -- 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
Конфигурация Галуа все же эффективнее Фибоначчи при программной реализации, даже в таком не очень удобном случае
Скрытый текст
Код: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.
Ссылки которые содержат номер страницы - не работают, если у вас в настройках форума другой размер страницы.Цитата:
Сообщение от parallelno
Речь про ссылки вида
Цитата:
Самая быстрая установка палитры по версии Improver
https://zx-pk.ru/threads/29144-progr...ml#post1136855
По идее не должно зависеть от формата страницы так как в линке id поста. Но кто знает как это на самом деле работает. Я поговорю с овнером форума. Спасибо что заметил.Цитата:
Сообщение от nzeemin
svofski напомнил про LFSRного мандрила, и я подумал, что надо бы полнее раскрыть потенциал - даешь 16 цветов!
Два варианта:
bab16pix - медленный (10 секунд) пиксельный (можно немного быстрее, но я подумал, что лучше сохранить читаемость исходника)
bab16byt - быстрый (менее секунды) байтовый
Чтобы все уместилось в памяти уменьшил ширину картинки до 248 точек. Конверсия картинки оптимизирована для палитры emu. Надеюсь авторы и пользователи других эмуляторов меня простят, тем более можно сделать альтернативную конверсию или взять другую картинку. Еще можно упаковать и сделать rom. zx0 сжимает до 24 килобайт, rip до 23.5 (это без распаковщиков).
Полноцветные картинки на Векторе это приятно. То, что нет памяти под полную картинку -- это вот Вектор такой Вектор..
C дизером вряд ли много можно выгадать, пытаясь паковать слои по отдельности. Я так думаю, что zx0 тут чего-то вытягивает в основном благодаря насыщенной красноте носа.
Как тебе такая идея для байтового варианта: упаковать картинку не плашмя, а выбирая байты "по маршруту" LFSR. Распаковывать ее прямо на экран с тем же LFSR-ом. И эффект получится и место останется для чего-нибудь еще красивого.
- - - Добавлено - - -
Кстати как насчет ordered dither-а? Он не будет лучше zx0-иться?
Как вариант можно распаковать на квазидиск и рисовать от туда.
Можно, но такое сжатие будет неэффективным, один байт в одном конце экрана, другой - в другом и между ними 0 корреляции.Цитата:
Сообщение от svofski
Опять же, когда байты рядом, ordered должен быть лучше, а когда далеко - уже не уверен.Цитата:
Сообщение от svofski
Есть компромисс - LFSRить и упаковать по блокам, типа как ты сделал недавно, только лучше квадратные сравнительно небольшие.
Меня нехватка 8 точек в ширину не сильно напрягает, это разве что в деме для голого вектора можно было бы попробовать удивить зрителей.
Да вот в случае рассеяной ошибки корреляция тоже только у нас в глазах. В Базыре хорошо видно -- нос и щеки еще туда-сюда, а так вообще там мало регулярности. Ну и картинки бывают разные, не все они про мандриллов. Не попробуешь - не узнаешь.Цитата:
Сообщение от ivagor
Нехватка 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
(Мандрила тоже пробовал, но он и так мандрил, кто его не видел).
Арзак единственный в этой коллекции с обычным Флойдом-Стейнбергом, но это потому что у него ручная штриховка.
Что до сжатия, жмется чуть чуть получше рассеянного дизера, зависит от картинки разумеется.
Хм. Коды Адамара-Уолша по битпланам?Цитата:
Сообщение от svofski
Я первый раз про такие слышу. Может быть если бы я где-то нашел про них на уровне eli5, я смог бы прокомментировать. В том, что я предложил, никакой зауми нет.Цитата:
Сообщение от Sandro
Э, ну тут мне даже как-то неловко. Широкоизвестная вещь. https://ru.wikipedia.org/wiki/%D0%A4...BB%D1%88%D0%B0Цитата:
Сообщение от svofski
Я бы даже сказал, что она практически везде лучше (как минимум не хуже), чем по байтамЦитата:
Сообщение от svofski
Мандрила я неупорядоченно дизернул этой утилитой. Твои примеры позже посмотрю.Цитата:
Сообщение от svofski
Над вейвлетами применительно к вектору я не думал, но почему бы и нет. Правда у меня нет серьезных планов по сжатию картинок, вроде и востребованности особой нет, всех более-менее устраивают имеющиеся решения.Цитата:
Сообщение от svofski
Это не столько ради сжатия, скорее ради эффекта проявления изображения. Если рандом, упаковать по маршруту, если прогрессивно, то и сохранять прогрессивно.Цитата:
Сообщение от ivagor
Но интерес обсуждать тут это у меня пару сообщений назад почему-то пропал.
Ordered дизерилку и твои примеры глянул. Признаюсь, что диагонального варианта до сих пор не видел, он своеобразный, возможно где-то подойдет для художественного эффекта. А в общем случае я все же за Байера.
Что касается проявления полноэкранной картинки, то есть еще варианты, например типастеганография. Если полутоновое изображение (для ч/б ТВ, с 16 оттенками) то можно саму программу скромно расположить в младшем бите изображения в уголке. Если подобрать картинку, то будет не очень заметно. С цветными сложнее, разве что очень повезет с картинкой и палитрой.
Ну и совсем дубовый вариант и тоже не всеподходящий. Программу максимально компактируем, рисуем напрямую там где не пересекаемся с кодом, а туда, где пересекаемся, в конце распаковываем остаток картинки.
Я не могу отдать предпочтение какому-то одному способу дизера на все случаи жизни. Но диагональный интересный. Напоминает журнальный принт, при этом прикольно выглядит даже при таком невысоком разрешении, особенно некоторые удачные сочетания цветов.
Это скорее непочатый край. Никто особенно и не думает -- покажу ка я Вектором картинку. Ну просто практическая ценность этого невелика из-за непропорциональности объема памяти. Если ты например делаешь демку и нарисовал к ней какой-нибудь графоний, получается, что у тебя вот и вся демка. Совместить упаковку и интересный эффект это одновременно и способ немножко сместить баланс памяти в чуть более выгодную сторону и прикрыть тормознутость чем-то, на что может быть интересно смотреть, особенно если жужжит ви53 и все вокруг кричат амига.Цитата:
Сообщение от ivagor
Вот например, очень часто встречающийся эффект -- большая картинка, то есть высотой больше одного экрана, вертикально скроллится. Отличный кейс для вертикального скролла и распаковки на лету. Правда из-за столбцовой организации памяти не получится пользоваться самой картинкой как буфером, это вот очень жаль.
Зато мы можем сделать 128 (32*4) параллельных dzx0 с буферами прямо на скроллящемся экране. Эх, не ту вещь я назвал гигачадом.
- - - Добавлено - - -
Да, я тоже пробовал этой сначала. Прикольно, что есть заточка на специфические палитры и компы и даже Вектор не забыт. Я пытался загрузить твою палитру, но чего-то не задалось. Кроме того там пока нету упорядоченных дизеров, надеюсь еще будут. Пока мне проще довести картинку до требуемого пиксельформата в IrfanView, сохранить в png и остальное уже сконвертить скриптом. Не знаю, чем ты получал свой pic и pal, но подозреваю, что тоже какой-то самодельной штукой.Цитата:
Сообщение от ivagor
Да, я скорее о малой востребованности, а не о наличии очень хороших упаковщиков/распаковщиков картинок для вектора, которые окончательно закрывают этот вопрос.Цитата:
Сообщение от svofski
Кстати про байты vs пиксели. Количественно можно оценить сжав для сравнения bmp - он сжимается лучше и zx0 и особенно ripом. А если еще порядок обхода сменить с построчного на поблочный, то будет еще лучше.
Насчет прогрессивной детализации самый простой и приземленный вариант мне видится так - делим картинку на четные и нечетные столбцы. Четные пакуем, нечетные можно не паковать. Выводим нечетные, потом на их место распаковываем четные и тоже выводим. Полета фантазии тут нет, но схема рабочая.
Гигачад128 даже немного пугает, я бы пожалуй в описанном случае предпочел (для простоты) построчную распаковку в буфер.
- - - Добавлено - - -
Да, состряпал преобразование rmb->pic, а pal - это просто первые 16 байт rmb. DaDither хорошая утилита, но там, кончено не все есть. Привлекает простота использования, а то мне не очень хотелось сдувать пыль со своих старых матлабовских дизерилок, вспоминать как ими пользоваться и подбирать параметры.Цитата:
Сообщение от svofski
Из всего озвученного, как ни странно, гигачад128 это чуть ли не самое простое, потому что по сути надо просто изменить параметр n_tasks и прописать адрес первого буфера $8000. Процедуру записи в AY можно оставить для устрашения :)
Это конечно же способ. Не знаю насчет зрелищности, но наверное с минимумом накладных расходов.Цитата:
Сообщение от ivagor
Про байты vs пиксели: твой пример с проявлением мандрила по пикселям можно считать потолком пиксельной производительности. Там можно оптимизировать итд, но любой алгоритм себе потребует еще больше, так что для оценки норм.
Увы, но скорее всего это так, сделать быстрее 10 секунд сложно. Для сравнения мой старый выводильщик bmp полноэкранную картинку выводит за 13 секунд.Цитата:
Сообщение от svofski
Так к слову сказать, полноэкранная цветная картинка с половинным горизонтальным разрешением может смотреться вполне себе очень даже. На C64 "multicolor bitmap mode" тому пример.
Можно вспомнить и более близкий пример - роббо sunami с атариевской графикой. Кроме нижней строки статуса все в половинном разрешении, смотрится и на векторе нормально. Для полного счастья не хватает только такого аппаратного режима графики, чтобы памяти в 2 раза меньше занимал.
Раз уж атари, то всегда вспоминается Montezuma's Revenge. Знаю знаю, Амбал очень крут и я согласен. Но он не играет кукарачу и вот как-то не то.
- - - Добавлено - - -
Еще один дизерятник, тоже со своими забавными пресетами, но не поддерживает диагоналей: https://doodad.dev/dither-me-this/
А под какой aspect ratio сделана картинка, можно поинтересоваться?Цитата:
Сообщение от ivagor
PAR вектора я в данном случае не учитывал (при конверсии PAR был принят=1:1).
Эта цифра мне не понравилась, сделал более быстрый выводильщик - полноэкранный bmp за 3 с половиной секунды (попиксельный вывод заменил на табличнобайтовый). Но надо 1 килобайт под таблицу.Цитата:
Сообщение от ivagor
Зачем за 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 году.
Графика все же страшно тормозит, но музыка все меняет (да простят меня авторы оригинальных композиций). Наверное сочетание звука и графики перегружают обычный барьер индифферентности и начинает казаться, что это что-то такое ух. Гештальт. Или синкопа.Цитата:
Сообщение от ivagor
Все же в 88 такое сделать было непросто.
Музыки для AY тогда конечно было намного меньше и она была попроще. Не было такого упаковщика/распаковщика, но опять же можно было написать что-нибудь простое или адаптировать из cp/m. И графику можно было конверснуть (да, надо найти графику и конвертилку, или написать конвертилку). Очень нужна была нормальная кросс-машина, на самом векторе долго и сложно.Цитата:
Сообщение от svofski
Полноцветные картинки были, по-моему в основном в виде слайдшоу, может быть со скроллером. Клоуны и девушки, почему-то такое сочетание. Правда скорее в 98, чем в 88, и понятно, что это все уже стало просачиваться с писишек. А в 88 даже на писишке было трудно найти клоуна и девушку (хотя помню какие-то чудеса под CGA на бейсике). Ладно, к программированию это мало отношения имеет.
С этим примером я наверное успокоюсь, когда смогу запихать две картинки в один ром. Или найдя музон покороче, или задизерив картинку потуже. Так-то с ним делать особо нечего.
Да, но вот все-таки сделать поточный dzx0, в котором getbyte не был бы как штаны через голову надевать, это много где могло бы пригодиться по-моему.
Я бы пошел по легкому пути - или 8 цветов или не на полный экран.Цитата:
Сообщение от svofski
Компрессия расширяет тут возможности -- если фон однотонный, он очень хорошо уходит в ничто. Обрезать края -- это практически то же самое. Что до цветов -- у меня сохранение попиксельное -- по два пикселя на байт. Уменьшать количество цветов это хорошо если по слоям.Цитата:
Сообщение от ivagor