Для ловли блох такого рода, рекомендую пересобрать избранный оптимальный пакер, добавив к нему функцию печати итогового числа бит. Часто бывает, что есть 2-3 варианта кода, вроде примерно одно и то же, на итоговый размер в байтах не влияет, но в таком упаковщике с битами видишь, какой вариант был реально оптимальнее. Я много сберёг используя такой подход в «Down with the rules». Очень много циклов развернул и т.д. У меня гораздо больше итоговый неупакованный размер интры, по сравнению с тем, что делал ты. Подозреваю, что на 4кб должно получаться 6-7кб кода «оптимизированного под упаковщик». Например, вместо декранчера писать хорошо жмущийся код — ну, ты понимаешь.
Т.е. для себя я сделал такой вывод: нужно переписать Hrust 1 и Hrum для работы с битовым потоком в байтах (вместо битов) и переписать их распаковщики примерно по той же схеме, по которой написаны сейчас ApLib, Exomizer и ZX7. Думаю, это уменьшит их размер Hrust 1 и сделает его вполне конкурентными в чём-то вроде 4K; в случае с Hrum я думаю больше смысла пытаться конкурировать с пакерами типа ZX7, т.е. брать размером распаковщика и скоростью распаковки.
Чото подумал, если все так хотят реальных чипов, чо б не сделать девайс в формате «бутерброда».
Плюсы:
— вставляется в панельку, отстутствует шлейф, приводящий шину данных з80 в состояние «кровь-кишки-говно-распидорасило»,
— занимает меньше места в пространстве.
Минусы:
— чуть габаритнее по высоте и совсем чучуть по ширине.
— чипы видимо придется запаивать — панельки особого смысла не имеют (как доставать нижний чип?).
Т.е. Exomizer однозначный лидер, ZX7 скорее всего уже на этом масштабе неактуально использовать.
ApPack, Hrum, MegaLZ на этом масштабе почти неразличимы, чего и следовало ожидать по итогам больших тестов.
на момент 1999 года, прорулил hrum с допиленным депакером ;)
интересно, насколько все изменилось сейчас, c2h5oh может и поменьше получиться, там сразу после релиза я табличку построения синуса менял на инкрементную, — должно сказаться на паковке…
Это сознательное решение: я не включил ни один специализированный упаковщик для упаковки картинок. Они, всё же, немного вещь в себе; тем более что там есть вариации ZX7 (RCS), различные версии Laser Compact и т.д. Это какое-то отдельное упражнение, которое я думаю оставить кому-то другому, отчасти из-за того, что сам я этими технологиями почти никогда не пользуюсь.
а что компрессор от Lethargeek?
он хоть и специфичный, но жмет то без потерь, и все равно что…
Эталон этот в три раза сжимает, до 5215. Распаковывает конечно медленно, но на картинках — красиво:)
ну и картинки уж точно вряд ли кто сильнее жмет.
возможно, возможен «optimal hrum packer», как для hrust'а? ;)
мы это все проходили в 2012 году, прям 1в1
Плюсы:
— вставляется в панельку, отстутствует шлейф, приводящий шину данных з80 в состояние «кровь-кишки-говно-распидорасило»,
— занимает меньше места в пространстве.
Минусы:
— чуть габаритнее по высоте и совсем чучуть по ширине.
— чипы видимо придется запаивать — панельки особого смысла не имеют (как доставать нижний чип?).
sp_save: ld sp,0
->
sp_save: ld sp,__sp
ifdef FORPACK
__sp equ #3131
__hl equ #2121
__de equ #1111
__bc equ #0101
else
__sp equ 0
__hl equ 0
__de equ 0
__bc equ 0
endif
при паковке hrum'ом, — лучше было оставлять ld sp,0, иначе наоборот + 3 байта на всю интру еще и добавит :)
c exomizer'ом же — 3 байта уберет.
;)
ApPack, Hrum, MegaLZ на этом масштабе почти неразличимы, чего и следовало ожидать по итогам больших тестов.
интересно, насколько все изменилось сейчас, c2h5oh может и поменьше получиться, там сразу после релиза я табличку построения синуса менял на инкрементную, — должно сказаться на паковке…
dizzy4k/c2h5oh unpacked
он хоть и специфичный, но жмет то без потерь, и все равно что…
Эталон этот в три раза сжимает, до 5215. Распаковывает конечно медленно, но на картинках — красиво:)
ну и картинки уж точно вряд ли кто сильнее жмет.