DOS ain't dead

I'd need to set a breakpoint ideally on any I/O port access (without specifying address of out instruction as I don't know all the locations in debugee) - can it be achieved with debugxv /v via v86 IO traps?
I tried to set BP at specific address with out instruction of type 02 - I/O watchpoint by command
BP xxxx:yyyy 02
BP confirmed it was set
then go
but program didn't stopped at breakpoint and run till the end.
I tried to add code to set CR4.3=1 (DE) as mentioned in readme but didn't help.
If I set BP with type 00 (code) it stops as expected at given address.
Debugee is now just a simple RM COM program with few byte outs for this test but I need to debug a PM program where I need to watch out port writes. Also I may need watch RD/WRMSR...
Or any else debugger capable do this (need to be run on real HW not inside VM)?

---
DOS gives me freedom to unlimited HW access.

> I'd need to set a breakpoint ideally on any I/O port access (without
> specifying address of out instruction as I don't know all the locations in
> debugee) - can it be achieved with debugxv /v via v86 IO traps?
> I tried to set BP at specific address with out instruction of type 02 - I/O
> watchpoint by command
> BP xxxx:yyyy 02
> BP confirmed it was set
> then go
> but program didn't stopped at breakpoint and run till the end.

What is xxxx:yyyy? For I/O watchpoints, you have to specify a port. So the syntax to catch access to I/O port 0x80 is:


bp %80 2


Note the % - it's necessary, else debug adds base of CS or DS to the "address". Alternatively, "bp 0:80 2" should also work (not tested).

---
MS-DOS forever!

> What is xxxx:yyyy? For I/O watchpoints, you have to specify a port.
> So the syntax to catch access to I/O port 0x80 is:
>
>
> bp %80 2
>

Thanks. Because it was not clear for me from documentation:
Although the breakpoints may be entered in the usual format ( segment:offset ), they are stored internally just as linear addresses, and so BP will display this linear address only.
There's no example how to set address for I/O watchpoint. At least the % is not much obvious.

Wouldn't be possible to extend it to I/O address range or at least mask instead of single value? E.g. %2xx for 200-2FFh range?
And please could you to extend r command to be able.directly R/W CRx regs?

---
DOS gives me freedom to unlimited HW access.

> bp %80 2
> Note the % - it's necessary, else debug adds base of CS or DS to the
> "address". Alternatively, "bp 0:80 2" should also work (not tested).

Huh, I got error with % (debugxv) - what's wrong? but 0:80 did the job and it stops at IO access...

-bp %80 2
    ^ Error
-bp 0:80 2
-bp
Bp0:00000080 02
-


---
DOS gives me freedom to unlimited HW access.

> Huh, I got error with % (debugxv) - what's wrong? but 0:80 did the job and
> it stops at IO access...

Sorry, I tested with a DebugR variant (jdeb386.exe). The '%' modifier isn't known by the DebugX variants. That means, btw, that to enter the I/O watchpoint in protected-mode with DebugX you'll most likely have to use "bp $0:80 2" - a bit of a mess.

---
MS-DOS forever!

> Wouldn't be possible to extend it to I/O address range or at least mask
> instead of single value? E.g. %2xx for 200-2FFh range?

It's restricted to what the hardware supports. And the hardware allows "ranges" of 1,2 or 4 (+8 in x64 mode) only.

> And please could you to extend r command to be able.directly R/W CRx regs?

That may be added to the DebugR variants ...

---
MS-DOS forever!

> It's restricted to what the hardware supports. And the hardware allows
> "ranges" of 1,2 or 4 (+8 in x64 mode) only.

OK, I understand, 4 HW breakpoints only. I guess if it could use some wider IO bitmap like for port trapping e.g. in VSBHDA...
So best I can do is to check range of 16 IO ports at one time, it would require run more times...

BTW when an IO watchpoint is hit debugxv displays code of next instruction after in/out - did it already executed it or it stop before in/out is performed? It would be nice, if possible, to stop before in/out is done and display the code starting with this instruction so I could see it without using unassemble command and skip it if needed.

> > And please could you to extend r command to be able.directly R/W CRx
> regs?
>
> That may be added to the DebugR variants ...

