#374 DEBUG.EXE - MS-DOS version always prints a newline, FreeDOS version doesn't

[Oliver]

The DEBUG Version of MS-DOS 6.2 always prints a newline, before printing the registers. That way, normal program output can be easier recognized and register output isn't messed up.
The disadvantage is, that for every "t" trace/step command one additional line is printed.

The DEBUG version v1.28 of FreeDOS behaves differently. It doesn't print a new line. If the normal program prints an output, then the register output is appended on the same line, resulting in a messed up register output.
The benefit of this behavior is that when the normal program doesn't output anything, there are more space/lines available for the debug stepping history.

Question, is that behavior by intention or is that a bug?
See the screenshots for comparison.

[fritz.mueller]

https://github.com/Baron-von-Riedesel/DOS-debug

there is a new version 2.0 out, also delivered with freedos 2304.
just for info.

[fritz.mueller]

If you want to get your problem fixed, please report it directly there. Most FD programmers do not watch this site.

[E. C. Masloch]

I added a runtime option to my forked debugger project. (It is based on FreeDOS Debug/X.) You can enable the option using a command like r dco6 or= 8000_0000 and then the R command as well as run commands (T, TP, P, G) will display the additional linebreak. If you don't want to build the latest sources yourself, you can download the "current release" archive from https://pushbx.org/ecm/download/ldebug.zip (it will be updated with this change within the next 5 hours as of now, so don't try it before then).

[E. C. Masloch]

[E. C. Masloch]

Would be possible to add, if you use install BIOSOUTPUT. The DOS I/O interface does not provide a way to query the current cursor position.

[E. C. Masloch]

Does this get mixed up with the other functions such as GETINPUT?

If you install BIOSOUTPUT then the getinput function is used, even if you uninstall GETINPUT as the latter only affects things if DOS input and output is used.

Install BIOSOUTPUT seems to have no effect according to this issue at the moment, is that correct? At least I just tried it and it still prints a new line no matter what the debugged program does or did you mean you still need to implement that?

Yes. I did not implement anything like this yet, just speaking hypothetically.

[E. C. Masloch]

I changed DCO6 8000_0000h to a conditional linebreak. It only works if the output is to int 10h, that is install BIOSOUTPUT was used (or install INDOS), and I/O is not across a serial port.

DCO2 40_0000h now is used to unconditionally display a linebreak.

[E. C. Masloch]

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 any longer).

[E. C. Masloch]

@; 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.

[E. C. Masloch]

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

https://pushbx.org/ecm/doc/ldebug.htm#cmdhelp-instsect

Note that a bootloaded kernel or application may re-initialise interrupt vectors intercepted by lDebug, particularly the interrupt 1 (trace) and interrupt 3 (breakpoint) vectors. If this happens then in the best case the debugger will lose control of the machine, in a worse case the machine may crash. You can use something like tp f_ffff while ! value from linear 0:1 * 4 length 3 dwords in writing silent 4 to try to step the debuggee until it tries to modify either of these two vectors. However, conditional tracing is much slower than running like with G.

If you do trace (using a scriptlet like the above, or manually) and you come across instructions that would modify the vectors, then you have to skip past these instructions, modifying ip and possibly other registers to match the expected operation of the kernel.

If so, which settings from the above would I then need to change and how would I then load that with LDEBUG?

At the moment I would probably debug something like this with the integrated debugger of the BOCHS emulator that is called BOCHS enhanced debugger, but if that also works with LDEBUG within the emulated machine, then I would have an alternative option.
BOCHS enhanced debugger runs directly on the host system outside of the emulated guest machine.

