DOS ain't dead

Hello,

there's a new Debug/X version in the pipeline - v2.50.
Last version was v2.02, so there have indeed a few major things been added:

- support for "hardware" breakpoints - meaning the 80386 debug registers.
- new DebugR variant DebugRV that can handle all programs in the context of a v86-monitor ( protected-mode and v86-mode ).

The old JemmDbg binary is now created with this new DebugRV binary, making it a full-fledged v86-monitor debugger, like 386SWAT (but without that ugly full-screen interface). However, this is still experimental (although it runs pretty stable) - no need to report bugs!

The debugger supports serial line communication, but also low-level video/keyboard access. The latter is a bit of a problem, since keyboard layouts tend to differ a lot - currently only US and GR layouts are supported. I had a look into the MS-DOS 4.0 source of keyboard.sys - I'm sure I don't want to touch that. The FreeDOS keyboard layout don't really look that much better, though...

So if anyone has a good approach to add new kbd layouts, tell me. The debugger doesn't need any sophisticated tables, it doesn't handle file or file names, it's just the alphanumeric keys, '#','$','%', BS and ENTER.

https://github.com/Baron-von-Riedesel/DOS-debug/releases/tag/v2.50pre

[edit: JemmDbg renamed to JDeb386]

---
MS-DOS forever!

> So if anyone has a good approach to add new kbd layouts, tell me. The
> debugger doesn't need any sophisticated tables, it doesn't handle file or
> file names, it's just the alphanumeric keys, '#','$','%', BS and ENTER.

you might look at mKEYB sources; in particular the keydefXX tables.

I don't think you're going to find an easy way to do this. Keyboard layouts are VERY complicated and confusing. E.g., you need to worry about things like code pages and keyboard modes. Some keyboards have a Latin Mode in addition to a "native" mode (Cyrillic, Hebrew, Greek, etc.).

The code from FD-KEYB I think is the one that addresses these most completely and accurately and it is NECESSARILY complicated. I can send you the Scancode -> ASCII translation tables from my SCANCODE program, but I think you're probably going to be better off using FD-KEYB.

> I don't think you're going to find an easy way to do this. Keyboard
> layouts are VERY complicated and confusing. E.g., you need to worry about
> things like code pages and keyboard modes. Some keyboards have a Latin
> Mode in addition to a "native" mode (Cyrillic, Hebrew, Greek, etc.).

Seems you didn't fully read my post:

> The debugger doesn't need any sophisticated tables, it doesn't handle file or
> file names, it's just the alphanumeric keys, '#','$','%', BS and ENTER.

Without the need for "dead keys", extended keys and the like, the situation is not longer "VERY complicated". Actually, the approach that I first considered seams feasible: to trap keyboard ports 0x60 and 0x64, then feed the keyboard driver with a bunch of make codes/break codes combinations and see what it makes out of that.

---
MS-DOS forever!

> Without the need for "dead keys", extended keys and the like, the situation
> is not longer "VERY complicated". Actually, the approach that I first
> considered seams feasible: to trap keyboard ports 0x60 and 0x64, then feed
> the keyboard driver with a bunch of make codes/break codes combinations and
> see what it makes out of that.

While that may seem feasible, based on experience I would say it probably isn't. There may not even be a keyboard driver installed, and even if there is you can't always tell since many of them don't follow the (incomplete) "standard" the MS used for their driver. There are also certain make/break codes that don't generate ASCII codes at all and if you accidentally simulate one of those you could end up in trouble. Also, with some keyboard drivers you can use INT 15.4F to inject make/break codes while with others you actually need to simulate ports 60h and/or 64h.

Also, you may not really want to depend on the BIOS or DOS keyboard driver from inside a protected mode debugger, anyway.

> Without the need for "dead keys", extended keys and the like, the situation
> is not longer "VERY complicated". Actually, the approach that I first
> considered seams feasible: to trap keyboard ports 0x60 and 0x64, then feed
> the keyboard driver with a bunch of make codes/break codes combinations and
> see what it makes out of that.

I did read it, and I understand what you're trying to do. But I also think you're just going to confuse your users if you don't take into account things like keyboard modes and maybe even things like arrow keys (which includes things like NumLock and Shift-key statuses).

> you might look at mKEYB sources; in particular the keydefXX tables.

Thanks, that's about what I was looking for - relatively straightforward and without bells and whistles.

Btw., on my keyboard "MKEYB GR" strangely doesn't translate key 0x56 ( backslash-key on the US keyboard ) - although I can see that the key is supposed to be translated. Probably have to compile it on my own.

---
MS-DOS forever!

> Btw., on my keyboard "MKEYB GR" strangely doesn't translate key 0x56 (
> backslash-key on the US keyboard ) - although I can see that the key is
> supposed to be translated. Probably have to compile it on my own.

It turned out that Mkeyb and MS SmartDrv don't like each other. The root of the problem is that MKEYB's Int 15h handler expects the carry flag to be set, else it does nothing. If SmartDrv is loaded AFTER Mkeyb, it also installs an Int 15h handler, to catch Ctrl-Alt-Del. It doesn't care about the the carry flag, and the crucial code is:


cmp ax, 4F53h
jnz prev_handler


That also explains why it's just key 56h that isn't translated, the usual keys have scan codes < 53h.

The simplest fix is to load MKeyb AFTER MS SmartDrv.

---
MS-DOS forever!

Debug/X v2.50 is here:

https://github.com/Baron-von-Riedesel/DOS-debug/releases/tag/v2.50

JDeb386 is a PL0 debugger for Jemm that makes use of the new Debug/X variant DebugRV, a full v86-monitor context debugger ( like 386SWAT ):

https://github.com/Baron-von-Riedesel/JDeb386/releases/tag/v1.2

---
MS-DOS forever!