#93 Status register flags in DEBUG.EXE - Could you provide an option to change the output of the flag registers to a better human readable form?
I know that DEBUG.EXE tries to be a 100 % replacement with identical behavior and look & feel of DEBUG.EXE from MS-DOS.
But there is one big problem in MS-DOS' DEBUG.EXE, the status register output is not very user friendly, and the same applies to DEBUG.EXE of FreeDOS.
As a user you have to know the meaning of the abbreviations when the status register values change.
In DEBUG.EXE the
Overflow Flag is called OV or NV, depending on the current value of the register.
The same applies to all the other registers:
Direction Flag = DN or UP
Interrupt Flag = EI or DI
Sign Flag = NG or PL
Zero Flag = ZR or NZ
Auxiliary Carry Flag = AC or NA
Parity Flag = PE or PO
Carry Flag = CY or NC
A typical output looks like this (for example after pressing r, t, or p):
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 NV UP EI PL NZ NA PO NC 0895:0100 8AE7 MOV AH, BH
This is not very user friendly and difficult to read. Especially for non English speakers.
If you don't know the abbreviations heart, you have to keep looking up which abbreviation stands for what. And when you work with it, errors creep in just because of the constantly changing names.
Thus could you offer an option in DEBUG.EXE to change the output format in a human readable form?
If you move the output of assembler directive (in this example "MOV AH,BH") a little bit to the left, then there is enough place to put zeros or ones directly under the status flag names and keep the flag names always the same.
That way the output could look like this and would be much more readable.
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 OF DF IF SF ZF AC PF CF 0895:0100 8AE7 MOV AH, BH 0 0 1 0 0 0 0 0
OF DF IF SF ZF AC PF and CF are the abbreviations of the status flag names and after the modification they always stay as they are, and only the value below in the next line changes.
OF = Overflow Flag Register
DF = Direction Flag Register
IF = Interrupt Flag Register
SF = Sign Flag Register
ZF = Zero Flag Register
AC = Auxualiary Carry Flag
PF = Parity Flag
CF = Carry Flag
And when then the CF and ZF changes, it would look like this:
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 OF DF IF SF ZF AC PF CF 0895:0100 8AE7 MOV AH, BH 0 0 1 0 1 0 0 1
Such an output is much easier to read and less error prone.
The 100 % compatibility to MS-DOS DEBUG.EXE could be kept, by providing this output with an option.
You could for example provide a command line parameter, lets call it /f for flags to change the output format of the status register flags from classic output to the new better readable one.
The user could then start DEBUG.EXE with:
debug /f
to have the new better and more readable and less error prone output format of the status register flags.
If this is not possible, because you need the free space in the third line of the output, you could as an alternative also just do it this way:
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 O0 D0 I1 S0 Z1 A0 P0 C1 0895:0100 8AE7 MOV AH, BH
In this case, the first char is the name of the status flag and the second char is its value which is 0 or 1.
And if the OF, SF and PF flag changes, it would look like this:
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 O1 D0 I1 S1 Z1 A0 P1 C1 0895:0100 8AE7 MOV AH, BH
And if you want improve that to make it easier to read, you could use a underline char _ instead of a 0 for the value zero. This would be easier to read, because it is easier to notice a change.
In this case, the output cold look like this:
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 O_ D_ I1 S_ Z1 A_ P_ C1 0895:0100 8AE7 MOV AH, BH
And when the IF and AC flag changes, it would look like this:
AX=0010 BX=00FF CX=FE2C DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=0885 ES=0885 SS=0896 CS=0895 IP=0100 O_ D_ I_ S_ Z1 A1 P_ C1 0895:0100 8AE7 MOV AH, BH
What do you think about this suggestion?
Sadly this edit field removed all the new lines between the code tags and i can't edit it.
New try:
A. Classic style:
B. New suggested style 1:
C. New suggested style 2 without the need for the third line:
D1. New suggested style 3 without the need for the third line and where 0 values are changed with an underline character:
D2. And when OF, ZF and CF changes in style 3:
Last edit: Oliver 2022-11-09
Could someone inform the developers at https://github.com/Baron-von-Riedesel/DOS-debug/issues about this feature request?
I don't have a github account to do it myself.
Just tell them about this feature request here.
Why don't you want to create a github account yourself? It is gratis, and to my awareness github isn't much worse or better than sourceforge.
Because github and also gitlab require too much to read and sign in their terms. And that's not worth it for me, just to be able to report bugs or write a feature wish.
It's like you have to sell your last shirt and then such terms are often changed so that you have to read everything again.
https://docs.github.com/en/site-policy/github-terms
Compare that to the terms and conditions of SourceForge and you'll see that SoureForge requires a lot less and is therefore far more user-friendly.
I had similar problems with this when I started using FreeDOS Debug/X. So in my fork I added a command that goes by
?Fwhich will display a nice table listing all the flag state names. You can view the text of this help page in the manual as well.It wouldn't be difficult to add your suggestions, at least the style 2 and style 3 suggestions you made. (Style 1 would be harder, and may need to adapt somewhat in case the disassembly would overlap this space.) However, I don't want to add those to my default builds because of the resident memory footprint. If you want I can prepare a build option of my debugger that enables it to output your style 2 or style 3 (or both). However, you would have to build the debugger from the sources or depend on a special build from me with this option enabled at build time in this case.
Went ahead and implemented the style 2 and style 3 in https://hg.pushbx.org/ecm/ldebug/rev/73873421b18d This is default off however, so you need to build from source with the option enabled to get it. The size of the code and data added for this is noted in the changeset message.
I enabled the style 2 and style 3 build options by default, you can get the current build at https://pushbx.org/ecm/download/ldebug.zip
You can enable the options with a command like
r dco6 or= 2000_0000and disable them withr dco6 clr= 2000_0000Sorry if I answer after many weeks, I've had a lot to do in the last few weeks. That's great news, thanks for that. I'll try the feature right away.
Ok, i tested your debug version and the features you added.
They work very well. In practice i think i like style 3 most.
However, the two options do not appear to be mutually exclusive. If I enter style 3 first and then style 2 without deactivating style 3, then the highest value in this case style 3 remains active because of the 4000_0000.
I also have a few suggestions:
I don't know why the user should enter such cumbersome commands just to change an option. This is not very intuitive and could be done much better. It could of course be due to memory shortages, but that's just a guess on my part.
Instead of
r dco6 or= 2000_0000why not just make it possible to enter something likeo.style=3, whereois for options, andstylethe name of the option and3the number to change the option?Another possibility would be to offer an options tree. In which you can navigate like in a file system with
cd optioncategorynameandcd ..and adircommand shows where you are at the moment and what options there are in this subtree and what their current value is.If you then want to set the option, it could look like this:
option/style/style_3=trueoroption.style.style_3=trueif you don't want to use a slash.Or just
style_3=true, if you are already inside the according subtree.With such an option tree feature you could reorganize all the options and it would all be much more intuitive because it would be intuitively accessible.
One would no longer have to enter any weird digits and numbers, just navigate into the options tree where one wants to change something, display it with
dirand then change the corresponding name entry withname=trueorname=falseor justname=1andname=0. And with a complete path specification, it would of course also be possible to do this from the root directory.And then there is one more thing. In my opinion, the help ? does have too many pages and when you reach the bottom, You have already forgotten what you read 2 pages above and what you actually wanted to type in.
As with the option tree, you could do the same with the help system and create a help tree to categorize all the help and in which you can then navigate with
cdas you are used to from the file system and view the entries withdir.Entering a debug command should be always possible no matter in which subfolder of the option or help tree you are.
Or alternatively, if a navigable help tree is too cumbersome following solution:
You could also divide the help in chapters and let the user select which chapter he wants to see a help page about. And this help page should be only 1 screen large with the possibility to enter a debug command at the bottom without scrolling the help page above to continuing normal debugging tasks.
Also, I would split the help display into three modes, so this could look like this:
If you only enter one question mark
?, you get a very spartan help with the basic combinations, as you know it from the classic debug and with the hint, that you can read more by entering??and???.If you enter two question marks, then the titles of all available chapters are displayed.
And if you want to display a chapter, then you give
?followed by the chapter name.If you enter three question marks, all chapters are shown in a tree like manner, like the tree command for files. That way, the user can see how they relate. And if you need sub-chapters, it's easy because it helps the user in navigating where he is. This tree view should pause per page and scroll.
Your debug program seems to be very feature rich, which I find very good But the intuitive operation and help could be greatly improved.
Yes, you have to disable style 3 to use style 2. This greatly simplified the implementation in https://hg.pushbx.org/ecm/ldebug/file/cedcd17efefa/source/rr.asm#l2245 because we can just use the R variable command to set or clear options in DCOx and have one of the options override the other.
I do actually have a few commands that are easier to memorise than modifying DCO variables using the R commands. They're documented in https://pushbx.org/ecm/doc/ldebug.htm#cmdinstall -- Would you prefer I add some more options to this command? Because this already has all or most code needed, most additional space would be used only in the data segment at https://hg.pushbx.org/ecm/ldebug/file/cedcd17efefa/source/msg.asm#l2012
This will definitely eat more memory and I don't think it is worth the work.
You can enter Control-C to the
[more]prompt to prematurely return to the debugger prompt, leaving most of the currently displayed help page readable. Other than that I am considering your suggestions for now.The DR-DOS 6.00 SID program actually did have two different help pages, one of which was accessed using
?and the other with??. I am considering this.Thanks for the feedback!
Yes, that would be a good idea.
Have you also thought about introducing a configuration file so that you have all the settings available directly when you start the program without having to configure LDEBUG first? A config file that is read at startup would be most practical in my opinion. Functions like a different representation of the flag register output or a highlighting of the registers changed after a debugging step would be things that I would always use. It would be practical if you didn't have to reconfigure that for every debugging session.
In the long run, I would suggest revising all the help and options settings and thinking about how to do this easily and intuitively and at the same time keep the memory footprint low.
If a larger conversion in assembler is too complex or takes too much time and you don't know exactly how to do it the best way in first place. A small mock-up in a time-saving scripting language such as Python could be helpful. And then with this, you could just try different methods and find out, what way or style works best in daily work and what doesn't.
And when you found the best method, you could integrate it into LDEBUG in assembler.
I understand.
That's a good tip. Thank you very much.
Yes,
SIDis the program that gave me this idea. Credit goes to Garry Kildall.BTW, in SID I found a few more features that could be integrated into FreeDOS's DEBUG or into LDEBUG, I just have to write the bug reports or wish lists for them.
You're welcome.
I understand the need for this, but I believe that this can be almost solved by using Script for lDebug files. For example in a blog post at https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2022:1217_new_95lx_setup_script_for_ldebug I listed my
95lx.sldwhich I usually run at startup of lCDebug on the HP 95LX. Instead of justlcdebugyou runlcdebug /cy95lx.sld, passing a Y command (to read an SLD) to the RC (command line) buffer for immediate execution. (The only commands that run before the RC buffer are N/K and L, if you specified a program to load on the command line.)May add it to the manual later.
I have a DR-DOS 6.00 manual (in german) that describes that system's SID somewhat. The pass points (permanent breakpoints with pass counters) are inspired by SID. I'm interested in learning what else you can think of, though. I'm not sure whether sf.net can do notifications or direct messages so I can keep up to date on your reports here, but if not you can just use the email address in my repos to tell me about any new tickets. Eg https://hg.pushbx.org/ecm/ldebug/rev/cedcd17efefa (look at the "author" field).
A script is better than nothing.
But I have an even better idea. Why not just define a default script filename that will be looked up in the
LDEBUGdirectory and run automatically every timeLDEBUGis started?Then you no longer have to enter
LCDEBUG YOURSCRIPT.SLDat every start. The name of the default script could be called for example justLDEBUG.SLDorDEFAULT.SLDAnd when the script file is missing, it is just ignored.
And if you allow to call a script from a script file ( i don't know if that is possible at the moment), the possibilities get even better.
Sourceforge does offer a private messaging system. I will inform you via that, as soon as i have written the bug/wishlist reports.
Last edit: Oliver 2023-06-25
I actually do something very much like that, but for now only for bootloaded mode. That's because some boot loaders do not provide a way to pass a command line to the loaded kernel, so in case no command line is passed, the bootloaded debugger loads an SLD file from the boot partition root directory if it is found, not empty, and contains a certain goto destination name. It's described a bit in https://pushbx.org/ecm/doc/ldebug.htm#invoking-boot
It wouldn't be difficult to add something similar to the application/device mode too. The most difficult part would be to look up the directory from which we loaded. But that part can be basically as complicated as we'd like, because it would stay in the INIT section which has less than 8 KiB used currently (out of 64 KiB allowed without any other changes).
If you look at https://hg.pushbx.org/ecm/ldebug/file/cedcd17efefa/source/debug.mac#l217 you can see that the DOS I/O backed Y command allows 16 levels of SLD files, while the bootloaded mode Y command allows 4 levels. (Could both be increased somewhat with just these build time options.)
I have new idea. Instead of writing the file name including the path directly into the code, you could simply read out an environment variable that could be set in for example the
AUTOEXEC.BAT,FDAUTO.BATor any other BATCH file.This environment variable then could contain the file name and the path.
This way you remain flexible with both the file name of the script and the path. Only the name of the environment variable would have to be firmly defined and chosen in such a way that it does not conflict with any other environment variable names that could be used under DOS.
But that shouldn't be a problem. Unlike filenames, environment variables with a length of 2^15-1 are allowed in DOS.
How about
ldebug_defaultconfigas a suggestion? That should be long and unique enough to not conflict with something else.That's good to hear. In my opinion even 2 levels is enough, if you can return to the caller script. There you could call new scripts.
If the scripts can only be chained, like batch files used to be without the CALL batch command, then a higher level depth would probably be necessary.
Last edit: Oliver 2023-06-25
I'll consider the environment variable. The SLDs do nest like CALL for batch files.
I implemented startup configuration files. Like for the bootloaded mode, the filename is hardcoded to
LDEBUG.SLDorLCDEBUG.SLDorLDDEBUG.SLDdepending on which build is in use. Similarly to the bootloaded file, the goto destination label:applicationstartupor:devicestartupmust be present. Unlike the bootloaded mode, the directory and drive used can be detected and affected.LDEBUGCONFIGis an environment variable read to find the path. If it doesn't exist, the debugger tries to locate its own executable. If that fails, the current directory at startup is used.As usual the automatic build will occur before 24:00 in the +0200 timezone, a little later today.
Last edit: E. C. Masloch 2023-06-30
The
LDEBUGCONFIGenvironment variable seems to be ignored.I set up a simple
LDEBUG.SLDfile. See screenshotldebug.sld.png.I put them in the same folder as
LDEBUG.COM.In the first run, the environment variable was not.
LDEBUG.COMfindsLDEBUG.SLDin the same folder.That can be seen by
LDEBUG.COM's output that differs from the normal output.Then i quit
LDEBUGand moved theLDEBUG.SLDfile in a subfolder calledTEST.I set the environment variable pointing to the subfolder.
Then i run
LDEBUG.COMagain.The environement variable points to the script's location, but the
LDEBUG.SLDscript isn't run by LDEBUG. This can be seen inLDEBUG.COM's output.See the other 4 screenshots.
TEST.BAT is the batch file that does the above test run.
TEST2.BAT reverses everything and puts it into default position.
And the screenshots that contain the string RUN in it's name is the output when the batch files are tun.
Oops, the config path wasn't actually used. So it would always try to load from the current directory. My tests didn't catch that. Here's the fix: https://hg.pushbx.org/ecm/ldebug/rev/7fcf6cc70adc
By the way, if you could copy the text as text that would be more easily readable than having to look at screenshots.
Thank you for fixing it.
I know, text would be better and would have a smaller size, be searchable and have a better accessibility support. But the problem is, i am using QEMU and FreeDOS as guest OS here. Copying text via cut & paste can't be used in that combination. Thus i have to copy the data on the Guest OS over to a floppy image and then mount it on the host OS, which is Linux. So to sum it up. It's cumbersome for me and the screenshots are much quicker to take and instantly accessible on the host OS.
You can use the new "copy output" Extension for lDebug, included in the current release builds as co.eld, to save the lDebug debugger control terminal output to a file. This will not include any output from the debuggee (program being debugged), however. The "[more]" prompts also are not included in the output. If "getinput" is used (eg
install getinputas described elsewhere) then by default the line input isn't being copied by co.eld either, but the final line that you submit is copied. The output is only copied while DOS is available (not InDOS mode) because it uses DOS I/O to write its content.The ELD is installed with a command
ext co.eld installand then a file is created-or-opened for appending using the commandcopyoutput name <filename>. Othercopyoutputsubcommands includecopyoutput on,copyoutput off,copyoutput close,copyoutput truncate, andcopyoutput uninstall. All subcommands are displayed when you runext co.eld helpThank you. I had to copy the file
co.eldfrom ldebug's bin folder to my working directory to make it work.And it does work. This seems to be a very nice feature for logging.
These ELD files seem to be new and add features as extension to LDEBUG. I didn't notice them in an earlier version. I like this extension feature.
Therefore I have a request. As with the script and config files
*.sldand their environment variables LDEBUG_DIR, LDEBUGCONFIG and LDEBUGSCRIPTS done before, could you implement another environment variable for ELD files in LDEBUG, which LDEBUG then evaluates when starting?So that you can use this environment variable to define a path in which you can store these ELD files? I prefer not to have them in the same directory as LDEBUG's
*.COMfiles. A subdirectory such as%LDEBUG_DIR%\ELD\would be great for that.And is it somehow possible to list all available extensions or ELD files in ldebug before installing them?
A command something like:
It would be nice if this extension command were mentioned in the normal help
?.I also noticed that there are XLD files in addition to the ELD files. Loading the co.eld file worked without me having to copy the XLD file into the working directory.
What task do the XLD files fulfill?
Nice!
I started creating the infrastructure, architecture, and specific ELDs only this September. You can read some about them on the blog: https://pushbx.org/ecm/dokuwiki/tag/eld?do=showtag&tag=eld
You do have to use an updated lDebug (such as the soon upcoming Release 7) to use them. In general, a newer/future ELD may also require a current lDebug, though in many cases recent ELDs will work with revisions other than the very most recent, too.
I think you are mistaken, there is no such variable recognised by lDebug.
ELDs are searched for in the current working directory on the current drive, then the scripts path (from %LDEBUGSCRIPTS%). It would require more resident (data/code) space in the debugger to support yet another path keyword so I think it should be fine to place the ELDs in the scripts path directory.
As an aside, by installing the extname ELD you can enter Y or EXT commands with the filename extensions omitted. The ELD will guess either .SLD (for Y commands) or .ELD then .XLD (for EXT commands) for you.
As mentioned elsewhere: https://sourceforge.net/p/freedos/feature-requests/118/?page=3#05c4/e111/feb5/e17b/3469/808d/345e/592b
You can use the dosdir.eld (or bootdir.eld when bootloaded) as well as the list.eld to list ELDs, either just as files (*dir.eld) or with their description lines (list.eld). ELD help can be displayed using the list.eld with its trailing HELP keyword. (SLD0 format help is not yet defined, can be added soon if you want it however.)
I will get around to that, however in the manual it is present already. By "extension command" did you mean individual ELDs (hard) or just the EXT command itself (easy)?
The XLDs are alternative builds of the ELDs. You only need one of them, and each is supposed to work without the other. The XLDs are slightly smaller in file size but sacrifice a few features for this space saving. For instance, if your lDebug is too old for some ELD and missing a link then the .ELD file will display a nice error message indicating what is missing, whereas the .XLD will just put up a cryptic error number that doesn't mean anything.
The main use of the XLDs is actually in developing ELDs because the eldcomp.eld can be used to run an XLD and then its corresponding ELD, and eldcomp will compare whether they leave the memory they used in the exact same state. As the differences between XLDs and ELDs are only in the linker, this normally should be true. This greatly helps to find invalid relocations in an ELD. (Relocations are a big deal for ELDs because both the ELD code instance and the ELD data block must be able to load at dynamically-chosen offsets within their respective segments.)
Hmm, okay then there's probably nothing we can do about it.
I still have a suggestion. Would a parent directory that is then set in the environment variable
%LDEBUGSCRIPTS%and the subordinate directories then have a fixed name help to keep memory requirement to minimum ?Suggestion:
That way only
.is modifiable via%LDEBUGSCRIPTS%and the subdirectory are hard coded.That would be a compromise. This way you could separate the config, script and extension files and only have one variable path that the user can then adapt.
There was no such file as extension as ELD.ELD.
So i tried:
I probably misunderstood you here.
How exactly do I get ldebug to load ELD files without specifying the filename extension?
Thanks, i will discuss this there.
Yes, every extensions, script etc, file should have a short description and a help section. And if possible a more generous usage section with examples.
The help and description section should be mandatory. The usage section should be present, but the content should be optional.
And there should be a way to automatically test whether the corresponding file has all 3 sections for those who write these script or extension files.
Just the EXT command itself.
All help data from individual ELD files should be part of them.
But as posted here:
https://sourceforge.net/p/freedos/feature-requests/118/?page=3#05c4/e111/feb5/e17b/3469/808d/345e/592b/806f
It would be nice if the EXT command does have a help option that is capable to read the help data of individual ELD files when their name is given after the help parameter.
Example:
I understand and thank you for your comprehensive answer.
I will then only use the ELD files.