DOS ain't dead

I have a problem hot to reset my new notebook with the i7-9750H processor and with 16GB RAM.

If I boot into FreeDOS with skipped configuration files (with the F5 key) I can normaly press CTRL-ALT-DELETE and reset the computer.
But with my normal DOS setup the computer just hangs.
I have a suspection to JEMMEX (version 5.78).
The load line is DEVICE=JEMMEX.EXE NOEMS

Shall I rather use some other command line?
(and yes, I would preffer some solution with V86 mode but do not insist on it)

---
DOS-u-akbar!

> Shall I rather use some other command line?

I also have problems rebooting my ryzen machine when jemmex is loaded. So I prefer using UMBPCI & HimemX these days.

It doesn't need to be a bug in jemmex. If v86-mode is on, the BIOS will behave differently; for example, it then has to call VDS interrupt 4Bh on various occasions ( which is implemented by the EMM ). On my ryzen, the BIOS, in v86-mode, somehow manages to "corrupt" the beginning of the XBDA, resulting in the first byte of the XBDA ( which is supposed to contain the XBDA's size in kB ) to become zero.

Another machine ( GIGABYTE motherboard with AMI BIOS ) causes a crash in v86-mode simply because it starts to use "unreal" mode as soon as an USB memory stick is to be read.

---
MS-DOS forever!

On my Gigabyte with intel P67 I have a problem with UMBPCI that soft reset makes screen black but it hangs and I have to push reset button. With JEMMEX it works OK.
USB legacy support BIOS code is often buggy so I prefer to disable all of this crap (I use PS/2 KB and mouse) if not really necessary - need to boot from USB stick.

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

> > Shall I rather use some other command line?
>
> I also have problems rebooting my ryzen machine when jemmex is loaded. So I
> prefer using UMBPCI & HimemX these days.
>
> It doesn't need to be a bug in jemmex. If v86-mode is on, the BIOS will
> behave differently; for example, it then has to call VDS interrupt 4Bh on
> various occasions ( which is implemented by the EMM ).

could you detail this?

the bug may also be caused by the loaded (is it loaded?) keyboard driver that tries to reboot. please check!

> Another machine ( GIGABYTE motherboard with AMI BIOS ) causes a crash in
> v86-mode simply because it starts to use "unreal" mode as soon as an USB
> memory stick is to be read.

Just as an FYI, this may not actually be Unreal Mode (at least not directly) but rather System Management Mode (SMM). AFAIK, all BIOS USB implementations throw the computer into SMM when a USB device is accessed, which can cause all kinds of grief if not implemented correctly.

> the bug may also be caused by the loaded (is it loaded?) keyboard driver
> that tries to reboot. please check!

It could also be the other way around -- the problem may be resolved (rather than created) by installing a keyboard driver, especially if it is the MS KEYB program which completely replaces the normal keyboard BIOS.

> > the bug may also be caused by the loaded (is it loaded?) keyboard driver
> > that tries to reboot. please check!
>
> It could also be the other way around -- the problem may be resolved
> (rather than created) by installing a keyboard driver, especially if it is
> the MS KEYB program which completely replaces the normal keyboard BIOS.


nope.
> If I boot into FreeDOS with skipped configuration files (with the F5 key) I
> can normaly press CTRL-ALT-DELETE and reset the computer.

to start, it would be cool to learn to know if there is a keyboard driver loaded, and -if so- which.

besides this, AFAIR xEMM386 has some code to deal with CtrlAltDel. is this still active in JEMM386?

> to start, it would be cool to learn to know if there is a keyboard driver
> loaded, and -if so- which.

When Jemm is loaded, I load keybgr.dll, which is somewhat "rudimentary" - it calls the preinstalled BIOS driver for all keys and then translates the few keys which are different on German keyboards.

> besides this, AFAIR xEMM386 has some code to deal with CtrlAltDel. is this
> still active in JEMM386?

Of course. The kbd driver ctrl-alt-del code jumps to f000:fff0 ( or was it ffff:0000? ) to do a reset, but this surely won't work in v86-mode. So Jemm replaces the physical page FF00h (ROM) with a page from its pool and modifies the code at FFFF0h to gain control.

---
MS-DOS forever!

> I have a suspection to JEMMEX (version 5.78).

The first thing to try would be to use v5.79. in v5.78, IIRC, there was the switch ?CLEARBOOTFLGS active ( see Jemm32.asm ), which has been deactivated in v5.79.

edit: no, forget it! The ?CLEARBOOTFLGS thing was active only if cmdline option FASTBOOT was set.

---
MS-DOS forever!

> > I have a suspection to JEMMEX (version 5.78).
>
> The first thing to try would be to use v5.79. in v5.78, IIRC, there was the
> switch ?CLEARBOOTFLGS active ( see Jemm32.asm ), which has been deactivated
> in v5.79.
>
> edit: no, forget it! The ?CLEARBOOTFLGS thing was active only if cmdline
> option FASTBOOT was set.

OK, I have downloaded the newest HimemX and Jemm386 a done more tests.
If I load only Himem the CTRL-ALT-DEL restart is properly done regardless I have loaded the czech keyboard driver or not.
But when I loaded also Jemm386 (from CONFIG.SYS or from command line /no diference/) then the computer just freezes.
I also tried to load UMBPCI but my chipset is not supported.
And no, I haven't tried the MS Keyb.
Anyway, with HimemX only I still have about 600KB of conventional RAM which is fine.

---
DOS-u-akbar!