DOS ain't dead

We are looking forward for new version of Jemm. The changelist for this version as described in the history.txt file on the GitHub is quite rich.
Anyway, is possible to implement some alternate CTR-ALT-DEL handler?
We discussed this topic in april (http://www.bttr-software.de/forum/board_entry.php?id=16526#p16526)

Sure, on my notebook (16GB RAM) I can use the HIMEMX only without JEMM - the CPU remains in real mode and the reboot is posslible. But surprisinly in this configuration is quite unstable in my case and far better behaviour I can observe in V86 mode.
Now I load the JEMMEX in the AUTIOEXEC.BAT file and before rebooting I manually unload the JemmEX. It is working but not much comfortable.
So my question is -- is possible to add some switch into JemmEX for alternate CRTL-ALT-DEL (C-A-D) handling?
The manual says that switch ALTBOOT is currently dummy.
Maybe would be fine if the ALTBOOT switch could: 1) catch the C-A-D keystroke, 2) switch the CPU into realmode 3) set the environment like when JemmEX unloaded from command line 4) Reboot computer

---
DOS-u-akbar!

> Maybe would be fine if the ALTBOOT switch could: 1) catch the C-A-D
> keystroke, 2) switch the CPU into realmode 3) set the environment like when
> JemmEX unloaded from command line 4) Reboot computer

FASTBOOT switches CPU to real-mode, restores interrupt vectors and at last calls Int 19h to "reboot". One could implement ALTBOOT as a FASTBOOT variant, the one difference be that finally a true reset (setting/toggling a bit in the KBC) is done.

---
MS-DOS forever!

> FASTBOOT switches CPU to real-mode, restores interrupt vectors and at last
> calls Int 19h to "reboot". One could implement ALTBOOT as a FASTBOOT
> variant, the one difference be that finally a true reset (setting/toggling
> a bit in the KBC) is done.

OK, but is true that for FASTBOOT option is needed some additional driver when using with FreeDOS?

---
DOS-u-akbar!

> OK, but is true that for FASTBOOT option is needed some additional driver
> when using with FreeDOS?

I guess that's historical now, some old FreeDOS kernel didn't allow to restore the IVT to the state before DOS is loaded. Also, since it's not a "warm boot" what is to be achieved, it's pretty irrelevant what state the IVT is in.

---
MS-DOS forever!

> I guess that's historical now, some old FreeDOS kernel didn't allow to
> restore the IVT to the state before DOS is loaded. Also, since it's not a
> "warm boot" what is to be achieved, it's pretty irrelevant what state the
> IVT is in.

OK. I tried the FASTBOOT option with FreeDOS (kernel 2042 [11/2016], FreeCOM 0.84-pre2, JemmEx 5.79 from config.sys).
In opposite of setup without FASTBOOT it works however with some bizarre aspect.
After pressing CTRL-ALT-DEL appears a error message: "No bootable device - insert boot disk and press any key"
I just press any key and the computer reboots.

---
DOS-u-akbar!

> After pressing CTRL-ALT-DEL appears a error message: "No bootable device -
> insert boot disk and press any key"

That message I also get with FASTBOOT if the XBDA has been moved into an UMB and not restored before the reboot.

If the XBDA is ok, the system reboots "quickly", but the second drive becomes the "first" (the one where the boot sector is loaded from) !?

---
MS-DOS forever!

> If the XBDA is ok, the system reboots "quickly", but the second drive
> becomes the "first" (the one where the boot sector is loaded from) !?

But... That is very undesireble behaviour. As you proposed the modification the of the ALTBOOT option - it seems to be perfect.

---
DOS-u-akbar!

> But... That is very undesireble behaviour. As you proposed the modification
> the of the ALTBOOT option - it seems to be perfect.

You misunderstood. I described how FASTBOOT behaves on my current machine, not how it was planned to behave.

