ecm 2026-07: Use LZSA1 or LZSA2 compression for crab-type flags

[ecm-pushbx]

As previously discussed in #4 I want to replace the lz4_8088 depacker, mainly due to the incompatible usage conditions.

This PR switches to use the LZSA2 or LZSA1 formats. The depackers are provided in https://hg.pushbx.org/ecm/vgadepak/file/356876ae6503

The usage conditions of these are inherited by the original 8086 LZSA depacker, reading as a zlib license as follows:

; 8086 Assembly LZSA2/LZSA1 depacker
;  by E. C. Masloch, 2021, 2026
;
;  based on:
;  decompress_small.S - space-efficient decompressor implementation for 8088
;
;  Copyright (C) 2019 Emmanuel Marty
;
;  This software is provided 'as-is', without any express or implied
;  warranty.  In no event will the authors be held liable for any damages
;  arising from the use of this software.
;
;  Permission is granted to anyone to use this software for any purpose,
;  including commercial applications, and to alter it and redistribute it
;  freely, subject to the following restrictions:
;
;  1. The origin of this software must not be misrepresented; you must not
;     claim that you wrote the original software. If you use this software
;     in a product, an acknowledgment in the product documentation would be
;     appreciated but is not required.
;  2. Altered source versions must be plainly marked as such, and must not be
;     misrepresented as being the original software.
;  3. This notice may not be removed or altered from any source distribution.

To assemble the depackers, use either of the following commands:

nasm -f obj lzsa.asm -D_LZSA1=1 -D_LZSA2=0 -l lzsa1.lst
nasm -f obj lzsa.asm -D_LZSA1=0 -D_LZSA2=1 -l lzsa2.lst

Changes in the VGAPride repo include:

• The planize.py script calls LZSA with -f 1 or -f 2, and emits .sa files. It also uses the -N switch currently, which requires a patch I submitted to ecm eod marker, capital -M and capital -N switches, and -S switch (more compatible block limit) emmanuel-marty/lzsa#74
• display.cpp calls lzsa_depack with as yet same protocol as lz4_depack
• vgapride.cpp refers to lzsa rather than lz4
• Turbo C project files include linking of lzsa.obj rather than assembling lz4_8088.asm
• planize.py also emits the uncompressed files, which was useful during debugging
• I had to set the compiler include and library directories to E:\TC\ to work in my setup. You may want to not include that.

I prepared a diskette image in https://pushbx.org/ecm/test/20260728/ with VGAPRIDE.EXE from https://github.com/foone/VGAPride/releases/tag/v0.6 and vgalzsa1.exe and vgalzsa2.exe which I tested as a remote diskette in https://www.pcjs.org/machines/pcx86/compaq/deskpro386/vga/ The LZSA2 build runs noticeably slower than the lz4_8088 one, LZSA1 is much closer in speed.

Here's the file sizes:

test/20260728$ ls -lgG
total 2516
-rw-r----- 1  224573 Nov 25  2022 20221125.exe
-rw-r--r-- 1 1474560 Jul 28 20:09 diskette.img
-rw-r--r-- 1      26 Jul 28 20:09 revision.txt
-rw-r----- 1  245399 Jul 28 19:16 vgalzsa1.exe
-rw-r----- 1  239239 Jul 28 20:08 vgalzsa2.exe
-rw-r--r-- 1  126580 Jul 12  2023 vgapride_0.6.zip
-rw-r--r-- 1  255283 Jul 12  2023 VGAPRIDE.EXE

255 kB for lz4_8088, 245 kB for LZSA1, and 239 kB for LZSA2.

Using raw LZSA blocks would allow to save a bit of data and some code, and we wouldn't have to depend on the -N switch. On the other hand, non-raw LZSA streams allow dispatching for the variant (LZSA2 vs LZSA1) so a single depacker function could handle both formats.

I am also interested in benchmarking the depackers on several different systems, for which I may re-use some of the code I added to inicomp. Further, display.cpp and the VGA commands format could be extended to pass along the buffer sizes to the depacker, which would allow a useful _UNSAFE=0 build which actually checks for buffer overflows. Finally, the display.cpp caller currently does not check the depacker's return value.