Вид для печати
Жаль, формат данных не документирован хоть как-нибудь. Без этого сложно оценивать алгоритм. Я правильно понимаю, что в начале количеством единиц кодируется адрес в таблице, откуда распаковываются длины кодов смещения и количества, сколько там бит ещё прочитать из потока для из заполнения?Цитата:
Сообщение от Eugene85
Исходник распаковщика, использующего алгоритм NRV2d из библиотеки UCL (такие упаковщики уже были, основной способ сжатия UPX).
Размер - около 200 байт. Сжатие - неплохое, но уступает остальным (zx0, hrust, apack, rip). Распаковка одна из самых быстрых, это основное преимущество. Обращаю внимание, оригинальный поток, запакованный с помощью утилиты uclpack, не подходит. Как переделать написано: в функции ucl_nrv_99_compress() поменять одно значение (финальный маркер, с длинного на короткий), и осуществить пересборку из исходника (упаковщик n2dpack прилагается). Пример использования (для ПК «Специалист»): исходный размер – 17 кБ, сжатый – 5 кБ.
Оставлю, может кому пригодится.
Sandro, неправильно.
Добавил краткое описание формата.
Прикидочная (за час) версия derip8080 получилась 372 байта и почти в 5 раз медленнее zx0. Оптимизировать несомненно можно и по размеру и по скорости, но вряд ли в разы. RIP с упаковщиком Eugene85 хорошая, но все же ограниченно пригодная для 8080 штука.
Я только сейчас осознал, что тема не имеет отношения к Спектруму :) Всё думал, причём тут 8080....
Ну то есть примерно как на Z80.Цитата:
Сообщение от ivagor
RIP (или какой-нибудь другой упаковщик будущего с LZ+Хаффманом) можно сделать более дружественным для 8080 (и не только для 8080), если реализовать пару вещей, которые дружно сделаны в новейших ретроупаковщиках:
1. Развернуть битовый поток в другую сторону. Делал такую утилиту постобработки для эксомизера, но потом там добавили опцию в самом упаковщике, что, конечно, более удобно.
2. Сделать смещение отрицательным, чтобы учитывать его не по SBC, а по ADD. Это уже потребует не совсем механических правок распаковщика и не так важно, как п.1
Это, конечно, легко. Если когда-нибудь публично появится декомпрессор, ориентированный на это, сделаю опцию, не проблема.Цитата:
1. Развернуть битовый поток в другую сторону.
А вот это проблема. Декомпрессор придётся существенно удлинить, а он и так немаленький; в общем, нет смысла. Не знаком с архитектурой 8080, но думаю можно использовать 8-битные SUB+SBC, как это сделано в декомпрессоре mRIP.Цитата:
2. Сделать смещение отрицательным
Другое решение: сжатие задом наперёд, тогда нужна будет именно ADD.
Примерно так я и делаю, вопрос не в принципиальной невозможности, а в компактности кода.Цитата:
Сообщение от Eugene85
Если речь про z80, то (по аналогии с декомпрессорами, использующими такой подход) думаю можно переделать и без удлинения, но надо внимательно посмотреть и подумать.Цитата:
Сообщение от Eugene85
Развернул битовый поток. derip8080 стал на 9 байт короче и на 4 с копейками процента быстрее.
Свет в конце тоннеля есть, сократил derip8080 до 330 байт и теперь он не в 5 раз медленнее zx0, а в 4. Меня пока не совсем устраивает, но уже похоже на что-то приемлемое. Т.к. для rip, в отличие от эксомизера, можно просто развернуть все биты в байтах, то думал воспользоваться какой-нибудь готовой бесплатной утилиткой и потом дать на нее ссылку на гитхабе, но неожиданно не нашел такой. Свою я конечно накропал, но может кто подскажет готовую?