MKSheppard wrote on 2021-09-10, 20:33:

I got DEBUG.EXE, but I'm trying to figure out how to write 03h to port 61h. […]
Show full quote

TheGreatCodeholio wrote on 2021-09-10, 01:30:

Try using a DOS program or DEBUG.EXE to write 03h to port 61h. This will make a BEEEEEEEP but will turn on the PIT timer as well.

I got DEBUG.EXE, but I'm trying to figure out how to write 03h to port 61h.

I'm trying this in debug:

-o 61h 03h

but I get an ^ error pointing at the H

EDIT:

I tried

debug.exe
-o 97 3

https://beausanders.org/ascii.htm

03h = 3
61h = 97

and WILD.EXE is still giving the malformed topo map generation

Sorry about that, DEBUG accepts hexadecimal without the 'h' suffix.

It should be:

o 61 3

It should immediately cause a BEEEEEEEEEP but it also turns on the clock gate for PIT timer 1 (tied to PC speaker) which may help the game work.

Codeholio, trying DEBUG 0 61 3 didn't work; but I found something that did.

After some trial and error; I narrowed it down to:

fpu = false

If this is set, the topo map generates correctly.

If it's set to TRUE, it generates the error I posted earlier.

This makes me wonder if WILDERNESS also had the same problems if an actual FPU was installed on actual hardware, since back then; the 8087 FPU and later the 287 and 387 FPUs were quite rare.

EDIT: Is it possible to add a config file setting for monitor hue presets to DOSBOX-X? Reason I ask is that in the WILDERNESS manual is this line:

We suggest you use a color monitor or television to more vividly recreate nature. Make sure the tint is adjusted so that the sky is blue and the world appears in its proper hues.

@MKSheppard, if you used a Windows VS build, try a MinGW build of DOSBox-X instead.

Visual Studio (VS) has issues with the 80bit precision of the old FPUs.

I just tried Wilderness in DOSBox-X on Linux, which has no issues with the FPU precision, and it renders just fine. Here is a level 10 rendering:

edit

You can change CGA rendering in DOSBox-X. By default with ``machine=svga_s3`` you will only get 4 colour CGA. But when you specify ``machine=cga`` it will automatically use composite video when it auto detects that a game is trying to use it. This is just like with regular DOSBox.

But there are some additional possibilities with DOSBox-X with ``machine=cga``:
- You can use the CTRL-F7 keyboard shortcut to change between an early and late model IBM CGA adapter emulation
- You can use the CTRL-F8 keyboard shortcut to change between Auto, RGBI and Composite monitor output emulation
- You can use the CTRL-Shift-F7 keyboard shortcut to decrease Hue (may need to press it many times to notice the difference)
- You can use the CTRL-Shift-F8 keyboard shortcut to increase Hue

MKSheppard wrote on 2021-09-11, 12:36:

Codeholio, trying DEBUG 0 61 3 didn't work; but I found something that did. […]
Show full quote

Codeholio, trying DEBUG 0 61 3 didn't work; but I found something that did.

After some trial and error; I narrowed it down to:

fpu = false

If this is set, the topo map generates correctly.

If it's set to TRUE, it generates the error I posted earlier.

This makes me wonder if WILDERNESS also had the same problems if an actual FPU was installed on actual hardware, since back then; the 8087 FPU and later the 287 and 387 FPUs were quite rare.

EDIT: Is it possible to add a config file setting for monitor hue presets to DOSBOX-X? Reason I ask is that in the WILDERNESS manual is this line:

We suggest you use a color monitor or television to more vividly recreate nature. Make sure the tint is adjusted so that the sky is blue and the world appears in its proper hues.

Ah, it's FPU precision. I assumed it was something with the PIT timer and randomization because something that old was unlikely to use the FPU.

