On at 2026-06-30 12:06:43 +0000, Crefelean Nicolae via Freedos-devel <[email protected]> wrote: >Hi, >About the floppy edition: please consider creating a special set for pre-386 >PCs by using LZ4_8088. > >Link: http://www.oldskool.org/pc/lz4_8088 > Important Q&A here: > >Q: Is this code faster than the LZ4 C source code? >A: For 8088-80286 CPUs, yes. For 386+, no, because the 386 has 32-bit >registers, additional segment registers, and additional instructions. >Compiling the LZ4 C code with a suitable 32-bit compiler will produce code >that definitely outperforms this 8088 assembly code. > >On the licensing side, it's basically FOSS, but you can read that bit on the >URL I mentioned.
I disagree, it uses a bespoke license that I think is incompatible with the GPL. The license text in full reads: === License The LZ4 library is provided under the BSD License. However, my code was not derived from any of the original LZ4 code so I can provide it via any license I choose. So, I am providing my code under what I am calling the Demoscene License. The Demoscene License grants you the following rights: * You are free to use this code in any production, commercial or otherwise, without providing remuneration to the author. * If you use this code, you must greet "Trixter/Hornet" if used in a demoscene production, or "Jim Leonard" if used in a normal program. Also, you must send email to [email protected] telling him you used the code so he can marvel at your result. === I think this is nonfree because it fails the desert island and dissident tests known from the DFSG, and I think it is also incompatible with the GPL. The "greet" part could be argued to be fulfilled by retaining attribution in derivatives, hence compatible with FLOSS. But the last sentence doesn't seem compatible to anything. > The project has also been maintained throughout the years, with a release as > close as 2024, so maybe someone can reach out to the guy and chat about a > proper FOSS license or anything else. :) Feel free. I'm aware that this depacker is much faster than my LZ4 depacker, although I believe this one doesn't support segmented addressing for files >64 KiB whereas mine does. >Cheers, >Nick The remainder of this message is about building a kernel file that's lDOS flavour, containing a FreeDOS kernel. Here's how to use my scripts to build an lDOS flavour kernel file, given a bash shell, Netwide Assembler, the required packers, and an existing FreeDOS kernel file (should be not compressed for useful results): for repo in lmacros ldosboot scanptab inicomp kernwrap lfreedos; do hg clone https://hg.pushbx.org/ecm/$repo; done cd lfreedos cp -iat . ~/proj/kernel/bin/kernel.sys INICOMP_METHOD="lz4 lzsa2 lzd" ./mak.sh I uploaded the results of this above scriptlet to our server [1]. Here's the file sizes of the compressed files: test$ ls -lgG */*/freedos.{com,sys} -rw-r--r-- 1 67472 Jun 30 20:01 tmp/lz4/freedos.com -rw-r--r-- 1 63712 Jun 30 20:01 tmp/lz4/freedos.sys -rw-r--r-- 1 56624 Jun 30 20:01 tmp/lz/freedos.com -rw-r--r-- 1 52864 Jun 30 20:01 tmp/lz/freedos.sys -rw-r--r-- 1 60176 Jun 30 20:01 tmp/sa2/freedos.com -rw-r--r-- 1 56416 Jun 30 20:01 tmp/sa2/freedos.sys test$ These are the LZ4, LZSA2, and LZMA-lzip compression methods. The ones used can be configured using the INICOMP_METHOD and INICOMP_WINNER variables to mak.sh, either specified in the environment or in cfg.sh or ovr.sh -- see cfg.sh for all supported methods, there's a bunch. The script in kernwrap indicates the tools used by each method. The .com files are lDOS iniload files, in which the initial loader allows use as a number of different kernel formats [2]. This format allows running the file as a DOS application as well, however the file resulting from this exercise will fail to load as an application (with an error message) because there's no application mode image specified. The .sys files are lDOS drload files, which is a different outermost stage that can only be loaded as an Enhanced DR-DOS or FreeDOS kernel file. The advantage is that it's about 4 kB smaller. On the blog there's a few mentions of LZ4, such as [3] and [4] (look at the comments of this for useful data). I didn't include LZ4 for some other benchmarks on the blog. If anyone is interested I can test the FreeDOS kernel files specifically, including an LZ4 method, on 4 systems: non-KVM amd64 Linux server, KVM amd64 Linux desktop, i686 DOS desktop, and an HP 95LX. One thing that doesn't work yet is to use the kernel config block / SYS CONFIG for configuring the kernel file, as SYS expects this to live at the beginning of the file, and lDOS's inicomp stage doesn't transfer it to the kernel payload. There is some prior work in inicomp to pass along an lDOS lCFG block, which could be adapted for the FreeDOS CONFIG block. Using drload it would be possible even to place the in-use CONFIG block exactly where SYS CONFIG expects it. If there is interest for that I could produce some updates to do so, but I'd like other kernel developers to chime in on the possible SYS changes. All the repos used here are accessible from our hgweb [5] or from the backups.hg directory [6] (load a file named 20260630 or later, which will be available later today, the lFreeDOS repo isn't included in prior files as I created it today). Regards, ecm [1]: https://pushbx.org/ecm/test/20260630.2/ [2]: https://pushbx.org/ecm/doc/ldosboot.htm#iniload-modes [3]: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2025/0717_lzexe_data_compression_format?s[]=lz4 [4]: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2022/0807_ldebug_caught_up_with_freedos_debug_and_ancient_change_log?s[]=lz4 [5]: https://hg.pushbx.org/ecm/ [6]: https://pushbx.org/ecm/backups.hg/ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
