Вектор-06Ц: Средства разработки

[Improver]

Improver, https://github.com/svofski/bin2wav/b...r/tape.js#L383

Спасибо. Значит, там так:
- 256 нулей
- 0E6h -- синхроимпульс
- старший и младший байты адреса начала данных
- старший и младший байты адреса конца данных
- собственно, сами данные
- 1 байт -- контрольная сумма данных
- 11 байт -- имя файла
- 1 байт -- контрольная сумма имени файла + контрольная сумма данных

Я всё верно расшифровал?
А какая скорость используется по-умолчанию для вывода потока?

[svofski]

Да. По сути это подвид формата РК, отличаются контрольная сумма и приписка в виде имени файла.
Про скорость не знаю. На слух

[ivagor]

Думаю заинтересованные лица знают, что из современных PCшных упаковщиков на векторе (8080) есть
1) exomizer2 - сжимает лучше всех (аналогичного класса), но очень медленный распаковщик.
2) MegaLZ - достаточно хорошо сжимает, b2m написал быстрый распаковщик
Почитал обзор и решил дополнить палитру быстрым распаковщиком - LZ4. Кроме того, распаковщик получился еще и компактный.
Поверхностное сравнение. Исходный файл - Тест устройств, 25600 байт.
Сжатие (только данные, без распаковщика):
1) exomizer2 - 14976 байт
2) MegaLZ - 15727 байт
3) LZ4 - 18094 байта

Размер распаковщиков:
1) exomizer2 - 239 байт
2) MegaLZ (слегка оптимизированный вариант b2ma) - 207 байт
3) LZ4 - 106 байт

Скорость распаковки:
1) exomizer2 - 16945332 тактов (в 8.2515 раз медленнее unlz4)
2) MegaLZ - 3634808 тактов (в 1.77 раза медленнее unlz4)
3) LZ4 - 2053600 тактов

unlz4 легко можно подсократить, но скорость несколько упадет.

[Improver]

Поигрался я в МДОСе командами "2", "3" и savedos... Запишу тут, чтобы не забылось:
- начальный адрес всегда 0100h.
- длинна файла всегда округляется до кратной 256, при этом savedos дополняет файл нулями, а в случае команды "3" файл дополняется мусором из памяти/диска.
- скорость по-умолчанию соответствует скорости в бейсике, мониторе и т.п. и равна длине короткого полупериода в 376 мкс.

Интересно будет сгенерить файл с другим начальным адресом, или не кратной 256 длинной -- проглотит ли его мдос? ;-)

[ivagor]

Вчера попробовал дожать LZ4. Чуть сократил (до 103 байт), чуть-чуть ускорил. И решил еще накропать вариации распаковщиков. В итоге их 4: compact (89 байт), normal (103 байта), fast (154 байта), faster (170 байт). Протестировал на 3х файлах: xorz (маленький, рыхлый); тесты устройств (средний, рыхлый); колобиха+ (большой, плотный, он уже сжат каким-то векторовским упаковщиком).
Для краткости результаты скорости только в сравнении с megalz (с exomizerom по скорости сравнивать нет смысла):

Скрытый текст

Колобиха+ (исходно 34688 байт, megalz - 31298 байт, lz4 - 32191 байт)
lz4 compact в 1.9621 раз быстрее megalz
lz4 normal в 2.1978 раз быстрее megalz
lz4 fast в 2.4591 раз быстрее megalz
lz4 faster в 2.6731 раз быстрее megalz

Тест устройств (исходно 25600 байт, megalz - 15727 байт, lz4 - 18904 байта)
lz4 compact в 1.6046 раз быстрее megalz
lz4 normal в 1.7823 раз быстрее megalz
lz4 fast в 2.0191 раз быстрее megalz
lz4 faster в 2.0579 раз быстрее megalz

