Real Information Packer 0.2x
Автор программы - Роман Петров (Йошкар-
Ола), тёзка и однофамилец йошкар-олинского
композитора Megus'а. Человек-загадка. На-
писав единственную программу, он скрылся в
неизвестность, и тут же возникли вопросы:
откуда такой уровень программирования? ко-
гда и как настолько ювелирно настроены па-
раметры сжатия? почему условия инкремента
длины ссылки с точностью до плюс-минус ба-
йта совпали с аналогичными условиями в фо-
рмате Rar2.x, хотя к моменту появления RIP
этот формат отнюдь не был обнародован?
В любом случае,это один из самых мощных
компрессоров на ZX,победить его сейчас мо-
жет только ZXRar, причём, будь ZXRar напи-
сан раньше RIP, ещё неизвестно,кто бы кого
победил... На маленьких файлах RIP принци-
пиально выгоднее - из-за меньшего объёма
деревьев и длины распаковщика.
Существует 3 распаковщика RIP: оригина-
льный v0.21 размером #121, с параметрами в
HL (откуда) и DE (куда); DERIP+++.H разме-
ром #112 (в отличие от предыдущего, позво-
ляет задать адрес деревьев независимый от
адреса распаковщика); и v0.25, пришиваемый
к упакованному файлу наподобие Hrum, дово-
льно неоптимальный.
Гвоздь формата - настоящие произвольные
деревья, хранящиеся в файле в упакованном
виде, совсем как в архивах Zip, Rar и т.д.
Процедура построения дерева в сущности ге-
ниальна. Приводить её здесь не имеет смыс-
ла,она повторена в исходниках DERIP, mRIP,
RZXSFX и т.п. Без её невероятной лаконич-
ности сама идея использования произвольных
деревьев в кодовых компрессорах осталась
бы бессмысленной. Считалось бы, что таких
деревьев достойны лишь архиваторы.
Вместе с тем, пользователю нового комп-
рессора пришлось привыкнуть к новой проб-
леме: найти #5C0 байт (#5C2 в DERIP+++.H)
памяти под деревья.Это уже не 256 байт под
активную часть распаковщика, как в Hrust1.
Нет, такой крупный объём надо где-то выде-
лять. Например,на экране.Не всегда это до-
пустимо. Вероятно, из-за таких проблем RIP
не получил большого распространения при
сборке электронной прессы.
Другая проблема - скорость распаковки.
Она значительно ниже,чем у старых компрес-
соров, даже ниже, чем у программы UnRar.
Этот недостаток нельзя устранить - он свя-
зан с принципиальным отсутствием в упако-
ванном файле байтового потока. Начинают
влиять циклы обработки деревьев, а ускоре-
ние их возможно лишь ценой существенного
увеличения распаковщика и буфера под де-
ревья.
Биты читаются из байта начиная от 0-го,
т.е. нестандартно.
Формат:
+0(2) - UnpLen, распакованная длина;
+2(2) - PakLen, упакованная длина, считая
со следующей ячейки (+4);
+4 - начало информации о деревьях. 18 че-
тырёхбитных чисел (тетрад), указывающих
количество бит в хаффмановских кодах у
дерева,используемого для извлечения рабо-
чих деревьев. Для каждого из кодов 0...17
хранится длина в битах ( 0 - код не испо-
льзуется; чем чаще код,тем он должен быть
короче).
Из этих тетрад однозначно строится де-
рево,по которому будут считаны аналогичные
данные о 288+32 символах рабочих деревьев.
Конечно, тех аналогичных данных (они лежат
далее) не обязательно 288+32 байт (в смыс-
ле, символов Хаффмана) - они хитро закоди-
рованы: 0..15 - просто код длины, типа тех
тетрад; 16 - конец информации; 17 - повто-
рить ещё 2 раза предыдущую длину.
Дерево из 288 литералов условно назовём
maintree, а дерево из 32 - просто tree.
Деревья строятся из длин по следующим
правилам:
1. Если дерево нарисовать так,что корень
будет сверху, единицы справа,а нули слева,
то левые подветви должны быть не длиннее
правых. Нижняя же кромка веток дерева дол-
жна плавно опускаться (глубина увеличива-
ться) слева направо.
2. Внутри ярусов (совокупностей листьев,
имещих одинаковую глубину) действует сор-
тировка: меньшие коды символов справа от
больших.Т.е.наоборот относительно Rar. Это
связано с сокращением распаковщика.
После того,как вся информация о деревь-
ях считана, извлекаются байты конца архива
(в обратном порядке) по дереву maintree,
сразу же закидываются в стек.Любой литерал
Є256 - конец этого процесса, и начинается
собственно распаковка.
Распаковка происходит циклами,каждый из
которых начинается с чтения символа по де-
реву maintree:
0..255 - просто байт.Поместить его в выхо-
дной поток;
257..260 - puts=1..4. Далее по дереву tree
считывается код длины disp:
0 - использовать старый disp;
1..4 - disp=1..4
5,7,...,31 - disp вида %10.., от 3 до 16
бит.Дочитываются недостающие биты disp,
начиная со старших;
6,8,...,30 - disp вида %11.., от 3 до 15
бит. Аналогично. Отсюда видно, что раз-
мер окна не превышает 49151.
Эта кодировка disp полностью соответству-
ет формату Rar (см. Inferno#4). Более то-
го, почти (256<>257) совпадает следующее:
При dispЄ256 инкрементируется puts. При
dispЄ#2000 ещё раз инкрементируется puts!
Реализуется копирование.
261,263,...,287 - коды длин puts (puts=
=%10..) от 3 до 16. Дополнительно считы-
ваются (соответственно) 1..14 бит для по-
дцепления к %10.. Далее считывается disp,
как выше;
262,264,...,286 - аналогично,но puts=%11..
От 3 до 15 бит. Далее disp, как выше;
256 - окончить распаковку.
После распаковки из стека вынимаются
байты конца файла (максимальное число мне
неизвестно).
mRIP (mrip4.H)
Формат отличается от оригинального RIP
следующими деталями:
1. Нет UnpLen, PakLen в начале;
2. Нет байтов конца файла в начале;
3. Нет кода "повторить предыдущий disp";
4. Нет коррекции puts при dispЄ#2000;
5. Тетрады длин кодов дерева для постро-
ения рабочих деревьев лежат в обратном по-
рядке.
В результате депакер уместился в бей-
сик-блоке,и был создан удобный автосборщик
для системных программ. На маленьких прог-
раммах он выигрывает у RIP'а один сектор
за счёт размера распаковщика. На длинных
теоретически может проиграть. Но на прак-
тике до этого не доходит из-за ограничений
на размер файла, пакуемого mRIP. Вот что
его ограничивает:
mRIP не перемещает блок перед распаков-
кой, поэтому адрес окончания упакованного
блока должен быть выше адреса окончания
распаковки. А адрес окончания упакованного
блока зависит не от вас, а от длины этого
упакованного блока плюс метка OTKUDA. А
эта метка (в текущей версии #AA00 ) в свою
очередь зависит от максимального размера
блока и метки maintree (в текущей версии
#f881 ), т.к. при распаковке генерируются
деревья,которые где-то нужно хранить,а за-
чернить экран не получается: не хватает
места в секторе бейсика.
Ограничения есть не только при распако-
вке, но и при упаковке: при упаковке очень
большого файла может не хватить памяти.
Можете надеяться упаковать память от #6000
до #E000 (pg0), но никак не всю память.
Для подключения mRIP к программе нужно:
1. Определить метки begin, end, GO - ра-
змеры программы и адрес её запуска;
2. Сформировать имя программы в #5CDD;
3. В начале программы установить стек,
раскрасить экран и бордюр, разобраться с
константами клавиатуры: REPPER и REPDEL...
Желательно LD (IY+1),#CC для безбоязненно-
го использования вашей программой памяти
#5bxx. Сам mRIP всего этого не делает;
4. В конце главного исходника поместить
INCLUDE "mrip*".
Рекомендуется писать именно "mrip*", а
не "mrip4", поскольку версия mRIP может
меняться. Если вы будете,например,распрос-
транять свои исходники, у получателя может
оказаться другая версия,ему придётся куда-
то лезть,что-то исправлять... (Большинство
народу терпеть не может всякие телодвиже-
ния.) И вам же будет удобнее обновлять ве-
рсии mRIP на своих дисках.Зачем обновлять?
Иногда очень неприятно рыться,искать САМУЮ
РАСПОСЛЕДНЮЮ версию по всем дискам, а там
сплошь всё старые да древние...
Если определена метка make, сборка про-
изойдёт и без нажатия Caps Shift - можете
использовать для распространения с mkace-
подобными сборщиками.
Для организации отладочного запуска,ко-
торый меняет код программы,вписывайте (ес-
ли нужно) после INCLUDE следующее:
ORG $
CALL 8026
JP NC,nenado
<ваши pokes>
JP GO
Ограничение на размер - не пересекайте
адрес #5c00.
подготовил А. Кодер
