Не мешает вычистить весь мусор из основного кодового блока, и пожать все в Exomizer.
Вид для печати
Не мешает вычистить весь мусор из основного кодового блока, и пожать все в Exomizer.
а чем тебе hrust не угодил ?Цитата:
Сообщение от ^m00h^
и я сильно сомневаюсь что этот exomizer есть под спек (про trd я уже молчу)
Декомпрессор на спектрум есть. https://spectrumcomputing.co.uk/foru...opic.php?t=284Цитата:
Сообщение от goodboy
Но тормозной.
ну это очевидно, а иначе зачем он нужен.Цитата:
Сообщение от Shadow Maker
только я сильно сомневаюсь в превосходстве над hrust`ом.
Лучше Hrust'а ничего не изобретено. Его создателю, по идее, нужно каждый год по две открытки высылать - на Д.Р. и на новый год.
ApLib и Exomizer лучше жмутЦитата:
Сообщение от goodboy
DenisGrachev, жать можно сколь угодно хорошо. А время распаковки?? А размер депакера?? Да и вообще без пруфов несчитова :v2_tong2:
пруф что хруст лучше? :)))))Цитата:
Сообщение от ZX_NOVOSIB
Ознакомся:
http://hype.retroscene.org/blog/dev/740.html
кому что как. мне и zx7 хватает.
был бы Exomizer под 6502 и хватило.
DenisGrachev, :v2_dizzy_aaaaa:вот тебе бабушка июрьев деньгидра хайпа... Какое объемное исследование. За такое нобелевку давать надо!
А где-то есть мануал, как этими вашими ApLib и Exomizer'ами пользоваться? То, что ими могут пользоваться люди, которые могут доказать теорему Пуанкаре, я понял, а как насчёт нормальных человеческих людей? Ну чтобы вот несжатый файл, бац - делаем то и то, бац - и получаем сжатый, а вот он депакер, и чтобы распаковать usr/jp/call такой-то.
И да, применительно к топику в котором мы находимся, hrust вообще уделал ApLib, а Exomizer'у проиграл 0,8%, но по времени распаковки всё-равно уделал. :D Такие пироги.
Exomizer пакуется так:
exomizer.exe raw joke2.txt -o joke2.pack
Вызов:
главное - не забыть, что портится IY.Код:ld hl,pic1 ;HL = start address of compressed file
ld de,#4000 ;DE = start address of decompressed data
call deexo ;Decompress the data
- - - Добавлено - - -
Чушь, высосанная из пальца не пруф.Цитата:
Сообщение от DenisGrachev
ради интереса пожал несколько кодовых блоков от игрушек.
exomizer действительно жмёт лучше hrust`a. (для меня лучше это когда результат явно меньше на 256b)
похоже пора осваивать современные технологии
goodboy, а время распаковки? Не совсем здорово, если времени на распаковку уйдет в 2 раза больше.
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 в зависимости от выбранного депакера
ещё не проверял. только удостоверился что блоки сжатые им явно короче сжатых hrust`омЦитата:
Сообщение от ZX_NOVOSIB
Только один параметр - первый файл, хвост сам прицепится.Цитата:
Сообщение от Bedazzle
Хм... Интересно....Цитата:
Сообщение от goodboy
Печалит только 2 факта:
1) "Распаковщик занимает 174 байта, плюс, требует для своей работы буфер памяти в 156 байтов" - это он, получается, больше, чем Хрустовый?
2) Паковать надо где-то, но не на реале.... :(
с этими распаковщиками чёрт ногу сломит.Цитата:
Сообщение от Slider
мне встречался без индексных регистров и таблицы
Для себя жал с одним параметром. Просто тут решил, чтобы максимально похоже было на пример предыдущего оратора. :)Цитата:
Сообщение от Shiny
Поддержу оффтоп, у apLib'а версии от r77shell есть фикс от него же который исправляет ошибки на файлах >32k. Вышел уже после статьи, линк на сеговском форуме.
собезьяничал ?(:Цитата:
Сообщение от Bedazzle
Вот именно. Не православно это. От лукавого. И ради чего? Ради 0,8%?Цитата:
Сообщение от Slider
В век многогигагерцовых 64-разрядных многоядерных монстров с кэшем в десятки мегабайт и с оперативой в десятки гигабайт неужели нельзя достигнуть прироста сжатия хотя бы в 10%? Пусть этот монстр пошерудит своими ядрами и найдет оптимальный словарь, оптимальные алгоритмы или что там. Дак ведь нет: 0,8% и всё.
а вот это правильно и крайне важно, потому как разницы в секторах может и не быть.Цитата:
Сообщение от goodboy
Кроме того не задумывались сколько теряется в этих хвостах сжатых данных если их выражать в секторах? усреднённо можно принять 128байтов * на количество загружаемых блоков.
наступил на ещё одни грабли, адрес размещения сжатого блока надо вычислять самостоятельно.
hrust в этом плане более интеллектуальный, он сам переместит сжатые данные до верхней границы.
при его использовании hl=de / source=destination вполне обычный момент.
exomizer при таком раскладе просто запорет данные
goodboy, hrust не идеален. Он тоже может при "hl=de / source=destination" запороть распаковку. Наступал на такие грабли.
такую ситуацию легко создать если в сжимаемом блоке уже есть сжатые данные
Так, вроде, никто не думает, просто самый удобный с достаточно отличным коэффициентом сжатияЦитата:
Сообщение от transman
Чтобы предотвратить такое, я, как правило, отодвигаю на сектор-другой адрес сжатого блока от адреса распаковываемого.Цитата:
Сообщение от transman
Ну и еще известная болячка Хруста, это когда данные идут до самого конца сжимаемого блока, он может квадратами покрыться. А вот если в конце ряд нулей, такого не бывает... ;)
П.С. Ну и вообще, выпилить может отсюда весь треп о пакерах и засунуть его в другую тему?
изначально созданный для с64,
но позже был написан депакер для z80