Xorz (исходно 6390 байт, megalz - 3048 байт, lz4 - 3802 байта)
lz4 compact в 1.4573 раз быстрее megalz
lz4 normal в 1.6348 раз быстрее megalz
lz4 fast в 1.8610 раз быстрее megalz
lz4 faster в 1.8610 раз быстрее megalz

[свернуть]

Коротко:
1) Даже самый компактный (и медленный) распаковщик и даже на не очень "удобном" файле примерно в полтора раза быстрее megalz;
2) В удачных случаях выигрыш в скорости может превышать 2,5 раза;
3) Преимущество unlz4 в скорости тем больше, чем хуже запаковались данные.

[Improver]

Тапир взаимно.

svofski, похоже, я обнаружил несущественную багу в тапире... На форматах cas/mon (и оно же бейсик по bload) в самом конце записи на графике показывается не контрольная сумма, а старший байт начального адреса:



Вот для опытов две вав-ки с идентичным содержимым, только одна грузится с адреса AA00, а вторая -- с CD00:Test_mon_bas.rar
Контрольная сумма в обоих должна быть равна 080h, и это даже можно увидеть по одинаковым "волнам" в конце графика, а вот показывается в красном прямоугольнике совсем не то число. Я чуть голову не сломал, пытаясь понять, почему так...

[ivagor]

Еще один декомпрессор, теперь суперкомпактный, на базе ZX7 Mini. Переписал для 8080 только вариант "обратного" распаковщика (опция back при упаковке), т.к. он лучше перекладывается для 8080 (короче и быстрее), хотя несложно реализовать и прямой распаковщик. Предлагаю 2 модификации: compact (53 байта) и normal (57 байт).
По степени сжатия - Тест устройств ZX7 Mini упаковал с 25600 до 17730 байт, т.е. чуть лучше LZ4, но, например, колобиха+ совсем не упаковалась, т.ч. тут надо смотреть конкретные случаи.
Скорость распаковки на примере Теста устройств:
compact - 3301972 такта
normal V4-5 - 2586572 такта
Т.е. быстрее MegaLZ, но медленнее LZ4.

[ivagor]

Финальный комплект ZX7 Mini. К "обратным" вариантам добавил на условной трансляции прямые, они на 3 байта длиннее и чуть-чуть медленнее. Вариант в предыдущем посте оставил, т.к. там без условной трансляции и легче адаптировать к другим ассемблерам (я использовал tasm).
Уникальная фича - добавил стековый распаковщик (только прямой). Он самый быстрый из ZX7m (хотя и медленнее LZ4), но не в этом основная фишка. Он может распаковывать прямо с квазидиска, я закомментил в исходнике соответствующие настройки. Я делал стековый распаковщик MegaLZ, но пока его не выкладывал и он намного медленнее и длиннее (данные на другом компе, сейчас не могу назвать точные цифры).
Недостаток стекового распаковщика - он разбух до 86 байт и прерывания на время его работы конечно должны быть запрещены.

[ivagor]

Пока я в теме и руки помнят, адаптировал для 8080 еще два распаковщика - ZX7 (полный, не mini) и Aplib. Почитать про них можно все по той же ссылке.
ZX7 сжимает почти на уровне MegaLZ, но распаковщик получился в 2 раза компактнее, хотя и в полтора раза медленнее.
Aplib - крутая штука, круче жмет только exomizer. Размер упаковщика получился немного меньше MegaLZ, но работает, увы, в 2 раза медленнее. Но все же в 2 раза быстрее текущего распаковщика exomizera для 8080, т.ч. если критична именно степень сжатия, то можно и Aplib использовать.

Upd 09.05.2020: убрал старую версию распаковщика aPLib/aPack, новая здесь

[Improver]

Возникла такая идея: а что если на основе одного из этих упаковщиков создать и внедрить в ОС некую систему динамического сжатия содержимого КД (и/или флопиков), по типу, как это делал ранее dblspace/drvspace, или их аналог stacker? Было бы прикольно...