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

[Eugene85]

Сделал компрессоры RIP и mRIP на PC.
Кто там хотел компрессор на базе LZ+Хаффман и заполнить пробел между zx0 и shrinklerом? Всё как заказывали

https://gitlab.com/eugene77/rip
https://gitlab.com/eugene77/mrip

[Advertiser]

[Sandro]

Сделал компрессоры RIP и mRIP на PC.
Кто там хотел компрессор на базе LZ+Хаффман и заполнить пробел между zx0 и shrinklerом? Всё как заказывали

Жаль, формат данных не документирован хоть как-нибудь. Без этого сложно оценивать алгоритм. Я правильно понимаю, что в начале количеством единиц кодируется адрес в таблице, откуда распаковываются длины кодов смещения и количества, сколько там бит ещё прочитать из потока для из заполнения?

[Eugene85]

Sandro, неправильно.

Добавил краткое описание формата.

[ivagor]

Набор тестовых файлов у меня на другом компе, но предварительные тесты (пробовал только RIP) показывают, что очень хороший вариант, похоже жмет лучше, чем gzip. Распаковщик для 8080 будет (если будет) большой и медленный, но все же явно быстрее шринклера.

[lexarr]

Исходник распаковщика, использующего алгоритм NRV2d из библиотеки UCL (такие упаковщики уже были, основной способ сжатия UPX).
Размер - около 200 байт. Сжатие - неплохое, но уступает остальным (zx0, hrust, apack, rip). Распаковка одна из самых быстрых, это основное преимущество. Обращаю внимание, оригинальный поток, запакованный с помощью утилиты uclpack, не подходит. Как переделать написано: в функции ucl_nrv_99_compress() поменять одно значение (финальный маркер, с длинного на короткий), и осуществить пересборку из исходника (упаковщик n2dpack прилагается). Пример использования (для ПК «Специалист»): исходный размер – 17 кБ, сжатый – 5 кБ.
Оставлю, может кому пригодится.

[ivagor]

Прикидочная (за час) версия derip8080 получилась 372 байта и почти в 5 раз медленнее zx0. Оптимизировать несомненно можно и по размеру и по скорости, но вряд ли в разы. RIP с упаковщиком Eugene85 хорошая, но все же ограниченно пригодная для 8080 штука.

[Eugene85]

Я только сейчас осознал, что тема не имеет отношения к Спектруму :) Всё думал, причём тут 8080....

и почти в 5 раз медленнее zx0

Ну то есть примерно как на Z80.

[ivagor]

RIP (или какой-нибудь другой упаковщик будущего с LZ+Хаффманом) можно сделать более дружественным для 8080 (и не только для 8080), если реализовать пару вещей, которые дружно сделаны в новейших ретроупаковщиках:
1. Развернуть битовый поток в другую сторону. Делал такую утилиту постобработки для эксомизера, но потом там добавили опцию в самом упаковщике, что, конечно, более удобно.
2. Сделать смещение отрицательным, чтобы учитывать его не по SBC, а по ADD. Это уже потребует не совсем механических правок распаковщика и не так важно, как п.1

[Eugene85]

1. Развернуть битовый поток в другую сторону.

Это, конечно, легко. Если когда-нибудь публично появится декомпрессор, ориентированный на это, сделаю опцию, не проблема.

2. Сделать смещение отрицательным

А вот это проблема. Декомпрессор придётся существенно удлинить, а он и так немаленький; в общем, нет смысла. Не знаком с архитектурой 8080, но думаю можно использовать 8-битные SUB+SBC, как это сделано в декомпрессоре mRIP.
Другое решение: сжатие задом наперёд, тогда нужна будет именно ADD.

[ivagor]

можно использовать 8-битные SUB+SBC

Примерно так я и делаю, вопрос не в принципиальной невозможности, а в компактности кода.

Декомпрессор придётся существенно удлиннить

Если речь про z80, то (по аналогии с декомпрессорами, использующими такой подход) думаю можно переделать и без удлинения, но надо внимательно посмотреть и подумать.