пакер exomizer

[^m00h^]

Не мешает вычистить весь мусор из основного кодового блока, и пожать все в Exomizer.

[goodboy]

и пожать все в Exomizer
а чем тебе hrust не угодил ?
и я сильно сомневаюсь что этот exomizer есть под спек (про trd я уже молчу)

[Shadow Maker]

а чем тебе hrust не угодил ?
и я сильно сомневаюсь что этот exomizer есть под спек (про trd я уже молчу)

Декомпрессор на спектрум есть. https://spectrumcomputing.co.uk/forums/viewtopic.php?t=284
Но тормозной.

[goodboy]

Декомпрессор на спектрум есть.
ну это очевидно, а иначе зачем он нужен.
только я сильно сомневаюсь в превосходстве над hrust`ом.

[ZX_NOVOSIB]

Лучше Hrust'а ничего не изобретено. Его создателю, по идее, нужно каждый год по две открытки высылать - на Д.Р. и на новый год.

[DenisGrachev]

ну это очевидно, а иначе зачем он нужен.
только я сильно сомневаюсь в превосходстве над hrust`ом.

ApLib и Exomizer лучше жмут

[ZX_NOVOSIB]

DenisGrachev, жать можно сколь угодно хорошо. А время распаковки?? А размер депакера?? Да и вообще без пруфов несчитова :v2_tong2:

[DenisGrachev]

DenisGrachev, жать можно сколь угодно хорошо. А время распаковки?? А размер депакера?? Да и вообще без пруфов несчитова

пруф что хруст лучше? :)))))

Ознакомся:

http://hype.retroscene.org/blog/dev/740.html

[Shiny]

кому что как. мне и zx7 хватает.
был бы Exomizer под 6502 и хватило.

[ZX_NOVOSIB]

DenisGrachev, :v2_dizzy_aaaaa:вот тебе бабушка и юрьев день гидра хайпа... Какое объемное исследование. За такое нобелевку давать надо!

А где-то есть мануал, как этими вашими ApLib и Exomizer'ами пользоваться? То, что ими могут пользоваться люди, которые могут доказать теорему Пуанкаре, я понял, а как насчёт нормальных человеческих людей? Ну чтобы вот несжатый файл, бац - делаем то и то, бац - и получаем сжатый, а вот он депакер, и чтобы распаковать usr/jp/call такой-то.

И да, применительно к топику в котором мы находимся, hrust вообще уделал ApLib, а Exomizer'у проиграл 0,8%, но по времени распаковки всё-равно уделал. :D Такие пироги.

[Shiny]

Exomizer пакуется так:
exomizer.exe raw joke2.txt -o joke2.pack

Вызов:


ld hl,pic1 ;HL = start address of compressed file
ld de,#4000 ;DE = start address of decompressed data
call deexo ;Decompress the data


главное - не забыть, что портится IY.

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


пруф что хруст лучше? ))))

Ознакомся:

http://hype.retroscene.org/blog/dev/740.html

Чушь, высосанная из пальца не пруф.

[goodboy]

ради интереса пожал несколько кодовых блоков от игрушек.
exomizer действительно жмёт лучше hrust`a. (для меня лучше это когда результат явно меньше на 256b)
похоже пора осваивать современные технологии

[ZX_NOVOSIB]

goodboy, а время распаковки? Не совсем здорово, если времени на распаковку уйдет в 2 раза больше.

[Bedazzle]

ZX7 пакуется так:
ZX7.exe joke.txt joke.txt.zx7



;компилируемый исходник включается нужный депакер, например
INCLUDE "dzx7_standard.asm"





ld hl, input_addr
ld de, target_addr
call dzx7_standard ; или dzx7_turbo или dzx7_mega в зависимости от выбранного депакера


ну, и как было указано в статье, нужно осторожно с используемыми регистрами.

[goodboy]

а время распаковки?
ещё не проверял. только удостоверился что блоки сжатые им явно короче сжатых hrust`ом

[Shiny]

ZX7.exe joke.txt joke.txt.zx7

Только один параметр - первый файл, хвост сам прицепится.

[Slider]

удостоверился что блоки сжатые им явно короче сжатых hrust`ом
Хм... Интересно....
Печалит только 2 факта:
1) "Распаковщик занимает 174 байта, плюс, требует для своей работы буфер памяти в 156 байтов" - это он, получается, больше, чем Хрустовый?
2) Паковать надо где-то, но не на реале.... :(

[goodboy]

1) "Распаковщик занимает 174 байта, плюс, требует для своей работы буфер памяти в 156 байтов" - это он, получается, больше, чем Хрустовый?
с этими распаковщиками чёрт ногу сломит.
мне встречался без индексных регистров и таблицы

[Bedazzle]

Только один параметр - первый файл, хвост сам прицепится.

Для себя жал с одним параметром. Просто тут решил, чтобы максимально похоже было на пример предыдущего оратора. :)

[krt17]

Поддержу оффтоп, у apLib'а версии от r77shell есть фикс от него же который исправляет ошибки на файлах >32k. Вышел уже после статьи, линк на сеговском форуме.

[Shiny]

Для себя жал с одним параметром. Просто тут решил, чтобы максимально похоже было на пример предыдущего оратора. :)

собезьяничал ?(:

[ZX_NOVOSIB]

2) Паковать надо где-то, но не на реале...
Вот именно. Не православно это. От лукавого. И ради чего? Ради 0,8%?

В век многогигагерцовых 64-разрядных многоядерных монстров с кэшем в десятки мегабайт и с оперативой в десятки гигабайт неужели нельзя достигнуть прироста сжатия хотя бы в 10%? Пусть этот монстр пошерудит своими ядрами и найдет оптимальный словарь, оптимальные алгоритмы или что там. Дак ведь нет: 0,8% и всё.

[daniel]

для меня лучше это когда результат явно меньше на 256b
а вот это правильно и крайне важно, потому как разницы в секторах может и не быть.
Кроме того не задумывались сколько теряется в этих хвостах сжатых данных если их выражать в секторах? усреднённо можно принять 128байтов * на количество загружаемых блоков.

[goodboy]

наступил на ещё одни грабли, адрес размещения сжатого блока надо вычислять самостоятельно.
hrust в этом плане более интеллектуальный, он сам переместит сжатые данные до верхней границы.
при его использовании hl=de / source=destination вполне обычный момент.
exomizer при таком раскладе просто запорет данные

[transman]

goodboy, hrust не идеален. Он тоже может при "hl=de / source=destination" запороть распаковку. Наступал на такие грабли.

[goodboy]

такую ситуацию легко создать если в сжимаемом блоке уже есть сжатые данные

[Slider]

goodboy, hrust не идеален
Так, вроде, никто не думает, просто самый удобный с достаточно отличным коэффициентом сжатия


Он тоже может при "hl=de / source=destination" запороть распаковку. Наступал на такие грабли
Чтобы предотвратить такое, я, как правило, отодвигаю на сектор-другой адрес сжатого блока от адреса распаковываемого.
Ну и еще известная болячка Хруста, это когда данные идут до самого конца сжимаемого блока, он может квадратами покрыться. А вот если в конце ряд нулей, такого не бывает... ;)

П.С. Ну и вообще, выпилить может отсюда весь треп о пакерах и засунуть его в другую тему?

[goodboy]

изначально созданный для с64,
но позже был написан депакер для z80