I checked what actually happens in Jemm when Ctrl-Alt-Del is catched (no FASTBOOT). I does
- set a flag for soft-reset in CMOS ram
- set 1234h in BIOS 40:72h
- switch to real-mode
- far jump to F000:FFF0 (or FFFF:0000)

that's already what was proposed for altboot. It "should" work.

---
MS-DOS forever!

JEMM386 surely internaly switches from real mode to V86 mode. Do you plan to support the undocumented Microsoft API for that? It is called GEMMIS and is used for cooperation between Windows 3.1 and MS-DSO with EMM386 loaded.

Some info about it

and related API reference from RBIL

---
DOS-u-akbar!

> JEMM386 surely internaly switches from real mode to V86 mode. Do you plan
> to support the undocumented Microsoft API for that? It is called GEMMIS and
> is used for cooperation between Windows 3.1 and MS-DSO with EMM386 loaded.
>
> Some
> info about it
>
> and
> related
> API reference from RBIL

I would certainly hope JEMM386 to support GEMMIS too. You will find more information about GEMMIS support for JEMM386 in this thread:

https://github.com/Baron-von-Riedesel/Jemm/issues/5

> I checked what actually happens in Jemm when Ctrl-Alt-Del is catched (no
> FASTBOOT). I does
> - set a flag for soft-reset in CMOS ram
> - set 1234h in BIOS 40:72h
> - switch to real-mode
> - far jump to F000:FFF0 (or FFFF:0000)
>
> that's already what was proposed for altboot. It "should" work

Hm, I just tested the CTRL-ALT-DEL (without FASTBOOT) in the last prerelease of Jemm386 but it still does not work - computer just freezes like in the previous versions.
What about implementing some optional debug logs to track which step freezes the computer?

---
DOS-u-akbar!

I noticed that in this version of Jemm386 disappeared the commandline option SB
(Sound blaster emulation compatible mode)
Why? Not needed more?

---
DOS-u-akbar!

> Hm, I just tested the CTRL-ALT-DEL (without FASTBOOT) in the last
> prerelease of Jemm386 but it still does not work - computer just freezes
> like in the previous versions.
> What about implementing some optional debug logs to track which step
> freezes the computer?

They ARE already implemented. To activate them do:

1. Adjust file MAKEFILE:

!if $(DEBUG)
AOPTD=-D_DEBUG -D?RBTDBG=1 <<<<<<
!else

2. run "nmake debug=1"

Use DEBEX\jemmex.exe in your config.sys

This version displays some milestone during reboot, finally when arrived in real-mode string "RBT" is displayed and it waits for a keypress.

---
MS-DOS forever!

> I noticed that in this version of Jemm386 disappeared the commandline
> option SB
> (Sound blaster emulation compatible mode)
> Why? Not needed more?

Should still be there ( see switch ?SB in the source ). Although I doubt that it does something useful.

---
MS-DOS forever!

> Hm, I just tested the CTRL-ALT-DEL (without FASTBOOT) in the last
> prerelease of Jemm386 but it still does not work - computer just freezes
> like in the previous versions.

Not very surprising, since I didn't change anything.

One could make ALTBOOT send a "system reset" command to the keyboard controller - if that will indeed restart your machine. You can check it with debug.com: start debug, then enter

-o 64,fe

and see if the system reboots properly.

---
MS-DOS forever!

> One could make ALTBOOT send a "system reset" command to the keyboard
> controller - if that will indeed restart your machine. You can check it
> with debug.com: start debug, then enter
>
> -o 64,fe
>
> and see if the system reboots properly.

I just tried your sequence but unfortunately it didn't bring my computer to restart - the system just hanged and stayed frozen and I had to press the power button.
What is interresting - the behaviour was completely identical with JEMMEX loaded (in V86 mode) and in raw real mode without any memory manager loaded.

---
DOS-u-akbar!

I wanted to share that I have a similar issue: I can't trust Ctrl-Alt-Del to reboot my machines when using FreeDOS/HimemX/Jemm386 or FreeDOS/JemmEx.

