DOS ain't dead

Hello,
The 386SWAT debugger seems to be able to continue tracing a real-mode (not V86) program that goes into protected mode, but I don't quite understand how to configure 386SWAT with 67h INTs, and I can't find any assembly language examples.
Does anyone know how to do this? Or do you know of another debugger that allows a program to change modes (RM -> PM without DPMI) while adapting to it? (with the segment registers which become selectors).
THANKS

> The 386SWAT debugger seems to be able to continue tracing a real-mode (not
> V86) program that goes into protected mode, but I don't quite understand
> how to configure 386SWAT with 67h INTs, and I can't find any assembly
> language examples.

Looking at https://sudleyplace.com/swat/swatdoc.html

here are some thoughts:

http://www.sudleyplace.com/swat/swatinv.html

you can invoke 386swat with ctrl-alt-pad5 while it is waiting in the background, or run to-be-debugged apps via SWATRUN.

http://www.sudleyplace.com/swat/swatmon.html

you can tell 386swat to trigger when an expression becomes true, but this will make everything slow while 386swat looks out for the trigger. You can do stuff like

gm [.csip == 67cd && ax == somevalue

to trigger when the upcoming instruction is INT 67 while AX has a value of your choice.

http://www.sudleyplace.com/swat/swatpro.html

you can tell 386swat to trigger on a subset of things triggering GPF, which includes (if you are in vm86 while emm386 is active) things like interrupts, interrupt flag changing things and I/O port access to watched ports. Usually, emm386 will not watch ports, but things like a virtual sound blaster or emm386 assisting a virtual soundblaster will watch ports.

You can also tell 386swat to trigger on various protected mode faults, interrupts and exceptions with trap... options and you can use vmsint and vmscount to trigger on switches to protected mode via VCPI.

Maybe one of those ideas gets you on the right track, I have not tested them myself.

---
FreeDOS / DOSEMU2 / ...

> Hello,
> The 386SWAT debugger seems to be able to continue tracing a real-mode (not
> V86) program that goes into protected mode, but I don't quite understand
> how to configure 386SWAT with 67h INTs, and I can't find any assembly
> language examples.
> Does anyone know how to do this?

I tested 386SWAT to run with hdpmi, but found it rather complicated - currently it just reboots if I try. May be my fault, though...

> Or do you know of another debugger that
> allows a program to change modes (RM -> PM without DPMI) while adapting to
> it? (with the segment registers which become selectors).

These are socalled "ring0" debuggers. MS wdeb386 actually works, I tried with hdpmi, but it won't do output to the screen, communicates with a serial line or a network card only. No big problem if you use a "virtualizer" like qemu or virtualbox.,,

I finally wrote my own, based on Debug/X: https://github.com/Baron-von-Riedesel/Deb386. The good thing about this debugger is that it is so small that it can remain in conventional memory ( 25 kb ) and won't have to hassle with paging things ( as long as the first MB of address space is "identity mapped" ).

Generally, such debuggers always need the help of the debuggee, that is, your program has to notify the debugger when it is appropriate to "intrude", Personally, I found the API that 386SWAT offers a bit strange, or at least not very well documented, but this applies to MS wdeb386 ( and probably deb386 ) as well.

---
MS-DOS forever!

Personally I tried two versions of 386SWAT. A V6.06 crashes at startup on some computers, and I don't know if V6.01 can really break in PM starting from RM without DPMI. Ctrl-Alt-Pad5 only works in RM if I put "RMLIDT" in the 386SWAT.PRO configuration file, so as you say it's a bit complicated and also weird, and as this debugger is no longer supported by Mr Bob Smith, I'll try yours. Thanks for your help.

> > The 386SWAT debugger seems to be able to continue tracing a real-mode
> (not
> > V86) program that goes into protected mode, but I don't quite understand
> > how to configure 386SWAT with 67h INTs, and I can't find any assembly
> > language examples.
>
> Looking at https://sudleyplace.com/swat/swatdoc.html
>
> here are some thoughts:
>
> http://www.sudleyplace.com/swat/swatinv.html
>
> you can invoke 386swat with ctrl-alt-pad5 while it is waiting in the
> background, or run to-be-debugged apps via SWATRUN.

Thanks for your help. In order for Ctrl-Alt-Pad5 to interrupt in RM, I need to put "RMLIDT" in the 386SWAT.PRO configuration file.

>
> http://www.sudleyplace.com/swat/swatmon.html
>
> you can tell 386swat to trigger when an expression becomes true, but this
> will make everything slow while 386swat looks out for the trigger. You can
> do stuff like
>
> gm [.csip == 67cd && ax == somevalue
>
> to trigger when the upcoming instruction is INT 67 while AX has a value of
> your choice.
>
> http://www.sudleyplace.com/swat/swatpro.html
>
> you can tell 386swat to trigger on a subset of things triggering GPF, which
> includes (if you are in vm86 while emm386 is active) things like
> interrupts, interrupt flag changing things and I/O port access to watched
> ports. Usually, emm386 will not watch ports, but things like a virtual
> sound blaster or emm386 assisting a virtual soundblaster will watch ports.
>
> You can also tell 386swat to trigger on various protected mode faults,
> interrupts and exceptions with trap... options and you can use vmsint and
> vmscount to trigger on switches to protected mode via VCPI.

Yes, I tried all the options in the 386SWAT.PRO configuration file, but none of the interrupts I tried after switching to PM 32b worked. The INT 67h DEF0, DEF2 and DEF3 are essential to indicate to the debugger that the segment registers are now selectors, these INT 67h are accepted but are not taken into consideration. That's why I'm mainly looking to see if anyone has already encountered this problem and solved it.

>
> Maybe one of those ideas gets you on the right track, I have not tested
> them myself.

The 386SWAT debugger was also used in the D3X dos extender (code in PM32 mode). See the SWAT.INC file which can be found in the archive for download from here:

https://board.flatassembler.net/download.php?id=7858
https://board.flatassembler.net/download.php?id=7859

on web:

https://board.flatassembler.net/topic.php?t=14416

When detecting the presence of 386 SWAT, you must first check whether interrupt 67h is supported and then specify which descriptors in GDT are reserved for this debugger and which descriptors point to interrupts int 01h and 03h in IDT. Then, when you enter protected mode, you can invoke one of these interrupts.

Good luck.

> The 386SWAT debugger was also used in the D3X dos extender (code in PM32
> mode). See the SWAT.INC file which can be found in the archive for download
> from here:
>
> https://board.flatassembler.net/download.php?id=7858
> https://board.flatassembler.net/download.php?id=7859
>
> on web:
>
> https://board.flatassembler.net/topic.php?t=14416
>
> When detecting the presence of 386 SWAT, you must first check whether
> interrupt 67h is supported and then specify which descriptors in GDT are
> reserved for this debugger and which descriptors point to interrupts int
> 01h and 03h in IDT. Then, when you enter protected mode, you can invoke one
> of these interrupts.
>
> Good luck.

Thanks for your help.
INT 67h DEF0 returns V6.01 for 386SWAT because that's the version I'm using. I also have a version 6.06 which crashes at startup with certain computers.. I add 30 empty descriptors at the end of my GDT, then with INT 67h DEF2 I point ES:DI to the start of these 30 new descriptors, but in BX I don't understand if I should put a selector there that points to the IDT of the PM. Then INT 67h DEF3 selects for example int 3 with BX, but in ES:DI I don't know if I should point to the PM's IDT or a new IDT reserved for SWAT? (because I think I understand that in the help). In PM 32b, I make a far call using a selector for the start of GDT of SWAT with the linear address that INT 67h DEF2 returned in EDX, but is this correct? An int3 displays a smiley which proves that my IDT is recognized and working, but it does not break 386SWAT. Maybe because now INT3 doesn't do the same thing as before? (for INT1, etc. my IDT contains IRETD everywhere).
I haven't tried your version yet because it's still too confusing for me in terms of INT DEF2, DEF3 and the far call to be made in PM, etc. Please, can you give me a little information more ?

> I finally wrote my own, based on Debug/X:
> https://github.com/Baron-von-Riedesel/Deb386. The good thing
> about this debugger is that it is so small that it can remain in
> conventional memory ( 25 kb ) and won't have to hassle with paging things.

Requirements to create the Binaries

- JWasm.
- DebugR - this Debug/X variant is included as a binary.
- if debug displays are to be activated, JWasm v2.17+ is needed.

Hi,
Sorry to bother you again, but since I can't find your debugger in executable form, I tried to assemble it myself, but I only find JWASM V2.12 and not JWASM V2.17, and I can't find not DEBUGR.BIN, so I can't test DEB386.

> Hi,
> Sorry to bother you again, but since I can't find your debugger in
> executable form, I tried to assemble it myself, but I only find JWASM V2.12
> and not JWASM V2.17, and I can't find not DEBUGR.BIN, so I can't test
> DEB386.

JWasm releases are available at https://github.com/Baron-von-Riedesel/JWasm/releases for MSWindows and (DJGPP) DOS binaries. On a Linux host system I believe compiling JWasm is not difficult.

---
l

> > Hi,
> I only find JWASM V2.12 and not JWASM V2.17, and I can't find not DEBUGR.BIN
>
> JWasm releases are available at
> https://github.com/Baron-von-Riedesel/JWasm/releases for MSWindows and
> (DJGPP) DOS binaries. On a Linux host system I believe compiling JWasm is
> not difficult.

Thanks, but where is DEBUGR.BIN?
It is only for use under DOS

> > > Hi,
> > I only find JWASM V2.12 and not JWASM V2.17, and I can't find not
> DEBUGR.BIN
> >
> > JWasm releases are available at
> > https://github.com/Baron-von-Riedesel/JWasm/releases for MSWindows and
> > (DJGPP) DOS binaries. On a Linux host system I believe compiling JWasm
> is
> > not difficult.
>
> Thanks, but where is DEBUGR.BIN?
> It is only for use under DOS

You have to build it yourself. I did it this way:

hg clone https://hg.pushbx.org/ecm/fddebug
cd fddebug
dosemu -K "$PWD" -dumb -td -kt
jwasm -nologo -bin  -Fo DEBUGR.BIN -Fl=DEBUGR.LST -DRING0=1 debug.asm

After a brief wait time the file is created:

fddebug$ ls -l DEBUGR.BIN
-rw-r----- 1 ecm ecm 21856 Mar 29 20:26 DEBUGR.BIN

---
l

> Sorry to bother you again, but since I can't find your debugger in executable form

Why is that so hard? I see it with one glance, it's called Deb386.zip:

https://github.com/Baron-von-Riedesel/Deb386/releases/tag/v1.0

---
MS-DOS forever!

> Why is that so hard? I see it with one glance, it's called Deb386.zip:
>
> https://github.com/Baron-von-Riedesel/Deb386/releases/tag/v1.0

Yes, maybe my PC is blocking my searches because I can't find this myself (maybe the antivirus). Sorry. THANKS.