Is compbdos optional?

[ecm-pushbx]

If I try to run with a drdos file that's not processed by compbdos the load seems to crash when it should call into the DOS in drbio/biosinit.a86 around https://github.com/SvarDOS/edrdos/blob/ac2d823fc9f96e423b22e8e263c4c1b52d4c7cfd/drbio/biosinit.a86#L433

Can you confirm this? If yes, I consider this a bug.

(Aside: I just uploaded my 2024 March revision of the kernel, current build will be updated in 24h from now. Picked the kernel patches. Didn't bother with updating the shell though. I did port compbios and compbdos to work with the ia16 gcc / libi86 though.)

[ecm-pushbx]

I studied the files and compbdos some more. The following command will create a usable uncompressed drdos file without compbdos:

dd if=drdos/bin/drdos.pag of=drdos.tra bs=1 skip="$(head --bytes=2 "drdos/bin/drdos.pag" | od -An --endian=little -t u2)"

I just looked for what I noticed in compbdos and found that you commented this already:

https://github.com/SvarDOS/edrdos/blob/ac2d823fc9f96e423b22e8e263c4c1b52d4c7cfd/ltools/compbdos.c#L28-L35

But I noticed it here: https://github.com/SvarDOS/edrdos/blob/ac2d823fc9f96e423b22e8e263c4c1b52d4c7cfd/ltools/compbdos.c#L87-L90

[ecm-pushbx]

The savings from not compbdosing the drdos module is small. However, we could probably disable the code in biosinit.a86 that depacks the drdos module for a little more space saved.

edrdos/repo$ ./mak.sh onlypl -D_PAYLOAD_DOS_FILE="'drdos.tra'" && ls -lgG edrpack.sys
  edrdos.bin:  1.903:1, 52.55% ratio, 47.45% saved, 81264 in, 42702 out.
...
-rw-r--r-- 1 45696 Mar 29 01:10 edrpack.sys
edrdos/repo$ ./mak.sh onlypl -D_PAYLOAD_DOS_FILE="'drdos.sys'" && ls -lgG edrpack.sys
  edrdos.bin:  1.778:1, 56.25% ratio, 43.75% saved, 75936 in, 42712 out.
...
-rw-r--r-- 1 45712 Mar 29 01:10 edrpack.sys
edrdos/repo$

[ecm-pushbx]

I added an "uncompressed" mode to compbdos for simplicity: https://hg.pushbx.org/ecm/edrdos/rev/840efe839234

I didn't use this yet as drdos.pag in my build is perfect for use as the ident86 before and after build artefact. BTTR Software seems to be down currently so let me mention that I started identicalising the JWasm port of the drdos module today. I eventually started adding the (newly added) ident86 stats lines to the changeset messages, like so:

Identicalised using ident86 7286a3e9be0f, using a trace listing file generated by tractest/convlist.pl aba03f97df32.

Amount different bytes: 122 Amount different lines: 0 Amount not different ranges: 38

[boeckmann]

Not exactly sure how to interpret the ident86 stats. Different lines = 0 while amount diferent bytes = 122 means "only" encoding and / or address changes? Did you encounter some conversion bugs so far? Did Robert forget to renew the domain name contract? :D

[ecm-pushbx]

Not exactly sure how to interpret the ident86 stats.

Documentation is severely lacking yet, as you may have found =^y

Different lines = 0 while amount diferent bytes = 122 means "only" encoding and / or address changes?

Only encoding, such as which operand of an inst reg, reg instruction is the ModR/M operand. However, it also detects different-length encodings of effectively the same instruction (eg and di, FFF0 vs and di, -10) and will accept this as zero different lines if the shorter side is padded with a trailing NOP (or potentially more of them though I don't think this ever is possible yet).

Address changes other than inserting needed NOPs always cause differing disassembly lines to be displayed and counted. A differing line may differ in the address (6-hexit wide and file based), length, and/or instruction disassembly text. If a differing line happens in a range, the entire remaining area in this range is disassembled. However, lines in which "second:" is marked "samesame" do not count as differing lines.

The "no difference" lines indicate that an entire range is found to disassemble to equivalent instructions. (Ranges are delimited by 16 bytes without a byte difference as x86 instructions cannot exceed 16 bytes.) The number of times this happens is "Amount not different ranges".

Did you encounter some conversion bugs so far?

Just the usual problems with renaming/editing in the same commit and details like commits containing unrelated changes not described in the commit message. And compat.def and a request.equ addition both happened after the commit that makes use of them.

I think one segment directive specified the alignment as word which threw off the addresses, I changed it to byte alignment.

Did Robert forget to renew the domain name contract? :D

Don't know, he did take note of my informing him around 14:00 today though. Told me he doesn't have time to look into it right now.