User Tools

Site Tools


blog:pushbx:2022:0807_ldebug_caught_up_with_freedos_debug_and_ancient_change_log

lDebug caught up with FreeDOS Debug, and ancient change log

As mentioned in the prior blog post lDebug very much has a "go everywhere, do everything" theme. Today we're caught up with FreeDOS Debug again for the most part. (Still missing is the patch to use the test_high_limit function where appropriate. It is nontrivial to decide which spots should use that function instead of test_d_b_bit, which was renamed from testattrhigh.)

The recent changes include adding a Protected Mode interrupt 41h handler (build option that is default disabled), outputting to the active video page in ROM-BIOS I/O mode, adding a build option (also disabled) to use ROM-BIOS video page switching for video screen swap (vv), adding the _FORCETEXT build option (also disabled), catching SysReq keypresses (untested, and also disabled by default), and the _ALTVID build option (default enabled!) and its switch /2 to output the debugger interface to a secondary screen. (Tested with 86Box's dual-screen setup that creates two windows on the host.)

Other than that we also have some other changes: DCO6 option 200h will enable usage of ROM-BIOS I/O without enabling InDOS mode for everything else. This is useful to write change highlighting attributes to the screen using interrupt 10h, but retaining DOS access for things such as loading program files. An earlier vv change made it so that sometimes text was displaced by 80 columns in dosemu -dumb -td -kt mode. The options help pages were expanded to allow selecting just one option variable, eg ?o3 to display only DCO3 option flag bits. And the new INT8CTRL variable allows configuring the duration (in ticks) of the Control pressed check in the interrupt 8 handler. In particular, setting it to zero will disable the Control pressed check, which allows to use interrupt 8 for double Control-C across serial detection without the Control pressed check interfering when not desired.

We also made it so the current releases will choose the LZSA2 compression method as the "winner" from now on. This is a better tradeoff for running on old hardware because it is much faster than the LZMA-lzip depacker. Internally we used to use only LZ4 for a while during development and testing, but it appears to be both slower and larger than LZSA2. (For example, LZ4 manages a 75.94% file size with 1048ms per run, where LZSA2 manages a 67.45% file size with 1044ms per run. Tested using a command like INICOMP_SPEED_TEST=1 INICOMP_WINNER=fastest INICOMP_METHOD="lz4 lzsa2" ./mak.sh.)

Less recent changes include aborting RC buffer execution with Control-C and omitting the default operand of aam and aad instructions in the disassembler. Furthermore, a crash or infinite loop upon encountering the end of a stdin-redirected script file was fixed. That bug was caused by the recent additions of the QA command, and the QB, QC, and QD modes to the qq command.

Finally, a recent trip down memory lane unearthed an old log file of NDebug (the prior name of what became lDebug, a la "Netwide Debug" to go with NASM's "Netwide Assembler"). It is listing changes made to it since as early as 2009 March. Unfortunately, the sources of these early days appear to be lost. It is dated 2010-10-21, mere days before the Mercurial repo's initial commit on 2010-10-24.

Discussion

C. MaslochC. Masloch, 2022-08-12 15:25:09 +0200 Aug Fri, 2022-08-12 18:09:29 +0200 Aug Fri

Oops. Reviewing this I found that INICOMP_SPEED_TEST=1 not only enables speed testing, it also selects the amount of runs to perform. Performing just 1 run will be strongly influenced by the start up costs of the virtual machine. I redid the test (on lDebug hg 59cda96de21d, in dosemu2 using KVM) with INICOMP_SPEED_TEST=4096 INICOMP_WINNER=fastest INICOMP_METHOD="lz4 lzsa2" ./mak.sh and the result was as follows:

ldebug/source$ cat ../tmp/debug.siz
  108544 bytes (100.00%), method             none
   82432 bytes ( 75.94%), method              lz4
   73216 bytes ( 67.45%), method            lzsa2
ldebug/source$ cat ../tmp/debug.spd
   14.99s for 4096 runs (   3ms / run), method              lz4
    7.47s for 4096 runs (   1ms / run), method            lzsa2

I wasn't wrong about LZSA2 actually being faster, but it is more dramatically faster (about as much as 2 times as fast) and the number given in this post was completely wrong and irrelevant. (The revised number may also be dominated by output speed but there is certainly a difference between LZ4 and LZSA2.)

C. MaslochC. Masloch, 2022-08-12 16:32:17 +0200 Aug Fri

Here are the results building the same revision on the server hosting this blog, which is running dosemu2 without access to KVM:

ldebug/source$ cat ../tmp/debug.siz
  108544 bytes (100.00%), method             none
   82432 bytes ( 75.94%), method              lz4
   73216 bytes ( 67.45%), method            lzsa2
ldebug/source$ cat ../tmp/debug.spd
  353.41s for 4096 runs (  86ms / run), method              lz4
  139.65s for 4096 runs (  34ms / run), method            lzsa2
ldebug/source$
You could leave a comment if you were logged in.
blog/pushbx/2022/0807_ldebug_caught_up_with_freedos_debug_and_ancient_change_log.txt · Last modified: 2022-08-07 00:50:36 +0200 Aug Sun by ecm