Basically you run a DOS and use instsect A: (program included in ldebug.zip) or for whatever drive you want to make bootable. You copy ldebug.com to the root directory of the same drive. You can include an ldebug.sld with the :bootstartup section if you want to include debugger settings. (install getinput and install biosoutput are both useless but don't do any harm in bootloaded mode.) Now you need to arrange it so the drive you set up is booted, this depends on the machine you're using and may involve an MBR loader if the drive is a partition on a partitioned disk.

Here's a recent post of mine with an example to create a bootable diskette image with ldosboot, bootimg, and lDebug: https://retrocomputing.stackexchange.com/questions/27275/creating-8086-binary-larger-than-64-kib-using-nasm-or-any-other-assembler/27279#27279 The advantage over using instsect is that you can create the entire image from a host system like Linux, instead of needing a DOS step.

Once you're in the booted lDebug you can use commands like boot fda or boot fdb or boot protocol MSDOS6 hda1 (There are many predefined protocols as well as settings for modifying them.)

boot quit will try to shut down the machine.

q will uninstall the debugger and continue at the current debuggee client cs:ip.

[E. C. Masloch]

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 default to the COM2 port at 9600 baud, but can be changed before you connect. See https://pushbx.org/ecm/doc/ldebug.htm#interface-serial

You can capture the output of lDebug on the remote machine and eg reconstruct data from dumps, or feed data with lDebug enter commands to the terminal. However, there is no support for any specific protocols for file transfer.

And can i still save data to disk like in a normal LDEBUG session when running on a normal DOS system?
I could put a fat16 formatted floppy disk inside drive B:

Also no. The only disk accesses that bootable lDebug supports are:

1. Boot a boot sector from disk unit or partition
2. Boot a file from a FAT file system
3. Read Script for lDebug file from a FAT file system
4. Read or write stretches of sectors, specified with sector numbers within disk units or partitions

About the hardware:
My old hardware is a 486DX and does have 2 floppy drives, 1 x 3.5" HD and 1 x 5.25" HD. It also does have at least one serial port and one parallel port and one NE2000 compatible ISA network card with a twisted pair connector.
I have also a null modem cable and if a remember correctly a LapLink cable, the latter uses the parallel port and was usually faster for data transfer than a null mode cable.

The PC Booter is a 5.25" floppy disk and requires the 5.25" floppy drive attached as first drive A: on the machine, otherwise the PC Booter isn't able to boot, and Bootloaders that had an option to switch the drive letters somehow via software never worked.
And the BIOS also did not allow to change that via BIOS settings.

It should work to write lDebug to a diskette for that drive. Once lDebug has loaded and is done executing the ldebug.sld file, swap the diskette for the one with your booter. Now enter a boot fda command to lDebug and it should "just work".

Note that for FAT12 file system access (including to boot itself), lDebug needs the ROM-BIOS to report the correct geometry that matches the file system. If this is not the case, it is possible to patch lDebug and the ldosboot boot sector loader.

There are three parts to patch:

1. FAT12 boot sector loader, see https://pushbx.org/ecm/doc/ldebug.htm#cmdhelp-instsect and the option /q none in particular.
2. iniload within the ldebug.com file, see https://pushbx.org/ecm/doc/ldosboot.htm#protocol-sector-iniload-patch and https://hg.pushbx.org/ecm/ldosboot/file/9c4923acc2be/patch.sld (I believe this needs to load ldebug.com as in ldebug /f ldebug.com or ldebug /f+ /e+ ldebug.com then load the patch script using y patch.sld.)
3. For SLD file load from the ldp you need to set the BOOTUNITFL00 (or whatever drive you booted) to reflect the proper patch. This can be carried over from the iniload query patch using its flag 80h. These variables aren't documented well yet, pointers are https://hg.pushbx.org/ecm/ldebug/file/27bafee89139/source/expr.asm#l2523 and https://hg.pushbx.org/ecm/ldebug/file/27bafee89139/source/debug.mac#l724 and https://hg.pushbx.org/ecm/ldebug/file/27bafee89139/source/boot.asm#l20

Which drive was A and which was drive B was always determined by which drive was attached to which plug of the floppy cable.
The floppy cable had 3 connectors, one connected to the floppy controller, the other was in the middle and designated drive B and the last connector in the strand was twisted and designated drive A. And the PC Booter on my 5.25" floppy only booted if the 5.25" drive was actually plugged into the connector that made the drive drive A:.
So in order to use the PC Booter, my 5.25" drive had to be Drive A:.

If your ROM-BIOS loader has the option, you can boot lDebug from drive B:. If not then swapping the diskettes as I described is your best bet.

Later, because of my MS-DOS 6.2 floppy diskettes, I needed the 3.5" drive as the boot drive and therefore as drive A:.
If I wanted to use the PC booter again, I had to reconnect the cable. It was very cumbersome, so I rarely did it.
So I'm tempted to use a debugger to investigate why the PC booter was hardwired to drive A:.

It probably doesn't use the unit number passed to it from the prior loader. A lot of kernels assume that they run off unit 00h or 80h.

[E. C. Masloch]

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.