VS2019 builds cannot do the full 80-bit precision except with dynamic core because Microsoft long ago (during the Win16 to Win32 to Windows 95 transition) decided that "long double" should just be "double". So there's no C++ compiler support for working with the full 80-bit precision, and that's why FPU precision is a problem there. GCC/MinGW still retains "long double" as 80-bit float and therefore no problems. Dynamic core is the exception to the rule because of the inline ASM used to access the FPU.

This is not a DOSBox-X problem but a problem for DOSBox SVN (which uses plain "double" anyway as far as I know) and all forks in general.

_Rob wrote on 2021-09-11, 14:46:

@MKSheppard, if you used a Windows VS build, try a MinGW build of DOSBox-X instead.

I can confirm that it is an issue with the Visual Studio version -- I just downloaded the 0.83.17 MinGW version and it generates wilderness topo maps just fine from the start.

You can change CGA rendering in DOSBox-X. By default with ``machine=svga_s3`` you will only get 4 colour CGA. But when you specify ``machine=cga`` it will automatically use composite video when it auto detects that a game is trying to use it. This is just like with regular DOSBox. But there are some additional possibilities with DOSBox-X with ``machine=cga``

Yes, I know. But having to use CTRL-SHIFT-F7/F8 every time I start the game to change the "monitor" hue is annoying, hence asking for a config file to preset "monitor" hue.

Can anyone help with a no sound issue running DOSBOX-X DOS port with the HX-DOS extender.
The computer is a toshiba netbook which of course has no sound support under dos apart from speaker output.
Boots to raw MSDOS 6.22 perfectly and loads doom, wolf3d etc.. perfectly with speaker output for sound.
DOSBOX-X runs perfectly and also loads above games perfectly but without sound, not even speaker beeps.
(Although had to disable DOS 6.22 HIMEM.SYS or use WIN98 HIMEM.SYS as DOSBOX-X would not load in DOS 6.22
which is either a bug or casued by having too much memory in the netbook 512MB under DOS).

Is it possible to just have speaker sound output through DOSBOX-X if the host computer has no sound card ?
I've tried setting speaker=true in the config file but no change. I would of thought that DOSBOX would not
need to emulate a speaker and just direct all speaker output directly to host speaker. ?

Thanks.

manicgamer wrote on 2021-09-19, 00:32:

Can anyone help with a no sound issue running DOSBOX-X DOS port with the HX-DOS extender. The computer is a toshiba netbook whic […]
Show full quote

Can anyone help with a no sound issue running DOSBOX-X DOS port with the HX-DOS extender.
The computer is a toshiba netbook which of course has no sound support under dos apart from speaker output.
Boots to raw MSDOS 6.22 perfectly and loads doom, wolf3d etc.. perfectly with speaker output for sound.
DOSBOX-X runs perfectly and also loads above games perfectly but without sound, not even speaker beeps.
(Although had to disable DOS 6.22 HIMEM.SYS or use WIN98 HIMEM.SYS as DOSBOX-X would not load in DOS 6.22
which is either a bug or casued by having too much memory in the netbook 512MB under DOS).

Is it possible to just have speaker sound output through DOSBOX-X if the host computer has no sound card ?
I've tried setting speaker=true in the config file but no change. I would of thought that DOSBOX would not
need to emulate a speaker and just direct all speaker output directly to host speaker. ?

Thanks.

speaker=true enables the emulated PC speaker output, it does not direct DOSBox-X to send port 61h output to the real PC speaker. DOSBox SVN and any other fork behaves the same, even if run under HX-DOS.

I've heard there are audio output drivers for HX-DOS, however I don't know how to set that up.

TheGreatCodeholio wrote on 2021-09-19, 01:43:

speaker=true enables the emulated PC speaker output, it does not direct DOSBox-X to send port 61h output to the real PC speaker. DOSBox SVN and any other fork behaves the same, even if run under HX-DOS.

I've heard there are audio output drivers for HX-DOS, however I don't know how to set that up.

Thanks for the info. So just to clarify, DOBOX is emulating the PC speaker and routing the output to the hardware sound card installed in the host PC ?
The emulated PC speaker is not sent to the hardware speaker on the Host PC ? There is no setting in DOSBOX to enable speaker output on the hardware PC ?