Or at least some command or commandline switch to enable DE bit in CR4 or set it automatically when someone define an IO watchpoint, I had to write my own tiny COM program to do it and run before starting debugx so better to have it in one tool...

---
DOS gives me freedom to unlimited HW access.

> BTW when an IO watchpoint is hit debugxv displays code of next instruction
> after in/out - did it already executed it or it stop before in/out is
> performed? It would be nice, if possible, to stop before in/out is done and
> display the code starting with this instruction so I could see it without
> using unassemble command and skip it if needed.

That's also a hardware "limitation" - no way to change that.

> Or at least some command or commandline switch to enable DE bit in CR4 or
> set it automatically when someone define an IO watchpoint, I had to write
> my own tiny COM program to do it and run before starting debugx ...

But you could write that tool in a minute, couldn't you? And I guess that's also true for the few people that may be interested in such matter...

---
MS-DOS forever!

> But you could write that tool in a minute, couldn't you? And I guess that's
> also true for the few people that may be interested in such matter...

Yes I did but seems to me weird that debugger supports breakpoints but I couldn't use them without external tool that enables DE...

---
DOS gives me freedom to unlimited HW access.

> > Wouldn't be possible to extend it to I/O address range or at least mask
> > instead of single value? E.g. %2xx for 200-2FFh range?
>
> It's restricted to what the hardware supports. And the hardware allows
> "ranges" of 1,2 or 4 (+8 in x64 mode) only.
While true for the debug registers, the CPU also supports the I/O map where for
every I/O address you can define allowed or disallowed.

Debuggers like SoftICE have supported this for ages...

> While true for the debug registers, the CPU also supports the I/O map where
> for
> every I/O address you can define allowed or disallowed.

Well, since we're now at the state of "claiming the obvious": the IO permission bitmap won't work in real-mode or PL0 protected-mode. In protected-mode PL3 it requires IOPL < 3.

> Debuggers like SoftICE have supported this for ages...

Thanks for the promotion... I once tried it and was disappointed ( can't remember why, but most likely because it didn't support protected-mode ).

---
MS-DOS forever!

> > While true for the debug registers, the CPU also supports the I/O map
> where
> > for
> > every I/O address you can define allowed or disallowed.
>
> Well, since we're now at the state of "claiming the obvious": the IO
> permission bitmap won't work in real-mode or PL0 protected-mode. In
> protected-mode PL3 it requires IOPL < 3.

True. It would require some sort of cooperation from JEMM386.

