Сжатие данных

[parallelno]

ivagor, упакованные данные могут лежать по тем же адресам что и распакованные. выше $8000

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

Забыл сказать что прерывания запрещены

[ivagor]

Примерно так

[parallelno]

ivagor, спасибо. но все равно что-то корраптит данные, но уже в других местах.

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

я использую форвард распаковку и распаковываю из адрессов ниже $8000 по адрессу $8000 в нулевой банк квазидиска если это поможет.

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

если я указываю команду 0 и распаковываю в основную память, а затем перемещаю в квазидиск c помощью PUSH, то данные корректные

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

сравнил твой код со своим. выглядит идентично. Может ли быть что гдето вне этого куска ниже код читает/пишет распакованые данные?

		push psw
dzx0_setqd2:
		mvi a,0
		out 10h
dzx0_ldir2:
		ldax d
		stax b
		NEXT_DE
		NEXT_BC
		dcx h
		mov a,h
		ora l
		jnz dzx0_ldir2
		xra a
		out 10h
		pop psw
		add a

		push psw
dzx0_ldir1:
		ldax d
		push psw
dzx0_setqd1:
		mvi a,0
		out 10h
		pop psw
		stax b
		xra a
		out 10h
		NEXT_DE
		NEXT_BC
		dcx h
		mov a,h
		ora l
		jnz dzx0_ldir1
		pop psw
		add a

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

вроде кроме двух ldax ничего не читает и не пишет данные вне ldir. проверил их несколько раз, вроде они адрессуют только область ниже $8000. Непонятно. Еще более непонятно то что если программу выполнять по шагам в Emu80 дебаге, то данные копартятся в другом месте. может это бага эмулятора? В v06x тоже данные копартятся но в другом месте.

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

Блин. нашел ошибку. все таки одна из процедур разрешала прерывания

[ivagor]

Неожиданно и от демопатей бывает польза. Впечатлил новый упаковщик upkr - мой тестовый набор сжал лучше шринклера, при этом в распаковщике умножение всего лишь (если сравнивать со шринклером) 8x8. Ждем распаковщика для 8080.

[svofski]

Забавно, что эта демка по духу близка progdemo. Я не очень понял, почему ее загнали в wild.

[ivagor]

Wild cкорее всего потому что это галерея картинок из 90х не нарисованных специально для этой демы.

[Advertiser]

[ivagor]

Если кто-то параллельно адаптирует распаковщик upkr для 8080, то мои текущие результаты такие: 268 байт (умножение развернутое, для сравнения шринклер 311 байт) и в 1.9 раза быстрее шринклера. Скорость распаковки примерно 6000 бит/секунду (в 2 раза медленнее loadfm, зато в разы быстрее традиционных форматов), очень медленно, но как упаковщик крайнего случая для дем 2k-4k подойдет. А шринклер теперь не нужен.

[ivagor]

Дожал upkr (гитхаб). Еще ускорить не получилось, зато подсократил (227 байт прямой, 257 - быстрый прямой, обратные на байт короче). Уже традиционно хочу оценить качество портирования по соотношению размеров вариантов 8080 и z80:
227/170=1.34
257/195=1.32
Судя по предыдущим результатам это хорошие, близкие к пределу цифры для распакощиков LZ и LZ+
Обращаю внимание, что в upkr есть опции --max-offset и --max-length, соответственно можно переделать распаковщик на кольцевой буфер.

[ivagor]

Добавил версию deupkr с умножением по таблице квадратов, там нужно сначала вызвать (один раз) процедуру генерации таблицы, потом (сколько угодно раз) можно вызывать распаковщик. Эта версия примерно на 9% быстрее варианта с развернутым циклом умножения (а само умножение быстрее более чем в полтора раза). За это пришлось заплатить увеличением размера распаковщика на 33 байта и местом под таблицу квадратов (1024 байта). Если сравнивать со шринклером, то эта версия deupkr все равно компактнее, занимает меньше места под таблицы и более чем в 2 раза быстрее. Разумных вариантов дальнейшего ускорения умножения 8x8 я на данный момент не вижу, а неразумные (например занять 128 Кб кваза под полную таблицу умножения) даже пробовать не хочется.

[ivagor]

Отколупал от базовых версий deupkr 2 байта, от табличной 4.
Потестировал в эмуляторе 6128 - 8085 очень неплохо ускоряет upkr (пробовал квадратно-табличный) за счет более быстрого выполнения части команд, на 16-17%. Можно еще немного оптимизировать по размеру и скорости за счет недокументированных команд, но этот выигрыш незначительный.
Сделал версию для 8088/86, можно считать что под Вектор 1608Ц (подойдет и для менее экзотических машинок типа Поиска или МС-1502).