That's a bit of a bummer then, as there is no way of using DOSBOX for any audio output on a PC without a soundcard or with just a bleepy speaker. I'm curious as to why the devs didn't just pass through the DOSBOX speaker directly to the hardware PC speaker as almost every PC has a bleeper speaker.
If the sound card is emulated in DOSBOX and the audio is then translated back to the hardware sound card, why is not possible to also translate that audio back through the hardware PC speaker. This would then allow PC's without dedicated soundcards or drivers and only a bleepy speaker to have SB audio also, although the audio quality would not be great.

I've download the HX+ drivers for Intel ICH/AC97 soundcards and will give it a try later. Just seems a little overkill to emulate a pc speaker and route it through a soundcard when a hardware speaker is available and easily accessable without drivers.

manicgamer wrote on 2021-09-19, 11:53:

Thanks for the info. So just to clarify, DOBOX is emulating the PC speaker and routing the output to the hardware sound card ins […]
Show full quote

TheGreatCodeholio wrote on 2021-09-19, 01:43:

speaker=true enables the emulated PC speaker output, it does not direct DOSBox-X to send port 61h output to the real PC speaker. DOSBox SVN and any other fork behaves the same, even if run under HX-DOS.

I've heard there are audio output drivers for HX-DOS, however I don't know how to set that up.

Thanks for the info. So just to clarify, DOBOX is emulating the PC speaker and routing the output to the hardware sound card installed in the host PC ?
The emulated PC speaker is not sent to the hardware speaker on the Host PC ? There is no setting in DOSBOX to enable speaker output on the hardware PC ?

That's a bit of a bummer then, as there is no way of using DOSBOX for any audio output on a PC without a soundcard or with just a bleepy speaker. I'm curious as to why the devs didn't just pass through the DOSBOX speaker directly to the hardware PC speaker as almost every PC has a bleeper speaker.

I've download the HX+ drivers for Intel ICH/AC97 soundcards and will give it a try later.

That's correct. As I understand it, DOSBox was initially developed on Windows where you generally don't write directly to the PC speaker anyway, especially on Windows NT/2000/XP/etc. where user-space isn't allowed to touch any I/O ports.

TheGreatCodeholio wrote on 2021-09-19, 12:15:

That's correct. As I understand it, DOSBox was initially developed on Windows where you generally don't write directly to the PC speaker anyway, especially on Windows NT/2000/XP/etc. where user-space isn't allowed to touch any I/O ports.

I understand the i/o port restriction in NT windows but it is still possible to access and send audio to the pc speaker without a soundcard installed using basic API calls. If DOSBOX had the function or option to directly output to the hardware speaker port then this would in theory open the doors to enable the emulated SB/GUS/Midi sound output through a PC speaker on PC's that have not soundcard or drivers that support a soundcard in realmode DOS ? Maybe I'm not understanding this too well, but it sounds pretty simple to me as there is already a speaker driver available for Windows 3.1/95 that can send PCM/Wave audio to a PC speaker but it's not perfect and introduces a delay in processing.

The setup I have at the moment is a netbook with an intel atom 1.6Ghz cpu and AC97 audio. I am booting DOSBOX-X directly from MS-DOS 6.22 and then booting Windows 95 from DOSBOX-X. This is all working fine and is pretty fast too, less than 15 secs from inital boot of the netbook I have Windows 95 loaded with a full working driver setup. The only part that I don't have is any sound or audio output from the netbook's hardware speaker. I was looking to use the speaker driver that is available for Windows 3.1/95.

manicgamer wrote on 2021-09-19, 12:26:

TheGreatCodeholio wrote on 2021-09-19, 12:15:

That's correct. As I understand it, DOSBox was initially developed on Windows where you generally don't write directly to the PC speaker anyway, especially on Windows NT/2000/XP/etc. where user-space isn't allowed to touch any I/O ports.