I've tried all combinations of fastboot/altboot. At best a Ctrl-Alt-Del will cause my monitor to go into a crazy flicker error state, and then a repeated Ctrl-Alt-Del will work. But that's maybe 20% of the time. Usually, the machine does nothing but become unresponsive to further keyboard input.

I'm using an IBM PS/2 386 luggable: the P70 8573-121.

Right now I'm just using "reboot35.com" when I can (https://www.bttr-software.de/freesoft/boot.htm#bootutils). It works fine.

> I'm using an IBM PS/2 386 luggable: the P70 8573-121.

That's a nice oldtimer, but probably also a bit "incompatible".

Jemm386 could simply cause a "triple fault" to reboot, that should work on (virtually?) all machines. Doing this with "ALTBOOT" is perhaps the simplest and best.

---
MS-DOS forever!

> One could make ALTBOOT send a "system reset" command to the keyboard
> controller - if that will indeed restart your machine. You can check it
> with debug.com: start debug, then enter
>
> -o 64,fe
>
> and see if the system reboots properly.

This method does not work on my i7 machine but got my one idea. In ACPI documentation are described registers for cold reboot.
I updated my test utility Numcores and now it can detect a version of your ACPI and the reboot HOWTO.
So for machine is the reboot register is B2h and the reset value is FBh.
Accordingly the DEBUG command "-o B2,FB" reboots my computer without any problem both in real and protected/V86 mode.

My favour ask for you is a slight modification for ALTBOOT parameter in Jemm386. Please, extend the syntax to something like "DEVICE=JEMM386.EXE ALTBOOT:xx,yy" where XX and YY would be a optional arguments for alternate reboot port and alternate reboot value.
So in my case I would call your driver with "DEVICE=JEMM386.EXE ALTBOOT:B2,FB"
Of course, ideal solution would be if the JEMM386 could perform the ACPI scan itself but I agree that it would need a lot of new code and my proposed compromise is sufficient.

---
DOS-u-akbar!

> My favour ask for you is a slight modification for ALTBOOT parameter in
> Jemm386. Please, extend the syntax to something like "DEVICE=JEMM386.EXE
> ALTBOOT:xx,yy" where XX and YY would be a optional arguments for alternate
> reboot port and alternate reboot value.

That's a horrible idea, IMO

My suggestion is: write a small device driver that hooks int 15h, ah=4Fh, catch ctrl-alt-del and then issue your I/O commands - it's trivial.

---
MS-DOS forever!

> That's a horrible idea, IMO

Why is it so horrible?

---
DOS-u-akbar!

> Why is it so horrible?

How is a user supposed to find out what ports may work on his/her machine?
How would a documentation of this new "feature" look like?

---
MS-DOS forever!

> > Why is it so horrible?
>
> How is a user supposed to find out what ports may work on his/her machine?
> How would a documentation of this new "feature" look like?

And how is user supposed to find out which I=mmmm-nnnn, X=mmmm-nnnn, etc. settings should use on his machine?
This reboot port/value can be fortunately unambiguously got from BIOS. (using my utility or some other utility)

The documentation could be simple
ALTBOOT - for reboot uses legacy keyboard port (instead of reboot address)
ALTBOOT:xx,yy - use alternate port(xx) and reboot value(yy)

---
DOS-u-akbar!

Hi, nice to see you finally solved your reboot problem.
It seems that KBC on your MB may cut off some legacy features that doesn't route reset signal properly and the system relies on ACPI (today view on OS requirements - it must support ACPI to use advanced features of HW)

I tried your tool and it displayed:

Detected ACPI interface in version 1.0
Physical processor cores: 4
Logical processor cores: 4

Values for coldboot as ACPI reports:
io: 2562 (0A02h)
mmio: 0 (00h)
value: 0 (00h)


