Perhaps some older C++ runtime that is missing?

Possibly, but like I said DAUM works 😒

Test outside a beta windows product. Using beta windows as a host introduces another set of variables specific to beta software.

Tried on windows 7 64bit sp1 still crashes.

Type at the dosbox-x commandline:
cycles fixed 2500

Then type:
cycles

This should set and show the number of cycles. There is probably a dosbox wiki page about setting the parameter "cycles". Avoid use of the menu item (which went unmentioned).

TheGreatCodeholio wrote:

I vaguely recall a bug with the FSTENV instruction where DOSBox interpreted both forms as the 16-bit form even if 32-bit override

I couldn't find a simple fpu test for 32-bit protected mode, but used "mcpdiag" for a test of 16-bit real mode. It's a dos program which runs in dosbox-x "dos" or dosbox-x "95 dos box". I also placed "printf" statements to detect entry into the FSTENV instruction in the relevant header files, for example:

1static void FPU_FSTENV(PhysPt addr){
2	FPU_SET_TOP(TOP);
3	if(!cpu.code.big) {
4		LOG_MSG("FSTENV REAL MODE\n");

Confirmed that the mcpdiag "environment test" fails, and that there is no entry into the FSTENV emulated instruction where core=dynamic. However, there is entry into the FSTENV instruction in the case where the core is not the dynamic core (and the "environment test" fails in this case, too).

In addition, I used Quake as a fpu test for 32-bit protected mode. For this case, there is entry into the 32-bit protected mode for the FSTENV instruction.

I haven't tested where core=dynrec.

Edit: for core=dynamic, there is entry into the FSTENV instruction where:

1CPU_Core_Dyn_X86_SetFPUMode(false);

I assume that the fpu instructions are passing through to the host and bypassing the fpu instruction logged above. However, why doesn't the same happen for 32-bit mode?

Just a quick question, truth5678: in order to activate the "core=dynrec" in the Jul19 DOSBox-X release, do you simply set core=dynamic in dosbox.conf or are there other steps or settings that need to be changed to activate it?

It's not present in dosbox-x. To test one of the dynarec cores, such as on an x86 platform, you may compile vanilla dosbox with the relevant configure setting (configure --help for a hint).

On the FSTENV question:
I compiled dosbox(-x) where fpu-x86 was disabled, so I presume it is using the C fpu functions. DOS Quake was used as a test of 32-bit protected mode.

Edit: with fpu-x86 disabled, confirmed that FSTENV is entering the the 32-bit protected mode form under both dynamic and normal cores.

Thank you, Codeholio, for identifying and working around the Adlib timer issue! I also noted the various improvements, especially to the ET4000 emulation. 😀

If you have a chance, you may be interested in the dynarec work in PCem.

Looking over the PCem source code, I'm impressed!

The only problem so far is that getting Allegro to compile and getting the PCem source to compile against it in Linux is a pain. All I can do apparently is run it in CGA mode, the EGA/VGA modes cause a segfault in Allegro for some reason, but the AMI 386 BIOS seems to run just fine. Assuming there's no issues, I will definitely be consulting the PCem source for DOSBox-X hardware emulation. It will be a valuable addition to the hardware testing I do with DOSLIB on actual 486 and Pentium systems I have lying around.

Also be aware that the Adlib hack is meant to be temporary. Something in DOSBox-X is allowing I/O reads to go too fast. I have some Pentium class systems where Wolfenstein 3D is able to detect the Adlib in 100 I/O cycles, so obviously on real hardware the 8-bit I/O is slow enough to let that 100 I/O read test work, even if it's through a PCI-ISA bridge.

truth5678 wrote:

Thank you, Codeholio, for identifying and working around the Adlib timer issue! I also noted the various improvements, especially to the ET4000 emulation. 😀

If you have a chance, you may be interested in the dynarec work in PCem.

I think the latest PCem source (with dynarec) is considered win32 only. I don't know if that is related to the issue, but it may be worthwhile to run PCem in Wine instead, at least until someone is maintaining a linux build.

The I/O read question is very interesting. I wonder if there are tools to verify and compare the number of cycles in real hardware versus the emulator. Perhaps ripsaw would have insight into the exact cause, especially since the I/O read issue is now well documented by dosbox-x. 😀

Thinking out loud here... I also recall the ISA bus allows a device to lengthen an I/O cycle by holding a "CHRDY" signal low until it's finished. I also recall the late SB16 cards had something that "fixed" Adlib issues. So I'm wondering if the test happens to work because either
a) 8-bit I/O on the ISA bus really is that slow (even through PCI-ISA bridges on Pentium and higher systems)
b) Some sound cards are delaying the cycle to slow it down (CHRDY signal on the ISA bus)
c) Later sound cards somehow speed up timers on port 388 to make that test work, like they look for the common detection pattern and purposely speed it up (same way I hacked it into DOSBox-X perhaps).

