zyzzle wrote on 2023-02-23, 05:00:

KormaX wrote on 2023-02-22, 17:35:

I compiled the proper version of Jemm386 so I can sideload it in my normal setup in order to switch to a "Sound Blaster compatibility mode" on fly, which is far better than rebooting.

Sounds very promising! Is it possible to upload your compiled JEMM386 binary here for us to test? If it enables loading from commandline and being disabled / enabled without rebooting, that is fabulous. It also seems a wonderful success that you found this custom-compiled version more stable with SBEMU (I assume you're using the latest .zip 22.Feb version just posted?). Are you willing to share the JEMM binary which can be 'sideloaded'? Appreciated.

I uploaded it here, or I hope so (I'm from DOS with Links, so I can't be sure until the comment is submitted 🤣).

Well, JEMM386 can NOT be unloaded once loaded, at least, not by any means I'm aware of. It can be loaded in fly using loaders, like Loadsys (with LOADSYS /OD, because it's a device driver.) Maybe devload also works, IDK. DDL doesn't. I tried loading it with LOADSYS /R /OD so it could later be removed by LOADSYS /U, but it installs itself some funny way and Loadsys can't track it. It thinks Jemm is failed to load and won't be on it's list, redirected interrupts not recorded. I also tried to mark the system state with Marknet and then restore with Relnet, but it just hung the system. Maybe they couldn't remove Jemm, maybe they did but the CPU remained in PM without the monitor 🤣 Thus, QPIEMU.DLL also stays in the memory.

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

My command line is:
LOADSYS /R /i08 /i09 /i0A /i0B /i0C /i0D /i0E /i0F /i1C /i70 /i71 /i72 /i73 /i74 /i75 /i76 /i77 SBEMU.EXE

If it doesn't work for you, just load it once with LOADSYS /R, and Loadsys will list the problematic interrupts you should mark.

Honestly, I don't know what happens in the XMS when this method is used, yesterday I unloaded and reloaded SBEMU many times and no problem occured. But unloading SBEMU's some parts and maybe removing the PSP (what LOADSYS does in my opinion) doesn't release the memory it requests from HDPMI, what's more, you can't reload it within the same VM. You have to remove HDPMI as well with LOADSYS /U (possibly removing everything related, but I'm not sure) and then you can reaload the both or operate your DOS with native HDA programs or whatever.

Baron von Riedesel wrote on 2023-02-19, 17:13:

IIRC Tyrian is a 16-bit protected-mode program - it hasn't been mentioned as of yet, but these are not compatible with SBEMU. Th […]
Show full quote

Bondi wrote on 2023-02-19, 15:58:

For some reason I get "runtime error (0025) cannot initialize" running Chasm the rift. It runs fine without sbemu/HDPMI32i, with no sound obviously.
I get the same (0025) error for Jack Jazz Rabbit and Tyrian. However, they don't run without the sbemu/HDPMI32i too, but with a different error (Error 200, due to the fast cpu iirc). Nevertheless it may work on other target computers, so probably worth checking.

EDIT: So i patched the JJR and Tyrian and they now run (without sound drivers), and with "runtime error (0025) cannot initialize" with sbemu/hdpmi.

IIRC Tyrian is a 16-bit protected-mode program - it hasn't been mentioned as of yet, but these are not compatible with SBEMU. The problem is that 16- and 32-bit clients cannot run in the very same VM.
That's a pity, because I would have loved to hear the Tyrian music with SBEMU...
To overcome this restriction, one would have to implement SBEMU as a 16-bit protected-mode TSR - a true "challenging" task, IMO. Or implement it as a "jemm loadable module" - that's possible, but is also pretty "advanced".

Wouldn't a second modified DPMI server do the job?

I mean, I might be mistaken, but according to my understandig, if HDPMI is initialized within Jemm's VM, then it's going to execute its real mode parts within said VM. So if the user disables HDPMI32I for further clients right after SBEMU is loaded and loads up another DPMI server for the 16 bit PM program that consistently rerouts the client's IO to real address mode, then the IO would end up being trapped by Jemm eventually reaching the 32 bit SBEMU within the 32 bit VM. Not economical in terms of CPU cycles, but would do the job. If I understand everything correctly, of course.

Okay, with /T1, Monkey Island and Volfied works. Now, for Volfied, its suboptimal that with HDA, I can either have Sound Blaster OR IBM Speaker, but not both. The optimal solution would be for SBEMU to optionally emulate IBM Speaker as well 😁 But I am not greedy 🤣

Prehistorik 2 still doesn't work.

KormaX wrote on 2023-02-23, 07:27:

Well, JEMM386 can NOT be unloaded once loaded, at least, not by any means I'm aware of.

