crazii wrote on 2024-04-25, 00:58:

Just a quick update: I've read some documents about VXD and it seems a hell of work, including exporting & linking win32 vmm fun […]
Show full quote

Just a quick update:
I've read some documents about VXD and it seems a hell of work, including exporting & linking win32 vmm functions, while loading & linking is not quite a problem since the dpmi binary is already a OS2 linear executable (LE/LX) and the loader can load it and potentially other VXDs which are OS2 LE/LX, linking functions needed to be added. the most heavy works are a set of vmm functions to be implemented and tested.
So I've decided take a little step first and added port trapping through vendor api, now SBEMU works for the games I tested previously, plus 16 bit clients, jazz jackrabbit and tyrian 2k tested. it will be release on beta5 (or maybe 1.1 alpha1).

The next step is gonna make SBEMU a VXD first working for win9x, and then use it to finish the VXD codes. but before that, now I'm back to SBEMU and complete unfinished business with beta4, and create a history branch of beta4.

Your project is king already run DOS, and Win9x will be a maximum of will be emperor.

Does SBEMU use MMX instructions if it can? Wondering if this could lead to a speedup on Pentium MMX systems.

Most systems one would find ac'97 or hda, would AT LEAST have mmx. (A small handfull of p54c systems might have ac'97, but...)

A good chunk would have SSMD instructions.

megatog615 wrote on 2024-04-25, 03:56:

Does SBEMU use MMX instructions if it can? Wondering if this could lead to a speedup on Pentium MMX systems.

Why? is it too slow for you?

I could see it being useful for having speedier rendering for higher bit-depth output (HDA can output 24bit or deeper audio, for example, at rates at 960,000hz or higher. )

Has anyone managed to successfully use SBEMU in combination with M$ HIMEM.SYS + JEMM386.EXE instead of JEMMEX.EXE?

I dont see how that would be that useful; Himem.sys is usually not the roadstop, it's EMM386 that is.

I have however, used it just fine with QEMM.SYS.

