Not sure what the point of this thread is.
Are you stating the current status, requesting it or both?
If it does what you want it to do for the few things you have tried then great, if not then it isn't.
If it does work now that doesn't mean it will work later especially if that's not the goal of the software.
For the issues you've mentioned, how long have the issues existed? Are there patches? Would those patches be accepted and maintained?

RetroMaster137 wrote on 2023-01-14, 15:32:

The question is, am I missing something here?

I'm looking for as many technical details as possible, no more no less. Because I might try to fix it myself (at least the SB16 bugs which are very well documented) after studying programming.

Considering what happened on my previous thread... I know it's not the typical course of action that would please a normal person, but I'm not normal 🤣. Would you please not think on what I'd want to do? Not to be rude, with all due respect, I just want answers to my questions 🤣, not others. No need to decypher my intentions. My only goal is debugging.

My reason to ask in this forum (instead of Oracle's), is because more people in here have tried DOS games. People who still program for DOS are more likely to visit this forum too, and (if they want) might explain exactly and at a technical level what works and what doesn't.

You might want to take a look at javispedro's work: he developed an extension pack for VirtualBox called "VMusic", which adds support for emulating "popular" music devices, including OPL3 (based on the accurate Nuked OPL3 emulation code), but also MPU-401. and even AWE. See this Vogons thread here: Re: VMusic - OPL3, EMU8K and MPU-401 for VirtualBox (Linux hosts only)

RetroMaster137 wrote on 2023-01-14, 15:32:

sound is the prime complaint when trying to run a DOS-based Windows (SB16 is broken)

It's not that bad, give poor ol' little VirtualBox a bit credit 😀
Many games and OSes do work out of the box, that thread is a bit too aggressive 😀
I'll buy that for DOS gaming it's probably hit or miss, and because this is designed for throughput you'll never get rid of strange timing issues, making it impractical as an "gamer archivist" tool.
But this should not be a problem at all under Windows.

If you are using DOS and 3.x under VirtualBox also check my "guest tools" New DOS mouse driver for VirtualBox/VMware/ PS/2 mice https://git.javispedro.com/cgit/vbados.git/
I personally do not have as much of an interest in games though, it's mostly ancient proprietary tools I used or developed myself, albeit I do play the occasional games (usually popular ones anyway).
Also check https://www.os2museum.com/wp/antique-display-driving/ , albeit he may not be able to redistribute the final binary.

As for Windows 9x...
There is this already released driver for video : https://www.os2museum.com/wp/windows-9x-video-minidriver-hd/ .
And both the SB16 emulation and VMusic work well enough.
There is a timing issue that results in a hang at boot if I try to use the AWE32 Creative drivers on 9x, but the stock drivers work well, and I can still use Creative tools (e.g. AWE32 soundfont uploading).
(The timing issue is because the driver has a short loop that expects a 44kHz counter to increment exactly by one during that time )

RetroMaster137 wrote on 2023-01-14, 15:32:

Btw, someone using Google might thank me for this:
SET BLASTER=A220 I5 D1 H5

Note that you can change the assignments through extradata, e.g.
VBoxManage setextradata $VM_NAME VBoxInternal/Devices/sb16/0/Config/IRQ 10
The relevant configs that can be changed here are IRQ DMA DMA16 Port

Thanks for your replies!! I'll have to install Linux later before I can give it a try. Looks like I'll be able to have a complete setup now!

RetroMaster137 wrote on 2023-01-14, 15:32:

Please do NOT point me to DosBox or PCem/86Box/UniPCemu, I'm aware of how good they are <3, I'm doing this for technical reasons […]
Show full quote

Please do NOT point me to DosBox or PCem/86Box/UniPCemu, I'm aware of how good they are <3, I'm doing this for technical reasons.
EDIT: I haven't tried QEMU yet!

In general, low-level compatibility is fairly... good? Everything I thrown to it has worked SO FAR, but it could be a lucky shot, probably. Even Digger (which used to play very choppy under NTVDM) works better (EDIT: There's different versions though). In general, the only bad egg has been Kgen98, which runs faster than normal, not sure if "uncapped" is the word. If I disable nested paging, it will run slower than normal (although it displays 100% CPU usage, so it MIGHT work correctly on a better PC than this).

To summarize:

- Kgen98 runs at crazy speeds
- SoundBlaster 16 support lacks synthesizer, and is broken (ticket)
- PC Speaker only works through Linux, beeps only (PCM playback will simply freeze)

To what I have found so far, sound is the prime complaint when trying to run a DOS-based Windows (SB16 is broken), though it technically works fairly well otherwise (bar the hardware spent in color conversion and these things).

The question is, am I missing something here?

Btw, someone using Google might thank me for this:
SET BLASTER=A220 I5 D1 H5

SB16 has always been in a purgatory state of working/not working. The main wave part works but the midi part doesn't. VMWARE SB16 doesn't work either. I mean it works but not the MIDI part of it.

digger wrote on 2023-01-15, 00:06:

You might want to take a look at javispedro's work: he developed an extension pack for VirtualBox called "VMusic", which adds support for emulating "popular" music devices, including OPL3 (based on the accurate Nuked OPL3 emulation code), but also MPU-401. and even AWE. See this Vogons thread here: Re: VMusic - OPL3, EMU8K and MPU-401 for VirtualBox (Linux hosts only)

No good for us Windows users! 😢. Don't assume everyone has or is good at Linux.

Mister98XPee wrote on 2023-01-23, 08:39:

SB16 has always been in a purgatory state of working/not working. The main wave part works but the midi part doesn't. VMWARE SB16 doesn't work either. I mean it works but not the MIDI part of it.

Since 2015ish VMware has a bit of initial support for SB16 FM (OPL3) & MIDI. It is hidden behind a .vmx option and likely will remain that way forever, albeit it does work. See:
https://communities.vmware.com/t5/VMware-Work … 11/ta-p/2781947

Mister98XPee wrote on 2023-01-23, 08:41:

No good for us Windows users! 😢. Don't assume everyone has or is good at Linux.

Not by choice. To develop VirtualBox plugins on Windows you need a Microsoft cross-signed Windows kernel driver certificate which is ridiculously expensive.

Riding along to soak up VirtualBox knowledge... it might be what I'm looking for for a future project.

(Basically got a buttload of old multimedia reference titles that need varying OS and screen res etc, in some respects they're gamey for A/V demands in others businessy, might want to print, and I wanna have them all on a server and view them on local machines.... so figuring what all VM type stuff will and won't do.)

javispedro1 wrote on 2023-01-15, 11:44:

As for Windows 9x...
There is this already released driver for video : https://www.os2museum.com/wp/windows-9x-video-minidriver-hd/ .

The post says "The driver uses a linear framebuffer and supports 8/16/24/32bpp modes
with resolutions up to 1920×1200 pixels (see more below).
The driver is not accelerated but tends to be very speedy on modern hardware."

Personally, this worries me a bit. The statement is a bit hollow, I think.
The specs of the test system are not just vague, but unknown, even.

Anything can be very speedy, I suppose, if the hardware is just high-end enough.
And virtualization, to my understanding, aims at not being a CPU hog, unlike accurate emulation (-> bsnes, *shudder*).

I mean, an Atari 2600 emulator with 99,9% accuracy that requires an
overclocked Pentium 4, cooled with liquid nitrogen, isn't impossible to create.

Also, by comparison, the '87 VGA CRTC can do certain operations on its own, it's not completely a dumb framebuffer. The demoscene proved that many times, I think.
The Windows 3.1 VGA driver supported dirty-rectangle, also, afaik.
This technique updates only parts of the screen that have changed.
I wonder if that 9x driver does that, too.
It's a simple mini driver, after all, so it's not a matter of course.

Edit: CPU utilization is a general problem in DOS-based systems.
For 9x, there's amnhlt, a little helper VXD that puts the CPU to sleep.
Re: 86box produces farting noises and lags on an i7 PC

Jo22 wrote on 2023-01-29, 22:06:

Personally, this worries me a bit. The statement is a bit hollow, I think.
The specs of the test system are not just vague, but unknown, even.

. I think that one of the main pros of (2D/GDI) hardware acceleration would be in emulation, where e.g. the native Windows rendering code would be run under the emulator while the rendering code from the emulated card would be run in the host. From the point of view of virtualization, where there is little if any difference in performance between guest code and host code (any performance issues come from other aspects, like VM exits / IO), I don't see the point.

Jo22 wrote on 2023-01-29, 22:06:

Edit: CPU utilization is a general problem in DOS-based systems.
For 9x, there's amnhlt, a little helper VXD that puts the CPU to sleep.
Re: 86box produces farting noises and lags on an i7 PC

I am surprised because I always hear these tools mentioned, but I never needed to resort to 3rd party tools to avoid high CPU utilization. VirtualBox supports both ACPI and APM, the later being supported as early as Windows 3.x at least. Even on DOS 6.x, I can use POWER.EXE to reduce CPU utilization to 0. From the documentation, it looks like it is also an APM driver.

javispedro1 wrote on 2023-01-30, 00:34:

. I think that one of the main pros of (2D/GDI) hardware acceleration would be in emulation, where e.g. the native Windows rende […]
Show full quote

Jo22 wrote on 2023-01-29, 22:06:

Personally, this worries me a bit. The statement is a bit hollow, I think.
The specs of the test system are not just vague, but unknown, even.

. I think that one of the main pros of (2D/GDI) hardware acceleration would be in emulation, where e.g. the native Windows rendering code
would be run under the emulator while the rendering code from the emulated card would be run in the host.
From the point of view of virtualization, where there is little if any difference in performance between guest code
and host code (any performance issues come from other aspects, like VM exits / IO), I don't see the point.

Yes, that would be neat, I think, too.

Things like this were being done in the early 90s, too, in one way or another.

For example, Insignia SoftWindows 1.0, the Windows 3.1+PC emulator for the 68k Macintosh,
used special libraries of Windows 3.1 that were ported to the Motorola 68000.
This was possible because Insignia worked closely together with Microsoft.
The company also provided the x86 emulator for the NTVDM used in the RISC versions of Windows NT.

Anyway, the idea was similar.
The Windows applications would call DLLs/their functions that would execute naively on the host side.
Maybe GDI was part of it, even, not sure.

That's something special in emulation, by the way.
Graphical systems provide function calls, APIs.
An emulator of such systems doesn't need to perform as much as CPU-intensive tasks
as an low-level emulator meant for DOS programs which like do talk to hardware directly and do implement their own logic.

Anyway, I'm not blaming DOS. DOS itself had an ABI/API that works similar, yet different.
It provided functions via interrupts, rather than conventional API calls as used in normal operating systems.
Unfortunately, the calls provided weren't enough. There was no graphics/sound ABI/API, for example.
DOS programmers were expected to use PC BIOS (has routines for CGA graphics) or EGA/VGA BIOS for this.
Or the high-level interface of 8514/A or XGA/XGA-2, which sadly didn't make it.
CP/M had gotten GLX in its late days, by comparison. 😁

Edit: GDI.. GDI was quite flexible as far as the range of supported hardware was considered.
It could be used for printers/plotters, too, most notably. Or remote desktop connections.
It kind of reminds me of X11 in this regards, another great obsolete technology.
Back in the late 90s, early 2000, XFree86 was a thing, still.

Edit: GDI+, as used by Windows XP+ (or Windows 9x by gdiplus.dll), was entirely CPU-based.
Applications relying on it can't take advantage of GDI acceleration, not even in Windows XP/7.

javispedro1 wrote on 2023-01-30, 00:34:

I am surprised because I always hear these tools mentioned, but I never needed to resort to 3rd party tools to avoid high CPU ut […]
Show full quote

Jo22 wrote on 2023-01-29, 22:06:

Edit: CPU utilization is a general problem in DOS-based systems.
For 9x, there's amnhlt, a little helper VXD that puts the CPU to sleep.
Re: 86box produces farting noises and lags on an i7 PC

I am surprised because I always hear these tools mentioned, but I never needed to resort to 3rd party tools to avoid high CPU utilization.
VirtualBox supports both ACPI and APM, the later being supported as early as Windows 3.x at least.
Even on DOS 6.x, I can use POWER.EXE to reduce CPU utilization to 0. From the documentation, it looks like it is also an APM driver.

Personally, I had to resort to those 3rd party tools.
For some reason I don't know, the CPU would see a high utilization without them. 🤷‍♂️

I'm aware of APM and ACPI, as well. Unfortunately they don't seem to be reliable.
Maybe because they're meant to save power rather than lower CPU usage, so the results aren't as expected.
Especially ACPI used to have compatibility issues in the 90s, I think.
Older revisions were broken and didn't work with Linux, which tried to follow the official specs.
Windows 98 had some workarounds for it, I vaguely remember,
but it wasn't before Windows Me/2k (roughly) that ACPI worked reliable.

APM and the 386SL CPU with SMM/power-savings features existed since the early 90s.
HLT is implemented in late 486 desktop CPUs, too, I think.
Windows 3.1x also supports APM. On paper, at least. Never really worked in my VMs, either.
Here I'm using WQGHLT, which unfortunately but understandably was written for 386 Enhanced-Mode.
The rock-solid Standard-Mode isn't supported by it.

The Power.exe in DOS merely talks to APM BIOS, which in turn has to take actions.
APM is/was very BIOS-centric in comparison to ACPI. The BIOS decided when to do things.

Programs like DOSIDLE have many options and also support APM.
That's what I use in DOS VMs, also. Just be careful not to set it too strong.
Certain programs with idle loops woukd otherwise halt completely (need keyboard press to run again etc). 🙂

Edit: Edited, some typos fixes.
Edit: Formatting fixed (on PC).