analog_programmer wrote on 2024-04-28, 07:00:

programming in the DOS. It's hard to find such information online nowadays, simply because hardly anyone is into DOS programming at all. I would be very grateful if you'd also send me specific online links with such an useful information.

PM sent, please check. I'm not sure if it is what you need/want. 😁

zyzzle wrote on 2024-04-28, 12:30:

Strangely, I did get the NoLTO build working! I do not know how or why, but it magically started to work *after* I ran the other […]
Show full quote

crazii wrote on 2024-04-28, 06:28:

Thanks for the testing. It's also possible that the bug always exist even for -Os, but didn't expose after some code changes that affect it. - If you read from (or write with the same value to) a mem address twice, it's very likely that compiler will optimize the 2nd even using -Os, especially in a inlined context.

Strangely, I did get the NoLTO build working! I do not know how or why, but it magically started to work *after* I ran the other build ("volatile"). Mysteries of the deep, as I did nothing different. All settings are the same, except I used a different HDPMI32i.EXE of 37,316 bytes from 2023 vs the more recent one of 39,118 bytes. The "volatile" build perhaps altered something at a deep hardware level (?), but I'm not sure. I'm just glad it's working again in this "modern" build.

I've also noticed various versions of HDPMI32, varying from 37k to 39k. The HDPMI32i included in the 4/27 compile above, for example, is 38,646 byte.

I tried all of these different versions of HDPMI32i.EXE, with the "volatile" build, and they all worked fine, SBEMU behaved as normal, and MIDI port at 0x330 was active and fine. So, -P0 was not needed after all, being a strange red herring.

Oh, yes the HDPMI is updated too, I should've let you know.

EDIT:

zyzzle wrote on 2024-04-28, 12:30:

I tried all of these different versions of HDPMI32i.EXE, with the "volatile" build, and they all worked fine, SBEMU behaved as normal, and MIDI port at 0x330 was active and fine. So, -P0 was not needed after all, being a strange red herring.

That's might be a coincidence that HDPMI32i didn't change much, the exes needs to be used together in the same zip.

crazii wrote on 2024-04-28, 18:56:

PM sent, please check. I'm not sure if it is what you need/want. 😁

Thank you! Actually it is what I need. At least as a some starting point and guidelines 😀

I just saw that you have some newer builds from UserBuild_2024.04.27_03-42 on the girhub. Do they include the fixes for the CMI8738 chip from UserBuild_2024.04.27_03-42?

Baron von Riedesel wrote on 2024-04-28, 14:49:

analog_programmer wrote on 2024-04-26, 14:45:

I just found another problem related to Jemm on my test system. M$-DOS FORMAT and even NFORMAT produces garbage FAT on floppy drives. When I reverted back to HIMEM + EMM386 this problem has gone.

I can confirm this issue to be generic. It happens if certain ISA DMA registers are trapped by "3rd-party" code ( as it is the case with SBEMU ).

https://github.com/Baron-von-Riedesel/Jemm/issues/25

That maybe avoid in a way, that the QPIEMU creates a rm wrapper for the internal v86 io trap functions as 'the old/original rm port trap handler', and SBEMU calls the old handler as possible as it could, instead of calling un-trapped io directly.

EDIT: according to RBIL, CF can indicates whether it is handled or not, I guess it is used by QEMM to call its internal function. SBEMU can set CF like when the DMA channel is not used by it.

