SvarDOS community forum

Hi, perhaps some of you did not already know this: As of 6th July 2022, the current license holder of CP/M and its derivates (DR-DOS) placed the software under a truly free license. Long ago, when Caldera DR-DOS was open source but no free software, Udo Kuhnt started a project called Enhanced DR-DOS. It includes enhancements to the DR-DOS Kernel source code from Caldera, supporting FAT-32 and a bunch of other stuff. This development is known under the name EDR-DOS. While Udo Kuhnt stopped developing EDR-DOS long ago, E. C .Masloch (aka ECM) continued to work on it in recent times. EDR-DOS being free software and getting some love recently, I created a SvarDOS package for the current version maintained by ECM. It can be downloaded from my Nextcloud, until it is either included in the SvarDOS package repository (if Mateusz is interested in), or I finally manage to put some proper Website in place. Instructions on how to switch to the EDR-DOS kernel and back to the default are provided in the package, along with a tool called DRSYS.COM, which is a modified SYS.COM from the FreeDOS kernel tree I compiled for use with the EDR-DOS kernel. https://nextcloud.iww.rwth-aachen.de/index.php/s/ZcDX9tFcDyTescs Perhaps someone is interested. I tested the kernel the last days. On my Pentium system, this works well. I think its always nice to have alternatives. Thanks to Mateusz for the excellent PKG tool. Bernd

Update: There seems to be some incompatibility between the SvarDOS command.com and the EDR kernel, leading to system freezes. I did not notice this until now because I use a different shell, 4DOS. So, be careful with combination of kernel and shell you are using. Confirmed to work: FreeDOS Kernel - SvarCOM EDR-DOS Kernel - EDR Command.com Both Kernels - 4DOS Further, I modified the README.TXT to make sure no-one overwrites his/her SvarDOS COMMAND.COM. Re-uploaded package as edrdos-20231116+1.svp.

Hello Bernd, Yes, I am very interested in this, and thank you for having looked this up. SvarDOS currently relies on the FreeDOS kernel, but it is not a design or ideological decision of any kind, I am very open to alternative kernels, as long as they are stable enough and reasonably compatible with MS-DOS. I see that your package contains both the kernel and command.com. Can those two work independently? That is - any chance to run the EDR command.com on FreeDOS kernel, or having the EDR kernel support SvarCOM? If so, then it would probably make more sense to have two separate packages, esp. since the SvarDOS package manager already knows how to handle a COMMAND.COM package. And then perhaps I should look into extending the pkg tool so it can install/switch also kernels. Did you test the EDR kernel extensively? Are there any obvious shortcomings or limitations when compared to the FreeDOS kernel? Is it superior in any way that you observed? (memory footprint maybe?) Mateusz P.S. You'r very welcome to push your work into the SvarDOS package repository, I'm very curious to see where this may lead

Hello Mateusz, the EDR command.com is currently locked to the EDR-DOS kernel. Sadly, SvarCOM and the EDR-DOS kernel seem to be somewhat incompatible. I first did not notice this, because when starting SvarCOM on top of 4DOS (my default shell) everything is fine. I will try to investigate this further. Regarding the EDR-DOR Kernel, let me quote ECM: "The EDR-DOS kernel, alike RxDOS and unlike FreeDOS, is written entirely in x86 assembly language. (The command.com shell utilises the C language in parts.) It fully supports FAT32 file systems and LBA int 13h disk access. Further, it supports FAT+ for file sizes up to 256 GiB minus 1 Byte on local FAT FS file systems. [...] Furthermore, the DR-DOS kernel is a highly compatible 8086 DOS beyond what is offered by FreeDOS. " On my Pentium, I did not notice such of a difference in performance or functionallity between both FreeDOS and EDR-DOS kernels. But on lower-end machines the EDR kernel may play out some benefits. I am only at the start of this voyage and open to suggestions how to improve the package. Before uploading to the repo, I will try to find out where the incompatibility between SvarCOM and the EDR-DOS kernel may come from. Bernd

> the EDR command.com is currently locked to the EDR-DOS kernel.

older builds by Udo doesn't very DR-locked besides DR-check (i.e. int 21h, AX=4452h and check return >= 1071h)

The current source version of EDR command.com should run on SvarDOS with the FreeDOS Kernel. I changed the version check to only issue a warning when not running under the EDR-DOS kernel. But honestly, I see no big use of it. FreeCOM and 4DOS seem more capable and stable. And there is also SvarCOM as the default shell, which should be sufficient for most uses. Matheusz, I lost track, are the EDR kernel related SvarCOM issues resolved? If it is working, I would make a new EDR kernel package for SvarDOS with the latest patches. The question is where to put the kernel files by default, root dir or some other place, perhaps under for example C:\KERNELS\EDR-DOS.

