перепутано у меня: я нашёл этот баг ещё в прошлую среду, и уже исправил — но потом была судорожная подготовка к verve и безумные выходные, так что до публикации не дошло… сейчас доделываю версию с бипером + слегка доработал функционал, в этой версии уже будет всё ок.
Крафтовый sizecode не может быть сравним с индустриальной компрессией, не подрывайте устоев веры!
В следующем материале попрошу разобрать проблему, каждую осень волнующую неокрепшие умы — «Bruteforce sizecoding на своременных вычислительных мощностях: вкалывают роботы, а не человек!»
Которых будут сетовать предлагаю расстреливать. Чтобы не мучались.
А вообще, компрессия — реально другой способ делать size-intro. Требует другие навыки, во многом ортогональные нормальному size-coding. Поэтому, с моей точки зрения, это скорее способ поддержать основы, путём увеличения видового разнообразия.
распространение этой информации нужно немедля запретить — она подрывает основы. вместо того, чтобы оптимизировать код люди будут сетовать на несовершенность компрессора, лишающего их шансов принять участие в size-compo
«Down with rules 256b» использует чуть подпиленный ZX7mini. Лично для меня это было важной частью задачи — показать, что компрессия актуальна в 256b, тем более что бут-сектор для Atari ST, послуживший моим вдохновением, занимал 512б и распаковывался, по словам автора, до 39438 байт: www.pouet.net/prod.php?which=57063
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Возможно ошибаюсь, у меня все жИ как бы не-настоящий TS, но зато хорошо отключать хоть чипы, хоть каналы по одному\оптом.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
«Я делаю миниинтры (от 256б» — хотелось бы продолжать верить, что в sizecoding вплоть до 512 байтов никакие типовые упаковщики-распаковщики не используются.
Да, тоже этим занимался :) Хотя это очень быстро меня утомляет, экспоненциальный рост сложности такой оптимизации всё же парит :)
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
это можно делать ifdef и сразу несколькими вариантами кода в исходнике, потом автоматический перебор всех вариантов включенных/выключенных definе, автокомпиляция-упаковка каждого состояния, сравнение всех и автовыбор минимальной интры… ;)
Упаковщик Hrum в составе mhmt УЖЕ оптимальный. Нет, Hrust 1 объективно лучший пакер Пьянкова на данный момент. Но по сжатию их вроде выжали на 100%. Теперь есть запас только по скорости.
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
Для ловли блох такого рода, рекомендую пересобрать избранный оптимальный пакер, добавив к нему функцию печати итогового числа бит. Часто бывает, что есть 2-3 варианта кода, вроде примерно одно и то же, на итоговый размер в байтах не влияет, но в таком упаковщике с битами видишь, какой вариант был реально оптимальнее. Я много сберёг используя такой подход в «Down with the rules». Очень много циклов развернул и т.д. У меня гораздо больше итоговый неупакованный размер интры, по сравнению с тем, что делал ты. Подозреваю, что на 4кб должно получаться 6-7кб кода «оптимизированного под упаковщик». Например, вместо декранчера писать хорошо жмущийся код — ну, ты понимаешь.
Т.е. для себя я сделал такой вывод: нужно переписать Hrust 1 и Hrum для работы с битовым потоком в байтах (вместо битов) и переписать их распаковщики примерно по той же схеме, по которой написаны сейчас ApLib, Exomizer и ZX7. Думаю, это уменьшит их размер Hrust 1 и сделает его вполне конкурентными в чём-то вроде 4K; в случае с Hrum я думаю больше смысла пытаться конкурировать с пакерами типа ZX7, т.е. брать размером распаковщика и скоростью распаковки.
Чото подумал, если все так хотят реальных чипов, чо б не сделать девайс в формате «бутерброда».
Плюсы:
— вставляется в панельку, отстутствует шлейф, приводящий шину данных з80 в состояние «кровь-кишки-говно-распидорасило»,
— занимает меньше места в пространстве.
Минусы:
— чуть габаритнее по высоте и совсем чучуть по ширине.
— чипы видимо придется запаивать — панельки особого смысла не имеют (как доставать нижний чип?).
И тредом, и делом =)
Спасибо большущее.
(СОХРОНИЛ)
В следующем материале попрошу разобрать проблему, каждую осень волнующую неокрепшие умы — «Bruteforce sizecoding на своременных вычислительных мощностях: вкалывают роботы, а не человек!»
А вообще, компрессия — реально другой способ делать size-intro. Требует другие навыки, во многом ортогональные нормальному size-coding. Поэтому, с моей точки зрения, это скорее способ поддержать основы, путём увеличения видового разнообразия.
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
возможно, возможен «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 байта уберет.
;)