> > Debuggers like SoftICE have supported this for ages...
>
> Thanks for the promotion... I once tried it and was disappointed ( can't
> remember why, but most likely because it didn't support protected-mode ).
True. SoftICE was one of the first protected mode programs x386 *at all* (and I was one of the first few customers of it for amazing €386).

It only learned to debug protected mode programs as SoftICE/W for Windows, many years later.

In it's form for real mode/VM it was an extremely powerfull debugger; parts of it still not seen anywhere else. Like

BPX 60:123 "break if 60:123 is executed" (the first 4 using debug registers,
more using INT3)

BPX 4321:1234 5000:0 TW
"trace execution in a certain address range if instruction executes a write operation" (implemented by setting no-execute
for some pages, filtering actual interrupts by CS:IP)

BPDW 123:4320 "breakpoint if DW 123:4320 is Written" (or read or accessed)

BPIO 3F8 RW
"trace I/O address 3F8 access (read, write, or read/write)

BPINT 3F AH=17
"break on interrupt 31 if AH==17"

where "trace" meant "keep the last few thousand instructions and register content in store for the moment execution breaks"

that's how I found bugs in foreign programs, corrupting MCB structures

and many more ...

It was even available for WinNT, used to debug the Windows kernel and drivers.
Quite pricy at almost 2K$, but worth every cent if you value your time != zero.

Edited to add All the tracing was done in "close to normal speed", i.e. it wasn't single stepping in software, but used 386 features to run even "trace everything inside the kernel (and only the kernel) until you hit INT13/write sector or access some I/O address" in close to normal speed.

Damn, I'm screwed. The machine I need debug on is Tx486DLC and it has not CR4 neither debug extension, it has only DR0-7 so I can't breakpoint on IO access :(

---
DOS gives me freedom to unlimited HW access.

> Damn, I'm screwed. The machine I need debug on is Tx486DLC and it has not
> CR4 neither debug extension, it has only DR0-7 so I can't breakpoint on IO
> access :(

Too bad ! Now you can try the alternatives:

- Softice for DOS
- Borland's TD386
- 386SWAT

They're all aware of the 386 features and run code in PL0, so in theory they may support what you need. Would be cool and a huge benefit for the DOS community if you'd write a little essay about the pros and cons of those debuggers.

---
MS-DOS forever!

I tried TD(32/386) but it refused to load the exe.
Then I remembered of DarkDebugger. I/O breakpoints didn't work too. But I was able to trace it after some tens of trials:
https://www.vogons.org/download/file.php?id=216795&mode=view
This IO instruction in Speedsys make's it hang on some MBs as it attmpts to read non-existing config register and this is then passed out as IO bus cycle and do something wrong with chipset registers.

Now I'd like to know how to patch (skip) this IO access at runtime by some TSR or loader as I cannot patch the EXE coz it's encrypted or packed by unknown exe packer... Speedsys checks for V86 mode and complains about it (can run but very limitest tests available)

---
DOS gives me freedom to unlimited HW access.

> Now I'd like to know how to patch (skip) this IO access at runtime by some
> TSR or loader as I cannot patch the EXE coz it's encrypted or packed by
> unknown exe packer... Speedsys checks for V86 mode and complains about it
> (can run but very limitest tests available)

That's trivial if Qemm or Jemm is loaded - they both implement a simple port trapping API ( remember SBEMU? ).

Since you're a poweer user and developer, you could also patch jdeb386 to make it stop (with GPF) at a certain I/O access range - it's all in Debug/X's source code, file trappv.inc, proc checkioplinstr.

---
MS-DOS forever!

> That's trivial if Qemm or Jemm is loaded - they both implement a simple
> port trapping API ( remember SBEMU? ).

Problm is that Speedsys don't like to run under Jemm/Qemm/Emm(any v86) and it does detection before that I/O port access.

---
DOS gives me freedom to unlimited HW access.

> Now I'd like to know how to patch (skip) this IO access at runtime by some
> TSR or loader as I cannot patch the EXE coz it's encrypted or packed by
> unknown exe packer... Speedsys checks for V86 mode and complains about it
> (can run but very limitest tests available)

That's tricky in real-mode. You could perhaps use normal "execute" hw breakpoints? You have to find out the offset of the "OUT 22,al" instruction (relative to PSP:0), and a TSR might then set such a bp before the program starts. When the bp is triggered, to be safe, checking the 2 bytes at CS:IP might be a good idea...

---
MS-DOS forever!

> This IO instruction in Speedsys make's it hang on some MBs as it attmpts to
> read non-existing config register and this is then passed out as IO bus
> cycle and do something wrong with chipset registers.
>
> Now I'd like to know how to patch (skip) this IO access at runtime by some
> TSR or loader as I cannot patch the EXE coz it's encrypted or packed by
> unknown exe packer... Speedsys checks for V86 mode and complains about it
> (can run but very limitest tests available)

It 'just' took me 19 years to upload SPEEDSYS source code: https://github.com/bttrx/speedsys

HTH

---
Forum admin

> It 'just' took me 19 years to upload SPEEDSYS source code:
> https://github.com/bttrx/speedsys

I changed the repo to private, because it needs a cleanup.

---
Forum admin

> > It 'just' took me 19 years to upload SPEEDSYS source code:
> > https://github.com/bttrx/speedsys
>
> I changed the repo to private, because it needs a cleanup.

Repo is back.

---
Forum admin

[accidentally edited]

---
DOS gives me freedom to unlimited HW access.

> I have quickly found the code I'm fighting with:
>
> PROC Cyrix52method
> cmp     [CPUclass],4
> jnz     Not486instrSupport
> xor     ax,ax
> sahf
> mov     ax,5
> mov     bl,2
> div     bl
> lahf
> cmp     ah,bl
> jne     Not486instrSupport
> mov     [cyrix52detect],1
> mov     si,offset cyrix
> mov     [NumRepCPUVendor],si
> call    colorstr6x8
> cli
> mov     al,0FEh
> out     22h,al
> in      al,23h
> sti
>

Link to that code in the repo: https://github.com/bttrx/speedsys/blob/6e070ee29f0...d50d818793b6f51e4a68441/src/SPEEDSYS.ASM#L10669

You mentioned that the executable that you've used is packed:

> Now I'd like to know how to patch (skip)
> this IO access at runtime by some TSR or
> loader as I cannot patch the EXE coz it's
> encrypted or packed by unknown exe
> packer... Speedsys checks for V86 mode and
> complains about it (can run but very
> limitest tests available)

If it's created by speedin1 then it's just a DOS/EXE UPX with the "UPX!" signature (offset 55h) and the depacked size (offset 6Bh) hacked. You can restore the signature manually then adjust the checksum (offset 6Fh). UPXDUMP can tell you the current and expected checksum. After hacking the size and checksum to mirror the speedin1 modification I was able to unpack an executable using upx-ucl -d test.exe, despite the wrong size field.

---
l

> You mentioned that the executable that you've used is
> packed:
>
> > Now I'd like to know how to patch (skip)
> > this IO access at runtime by some TSR or
> > loader as I cannot patch the EXE coz it's
> > encrypted or packed by unknown exe
> > packer... Speedsys checks for V86 mode and
> > complains about it (can run but very
> > limitest tests available)
>
> If it's created by
> speedin1
> then it's just a DOS/EXE UPX with the "UPX!" signature (offset 55h) and the
> depacked size (offset 6Bh) hacked. You can restore the signature manually
> then adjust the checksum (offset 6Fh).
> UPXDUMP can tell you
> the current and expected checksum. After hacking the size and checksum to
> mirror the speedin1 modification I was able to unpack an executable using
> upx-ucl -d test.exe, despite the wrong size field.

Hmm, the speedsys.exe file in https://www.philscomputerlab.com/dos-benchmark-pack.html isn't packed in this way.

---
l

> > You mentioned that the executable that you've used is
> > packed:
> >
> > > Now I'd like to know how to patch (skip)
> > > this IO access at runtime by some TSR or
> > > loader as I cannot patch the EXE coz it's
> > > encrypted or packed by unknown exe
> > > packer... Speedsys checks for V86 mode and
> > > complains about it (can run but very
> > > limitest tests available)
> >
> > If it's created by
> >
> speedin1
> > then it's just a DOS/EXE UPX with the "UPX!" signature (offset 55h) and
> the
> > depacked size (offset 6Bh) hacked. You can restore the signature
> manually
> > then adjust the checksum (offset 6Fh).
> > UPXDUMP can tell
> you
> > the current and expected checksum. After hacking the size and checksum
> to
> > mirror the speedin1 modification I was able to unpack an executable
> using
> > upx-ucl -d test.exe, despite the wrong size field.
>
> Hmm, the speedsys.exe file in
> https://www.philscomputerlab.com/dos-benchmark-pack.html isn't packed in
> this way.

I did try to hack 55h to "UPX!" and then adjusted the checksum at offset 6Fh and it seems to depack using upx-ucl -d. I didn't run the resulting executable but it seems fine. So maybe it is packed the same way after all, just different garbage in the hacked fields?

---
l

> I did try to hack 55h to "UPX!" and then adjusted the checksum at offset
> 6Fh and it seems to depack using upx-ucl -d. I didn't run the
> resulting executable but it seems fine. So maybe it is packed the same way
> after all, just different garbage in the hacked fields?

OK, as we have sources now, no need to mess with binary anyway. Sometimes I saw that someone "obfuscated" his binary by overwriting UPX signature. So I just commented out
rem speedin1.exe
in SPEEDSYS.BAT to leave it as is. Now recompiled with TASM 4.1 and made dirty hotfix that allows run on 486DLC/SLC... Also corrected a typo "faind" -> "find" in srcs.

---
DOS gives me freedom to unlimited HW access.