• avatar tsl
  • 0
Ахахаха =)
LZ4 optimal        | 9804 (9791 если удалить заголовки)
Т.е., видимо, есть смысл посмотреть на TLZ.
  • avatar Vitamin
  • 1
В любом случае, спасибо за дополнительные данные — тем более что наблюдения по коэффициентам сжатия вполне совпадают, насколько я вижу.
Приложи пожалуйста сам файл — я хочу добавить цифру для LZ4 — т.к. сейчас очень большая лагуна между LZ4 и всем остальным. Интересно посмотреть, какие байтовые пакеры жали получше — думаю, мне бы не помешал упаковщик нацеленный на быструю распаковку, но нацеленный на нашу платформу (LZ4 достаточно ощутимо неэффективен по формату, ну и сам формат не вполне удобен для Z80).
  • avatar Vitamin
  • 3
RLE не считалось позорным алгоритмом сжатия!
Pack2 так делает. Еще и задом наперед.

Байтовые упаковщики встречались иногда в 1990е, но быстро проиграли смешанным битовым-байтовым пакерам, т.к. не могли конкурировать по коэффициенту сжатия.
CharPres. Настолько херово жмет, что им по два раза жали:)

Offtopic.
Нарыл у себя в тестах немного данных по разным архаичным и не очень упаковщикам.

16384 байта TR-DOS Ver 5.03 (md5 0da70a5d2a0e733398e005b96b7e4ba6)

Пакер              |Сжатый размер
-------------------+-------------
ESV Cruncher mode 1| 14262       
ESV Cruncher mode 2| 14108       
ESV Cruncher mode 3| 14018       
ESV Cruncher mode 4| 14039       
ESV Cruncher mode 5| 14130       
HRiP (Hrust2.3)    |  8632       
Hrum               |  8928       
LZH1               | 10211       
LZH2               |  9865       
LZS                |  9917       
MegaLZ greedy      |  8849       
MegaLZ optimal     |  8776       
Pack2              | 11626       
TLZ1               |  9711       
TLZ2               |  9750       
Trush              | 14299       
RARv2 -m1          |  8283       
RARv2 -m2          |  8282       
RARv2 -m3          |  8222       
RARv2 -m4          |  8220       
RARv2 -m5          |  8223       
RARv2 -mm          | 13360       
ZIP -p1            |  8491       
ZIP -p9            |  8369                   
ZXZip fast         | 11103       
ZXZip normal       |  8712       
ZXZip slow         |  9964       

Размеры со всеми заголовками и депакерами (если без него нельзя). Для архивов — размеры блока файла со всеми заголовками.

Так получилось, что CodeCruncher3 и Data SQueezer тестировались на других данных, поэтому в сравнении не участвуют.
Показ работ — точно. Возможно еще будет плавающая камера с феста. И если найдется кто-нибудь — стрим от первого лица =)
Она пакует задом наперёд. Это упрощает распаковщик (на несколько байт), плюс, не нужно так же много возиться со стеком, так что и побыстрее распаковка. Выигрыш/проигрыш зависит только от конкретного набора данных, как повезёт. По сути — один хрен. По-хорошему, нужно было встраивать опцию упаковки задом наперёд в ZX7, как это сделано в Exomizer, но Einas — довольно странный чувак.

Главное достоинство распаковки задом наперёд — можно иметь кодовый блок заканчивающийся на самом верху памяти и распковывать внахлёст просто загрузив упакованный блок так, чтобы его начало оказалось немного ниже начала распакованного блока. В 1990е я написал несколько пакеров на спектруме; они были очень примитивные, но паковали они все задом наперёд как раз из-за того, что я переделывал мультифейсные кассетные релизы и мне часто бывало нужно распаковать в упор до конца памяти.
Отличная статья.
Немного скажу за zx7. Cуществует версия пакера zx7b * Modified in 2013 by Antonio Villena, какие то файлы жмет лучше, какие то хуже, но думаю автора депакера хуже бы делать не стал? Он сам ей всегда и пользуеЦЦа.
Ты просто не представляешь, сколько раз я посоветовал людям попробовать ApLib, и получить в ответ жалобу, что «при распаковке всё вылетает».
  • avatar tsl
  • 1
Я просто ВСЕГДА либо запрещаю прерывания, либо ставлю свой ISR (на IM2, либо же на IM1, если по #0038 мое ПЗУ или ОЗУ). Думал, все так делают =)
Спасибо, сейчас посмотрю, как там пишется Hrum, чтобы сделать нормальный распаковщик.
  • avatar tsl
  • 2
Оригинальный репозиторий MHMT, бывший в открытом доступе на длкорпе, кажется.
Потому что спектрумовские прерывания Бейсика (которые IM 1) модифицируют системные переменные через IY. Поэтому, если взять распаковщик использующий IY и не запретить прерывания — Бейсик будет гадить вокруг текущего значения IY, что может дать большое кол-во непредсказуемых багов. Ошибка, конечно, детская, но неприятная и распространённая.

В принципе, мне бы нужно было точно так же сказать про HL', потому что если в HL' неправильная величина, вернуться из распаковщика в Бейсик будет затруднительно.
  • avatar Vitamin
  • 0
Из бейсика не вызовешь депакер напрямую
  • avatar tsl
  • 0
Отличная статья.
А почему «внимание IY»? =)
  • avatar diver4d
  • 0
Сохранить в BASin в TAP, загрузить в эмуляторе с поддержкой TAP и TRD, сохранить в TRD.
Через сохранение в SNA не всегда получается, unreal, например подвисает на снапшотах из BASin.
  • avatar diver4d
  • 2
Очень подробный и крутой материал, спасибо!
  • avatar mr287cc
  • 0
.
  • avatar boris
  • 0
Всем привет! Просьба помочь человеку с игрой. Написал на basein и теперь не знает как перевести ее в tr-dos формат. Кто знающий подскажите!