But when I send 0 to port A02h it does nothing. Maybe my MB is not crippled enough so it has working legacy reset but no ACPI reset :P

Your proposal of altboot option for JEMM seems to me OK and easy to implement instead of adding ACPI code for autoprobe - that we see is not reliable, yet ;)

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

Yes, in ACPI specification is even defined a cfg byte (Legacy_devices) which defines whether the legacy kbd ports 60h and 64h are implemented in compatible way.

It it correct that you have 4-cores processor?
It is interresting that your BIOS reports the ACPI ver 1.0 only. (btw. did you run this util under pure DOS or under Windows?)
Anyway - I am not sure whether in 1.0 standard is already defined the ACPI reboot information.
I have to look in the ACPI 1.0 documentantion.

---
DOS-u-akbar!

> Yes, in ACPI specification is even defined a cfg byte (Legacy_devices)
> which defines whether the legacy kbd ports 60h and 64h are implemented in
> compatible way.

And it's defined by chipset, some may have a config bit to enable/disable this function some may have removed it.

> It it correct that you have 4-cores processor?

As I post numcores results before I told that I have disabled HT in BIOS (because in some cases it degrades performance under XP)

> It is interresting that your BIOS reports the ACPI ver 1.0 only. (btw. did
> you run this util under pure DOS or under Windows?)

Yes, the MB has the latest Award non-UEFI BIOS where ACPI 1.0 was standard, ran in DOS with JEMM.

> Anyway - I am not sure whether in 1.0 standard is already defined the ACPI
> reboot information.
> I have to look in the ACPI 1.0 documentantion.

Then you should check for existence/validity of reset method. I can only say I have power down method that is used by fdapm to shutdown pc. Do you know some other program to test if reset is present? Maybe ACPICA has some ACPI compliance tests that would report it, I vaguely remember that I trid some such tool but didn't rememver what it reported...

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

Hm, I was right. The reset mechanism is not defined in the ACPI 1.0. It occurs from ACPI 2.0.
Anyway, I updated my tool - added some sanity checks and fallback to legacy keyboard controler detection. And I renamed it from NumCores to ACPItest.
In a week I will try to add the mechanism for ACPI shutdown as my notebook has no APM - it is ACPI only.

---
DOS-u-akbar!

I neither have APM but fdapm can shutdown via ACPI fine. Also I wrote a simple tool that do shutdown via chipset registers that I used to force shutdown Win98 where shutdown was not working due to nvidia drivers bug.

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

OK, now it checked that reboot is not available.

ACPI info tool (compiled 3.2.2021)

Detected ACPI interface in version 1.0
Physical processor cores: 4
Logical processor cores: 4

I got no information from ACPI how to perform coldboot.


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

After some effort I was able to write the ACPI poweroff routine. I really need it because the "fdapm /poweroff" command does not work on my notebook.
But - the routine works nicely on my Pentium-4 machine in opposite of the notebook.
I investigated where the problem on my notebook is and I found that some ACPI tables are bigger than 65535 bytes - what is a problem for realmode applications. And the important DSDT table where is located object S5 (which contains poweroff info) has size 196238 bytes on my machine.
Of course, after some effort I will get it to work but this is a problem for FDAPM. I thought that I will be able to write a patch for the poweroff function but it would need a deeper changes in the FDAPM source.

---
DOS-u-akbar!

> > JEMM386 surely internaly switches from real mode to V86 mode. Do you
> plan
> > to support the undocumented Microsoft API for that? It is called GEMMIS
> and
> > is used for cooperation between Windows 3.1 and MS-DSO with EMM386
> loaded.
> >
> >
> Some
> > info about it
> >
> > and
> >
> related
> > API reference from RBIL
>
> I would certainly hope JEMM386 to support GEMMIS too. You will find more
> information about GEMMIS support for JEMM386 in this thread:
>
> https://github.com/Baron-von-Riedesel/Jemm/issues/5

finally this issue got an enhancement tag added this year.