I don't maintain either the gitlab mirror or github repo of (Free)DOS Debug. This mistake does appear to be fixed in the most recent revisions of both however.
(SLD0 format help is not yet defined, can be added soon if you want it however.) 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...
ext list.eld dosdir.eld help File not found. You need to provide ::scripts::dosdir.eld for this to work. The list.eld doesn't (yet) automatically look in the scripts path directory. Added in https://hg.pushbx.org/ecm/ldebug/rev/84443e9fa59e You do still have to provide an extension like dosdir.eld, dosdir.?ld, or dosdir.* however, even if you have extname.eld installed. (The extname ELD never reaches into the parameters passed to another ELD like list.eld's pattern.)
ext list.eld dosdir.eld help File not found. You need to provide ::scripts::dosdir.eld for this to work. The list.eld doesn't (yet) automatically look in the scripts path directory. Added in https://hg.pushbx.org/ecm/ldebug/rev/84443e9fa59e You do still have to provide an extension like dosdir.eld, dosdir.?ld, or dosdir.* however, even if you have extname.eld installed. (The extname ELD never reaches into the parameters passed to another ELD like list,eld's pattern.)
Like the rdumpidx.eld in https://sourceforge.net/p/freedos/feature-requests/130/#8169 this ELD will only modify the R register dump in 16-bit, Real/Virtual 86 Mode, non-40-column mode. The requirement that debuggee not be in Protected Mode and the limit to 16-bit registers means we do not have to worry about segment limits when accessing the contents.
Added yesterday as the Extension for lDebug called rdumpstr.eld. Like the rdumpidx.eld this will not display bytes >= 128 as text, instead replacing them by dots (to save on a little space). Again if you would like this to change just say so.
Added as the Extension for lDebug called rdumpidx.eld in yesterday's build. You can install it using ext rdumpidx.eld install and then in a 16-bit, Real/Virtual 86 Mode, non-40-column register dump the ELD will insert the desired display. The SI= display uses byte [ds:si] while DI= uses byte [es:di]. For printable ASCII single quote marks are used, except when the content is a single quote mark. Otherwise the DT command's table is used for the two-letter or three-letter name, no quote marks. For...
The symbolic build option of lDebug does provide some support for placing labels in memory. However, it is not considered ready yet. In lieu of labels, you can assign offsets such as the AAO (address assembly offset) to variables in lDebug (like the V variables), then later use those variables in the assembler. There is an example at https://pushbx.org/ecm/dokuwiki/blog/pushbx/2022/1111_link_spam?s[]=v0&s[]=assembler#b16cat_and_echoify
I don't see how a simple pipe operation could lead to the use case you're describing; the H command would have to decide what parts of its input to use. In any case, in lDebug you can use h dword [40:6C] or the like. This uses the indirection feature of the expression evaluator: https://pushbx.org/ecm/doc/ldebug.htm#exprindirection
The plus sign way is chosen by DR-DOS SID / Debug I believe. But I don't like it because it violates the principles of lDebug's expression evaluator. Are you aware of dw 0:413 l 10? In lDebug you can spell it as dw 0:413 length 10 too, to be clearer.
If you want hardcoded table contents it would be easy to add them as an ELD. (One which could run transiently or be installed residently.) However, you're mentioning some dynamic wants: The fields should change if it is an CGA or hercules video card accordingly. Other cards, like a SCSI adapter and its ROM should be shown too. I assume that these values can be read out automatically, if this is not the case an approximation might do the job too. If you provide an algorithm or reference for detections...
What about the config file? Isn't this evaluated before debuggee? No, not actually. The order of operations is init relocate -> check processor -> init command line -> init relocate second time, grow/shrink buffers -> init relocate entire process if /T given -> install interrupt handlers -> init discarded -> K command with filename given on command line -> L command to load a program -> first cmd3 command input loop iteration -> RC command line buffer commands start to be processed -> Y command to...
Is there a difference between dm header and dm table, apart from the different width? If not, then I would suggest just offering table and removing the other parameter. No, that is indeed the only difference. However, dm header without the table option is very cheap to include and I actually prefer the well known format with a header to the table format. By the way, a help.eld like this would allow extensive online help for ldebug without ldebug itself taking up more memory space. It could be used...
Okay, but it doesn't work the same way with some other elds. printf.eld now has a help which will show with ext printf.eld (empty command line tail) or ext printf.eld help. -ext instnoth.eld ELD linker: no other link info found! ; definitely not the help description The *oth.eld files require an "oher link" debugger to be resident and have its install amis and ext amisoth.eld installhaving run. I may consider adding a more informative message but the check runs very early during the ELD's linking,...
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: No, this would also require more memory. There was no such file as extension as ELD.ELD. So i tried: -ext eld install EXT command failed to open file. -ext eld.eld install EXT command failed to open file. -install ELD ^ Error I probably misunderstood you here. How exactly do...
-ext list.eld dosdir.eld help File not found. You need to provide ::scripts::dosdir.eld for this to work. The list.eld doesn't (yet) automatically look in the scripts path directory. -ext dosdir.eld install File not found. The dosdir.eld cannot be installed residently. Hence install is not a recognised keyword. Instead, this means you are asking it to list a file named matching the pattern "install" instead. To be honest, I'm glad it doesn't work. Because I would like to have a different directory...
Do I understand correctly that with this feature you can load files later, i.e. when ldebug is already running, without having to specify the file name extension? And the debugee is then searched in the PATH? Yes, this is correct. The path search occurs at K/N command time however, not when L runs to actually load the program. (Both /P init time search and path.eld run time search will also skip directories now, so if say you had a directory "MEM" and a "MEM.EXE" somewhere in the path, k mem and...
I don't love aliases but I think they should work without things like that. I also replied elsewhere already about the @: https://sourceforge.net/p/freedos/feature-requests/111/#eb1c/1f01/26d3/9c1a/4614 If you want to play it safe, you can alias add $set d 100 l 10 yourself and make sure not to add aliases without the prefix. And unless you alias add alias ... (perhaps I will make a warning/error for that) you can always get out of weird aliases by running alias uninstall.
I just tried this. I installed dm.eld with ext dm.eld install but the inbuilt DM command still seems to have priority. Because no header is displayed in the table like dm.eld does when using ext dm.eld header. But ext dm.eld table does work as expected. What exact command did you try? Just dm will indeed run the ELD, but you need to supply it with the dm table keyword or dm header to make it use the new format. As usual for ELDs, dm xyz is handled by the ELD in a similar way as ext dm.eld xyz. I...
However, linfo help won't show the help. ELD help pages are always transient (only available for oneshot operation or if read by list.eld), never installed residently. So you will have to do with ext linfo.eld help. Oh, just noticed it does have a transient help page already, although it is missing some of the features.
I would rename it from LINFO to FILEINFO. This is more meaningful in my opinion. I think it displays information specifically about the L-command program load file, as specified by the N/K commands. I think FILEINFO could be mistaken as being more generic about what "files" it means, whereas LINFO is somewhat clearer that it is related to the L command. Help will be added to the ELD.
No, this would require at least a residently installed ELD (possible, but I don't see the need) or changes to the debugger itself (absolutely not).
Thank you that works great. But i noticed an inconsistency: -ext co.eld help ... ; help text. Gives me a help and usage information for co.eld. But when i try this with printf.eld i get: -ext printf.eld help PRINTF error: No starting quote mark! Yes, this is inconsistent. I might add a help to printf.eld later. Same with: -ext LIST.ELD HELP File not found. You can use ext list.eld without any parameter, it will display the help. But now i know, what LIST.ELD does, this works: -ext LIST.ELD LIST.ELD...
Thank you. I had to copy the file co.eld from 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. Nice! 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. 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...
Could the display "RH stept=XXXX decimal: XX" be indented by two spaces? This makes it stand out better from the register output. May have forgotten to tell you, this was done in October already: https://hg.pushbx.org/ecm/ldebug/rev/bf3fc3adb532
I did some work towards this now. Not free form text processing, but you can do some of this like so: ~-ext set.eld run /e vldversion=?build ~-ext variable.eld run ext printf.eld "%s Auxiliary buffer: %b\r\n" start "%vldversion%" end dauxbuflen Condtnl. Debuggable lDebugX (2023-12-10) Auxiliary buffer: 8.0 KiB ~-
Could you make LDEBUG allow to define a folder for script files in the startup configuration file LDEBUG.SLD? That way, loading and using the script files would be easier and they could all lay in one script folder. If they have their own script folder, they also wouldn't mess with the normal LDEBUG executables if a user does use the dir command on his ldebug folder. By default, a user will have their ::scripts:: path in lDebug set up to match the directory from which lDebug's executable was run....
No, I meant an occasional use if you need the option when using the S command. Thus as a parameter given to S, not a global option. I added this to the withhdr Extension for lDebug just now. With today's build (in about 4 hours) you will be able to run ext withhdr.eld install and then you can use with nodump s ... to run the S command without a dump for just the one command.
Yes, this is how it works currently. Paging is disabled when reading from a Y script file. I may look into enabling this at a later time. Okay. You can run install pagingy now to enable paging when running a Script for lDebug.
If you want, I can add a small Extension for lDebug that provides an alternative L command which would also reset the RH buffer. Should I do that?
You can use the new alias Extension for lDebug, install it as ext alias.eld install then run alias add cls clear.
Couldn't this function be made part of dump d so it's available on a case use basis when you need it? So that you just have to add a parameter with d, and then d automatically displays this help? I added the withhdr Extension for lDebug for this. You install it like ext withhdr.eld install. Then you can use with header d ... or with trailer d ... or with header with trailer d ...
I added the path.eld (Extension for lDebug). This adds the path search features of the /P switch for init to the resident debugger, so you can run eg ext path.eld k mem or ext path.eld install followed by k mem. When using the latter form (residently installing the ELD) you can enable or disable the various features as well: ~-ext path.eld Install this ELD using the INSTALL keyword parameter. Run N or K command to invoke path search. Run as PATH keyword [ON|OFF|TOGGLE] to configure this ELD, where...
About the alias i have a question. Is it possible to define an alias via the script engine? It is now possible to define simple alias commands using the alias.eld (Extension for lDebug). However, these must start a command entered to the debugger, they cannot (yet) be replaced anywhere within a command.
I added support to this to my dm.eld, an Extension for lDebug that recreates the DM command. Even if the debugger build you use does include the DM command already, you can run ext dm.eld header to run once (must have DOS available), or ext dm.eld install to install the ELD so its DM command will take precedence over the builtin one. Displaying the header or the table type output requires to specify a keyword after the DM command. This is what it looks like (can be changed if you prefer): ~-ext dm.eld...
I added an Extension for lDebug which will dump assembled machine code bytes in hexadecimal after any successful assembler command, install it using ext aformat.eld install. I also added set.eld and variable.eld which as mentioned in https://sourceforge.net/p/freedos/feature-requests/93/?page=1#93d6/154a/fd12/494e/401d/dfe2/30f2 allow to use text variables. The variable ELD can actually be installed residently as well, in that case any %vldvariable% occurrences in all regular debugger commands (but...
I recently added an Extension for lDebug as requested by another user per email. It is called linfo.eld and once installed like ext linfo.eld install it will display information on an executable file when it is being loaded: ~-ext linfo.eld install LINFO installed. ~-linfo probe LINFO, file size = 375 (0177h), no EXE header PSP at segment = 598Eh, memory block size is 281 KiB ~-l Loading file: DPMIMINI.COM DPMI entry hooked, new entry=2FC0:52FE LINFO: Success LINFO, file size = 375 (0177h), no EXE...
Would it also be possible to add a PRINTor ECHO command so that you don't see the semicolon? I added a printf Extension for lDebug, it is included in current release builds. Run it like ext printf.eld "Hello World!\r\n" to display a message. The message can include some printf escapes/format specifiers as well. I will have to get around to documenting all of those some time later. Your example works with that: -ext printf.eld "Startup configuration file ""LDEBUG.SLD"" loaded\r\n" Startup configuration...
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 getinput as 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...
rebase: add boolean config item rebase.store-source
I added the /PS switch (enable only path search) and /PE switch (enable only guessing filename extension), as well as a /PW switch that can be used like /PW- to disable the unknown filename extension warning. Grab the build at https://pushbx.org/ecm/download/old/ldebug/20230822.zip if you want to test this.
1) Could you make it possible, that LDEBUG accepts programfiles as parameter without the requirement to name their extensions? DOS does the same for normal program execution, thus it would improve normal user expectation and it would also mean less typing. I did some tests and it seems that in DOS Programs with a COM extension have the highest priority. I.e. DOS or COMMAND.COM first starts a program with a COM extension if no extension was specified and a COM and EXE version with the same name are...
By the way, I have a new suggestion. Before loading a file into ldebug, how about checking the file extension, whether it's a .EXE, .COM, .ROM or .BIN file? And if it's something else, the user should be asked if he really wants to load that file. This can prevent accidental loading of non-executable files, like I did.. I implemented this a few days ago. If you run lDebug with a filename specified on the command line, and that filename has an unknown filename extension, a warning is displayed. The...
Added a clear command yesterday. It will write the escape sequences \ec\e[2J which work for me on a serial terminal, dosemu -dumb, and dosemu -t with RxANSI installed. If output is to the int 10h ROM-BIOS terminal and this is not a -dumb dosemu2 then the \e[2J is translated into int 10h calls that clear the screen and reset the cursor to the top left.
But I understand the meaning behind it, so an empty line in the RH buffer could indicate that there is usually an output at this point/step. Yes, but only if the conditional linebreak and int 10h output are used, and only if the output didn't itself end with a linebreak. Could you make this optional but independent from the linebreak setting for the ldebug terminal? I will consider this, but it would be a little more code than just never emitting the linebreak to the RH/silent buffer. Well, this...
dosemu2 gained the ability to pass a General Protection Fault and Stack Fault to the 86 Mode int 0Dh and int 0Ch handlers in the meantime: https://github.com/dosemu2/dosemu2/commit/da3153b651bbd88ea4a466218c2e1e95a28804ca From my own experience I know that BOCHS is a bit cumbersome to configure, if you want my configuration file I can send it to you. I also made a simple bash script that makes it a little easier to use a hd image file and floppy image file in bochs. I could give you that too. Sure,...
Hm, I'm not sure right now. What would that do/change if the program output isn't stored in RH buffer anyway? The linebreak is displayed if there is text in the current line (current column != 0). If RH mode is enabled but the output isn't to the silent buffer, then the output is both written to the RH buffer and to the debugger terminal. The RH buffer will simply have an empty line then, while the debugger terminal will have the linebreak so as to separate the RE dump output from the prior text....
1) Would it be possible to have the counter count in decimal? Changed just now to display RH step=000F decimal: 15 Since for some entries, e.g. program outputs, the first line could be an output of the program, one would have to count the lines per entry from the bottom to find the first line of the register output. Program output is never captured in the RH buffer. (Would you prefer that the conditional linebreak is not written to the RH buffer?) Thanks for the tip. I must have somehow overlooked...
For 86 Mode, both qemu and dosemu2 can use KVM, but qemu will run the client in Real 86 Mode and pass along all exceptions to the client, it appears. For dosemu2, the client still runs in Virtual 86 Mode, and some exceptions will terminate dosemu rather than be passed to the client. (lDebug's RV command can display one of four modes: Real 86 Mode, Virtual 86 Mode, or DPMI with a 16- or 32-bit code selector.) The Virtual 8086 Mode isn't available in 64 Bit long mode. You failed to read what I wrote....
To test the following bug, exit ldebug and restart it. The new bug can be seen by increasing n to a point, where n is larger than the number of entries in the history buffer. This time, the bug is reproducible. First we run the program as normal with tp to_end to fill the buffer for the first time and then we take a look into the buffer by just running rh without arguments. A command like rh 27 (#24)should show all of them, but doesn't. This means "start at the 40th-to-last step and display up to...
-tp 17 ; equals tp (#23) You can just use tp #23 if you want up to twenty-three steps. No parentheses or hexadecimal input needed.
By doing so, i found a bug in the following command -tp 17 ; equals tp (#23) -rh (#23) (#23) The last step (0), which is the program termination message is printed first, then steps #23, #22, #21, #20 in reverse order until #1. As you noted in another message, the first step being displayed is simply left over from an earlier execution. Passing N equal to K (in the rh N K two-parameter command form), like in rh #23 #23 (no parentheses needed), will never display the very last RH step. Consider rh...
If you should decide for a special build I would suggest ldebugr as a name, the r then stands for real mode without DPMI. As I assume you want to omit the PM or DPMI part in this particular build to keep the program under 64kb. lDebug without the X already is the 86-Mode-only variant. So if I want to add a more feature-rich build it should have a name indicating that it has more options enabled, not simply a trait that it shares with the non-X default lDebug build. (As an aside, the script names...
Please attach your executable and source file step.asm. An exact list of the commands you ran to get the bug would also be helpful.
But that's why i recommended to check the file extension that is loaded to inform the user and prevent such accidents by asking him again, if he is sure if he wants to load data as program code. I understand where you're coming from, but I think I'll just chalk this up to user error. You were able to figure out the cause of your problem by yourself, after all. I could add an option for this but I would not want to include this code in the default build, as the lCDebugX build is very close to 65_536...
Well, i was wondering about this '╠' character. Depending on the steps g has to take, it is written over the Hello World! in stdout. The parameter (number) that you give to G is not "the steps G has to take". The parameter for G is completely different from the parameter for T/TP/P. https://pushbx.org/ecm/doc/ldebug.htm#cmdg : The G command allows specifying breakpoints, which are either segmented addresses (86M or PM addresses depending on DebugX's mode) or linear addresses prefixed by an "@ " or...
I don't have any central todo file yet. So i assume, it's not writable from normal ldebug command line and it's scripting capability. Only for internal inbuilt commands like S. Right, I misunderstood you. Only the S command may write these variables currently. (Either run from the user terminal or from a script file.) It wouldn't be much of a change to allow them to be written by the user. Do you have a use case for that?
It seems to be, that IP has changed pointing to 100h, which is something different than this dec AX. I assume it's probably a return point to some DOS routine or ldebug. Calling the DOS terminate process function (21.4C) will indeed return control flow to the parent process, which is the debugger. The debugger will then re-create an empty process. All registers seem to be set to 0, including IP. An empty process created by the debugger, as well as a process created from loading a flat-format .COM...
Maximum input length for a search string is FF5( #245) or respectively FF6 (#256) if you shorten the range to "FFF". The rest is required for s0,FFFF"" and a CRLF. I think you accidentally added a second "F" to what should be "F5h" and "F6h". Anyway, yes, using a normal (byte) search pattern you can only enter less than 256 bytes, using a quoted string. (You need s0,FF,"..." as well as a CR in the 255 bytes of data buffer in line_in. No LF.) However, you can specify a search pattern with AS WORDS...
The hello.asm file does crash eventually for me if I use T commands, but QA, L, and Q commands still work at that point. If I do use the G command it crashes my dosemu2 machine, either directly (-E "ldebug c:\bin\lddebug.com hello.asm") or similarly to your case I get an "Invalid opcode" fault and then the debugger doesn't work correctly any longer (-E "ldebug.com hello.asm"). However, this is unlikely to be due to a debugger bug. When the machine crashes, it can corrupt parts of its own process,...
This codepoint is what 0CCh, the int3 breakpoint instruction, looks like when you display it to your terminal. By running g 10 you happen to replace the "H" byte of your text by the 0CCh. This is not a bug, it is expected that your data can be corrupted by placing a temporary breakpoint into it.
It would be even better if you could have the output of ?VERSION and the size of the aux buffer on one line, but if I remember correctly you once mentioned that this is currently not possible. Not without a specialised command, or better support for controlling command output, or an additional extension/scripting interface. By the way, I forgot to mention in one of the other replies that the +NN hint for the S command data dump output was finished on Monday already. So you can download the current...
Okay, i have an additional idea to that. If you add underscores to the hex values between the search strings's hex values, then it will become more recognizable. So something like this: Dots instead of underscores look recognizable too. Dots version: I am considering this as well. I'd probably put dots usually, and an underscore instead of a dash. Wouldn't add much more additional code to allow these symbols to be changed I think. Btw do you use some internal bugreport system or todo list to keep...
I think it's because of the way how rh works. When i wrote my last comment, i have forgotten that rh only logs the output. Thus there can be of course no steps logged made by g, except the output Program terminated normally (xxxx). So it's not a bug, it's just a result of how rh works. Correct. If you happen upon a breakpoint (temporary (gg), permanent (bb) hit or pass, or not managed by the debugger at all; that is "unexpected") then the RE output from the G command is also captured into the RH...
But i accept, when you don't want do it. In this case your suggestion of a +NNNN hint would be the best option, i think. At least for 16 Bit real mode programs. I added this hint. It will take two, four, six, or eight hexits as needed. So most practical use cases with search patterns shorter than 100h bytes will add just 4 columns (+01) to the display. This happens to allow a full 16 bytes of the following data dumped in 16-bit segments (including any 8086 Mode uses). For longer search patterns or...
Session not showing the G/RH bug: E:\>ldebug lddebugu.com &; Welcome to lDebug! -install rh Register dump history enabled. -u 20A9:0140 8CC8 mov ax, cs 20A9:0142 31DB xor bx, bx 20A9:0144 055D1A add ax, 1A5D 20A9:0147 50 push ax 20A9:0148 53 push bx 20A9:0149 CB retf 20A9:014A 26807F0200 cmp byte [es:bx+02], 00 20A9:014F 7414 jz 0165 20A9:0151 26C747030001 mov word [es:bx+03], 0100 20A9:0157 26807F020E cmp byte [es:bx+02], 0E 20A9:015C 7406 jz 0164 20A9:015E 26C747030381 mov word [es:bx+03], 8103...
BTW, there is an issue when using g followed by rh. rh only shows steps that where done by t or p, but not by g. That would be quite the bug, but I cannot reproduce it. Please list an entire session showing this problem. And when doing some steps followed by L and then some steps again, rh shows the steps before and after the L. If I understood that correctly, L loads the initial state of the program and, as I understand it, should also flush rh. But that is not the case, the history of the old steps...
That sounds good. But i would suggest to add a feedback message when LDEBUG is started with the /A option. Something like: C:\TEMP>ldebug program.exe /A Auxiliary buffer is increased to 24 KiB. - A switch for lDebug actually needs to go before the debuggee program specification. If you put a switch after the filename, the debugger will interpret this as part of the command line to send to the N/K command. As for the display, you can use h as bytes dauxbuflen starting today. It will display the size,...
How about simulating the highlighting with with ASCII character brackets lik < and >? Would be easier, maybe I will look into that too. Could you make LDEBUG allow to define a folder for script files in the startup configuration file LDEBUG.SLD? I added a scriptspath variable, it is set up by init using either the %LDEBUGSCRIPTS% variable or the debugger executable's path. By shoving this into init we can keep down the amount of code needed in the resident code segment. So, no, you do not get to...
Works great. But is it also possible to only show the SEGMENT:OFFSET address like in MS-DOS debug? From the manual section on the S command: "There is an option to disable the data dump so as to only display the match addresses. If the bit 80_0000h is set in the DCO variable then the data dump is suppressed." From the DCO options list: "0080_0000 S: do not dump data after matches". This SILENT keyword is btw. not mentioned in the help documentation in the search command chapter. It's only mentioned...
but rh 1 3 is still confusing, because the last step seems to be counted as step 1, not step 0 like we programmers are used to and how rh with only one number given works. Thus step 0 would be the next step, which isn't taken so far. No, the two-parameter form specifies the first parameter (start of dump) exactly the same as the one-parameter form. rh 1 3 asks to start the dump at step 1 (the second-most recent step) and go on for 3 steps (counting down towards the present moment, from 1 to 0 to...
I added an application mode only option named /A. Invoking the debugger with /A or /A=MAX will enlarge the auxiliary buffer, used as silent and RH buffer, from about 8 KiB to 24 KiB. For simplicity of the resident memory use, this option can only be specified at startup and the buffer cannot be grown or shrunken during a session. Watch for the automatic build later today if you want to try it.
Updated script to work in PM as intended, in https://pushbx.org/ecm/test/20230711/searchd.sld The changed line reads if ( (desctype srs) & 4000 == 0) then goto :64kib rather than desctype srs & 4000
Where the search term "Musterfrau" is highlighted and the rest surrounding it, is not. Highlighting parts of a dump would be useful but it messes a lot with how the D commands are implemented so far. Maybe I will rewrite this at a later point.
You can use s range SILENT 0 pattern to display only the SRC (search results count) line from an S command, then afterwards you can use y searchd.sld and it will detect the search variables anyway.
I prepared a Script for lDebug file which does some of what you want. You need to set the SRS, SRO, and SRC variables (all set by an S command) as well as the COUNT variable (either using r count NNNN or using the COUNT command, today's current build will also set the COUNT variable from the S command alone). Then call y searchd.sld. The file is at https://pushbx.org/ecm/test/20230711/searchd.sld and the content is: @r ysf |= 4000 r v10 = src if (v10 > 0F) then r v10 = 10 r v11 = 0 :loop if (v10...
That's confusing. The last step, most recent is 0 in the history, counting backwards from there, why not just printing step 1 to step 3: You can use rh in from 1 length 3 for that. I'm not convinced to change the default behaviour because it was very simple to implement based on the silent trace buffering. Suggestion: Is it possible to do a call of r without printing an output under the hood after entering install rh, that way the history is already fed with the first r until it gets overwritten...
Added an RH IN command. Like usual for DI IN or a VALUE ... IN expression, the IN numbers must be comma-separated. And there is little error checking, so if you specify too large numbers then for each of those numbers the oldest step is displayed. Like other IN lists, you can specify RH IN FROM number TO number or RH IN FROM number LENGTH number. I also added a patch which will reverse the order in which these value ranges are processed for the RH command, so from 1 to 3 will display step 3, step...
40 steps is more than enough. I assumed 20, which should be sufficient in most cases. But 40 is even better. The number may be a little lower if you have many memory references, or if you use the register change highlighting as you do. I noticed, that if you start with a smaller number than an older step only one step is printed. For example RH 0 3. This prints only step 0. Yes, this is intended. Also there seems to be a bug with the ordering. See the screenshots. There i did a: I don't think there...
3) A history function in LDEBUG that shows the previous register states of previous steps. Here I could imagine two possibilities, either you only save the register states in the history that have changed from the last n steps and reconstruct the rest for the output starting from the current register status. Or you save all register states of the last n steps completely. The former takes up more space in the code segment, the latter in the data segment. And you said that you have still some free...
As far as I know, the modern virtualization via AMD-V and AMD-Vi, which includes AMD SVM, and Intel VT-x and VT-d have never been affected by this 64-bit long mode limitation, as these are practically running in ring -1 and can therefore be fully used without limitations, as long as the guest system is not also 64 bit. Right. The limitation practically applies to VM8086 on the host system Ring 0 to Ring 3, without using these newer VM technologies. Yes. My QEMU/KVM environment, which uses Intel VT-d...
Yes i know. That's why i edited my comment and added the 32 bit at the front of the word Windows, because the Virt8086 virtualization of the CPU, which is used by NTVDM, can only be used in 32 bit mode for 16 Bit real mode applications, not in 64 Bit long mode. Thus this means no ldebug or any other 16 Bit real mode application inside of the CMD shell by using NTVDM in a 64 Bit Windows, because in long mode there is no Virt8086 available. There seem to be some community alternatives available that...
BTW., i was curious about the maximum input length. COUNT itself seems to be a 32 bit signed integer variable, because that's what r says: It's a 32-bit (unsigned) variable because count range 0 length 10000 and in lDebugX count range 32bitsegment:0 length 12345678 can result in lengths > 0FFFFh. You can cause an overflow of line_out with long strings and the new as words or as dwords keywords for list parameters, which I added to allow you to enter 16-bit values to the F command string. That is,...
Also added support for empty strings, that is count "" works now. However, just count without a parameter is still forbidden. This change only cost 1 byte: https://hg.pushbx.org/ecm/ldebug/rev/ee5669f374d7
It doesn't really matter, but as I do not have much love for LISTLENGTH I renamed it all to COUNT, dropping the STRINGLENGTH alias as well.
It is intentional, as in https://hg.pushbx.org/ecm/ldebug/file/27bafee89139/source/ll.asm#l678 or https://hg.pushbx.org/ecm/fddebug/file/161e5a01a3d3/DEBUG.ASM#l6847 However, those seem to be accurate in reproducing the MSDebug code as in https://hg.pushbx.org/ecm/msdebug/file/62d3a72c1915/debcom2.asm#l1338 Your MS-DOS Debug example is meaningless because ds equals cs there. If you try debug hello.exe with MS-DOS or MSDebug you will likely get the same output.
Regarding my question, have you then come to a decision to display a different error message if the range end address is less than the start offset address, as we discussed? No, not yet.
You're free to add features like this. I'd rather work on sending data across the serial terminal link though, that is rather more within my abilities.
Thank you very much. I will read that. This also opens up new possibilities, since I could then debug the PC booter on real hardware without using an emulator. Yes. This is why I created this mode, in part. But now i also have another question. If i try that on real hardware, is there a way to transfer data from lDEBUG to another machine via a null modem cable or Ethernet, if needed? No, the only networking that lDebug can do is to connect to a serial terminal for the debugger interface. The settings...
I have also another question that doesn't fit anywhere, so I'll ask it here. Is it also possible to debug so-called PC booters (Self-booting disk) with LDEBUG? So programs that boot directly from the floppy and are not DOS programs themselves and do not require DOS, but at most only use BIOS functions? Yes, this is possible with lDebug as a bootloaded debugger. Here are some pointers for that: https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2022:1107_bootable_ldebug_vs_freedos_debugb https://pushbx.org/ecm/doc/ldebug.htm#invoking-boot...
@; Startup configuration file "LDEBUG.SID" loaded There is no reason to put this line before the label. And in both of these lines you misspelled .SLD as .SID. r dco2 20_0000 Missing or=. @:devicestartupr Superfluous R at the end. And you don't have to put that into the file if A. you never use lDebug as a device driver and B. the section is empty anyway so it will never have any effect.
I tested now both, the underscore feature and the new alias for LISTLENGTH. The underscore feature works without flaws. I also noticed, that you made it possible to use underscores even for input. This is very good, i really like that. Yes, this is a long-standing feature that I copied from NASM. As I mentioned, Underscores have the advantage that you can use them for numeric input of long numbers in NASM and lDebug. Using underscores is allowed anywhere in a literal number, except at the very beginning....
You should use r dco6 or= 8000_0000 to avoid resetting all other DCO6 flags. And yes, you need both that flag as well as a setup that uses int 10h to write the output. This can be done using install BIOSOUTPUT or its alias install INT10OUTPUT (no side effects), or install INDOS (side effect that DOS is no longer called, including that Script for lDebug files cannot be read), or r dco6 or= 100_0000 (both input and output done using the ROM-BIOS, side effect that Script for lDebug files cannot be read...
Right, I added detection for DTOP<separator> to handle it as D TOP rather than DT OP. In https://hg.pushbx.org/ecm/ldebug/rev/49212f6c68c8 and a small optimisation in https://hg.pushbx.org/ecm/ldebug/rev/09e3c614e9f8
Correction, i noticed, that there also needs to be a comma between top and the segment or offset address. So this doesn't work: -D TOPDS:100,100 1234:0000 Yes, correct. The TOP keyword is parsed using isstring? which absolutely requires a separator after the word to terminate the word, That separator may here be a blank, tab, comma, or EOL. This is the code handling the separators: https://hg.pushbx.org/ecm/ldebug/file/cd34addb0eaa/source/lineio.asm#l46 And i found a bug, if you try to use a segment...
I understand, so the command interpreter is written in a way, that it calls a command as soon as it detects one and then passes the rest of the input to that called command, right? Otherwise the command interpreter itself could test, if it is a DTcommand or a D TOP. Two-letter commands like DT are handled early on in the D commands dispatcher, at https://hg.pushbx.org/ecm/ldebug/file/cd34addb0eaa/source/dd.asm#l47 First it checks that there is a D immediately before the current text. If there isn't...
Added DX TOP keyword: https://hg.pushbx.org/ecm/ldebug/rev/440b410b8495 Note that in D TOP there must be a comma or blank between the D and the TOP, or the command will be misdetected as DT OP.
Added the D TOP keyword: https://hg.pushbx.org/ecm/ldebug/rev/6101f0bcaba3 You have to enter it each time, except for when you run autorepeat the debugger will remember whether you used it prior. It must always go before the range, if any is given.
About the alias i have a question. Is it possible to define an alias via the script engine? No. SLseems to be free to use too, or SLEN. SL. is used by the symbolic build I think.
Added a STRINGLENGTH variable alias. It isn't as short but I don't want to use a C function name for this. LISTLENGTH is still usable too.