Well, the documented way to unload Jemm386 is "JEMM386 UNLOAD". AFAIK it's the only way to properly unload it.

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

Why using tools like LOADSYS??? HDPMI also has a documented option to be unloaded. If it refuses to unload, it has very strong reasons to do so ( for example, because there's still a client running ).

zyzzle wrote on 2023-02-23, 00:21:

- I can't run SBEMU.EXE again after I've run it the initial time, in order to change settings / modify values. It does run *once*, regardless of settings, regardless of protected mode or real mode emulation. However, all future attempts to run it again / change settings result in a SIGFAULT generated CWSDMPI / DPMI. The only way to reconfigure is to reboot the machine. This behavior occurs on all three of my HDA systems, with no other DOS TSRs except either JEMMEX or HimemSX running. Not sure of this is an HDPMI32 problem, or what?

I've just finished the TSR installation check. that means SBEMU now can run unlimited times and change parameters without rebooting. I'll release after a few more tests.

Baron von Riedesel wrote on 2023-02-23, 14:02:

Well, the documented way to unload Jemm386 is "JEMM386 UNLOAD". AFAIK it's the only way to properly unload it. […]
Show full quote

KormaX wrote on 2023-02-23, 07:27:

Well, JEMM386 can NOT be unloaded once loaded, at least, not by any means I'm aware of.

Well, the documented way to unload Jemm386 is "JEMM386 UNLOAD". AFAIK it's the only way to properly unload it.

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

Why using tools like LOADSYS??? HDPMI also has a documented option to be unloaded. If it refuses to unload, it has very strong reasons to do so ( for example, because there's still a client running ).

I also have very strong reasons to remove it, as I explained it in my comment. I mean, my DOS feels itself like this in 99% of the time anyway: https://www.youtube.com/watch?v=GjO1Zp4MhPk
so it doesn't change much, but I didn't want to reboot every time I wanted to try or modify something.

JEMM386 /? didnt mention the UNLOAD option, and, as I don't use Jemm otherwise, used it based on the info the binary had given. I suppose that there is a LOAD option then to load it from the command line, or something, I'll check it.

EduBat wrote on 2023-02-22, 18:47:

Any hints on how you guys are doing the testing ? So far all my tests end up with a "exception 0d in ring 0" (or something like […]
Show full quote

Any hints on how you guys are doing the testing ? So far all my tests end up with a "exception 0d in ring 0" (or something like that.) It must be something really silly that I'm overlooking.
My setup is a pentium 4 with a ICH-3M running Freedos 1.3.
I load jemmex in fdconfig.sys with device=jemmex.exe (no other options) then follow the instructions in the read.me in the zip file.
Both Freedoom and Boom show the error message above.

Thanks in advance.

I never tested it on freedos, only on MSDOS7.0/7.1, do you have any other system to test? I think I'll test it on Freedos later.

KormaX wrote on 2023-02-23, 14:29:

JEMM386 /? didnt mention the UNLOAD option, and, as I don't use Jemm otherwise, used it based on the info the binary had given. I suppose that there is a LOAD option then to load it from the command line, or something, I'll check it.

I don't know where you've got your jemm386 version, mine displays with "jemm386 /?"

At the very bottom the load/unload thing is mentioned...

Baron von Riedesel wrote on 2023-02-23, 14:40:

I don't know where you've got your jemm386 version, mine displays with "jemm386 /?" […]
Show full quote

KormaX wrote on 2023-02-23, 14:29:

JEMM386 /? didnt mention the UNLOAD option, and, as I don't use Jemm otherwise, used it based on the info the binary had given. I suppose that there is a LOAD option then to load it from the command line, or something, I'll check it.

I don't know where you've got your jemm386 version, mine displays with "jemm386 /?"

Jemm386 v5.84 [02/06/23]
Jemm386. Parts (c) tom ehlert 2001-2006 c't/H. Albrecht 1990
usage: either add a line to CONFIG.SYS: DEVICE=JEMM386.EXE [ options ]
or run it from the command line: C:\>JEMM386 [ options ]
available options are:
+A20/NOA20 A20-disable emulation on/off (default on)
ALTBOOT use alternate reboot strategy
B=segm specify lowest segment address for EMS banking (default=4000)
D=n set DMA buffer size in kB (default=64, max is 128)
EMX increased EMX DOS extender compatibility
FASTBOOT fast reboot. Requires Jemm386 to be loaded in CONFIG.SYS.
FRAME=E000 set EMS page frame (FRAME=NONE disables frame). Any value
between 8000 and E000 is accepted, but not all will work.
I=start-end force a region to be used for UMBs. Without this option
range C000-EFFF is scanned for unused pages. May also be used
to add (parts of) regions A000-BFFF or F000-F7FF as UMBs. Don't
use this option if you don't know what you are doing!
I=TEST scan ROMs for unused pages, include found regions as UMBs
[MAX=]n limit for VCPI (and EMS if < 32M) memory in kB (default 120 MB)
MIN=n reserve up to <n> kB for EMS/VCPI memory on init (default=0)
MOVEXBDA move XBDA into UMB. Some BIOSes won't allow this.
NOCHECK disallow access to address space without RAM (MMIO)
NOEMS disable EMS handling
NODYN no dynamic XMS memory allocation (use MIN= to set fix amount)
NOHI don't move resident part into first UMB
NOINVLPG don't use INVLPG opcode
+PGE/NOPGE Page Global Enable feature usage on/off (default off)
RAM/NORAM try to supply UMBs on/off (default on)
S=start-end assume Shadow-RAM activated by UMBPCI, include it as UMB
SB SoundBlaster driver compatibility mode
SPLIT regain partially used EPROM 4k pages for UMBs
+VCPI/NOVCPI VCPI Support on/off (default on)
VDS/NOVDS Virtual DMA Services on/off (default on)
+VME/NOVME V86-Mode Extensions on/off (default off)
VERBOSE display additional details during start (abbr: /V)
X=start-end exclude region from being touched or used by Jemm386
X=TEST scan memory region C000-EFFF for UMB exclusion

'+': option can be set dynamically by running Jemm386 from the command line

When invoked from the command line Jemm386 additionally will understand:
LOAD install
UNLOAD uninstall

At the very bottom the load/unload thing is mentioned...

🤣, you are absolutely right. It was there entire time 🤣 🤣 🤣
I was hurry every time I tested this thing, so I just somehow never registered that there's anything useful after the main list, because I don't have much time currently.
But, yeah, the lazy person gets tired twice.
Thank you.

KormaX wrote on 2023-02-23, 11:52:

Baron von Riedesel wrote on 2023-02-19, 17:13:

IIRC Tyrian is a 16-bit protected-mode program - it hasn't been mentioned as of yet, but these are not compatible with SBEMU. Th […]
Show full quote

Bondi wrote on 2023-02-19, 15:58:

For some reason I get "runtime error (0025) cannot initialize" running Chasm the rift. It runs fine without sbemu/HDPMI32i, with no sound obviously.
I get the same (0025) error for Jack Jazz Rabbit and Tyrian. However, they don't run without the sbemu/HDPMI32i too, but with a different error (Error 200, due to the fast cpu iirc). Nevertheless it may work on other target computers, so probably worth checking.

EDIT: So i patched the JJR and Tyrian and they now run (without sound drivers), and with "runtime error (0025) cannot initialize" with sbemu/hdpmi.

IIRC Tyrian is a 16-bit protected-mode program - it hasn't been mentioned as of yet, but these are not compatible with SBEMU. The problem is that 16- and 32-bit clients cannot run in the very same VM.
That's a pity, because I would have loved to hear the Tyrian music with SBEMU...
To overcome this restriction, one would have to implement SBEMU as a 16-bit protected-mode TSR - a true "challenging" task, IMO. Or implement it as a "jemm loadable module" - that's possible, but is also pretty "advanced".

Wouldn't a second modified DPMI server do the job?

I mean, I might be mistaken, but according to my understandig, if HDPMI is initialized within Jemm's VM, then it's going to execute its real mode parts within said VM. So if the user disables HDPMI32I for further clients right after SBEMU is loaded and loads up another DPMI server for the 16 bit PM program that consistently rerouts the client's IO to real address mode, then the IO would end up being trapped by Jemm eventually reaching the 32 bit SBEMU within the 32 bit VM. Not economical in terms of CPU cycles, but would do the job. If I understand everything correctly, of course.

I don't think so. VM only traps V86 programs. In protected mode it's trapped by the ring0 kernel provided by DPMI host.
I don't know the difference between 16 & 32bit DPMI host. I think 32bit host ideally could be compatible with 16bit, the only differences of the client is the segment limit?. Or is it true that 16bit PM games cannot run under win9x? or win9x dynamically choose the right host?

One thing to note: My NEC versa s260 will freeze on JEMM startup when a USB stick is plugged. I guess JEMM has problems on detecting MMIO areas, or should I manually specify?

crazii wrote on 2023-02-23, 14:45:

I don't know the difference between 16 & 32bit DPMI host. I think 32bit host ideally could be compatible with 16bit, the only differences of the client is the segment limit?. Or is it true that 16bit PM games cannot run under win9x? or win9x dynamically choose the right host?

16-bit DPMI was meant for 80286 processor.

georgel wrote on 2023-02-23, 14:51:

crazii wrote on 2023-02-23, 14:45:

I don't know the difference between 16 & 32bit DPMI host. I think 32bit host ideally could be compatible with 16bit, the only differences of the client is the segment limit?. Or is it true that 16bit PM games cannot run under win9x? or win9x dynamically choose the right host?

16-bit DPMI was meant for 80286 processor.

Oh, OK, I recall some limits on 286 protected mode.

KormaX wrote on 2023-02-23, 11:56:

Okay, with /T1, Monkey Island and Volfied works. Now, for Volfied, its suboptimal that with HDA, I can either have Sound Blaster OR IBM Speaker, but not both. The optimal solution would be for SBEMU to optionally emulate IBM Speaker as well 😁 But I am not greedy 🤣

Prehistorik 2 still doesn't work.

I tested monkey island for more times with /T5, it occasionally quit with divide zero exception without reading any DMA/SB io port. weird.

KormaX wrote on 2023-02-23, 07:27:

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

Does LOADSYS tracks other IVT entries? now I installed a AMIS TSR service at 0x2D, does that means you need also to specify /i2d in command line?

crazii wrote on 2023-02-23, 15:05:

KormaX wrote on 2023-02-23, 07:27:

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

Does LOADSYS tracks other IVT entries? now I installed a AMIS TSR service at 0x2D, does that means you need also to specify /i2d in command line?

It's very likely that I will need to do so. It's a good opportunity to test it as well. Theoretically, if I don't specify it, LOADSYS will throw an error message on me that it's there and also it's going to refuse to unload SBEMU afterwards because of that vector.

I expect an error message like this:

!!!Warning: Side effect: Interrupt 08 changed but does not point at the program just loaded - C:\SBEMU\SBEMU.EXE - It will not be reset at unloading. Load with /ióó option to reset at unload.

crazii wrote on 2023-02-23, 14:45:

KormaX wrote on 2023-02-23, 11:52:

Baron von Riedesel wrote on 2023-02-19, 17:13:

IIRC Tyrian is a 16-bit protected-mode program - it hasn't been mentioned as of yet, but these are not compatible with SBEMU. The problem is that 16- and 32-bit clients cannot run in the very same VM.
That's a pity, because I would have loved to hear the Tyrian music with SBEMU...
To overcome this restriction, one would have to implement SBEMU as a 16-bit protected-mode TSR - a true "challenging" task, IMO. Or implement it as a "jemm loadable module" - that's possible, but is also pretty "advanced".

Wouldn't a second modified DPMI server do the job?

I mean, I might be mistaken, but according to my understandig, if HDPMI is initialized within Jemm's VM, then it's going to execute its real mode parts within said VM. So if the user disables HDPMI32I for further clients right after SBEMU is loaded and loads up another DPMI server for the 16 bit PM program that consistently rerouts the client's IO to real address mode, then the IO would end up being trapped by Jemm eventually reaching the 32 bit SBEMU within the 32 bit VM. Not economical in terms of CPU cycles, but would do the job. If I understand everything correctly, of course.

I don't think so. VM only traps V86 programs. In protected mode it's trapped by the ring0 kernel provided by DPMI host.
I don't know the difference between 16 & 32bit DPMI host. I think 32bit host ideally could be compatible with 16bit, the only differences of the client is the segment limit?. Or is it true that 16bit PM games cannot run under win9x? or win9x dynamically choose the right host?

My thought was that the modified PR0 DPMI kernel in question actually goes RM in order to perform said IO operations. As far as I remember, if a DPMI host is invoked within a v86 VM, it goes back to that VM when trying to switch back to real mode. But, as someone who has never written such a thing, I don't know. As the conversation above shows, I didn't even remember correctly the instructions on JEMM 🤣

UPDATE:
There's no improvement on the emulation 😁, but on the TSR part. now SBEMU can change parameters without rebooting.
Note that the default parameters takes effect on initial run. after that, you can only change parameters through command line. hope this will help most parameters for the initial startup.
e.g. initial parameter: /PM1 /RM0
then "SBEMU /PM0" will disable all emulations, the default parameter [/RM1] has no effect, only specified parameters have effect.

crazii wrote on 2023-02-23, 16:24:

UPDATE: There's no improvement on the emulation :D, but on the TSR part. now SBEMU can change parameters without rebooting. Note […]
Show full quote

UPDATE:
There's no improvement on the emulation 😁, but on the TSR part. now SBEMU can change parameters without rebooting.
Note that the default parameters takes effect on initial run. after that, you can only change parameters through command line. hope this will help most parameters for the initial startup.
e.g. initial parameter: /PM1 /RM0
then "SBEMU /PM0" will disable all emulations, the default parameter [/RM1] has no effect, only specified parameters have effect.

SBEMU.zip

This version became extremely incompatible and unstable. Blood, for example can only freeze and hang with it.