So then, if a) is true, I could cause Wolfenstein 3D to fail detection by playing with whatever BIOS settings are available regarding ISA bus cycle length (somehow?). I'll see if that's even possible.
I'm not sure how to validate b) unless I were to obtain a ADC that's fast enough and stick wires into the ISA bus to sample how long CHRDY is held down (in BCLK ticks), then poke at port 388 with DEBUG.
For c) I'm wondering if my ADLIB sample in DOSLIB could be modified to (try to) time how long port 388 I/O reads take (verses other I/O reads for reference). Since I'm targeting a Pentium, I could use the RDTSC instruction which probably has enough resolution to do that. Another timing test could measure expected vs. actual time before the Adlib timers signal overflow. Timing from software could be an alternative to b) as well without sticking wires in the ISA bus.

I also vaguely remember something about later SB16 and clone cards using an OPL3 clone that emulates the OPL3. I wonder if the OPL3 clone chips fall into the c) category. Or considering that most DOS games use something like IRQ0 to drive the Adlib music, whether the clone chips even implement the Adlib timers. In fact I wonder if they allow the test to work by simply letting the timers overflow in a very short fixed amount of time and then assume the timers will never be used after that. (I could be wrong---anyone know of a DOS game that depends on Adlib timers to keep time? Doing that doesn't make a lot of sense to me since those timers cannot cause an IRQ as far as I know). The reason I bring that up is that if you look at the integration of PC components over time, each chip had features that nobody ever used, so when integration happened, some of the unused modes simply went away. Reading the various Intel/NEC datasheets for the floppy controller (when I developed the test program in DOSLIB) reveals that up until about 1993 or so the chipsets still supported the "FM" modulation mode that nobody ever really used, and then in 1994 the chip manufacturer removed support for it. Too bad perhaps for a few people still using 8" floppy drives, but there you go.

What do you think? Anyone up for testing these ideas?

I wonder if the Wolfenstein 3D source code could be modified to show the time between I/O reads? We could run that version of the executable on hardware versus emulation. It may merely provide the overall time between I/O reads, but it should verify the time interval at which adlib sound detection works.

I'm presently trying to replicate the issue in order to further my comprehension of the sound emulation. 😀

Edit: I turned off "adlib force timer overflow with on detect" under core=dynamic, cycles=max, and replicated the missing sound detection, but the sound worked when I restarted Wolf3d. Presumably it defaults to the soundblaster option? It would be interesting to know if there are other games with a similar issue (I recall DoTT having a sound detection issue, but it occurs even on restarting game; although it may employ a kind of I/O read routine on every start whereas Wolf3d may not).

1sbtype=sb16
2sbbase=220
3irq=7
4dma=1
5hdma=5
6sbmixer=true
7oplmode=auto
8adlib force timer overflow on detect=false
9oplemu=default
10oplrate=44100
11dsp require interrupt acknowledge=auto
12dsp write busy delay=-1
13dsp busy cycle rate=-1
14dsp busy cycle duty=-1
15allow dma address decrement=true

TheGreatCodeholio wrote:

I also vaguely remember something about later SB16 and clone cards using an OPL3 clone that emulates the OPL3. I wonder if the OPL3 clone chips fall into the c) category.

You mean you really want to implement CQM? There are some definite audible differences in the CQM chip though, like dropped polyphony on some songs in Doom and Doom II (most notably D_E2M2)

leileilol wrote:

TheGreatCodeholio wrote:

I also vaguely remember something about later SB16 and clone cards using an OPL3 clone that emulates the OPL3. I wonder if the OPL3 clone chips fall into the c) category.