I understand the i/o port restriction in NT windows but it is still possible to access and send audio to the pc speaker without a soundcard installed using basic API calls. If DOSBOX had the function or option to directly output to the hardware speaker port then this would in theory open the doors to enable the emulated SB/GUS/Midi sound output through a PC speaker on PC's that have not soundcard or drivers that support a soundcard in DOS ? Maybe I'm not understanding this too well, but it sounds pretty simple to me as there is already a speaker driver available for Windows 3.1/95 that can send PCM/Wave audio to a PC speaker but it's not perfect and introduces a delay in processing.

As far as I know Microsoft provides one basic API call: MessageBeep. It makes a short "beep" (you've probably heard it at some point in your life, right?). That's all it can do. There are no other parameters. Beep. You can't talk to the PC speaker hardware, and Microsoft doesn't care, so that's all you get.

Windows 3.0 through ME, despite the protected mode environment, did not block I/O ports (though they did have device drivers to trap and virtualize some things so Windows and DOS applications "get along"). If DOSBox had been developed when Windows 95/98 was popular, it could have used outp() to port 0x61, sure. It probably could have also written directly to 388h/389h too. There were additional amusing quirks about Windows 95 as well: did you know NULL pointers are valid AND writeable in Windows 95? It took Microsoft until Windows 98 to at least make NULL pointers read-only so you properly crash if you write to it.

Back in the Windows 3.1 days, it was common for some code to just talk directly to I/O ports because Windows 3.1 was particularly minimal in what I/O ports it trapped and virtualized. It was also common for Windows 3.1 games to bypass Microsoft's API entirely if they wanted more than the basic beep. Some games like "Wargames" come to mind, and a few that I saw on Shovelware Diggers, that are able to make more than basic beeps. The PC speaker sound driver is also able to talk directly to hardware as well (I used to have that driver, in fact, before finally getting a sound card in the mid 1990s). You may have noticed from that driver as well that CLI and STI are perfectly valid from user-space, when the driver masks interrupts to play a sound without interrupts to garble it.

There's even a DPMI server deep down inside Windows 3.1/95/98/ME that you can call if you are running as 16-bit Windows code (the DPMI interrupt call crashes for some reason when called by Win32 code). You can use it to call anything you want in MS-DOS or the BIOS below, have fun. "CD player" type programs in Windows 3.1 for example are said to use DPMI to communicate with MSCDEX.EXE.

In fact, to see how much of Windows is just talking directly to hardware or calling MS-DOS or the BIOS from user-space, I suggest you download the Windows 3.1 DDK and see for yourself. Each driver is two parts: user-space code that just talks to things directly, and 386 "virtualization" drivers that selectively trap and emulate I/O ports and resources so that Windows and DOS applications get along with each other. Have fun.

TheGreatCodeholio wrote on 2021-09-19, 13:00:

As far as I know Microsoft provides one basic API call: MessageBeep. It makes a short "beep" (you've probably heard it at some point in your life, right?). That's all it can do. There are no other parameters. Beep. You can't talk to the PC speaker hardware, and Microsoft doesn't care, so that's all you get.

I knew it was a bit more complex than I thought, although a simple beep is better than no beep :0

There are opensource lib drivers available to access IO ports in NT/XP/2000 32/64 bit.
InpOut32 and InpOut64 here for example:
https://www.highrez.co.uk/downloads/inpout32/default.htm

There are also a selection of speaker drivers for DOS/Windows 95 here:
https://remember.the-aero.org/speaker/index.htm#drivers

Also the lesser known RealSound technology here:
https://en.m.wikipedia.org/wiki/RealSound

So the concept is still possible to implement this in DOSBOX but most of this is all a bit out of my skill set, I'm only comfortable tweaking a few config files. So looks like I hit a tree Jim 😀

An urgent messhage needsh to be conveyed to the yousher? Thish shounds like a job for 007 ... the ASCII character, BEL. Dunno why windows needs an API for that.

Anyone knows why DOSBox-X struggles so much with sound blaster emulation in Windows 98SE? Every game I throw at it crashes, except when sbtype=none and I can play all them but without sound.

Bruninho wrote on 2021-10-05, 05:40:

Anyone knows why DOSBox-X struggles so much with sound blaster emulation in Windows 98SE? Every game I throw at it crashes, except when sbtype=none and I can play all them but without sound.

I tested Quake II with Windows 98FE, didn't experience any problems.

A lot of users have complained that Windows 98 seems to dislike sb16 emulation. But I wonder if it's simply a mismatch of IRQ and DMA resources? By default the sb16 emulation emulates the non-PNP version of the SB16 and it's possible Windows 98 might get the IRQ wrong. Can you try and make sure the dosbox.conf IRQ/DMA settings match what the Control Panel system panel thinks it is?

Yeah, they match. Games I am testing: Need For Speed II SE, FIFA 98 Road To World Cup, FIFA 99.

They run fine without sound. When there is a sb16 or sb16vibra, chaos ensues. For example, Dosbox-x crashed when I simply moved the Windows volume slider to max. When running NFS2SE, crashes to windows desktop on race start as soon as engine sounds fire. FIFA 9x freezes and crash on match kick-off; game commentary is still on, but the match is frozen. I did notice that the sound had some lag in a few occasions.

I have no issues using the exact same installation image on QEMU. The only difference is the Voodoo drivers being installed in dosbox-x.

I have even tried a clean new install of Windows.

I also found another two people with similar issues. And I also tested the dosbox-x Windows version, on my Win10 VMware machine, same thing happened.

Dxdiag test reports for DirectSound then said: "Your sound card does not support hardware buffering. Sounds will only play back from software buffers." I did not make the same test on QEMU, but I will do later; most likely it will crash imo.

Bruninho wrote on 2021-10-05, 14:28:

Yeah, they match. Games I am testing: Need For Speed II SE (available on myabandonware), FIFA 98 Road To World Cup, FIFA 99. […]
Show full quote

Yeah, they match. Games I am testing: Need For Speed II SE (available on myabandonware), FIFA 98 Road To World Cup, FIFA 99.

They run fine without sound. When there is a sb16 or sb16vibra, chaos ensues. For example, Dosbox-x crashed when I simply moved the Windows volume slider to max. When running NFS2SE, crashes to windows desktop on race start as soon as engine sounds fire. FIFA 9x freezes and crash on match kick-off; game commentary is still on, but the match is frozen. I did notice that the sound had some lag in a few occasions.

I have no issues using the exact same installation image on QEMU. The only difference is the Voodoo drivers being installed in dosbox-x.

I have even tried a clean new install of Windows.

I also found another two people with similar issues. And I also tested the dosbox-x Windows version, on my Win10 VMware machine, same thing happened.

Dxdiag test reports for DirectSound then said: "Your sound card does not support hardware buffering. Sounds will only play back from software buffers." I did not make the same test on QEMU, but I will do later; most likely it will crash imo.

No issues here with the volume slider, sbtype=sb16, Windows 98FE, host system 64-bit Linux, even if I have ActiveMovie looping a WAV file.

What build are you using?

Latest. 0.83.18 currently
I’ve tried with all older builds back to 0.83.7, no joy too. I’m on a 2013 rMBP “13 i7 2.8GHz & 16Gb RAM, macOS Big Sur. The other Windows build I tested was .17

A clean w98SE install and a fresh installed NFS2SE, and @almeath dosbox-x build didn’t run the game too. The fact that I can run it on QEMU makes me think that its either a sound blaster problem or some dosbox-x cfg tweak may be required. However I have been trying various cfg changes without luck.

There's been some abandonware sites, OS and games transferred mentioned in this thread. Please leave those for elsewhere.

DosFreak wrote on 2021-10-05, 17:06:

There's been some abandonware sites, OS and games transferred mentioned in this thread. Please leave those for elsewhere.

I’ll edit my posts for that. Sry