If we could make a "Fake" EMM386 (FOSS reimplementation, cleanroom style, that supports loadable modules, and presents itself exactly like MS's EMM), that would be the shiznit-- but meh.

wierd_w wrote on 2024-04-25, 08:30:

I dont see how that would be that useful; Himem.sys is usually not the roadstop, it's EMM386 that is.

I have however, used it just fine with QEMM.SYS.

If we could make a "Fake" EMM386 (FOSS reimplementation, cleanroom style, that supports loadable modules, and presents itself exactly like MS's EMM), that would be the shiznit-- but meh.

I found that JEMM still is less compatible than original DOS 7.1 (the one from win98) memory management, so I prefer as much as possible to rely on original parts of the DOS 7.1. That's why I'm asking if there is no problem SBEMU to be used in combination with original DOS HIMEM.SYS + JEMM386.EXE (replacing original EMM386.EXE).

I read about the problems with port trapping with addresses lower than 100h with EMM386.EXE and maybe the best solution for compatibility will be some patched EMM386, but this is forbidden topic here.

I did not mean a patched version; I meant what I said-- re-implementation.

Think less binary patch, think more "WINE project".

EMM386.exe is a stationary target these days.

wierd_w wrote on 2024-04-25, 04:12:

Most systems one would find ac'97 or hda, would AT LEAST have mmx. (A small handfull of p54c systems might have ac'97, but...)

A good chunk would have SSMD instructions.

I want to use an sb live with an MMX 233 without using the crap creative emulation under DOS. SBEMU is so much better.

wierd_w wrote on 2024-04-25, 08:58:

I did not mean a patched version; I meant what I said-- re-implementation.

If the Jemm project isn't a reimplementation or as an end goal a better implementation of memory management in DOS, then what is it?

P.S. I'm thinking on trying the latest PC-DOS version 2000 or even 7.1 with SBEMU.

I did not mean to imply it wasnt trying to be a better ems simulator.

More, that it needs to impersonate emm386, and do things the way emm386 does things, in order to get the compatibility of emm386.

Emphasis on ensuring windows cannot tell the difference, and neither can dos programs.

wierd_w wrote on 2024-04-25, 07:05:

at rates at 960,000hz or higher.

Even Bats top out at 100Khz 😀

I added an extra zero there... whoops...

but still, the actual spec DOES top out at about the top end of bat hearing. 96khz/24bit, is the minimum requirement for "High definition audio".

At that kind of sample rate, having SSMD instructions in play might be kinda nice to have. 😜

It seems that MMX optimizations will be more universal than SSE, as SBEMU claims support for SB Live!, SB Audigy, Ensoniq ES1371, Ensoniq ES1373, C-Media CMI8338 and C-Media 8738 and thus the PCI sound cards based on these chips will be usable with SBEMU on P1 or K6 s.7 systems.

I have two CMI8738 PCI soundcards and DOS drivers for these are so damn broken.

wierd_w wrote on 2024-04-25, 10:40:

At that kind of sample rate

its audiophool scam

rasz_pl wrote on 2024-04-25, 12:11:

wierd_w wrote on 2024-04-25, 10:40:

At that kind of sample rate

its audiophool scam

Agreed, you probably wouldnt be able to notice much above 48khz... but...

It WOULD let you more easily software mix two or more streams of legit 44100hz digital audio together without smashing them, which would be good for digital audio effects from a fake SB DAC emulation, and a high quality OPL2/3 waveform generator emulation. The resulting 'space' would more than handle the full dynamic range of both signals being layered.

(And thus would not have the 'low volume' issues currently seen, since clever range clipping to do the mixing wouldnt be needed.)

wierd_w wrote on 2024-04-25, 10:40:

I added an extra zero there... whoops...

but still, the actual spec DOES top out at about the top end of bat hearing. 96khz/24bit, is the minimum requirement for "High definition audio".

At that kind of sample rate, having SSMD instructions in play might be kinda nice to have. 😜

96khz / 24 bit is really overkill. Most of the DOS games of the era we're using SBEMU for topped out at 8-bit / 11.025 or if lucky 22.05 khz. Only a very few even used 16-bit samples, and then at low bitrates.

And all the legacy mod players back in the day topped out at 16 bit/48khz. I don't know of a single one which supported 24-bit audio and / or 96khz, which was always a "gimmick" high-end thing anyway. I don't think even the current, vintage 2024 OpenMPT DOS port supports 24-bit audio.

(I see others beat me to the punch on espousing this above).

zyzzle wrote on 2024-04-26, 01:06:

96khz / 24 bit is really overkill. Most of the DOS games of the era we're using SBEMU for topped out at 8-bit / 11.025 or if luc […]
Show full quote

wierd_w wrote on 2024-04-25, 10:40:

I added an extra zero there... whoops...

but still, the actual spec DOES top out at about the top end of bat hearing. 96khz/24bit, is the minimum requirement for "High definition audio".

At that kind of sample rate, having SSMD instructions in play might be kinda nice to have. 😜

96khz / 24 bit is really overkill. Most of the DOS games of the era we're using SBEMU for topped out at 8-bit / 11.025 or if lucky 22.05 khz. Only a very few even used 16-bit samples, and then at low bitrates.

And all the legacy mod players back in the day topped out at 16 bit/48khz. I don't know of a single one which supported 24-bit audio and / or 96khz, which was always a "gimmick" high-end thing anyway. I don't think even the current, vintage 2024 OpenMPT DOS port supports 24-bit audio.

(I see others beat me to the punch on espousing this above).

Yes. It's just like you enlarge a 11k*11k pic to 96k*96k using traditional algorithm, the quality might be improved, but very much limited, because the original input quality is low . but the software FM's sample rate is dynamic that can benefit from it, but I believe it's low-priority vs compatibility improvements. 😁

analog_programmer wrote on 2024-04-25, 08:49:

I read about the problems with port trapping with addresses lower than 100h with EMM386.EXE and maybe the best solution for compatibility will be some patched EMM386, but this is forbidden topic here.

I don't see why it's forbidden, to modify a proprietorial program? It's not necessary to modify the program or it's image in RAM.
I'm not a lawyer but It MIGHT BE OK if only the IO permission bitmap be patched at runtime, without modifying the executable binary in RAM. That's what SoftMPU did, modifying the GDT only.