> are the EDR kernel related SvarCOM issues resolved?

Yes, albeit I still have not released a new version. But the trunk version works. It was all happening here: https://github.com/SvarDOS/bugz/issues/38 So I only need to release a new, proper SvarCOM version now. Will do so within the incoming week.

> The question is where to put the kernel files by default, root dir or some other place, perhaps under for example C:\KERNELS\EDR-DOS.

That's a good question. I do not think that it would be wise to install a new kernel automatically as there are too many things that can go wrong. It would probably be best to just download/unpack files in a directory and have some readme file that explains to the user how the given kernel is supposed to be activated, along with limitations (like no FAT32 support, different CONFIG.SYS syntax...) and risks. It might be better to keep the kernels close to the rest of SvarDOS files, so maybe %DOSDIR%\KERNELS\[EDR-DOS|FREEDOS|MSDOS2]? I think that such directory should be self-contained, ie. includes the kernel file(s), its documentation and possibly helper tools, if any (like a dedicated SYS tool). Mateusz

I uploaded the EDR kernel and command.com to the package repository. It installs to \svardos\kernels\edr-dos and is self-contained. The README.TXT describes how boot the EDR kernel. The package may be fetched via pkgnet: pkgnet fetch edrdos Or via browser: http://svardos.org/repo/?a=pull&p=edrdos Install it with: pkg install edrdos.svp. As it is a first release, this may show some unexpected behaviour.

You mean 'pkgnet pull edrdos', not 'fetch'. :-)

That is impressive work, thanks! I have pushed right now SvarCOM 2024.1, that is the version where I fixed EDR-DOS compatibility (with the invaluable help of ECM!). So there is no longer a need to have EDR kernel and shell bound together ;-) Mateusz

I successfully updated my machine to SvarCOM 2024.1. :-) (But I'm not using EDR-DOS.)

I updated the EDR package to include COUNTRY.SYS, and removed COMMAND.COM. The COUNTRY.SYS the EDR kernel expects does not have the same structure than the FreeDOS one. Currently, codepage 858 is not supported. My plan is to add this in one of the next releases.

This is very nice work, thank you! Do you have any plans for incorporating compression? Currently the EDR kernel's disk footprint is 73K (36+37), while the FreeDOS kernel.sys is 45K. Might not seem like much, but on floppies every sector counts. :) About COUNTRY.SYS: IIRC FreeDOS uses the "standard" MSDOS format for compatibility reasons. EDR is somewhat an odd duck here... Is there any reason (advantage) why it uses a custom COUNTRY.SYS format instead of whatever Microsoft designed back in the day? Mateusz

I see no obvious advantage of EDR using a different format for country.sys beside the following: it directly reflects the structure of the internal data structures, making reading it very straightforward. But this also means that if the internal structures change, country.sys has to be adapted. Its a little bit of a pitty... I would like to add compression support. ecm already tested her single-file kernel with compression. But she told it is VERY slow on old machines, making the boot taking several minutes. I tried compressing the files with the heatshrink algorithm https://spin.atomicobject.com/heatshrink-embedded-data-compression/. The resulting sizes are 22K for DRBIO.SYS and 33K for DRDOS.SYS. DRBIO is better compressed, because it still contains large padding areas willed with zero. DRDOS.SYS is only down by 4K. So conclusion is that heatshrink is not very good at compressing actual X86 machine code. But it may nevertheless be beneficial to use the algorithm. That could remove the depencency on two tools of the build process: compbios and compbdos. These strip most padding areas from the files (but not all). DRBIO contains code to actually uncompress these regions again. I made a re-implementation of both Digital Research tools under https://github.com/SvarDOS/edrdos/tree/main/ltools. But this as a whole is not such an elegant solution, because a) zero-stripping is handled slightly different for DRBIO and DRDOS and b) there are still areas of zero left. For DRBIO this is necessary because it may not contain zero-stripped areas in front of the decompression code. So idea is to perform the decompression (in whatever form) before actual kernel initialization, basically giving the kernel as a payload to the uncompression code. But have to think more about it...

There is another compression algorithm called exomizer https://bitbucket.org/magli143/exomizer/src/master/ This was originally targetted at 8-bit systems like C64. Decompression seems to be relatively fast. I test-compressed DRBIO and DRSYS with it: DRBIO.SYS: 18K DRDOS.SYS: 27K That looks promising :-)

follow up link for posterity: https://github.com/SvarDOS/edrdos/issues/28