Values QEMM v7.03+ I/O callback function is called with:. AL/AX = data to/from trapped port. CL = I/O direction (00h = IN instru […]
Show full quote

Values QEMM v7.03+ I/O callback function is called with:.
AL/AX = data to/from trapped port.
CL = I/O direction (00h = IN instruction, else OUT instruction).
DX = I/O port address

Return:
CF clear if port handled by callback function
CF set if not handled
all other registers returned to application executing the IN or OUT
instruction (allowing arbitrary changes to port address, data value,
etc.)

analog_programmer wrote on 2024-04-29, 05:34:

I just saw that you have some newer builds from UserBuild_2024.04.27_03-42 on the girhub. Do they include the fixes for the CMI8738 chip from UserBuild_2024.04.27_03-42?

Do you mean the IRQ10 problem? Yes, they do. actually it's not CMI only, the emulation code has bugs on all cards.

crazii wrote on 2024-04-29, 06:10:

Do you mean the IRQ10 problem? Yes, they do. actually it's not CMI only, the emulation code has bugs on all cards.

Yeah, the problem with interrupt and DMA. I'll test the latest github build later.

analog_programmer wrote on 2024-04-28, 07:00:

This morning I switched to my other CMI8738 soundcard (the one with LX version of the chip) and it turned out that it is far less choppy sounding than the first one which I've tested yesterday - the one with MX version of the chip. I also tested SBEMU with /FIXTC1 command line switch, but in my case it didn't improve anything with my CMI8738 cards. I also changed the slot1 CPU (PII Klamath 266) with the fastest compatible CPU that I have - s.370 Celeron Mendocino 366 in a slotket adapter and this didn't improve choppiness too. At first glance both of my CMI8738 cards are similar in their "triangular" resembling PCB design, but the one with the MX chip has more spared passive components - SMD capacitors and resistors. So it seems this problem with choppy sound is not related to SBEMU. My no-name CMI8738-MX soundcard is just lower quality than the other no-name card with LX chip.

BTW you can try the /SCFM1 to use hardware FM for the CMI instead of software FM emulation, it may get a performance boost and help with the choppy. But note that some CMI cards don't have HW FM, you may need to test it out.

crazii wrote on 2024-04-29, 07:55:

BTW you can try the /SCFM1 to use hardware FM for the CMI instead of software FM emulation, it may get a performance boost and help with the choppy. But note that some CMI cards don't have HW FM, you may need to test it out.

Great! I'll try this with the latest build. If I remember correctly the CMI8738 has it's own OPL3 hardware implementation.

UPDATE: Ok, "/K44100" is a valid switch and didn't mess things for worse with the CMI8738 😀

Just tried the last build "UserBuild_2024.04.28_03-45" and... surprise! No more choppy sound even with my worse MX version soundcard and weak PII Klamath 266 CPU 😀

I also tried the "/SCFM1" switch and it didn't improve things more with TR1, but this DOS game lacks any FM music. At least it didn't crash or break anything with my C-Media cards. I also tried "/SCFM1" in combination with "/K44100" and then with "/K44100 /FIXTC1" and I can't hear any difference in sound quality in any of the cases.

In this last build the sound volume again seems a little lower compared to the yesterday's (then) "last" build I've tested, but the more important thing is that the choppiness is gone.

Good job!

UPDATE 2: Oops, while I was testing yesterday's build and finishing this comment, there is now a newer fresh build "UserBuild_2024.04.29_09-29". I can't keep up with the testing 😁

Just a question what can I check to start debugging this?

As I am working with a Dell Optiplex 3030 AIO system but SBEMU seems to crash the device. I am using the latest version.
I don't have QEMM or JEMM loaded yet. I made a video to just capture the output before it flashes away and it said:

1QEMM or QPIEMU not installed, disabling real mode support.
2Sound card: Intel HDA
3Real mode support: disabled.
4Protected mode support: enabled.
5OPL emulation at port 3: enabled.
6MPU-401 UART emulation at address 330: enabled.
7SB Pro(1:Intel HDA) emulation at address 220, IRQ 7, DMA 1: enabled.

After this the system crashes and delivers me a black screen.

EDIT: some breaktrough.
Apparently if I set the interrupt to 7 (the default it crashes on my system). Weird. Anyway I removed the switch and now it works.

enira wrote on 2024-04-30, 14:02:

OPL emulation at port 3: enabled.

The port 3 is wrong and confusing, I'll check the code first.
EDIT: OK its probably a typo and the message is hard coded to be 388.

You may want to try with JEMMEX installed, and add /P0 for SBEMU, and /I5 to change IRQ to see what happens. there'll be logs on next release after beta4.

crazii wrote on 2024-04-30, 14:17:

The port 3 is wrong and confusing, I'll check the code first. EDIT: OK its probably a typo and the message is hard coded to be 3 […]
Show full quote

enira wrote on 2024-04-30, 14:02:

OPL emulation at port 3: enabled.

The port 3 is wrong and confusing, I'll check the code first.
EDIT: OK its probably a typo and the message is hard coded to be 388.

You may want to try with JEMMEX installed, and add /P0 for SBEMU, and /I5 to change IRQ to see what happens. there'll be logs on next release after beta4.

Found the issue, set in the edit. But crashing isn't entirely done yet.

I loaded in JEMMEX and installed Warcraft 2.
When I go to Music Setup everything works. Test produces sound.

But when I want to add the sound effects (digital setup), autodetect suggests a sound blaster 16/AWE32 device, it fails: There has been an error attempting to initialize the card you selected.
Please choose a diffrent card.

So I tried: I picked sound blaster. Which seems to initialize fine. But when you hit test to test the sound the system freezes again.

I tried all cards and they fail to initialize. Only Sound Blaster and Sound Blaster Pro seems to pass this step but when hitting test the system freezes.

That's super weird, I would guess it either works or not, not 50%.

enira wrote on 2024-04-30, 14:02:

EDIT: some breaktrough.
Apparently if I set the interrupt to 7 (the default it crashes on my system). Weird. Anyway I removed the switch and now it works.

Weird, the default value is still 7 if not set. did you set BLASTER before installing SBEMU? what's the settings? T6 probably?
and Any extra parameters to SBEMU?
I found some new high dma issues, especially for T6 or games assumes a 16/AWE by default, but need more information before posting the testing binary.

crazii wrote on 2024-04-30, 15:43:

Weird, the default value is still 7 if not set. did you set BLASTER before installing SBEMU? what's the settings? T6 probably? a […]
Show full quote

enira wrote on 2024-04-30, 14:02:

EDIT: some breaktrough.
Apparently if I set the interrupt to 7 (the default it crashes on my system). Weird. Anyway I removed the switch and now it works.

Weird, the default value is still 7 if not set. did you set BLASTER before installing SBEMU? what's the settings? T6 probably?
and Any extra parameters to SBEMU?
I found some new high dma issues, especially for T6 or games assumes a 16/AWE by default, but need more information before posting the testing binary.

No blaster set at the moment. I read in the docs that SBEMU sets this once loaded?

AUTOEXEC.BAT

1@ECHO OFF
2C:\DOS\SMARTDRV.EXE /X
3PATH C:\DOS
4
5C:\DOS\DRIVERS\JLOAD C:\DOS\DRIVERS\QPIEMU.DLL
6
7MSCDEX.EXE /D:CDROM /L:G
8C:\DOS\DRIVERS\HDPMI32I.EXE -x -r
9C:\DOS\DRIVERS\SBEMU.EXE

CONFIG.SYS

1LASTDRIVE=Z
2DEVICE=C:\DOS\SETVER.EXE
3DEVICE=C:\DOS\DRIVERS\JEMMEX.EXE
4DOS=HIGH
5FILES=30
6STACKS=9,256
7DEVICE=C:\DOS\DRIVERS\XDVD2.SYS /D:CDROM

UPDATE: Some observed behaviour:
It seems that SBEMU doesn't like the way Warcraft 2 handles its sound.

I tested the same now with Red Alert and I can get through the installation. Whilst the installation defaults to Sound blaster 16 / AWE32 the sound test produces no sound. When you go back and manually select Sound Blaster, you pass the check. But playback of the first intro video, the system hangs. Once you reboot it seems to work perfect.

Sooo... if other users are experiencing the same issues with Warcraft 2, it's a Warcraft issue. And you can add the Dell AIO 3030 to the list of compatible devices. As Red Alert works (given once you get past the install crash).

Always willing to help you troubleshoot whats happening with the Warcraft 2 if you have a test build that can dump to a log file. I find this an awesome initiative.

I've used it with war2 before, set it to 8bit soundblaster compatible with generic opl3.

It hates sb16.

The music volume does odd things when pcm audio plays though.

enira wrote on 2024-04-30, 16:09:

No blaster set at the moment. I read in the docs that SBEMU sets this once loaded?

Yes. So what were the parameters used before, that cause your system hang? /I7?

crazii wrote on 2024-04-30, 20:10:

enira wrote on 2024-04-30, 16:09:

No blaster set at the moment. I read in the docs that SBEMU sets this once loaded?

Yes. So what were the parameters used before, that cause your system hang? /I7?

Yes ,SBEMU.EXE /I7 made it hang. I was fiddling around with /I9 and /I5 and when I set it to /I7 the PC crashed.

enira wrote on 2024-04-30, 20:25:

crazii wrote on 2024-04-30, 20:10:

enira wrote on 2024-04-30, 16:09:

No blaster set at the moment. I read in the docs that SBEMU sets this once loaded?

Yes. So what were the parameters used before, that cause your system hang? /I7?

Yes ,SBEMU.EXE /I7 made it hang. I was fiddling around with /I9 and /I5 and when I set it to /I7 the PC crashed.

So what's the IRQ it uses when it works? not 7 anymore? that's not expected.
BTW war2 works fine on my P3 laptop, and the setup runs fine on a more modern one. There're still too many compatibility problems needs to be fixed.

crazii wrote on 2024-04-30, 20:46:

enira wrote on 2024-04-30, 20:25:

crazii wrote on 2024-04-30, 20:10:

Yes. So what were the parameters used before, that cause your system hang? /I7?

Yes ,SBEMU.EXE /I7 made it hang. I was fiddling around with /I9 and /I5 and when I set it to /I7 the PC crashed.

So what's the IRQ it uses when it works? not 7 anymore? that's not expected.
BTW war2 works fine on my P3 laptop, and the setup runs fine on a more modern one. There're still too many compatibility problems needs to be fixed.

If I remove the flag everything just works

enira wrote on 2024-04-30, 21:35:

crazii wrote on 2024-04-30, 20:46:

enira wrote on 2024-04-30, 20:25:

Yes ,SBEMU.EXE /I7 made it hang. I was fiddling around with /I9 and /I5 and when I set it to /I7 the PC crashed.

So what's the IRQ it uses when it works? not 7 anymore? that's not expected.
BTW war2 works fine on my P3 laptop, and the setup runs fine on a more modern one. There're still too many compatibility problems needs to be fixed.

If I remove the flag everything just works

So it still output like this:

1SB Pro(1:Intel HDA) emulation at address 220, IRQ 7, DMA 1: enabled.

With the exactly same IRQ 7, but it works? No way! I don't know what happens but very curious about it. 😁

crazii wrote on 2024-04-30, 21:57:

So it still output like this: […]
Show full quote

enira wrote on 2024-04-30, 21:35:

crazii wrote on 2024-04-30, 20:46:

So what's the IRQ it uses when it works? not 7 anymore? that's not expected.
BTW war2 works fine on my P3 laptop, and the setup runs fine on a more modern one. There're still too many compatibility problems needs to be fixed.

If I remove the flag everything just works

So it still output like this:

Copy code to clipboard

1SB Pro(1:Intel HDA) emulation at address 220, IRQ 7, DMA 1: enabled.

With the exactly same IRQ 7, but it works? No way! I don't know what happens but very curious about it. 😁

Yep, so now it's running at IRQ7, all at defaults.
But I must say I do find the the Dell 3030 a very temperamental machine. For example XDVD2.SYS is the only driver that works for its CD drive where in theory the TSSTcorp drive isn't that exotic to begin with.
It's a newer drive, but it's something I assume GCDROM would be able to pickup, but alas.

Currently testing with QEMM version 9 so I can load Windows 3.11 as well to do some more sane file manipulation. However it seems that under QEMM it throws Illegal Page Reference [PTE=6B64-6B00h].
Are there specific settings or parameters needed for QEMM?