You mean you really want to implement CQM? There are some definite audible differences in the CQM chip though, like dropped polyphony on some songs in Doom and Doom II (most notably D_E2M2)

Noooo... of course not. I was just thinking out loud that, as far as I know, the Adlib timers are used only during the detection phase of most DOS programs, and not used for any other purpose, and perhaps these emulated chips were connected to the CPU through faster busses, so perhaps (just guessing at this point) they made older detection routines work by making the timers go to overflow state after some I/O reads or by making the interval really short?

It's a matter of DOS games that make assumptions about I/O read timing and what later cards (on faster busses like PCI) probably had to do to work with the DOS games.

I think vanilla dosbox partly uses cycles=auto to have low cpu cycles during sound detection, and then the cycle count is increased on-demand. If this is true, then this setting is a workaround for timing issues in sound detection, although your method is much closer to the source of the issue.

From documents on the internet, it seems that the I/O register writes is where one time delay occurs (references below), and they suggest the amount of delay, although I imagine that could be estimated from the methods described above. I don't recall finding a value for a delay in the I/O reads. Since real hardware isn't showing this issue in the case of Wolf3d, then there should only be a delay in the I/O for the sound emulation, and not in the overall speed of the emulation, as you suggested.

I also think your workaround is excellent, especially if games with similar issues are now detecting sound with cycles='large number'. Also, vanilla dosbox seems mainly event-driven, while achieving good performance, and so any accuracy issues are balanced against this goal. However, if a delay in I/O has little or no effect on the overall sound emulation, and only on detection, then that should be perfect. I also wonder if sound detection typically triggers a certain command, such as a reset, which could then be used to trigger an I/O delay which is then reverted to the default after a certain amount of time.

(In case the ISA bus is the cause): I haven't made the calculations yet, but is the ISA bus or the published I/O delay times the expected bottleneck in performance? If the I/O delays are longer than the ISA bus speed for transferring information, then shouldn't the I/O delays be the culprit (or vice versa)?

Source information: http://rpix86.patrickaalto.com/rblog2013.html ; http://www.shipbrook.net/jeff/sb.html.

Looks like I'll be able to test my ISA bus cycle theory after all.
A friend of mine just dropped off an old Pentium III 500MHz system he was going to throw out anyway. Look what I found in the BIOS setup menu:

It has the typical hardware of mid-1999 systems of the time: one AGP slot, several PCI slots, and one ISA slot. Unlike the other Pentium III I have sitting around the BIOS still allows the ISA bus to use IRQ 9 and IRQ 14-15 if you enable it in the BIOS (the other system reserves IRQ 9 for the ACPI SCI interrupt).

If my theory is right, and I plug older Sound Blaster cards into the ISA slot with 8-bit I/O recovery less than the usual 3-4 BUSCLK, Wolfenstein 3D and other DOS games should fail to detect the Adlib chip [I will check to see if the card in general can't handle such short 8-bit I/O cycles, since 8-bit I/O is said to have a 4 or 5 or whatever clock delay]. If my other theory is right, newer SB16 and AWE32 cards in the ISA slot should work with Wolfenstein 3D no matter what the I/O recovery time is. Of course it's also very likely the ISA card uses the CHRDY signal to delay if it needs to, so it's also possible that the older Sound Blaster will make the ISA bus wait the 4-5 clock delay for 8-bit I/O anyway. So it would still be useful to write a program that does I/O reads and times them.

Also conveniently for the test the system had an old SBLive! card in one of the PCI slots, so if I can find the Creative drivers that abused EMM386 to emulate legacy Sound Blaster for DOS games, I could see what they do too.

CodeHolio,

Does this have file-locking support across Dosbox instances (I saw support for Share.exe, but need to know if its across instances), or does it rely on filesystem locking from the hosting OS?

The Daum SVN notes don't reference what was really incorporated and I can't find the SVN source to read about it.

BTW, thanks!

In ints/xms.h, submit the following change:

1-Bitu	XMS_GetHandleInformation(Bitu handle, Bit8u& lockCount, Bit8u& numFree, Bit16u& size);
2+Bitu	XMS_GetHandleInformation(Bitu handle, Bit8u& lockCount, Bit8u& numFree, Bit32u& size);

😀