IRQ5 does not work for me on the FSC-machines, I have to use IRQ7.

analog_programmer wrote on 2024-04-27, 10:51:

Maybe we have to make some more detailed "readme" documentation.

Yes, I'm working on it right now, as it's recommended by PhilsComputerLab too.

EDIT: BTW there's a brief introduction of options if you use 'SBEMU /?'

dr.zeissler wrote on 2024-04-27, 10:42:

While testing SBEMU on different FSC-Computers I recognized that there is no "SBEMU" that includes every patch ever made?
To be clear the newer and patched working AD1980 (E600/D1534) supported sbemu-version breaks support on a former working (C610/D1644) AC97 and i865gv.
If this is the way it is, the main/first post should link more versions of SBEMU that are patched for different chipsets/audiochips.

The latest builds should've included all patches, there's no separated builds for specific machines. There're temporary TESTING builds, uploaded as zip in some post, if they work, they will be used in the final release. if it worked previously but doesn't now, then there might be new bugs introduced, creating an issue on github is recommended, but you can also post it here if you feel more comfortable. 😁

crazii wrote on 2024-04-27, 02:06:

EDIT: does the 11-Feb build work? there seems no big changes from 09-Feb.
After that the O2 and LTO is on, probably causing problems, but are fixed on the 2024.02.18_00-37.

EDIT2: I see that SETPVI is used. you can try again without it. SETPVI may be needed by VSBHDA but not needed by SEBEMU, and it might cause problem especially code runs fast with O2 optimization, the bug exposed by O2 is fixed (interrupt related), however if setpvi is used, it is still not gonna work properly.

Yes, the 11-Feb build does work. I just tested. Builds after that date don't, same freeze as in the 11-Apr release.

And, there is the same behavior with or without SETPVI loaded. Seems to detect, but system is frozen, with no return to the command prompt. And, SBEMU reports incorrect /SCL zero values for max samplerate, bitrate, and channels for the ALC259 Realtek PCI soundcard, but with the correct soundcard id. I'd been using SETPVI since the days of the Feb 2023 betas, and it seemed to help back then.

zyzzle wrote on 2024-04-27, 11:27:

crazii wrote on 2024-04-27, 02:06:

EDIT: does the 11-Feb build work? there seems no big changes from 09-Feb.
After that the O2 and LTO is on, probably causing problems, but are fixed on the 2024.02.18_00-37.

EDIT2: I see that SETPVI is used. you can try again without it. SETPVI may be needed by VSBHDA but not needed by SEBEMU, and it might cause problem especially code runs fast with O2 optimization, the bug exposed by O2 is fixed (interrupt related), however if setpvi is used, it is still not gonna work properly.

Yes, the 11-Feb build does work. I just tested. Builds after that date don't, same freeze as in the 11-Apr release.

And, there is the same behavior with or without SETPVI loaded. Seems to detect, but system is frozen, with no return to the command prompt. And, SBEMU reports incorrect /SCL zero values for max samplerate, bitrate, and channels for the ALC259 Realtek PCI soundcard, but with the correct soundcard id. I'd been using SETPVI since the days of the Feb 2023 betas, and it seemed to help back then.

Here's build with -Os instead of O2 and LTO removed, can you test it?

If it works then there's more investigation needed since for bugs from different build configs.

EDIT:
another fix trying to fix problem introduced by O2 / LTO:

Excuse me, wierd_w, for I'm a simple person and I can't recall all the correct SB DOS settings from about 30 years ago 😀

So far, good news with the latest SBEMU build UserBuild_2024.04.27_03-42 and "SET BLASTER=A220 I5 D1 H5 T6 P330" (I prefer interrupt 5 over 7, because on my test system 7 is hooked to LPT1 and 5 is free):

The problem really comes from HighDMA set to 3. Now with HighDMA set to 5 TR1 sound setup program always autodetects correct values according to BLASTER values. Just for information and conformation to my previous descriptions of the already reported and fixed problems: With the older builds TR1's sound setup always determine wrong DMA 0 and interrupt 10 on first run and sometimes (I think with DMA set to 0) this actually produced sound, then on the second run it finds the right values as in the BLASTER variable.

The sound with CMI8738 is a little more choppy in the last build, but maybe this is due to my poor test system with Klamath 266.

HWINFO.EXE and CheckIT 3.0 report correct Interrupts and DMA settings with the last build, but NSSI reports SB with DMA 0 while DMA 1 is in use (maybe some bug in this long time dead software).

CMTEST.EXE still gives an error on DMA channel detection.

crazii, I have a suggestion for some stupid-proofness of the SBEMU. You better know which interrupt, DMA (low and high) and addresses values are suitable for different SB emulations - SB 1.0, SB 2.0, SB Pro, etc. You may add some checks if some of these values are improperly set in BLASTER environment variable (like in my case) and if so, the wrong value to fall back to the most common default value according to emulated SB card with some message in console. I'm sorry that I can't help you for this, because I don't use github outside of my job from very long time due to its corporate M$ ownership.

So far I'm very happy with this last build which gave me hope that CMI8738 cards are not with hardware broken SB emulation in pure DOS 😀

Thank you for your commitment to this worthwhile project!

analog_programmer wrote on 2024-04-27, 12:17:

You may add some checks if some of these values are improperly set in BLASTER environment variable (like in my case) and if so, the wrong value to fall back to the most common default value according to emulated SB card with some message in console.

Yes, that check is added just now, as previously noted here:

crazii wrote on 2024-04-27, 10:32:

EDIT: additional checks added if HDMA is less than 5, then Dx and Hx must be the same, in your case SBEMU will set H3 to H1. (or set D1 to D3 will work too).

crazii wrote on 2024-04-27, 12:50:

Yes, that check is added just now, as previously noted here:

crazii wrote on 2024-04-27, 10:32:

EDIT: additional checks added if HDMA is less than 5, then Dx and Hx must be the same, in your case SBEMU will set H3 to H1. (or set D1 to D3 will work too).

Great, but I meant some more detailed checks according to SB emulated card. As for this example I think it will be better to set HighDMA channel to valid default value of 5, instead to set the same value as for LowDMA or vice versa. It seems that cards older than SB16 don't even need HighDMA setting.

Anyway, better off something like this than nothing 😀

crazii wrote on 2024-04-27, 11:32:

Here's build with -Os instead of O2 and LTO removed, can you test it? sbemu_Os_NoLTO.zip […]
Show full quote

Here's build with -Os instead of O2 and LTO removed, can you test it?
sbemu_Os_NoLTO.zip

If it works then there's more investigation needed since for bugs from different build configs.

EDIT:
another fix trying to fix problem introduced by O2 / LTO:
sbemu_mmio_volatile.zip

Thanks so much, crazii for these "fix" builds.

I'm very happy to report that your EDIT new build above (sbemu_mmio_volatile.zip) detects properly, and does not freeze, and works completely normally now. Even with setpvi.exe loaded. Whatever you did in that "volatile" build enabled it to work perfectly on the Kabylake system with ALC259 card. It must have had something to do with LTO / compiler optimizations which borked it before.

The first build (sbemu_Os_NoLTO.zip) exhibited the same freeze as the other post-Feb 11th versions of SBEMU.

@analog_programmer

Phht! You and me both! I'm getting old enough now to start being mindful of my own forgetfulness, so you're in good company!

I've been suffering the Mandella Effect more and more often these days!

I agree with you over preference for IRQ5 over 7, and for the same reason. I really do not understand why or how it became 'defaults' at 7. That only makes sense if you are doing dumb stuff with the parallel port, or have it disabled all together. (So that you can do stuff with say a network card living on irq 5. But if you ask me, it's more sane to disable a com port to get IRQ3, and put the nic there. The lpt port is infinitely more useful.)

For some reason though, every modern emulator wants to set it on 7, and it seems sbemu has just adopted that convention.

I've always set soundblasters on 5 though.

zyzzle wrote on 2024-04-27, 13:02:

Thanks so much, crazii for these "fix" builds. […]
Show full quote

crazii wrote on 2024-04-27, 11:32:

Here's build with -Os instead of O2 and LTO removed, can you test it? sbemu_Os_NoLTO.zip […]
Show full quote

Here's build with -Os instead of O2 and LTO removed, can you test it?
sbemu_Os_NoLTO.zip

If it works then there's more investigation needed since for bugs from different build configs.

EDIT:
another fix trying to fix problem introduced by O2 / LTO:
sbemu_mmio_volatile.zip

Thanks so much, crazii for these "fix" builds.

I'm very happy to report that your EDIT new build above (sbemu_mmio_volatile.zip) detects properly, and does not freeze, and works completely normally now. Even with setpvi.exe loaded. Whatever you did in that "volatile" build enabled it to work perfectly on the Kabylake system with ALC259 card. It must have had something to do with LTO / compiler optimizations which borked it before.

The first build (sbemu_Os_NoLTO.zip) exhibited the same freeze as the other post-Feb 11th versions of SBEMU.

Glad to hear that!
That's GCC optimized out some repeated/redundant memory reads/writes, normally it's OK, but NOT OK for MMIO that reads/writes memory mapped device registers, because they might be changed by devices, not by the CPU.
But I don't understand why the Os_NoLTO doesn't work, it should be as before, and as the mmio_volatile one. I'm still confused, but let's say we have take a little step further to fix the bug. 😁
Thanks for your test!

wierd_w wrote on 2024-04-27, 13:15:

@analog_programmer […]
Show full quote

@analog_programmer

Phht! You and me both! I'm getting old enough now to start being mindful of my own forgetfulness, so you're in good company!

I've been suffering the Mandella Effect more and more often these days!

I agree with you over preference for IRQ5 over 7, and for the same reason. I really do not understand why or how it became 'defaults' at 7. That only makes sense if you are doing dumb stuff with the parallel port, or have it disabled all together. (So that you can do stuff with say a network card living on irq 5. But if you ask me, it's more sane to disable a com port to get IRQ3, and put the nic there. The lpt port is infinitely more useful.)

For some reason though, every modern emulator wants to set it on 7, and it seems sbemu has just adopted that convention.

I've always set soundblasters on 5 though.

Ha! count me in. Before writing USBDDOS/SBEMU I almost forgot everything on DOS programming, that I have to read all the documents again, like when I first learned DOS programming more than 2 decades ago.

wierd_w wrote on 2024-04-27, 13:15:

I agree with you over preference for IRQ5 over 7, and for the same reason. I really do not understand why or how it became 'defaults' at 7. That only makes sense if you are doing dumb stuff with the parallel port, or have it disabled all together. (So that you can do stuff with say a network card living on irq 5. But if you ask me, it's more sane to disable a com port to get IRQ3, and put the nic there. The lpt port is infinitely more useful.)
For some reason though, every modern emulator wants to set it on 7, and it seems sbemu has just adopted that convention.
I've always set soundblasters on 5 though.

I don't remember the details but IRQ7 might get more compatibility.
I only remember some of my YMF cards doesn't work (not at all, or for some games) with IRQ5 on win98se, so I changed it to 7. But if games are running under DOS using IRQ5, I have to run setup for each game to set IRQ when the OS switches, and that's obviously stupid so I kept them all to IRQ7.

wierd_w, I fully agree with your point. My current SBEMU on CMI8738 test system does not have any PCI or ISA NIC adapter installed, so I decided to use interrupt 5 over 7 for the SB16 emulation as it is completely free. If I add some NIC adapter I may switch to default interrupt 7 for the SBEMU. It all depends on current configuration, free system resources and sometimes luck with the settings. "Plug and pRay"... wasn't it just about windows? No? 😁

crazii, can you recommend me some online available literature or reference books/documents, 'cause I haven't dabbled with low level DOS programming at all even back in the times when the good old DOS was still "alive"? If you prefer, you can send me PM to avoid generating unnecessary "spam posts" in the thread. Thank you!

analog_programmer wrote on 2024-04-27, 14:31:

wierd_w, I fully agree with your point. My current SBEMU on CMI8738 test system does not have any PCI or ISA NIC adapter installed, so I decided to use interrupt 5 over 7 for the SB16 emulation as it is completely free. If I add some NIC adapter I may switch to default interrupt 7 for the SBEMU. It all depends on current configuration, free system resources and sometimes luck with the settings. "Plug and pRay"... wasn't it just about windows? No? 😁

🙁

Sadly, no. plug&pray was also a thing in the tail end of the DOS era... I remember my cheap vibra16 AND my legit SB32, both needed the ctcm configuration utility, because Creative Labs didnt want to give me jumpered cards anymore.

I WAS lucky that my EtherlinkIII card could live happily on IRQ3, so I got to keep my parallel port! Whoohoo!

analog_programmer wrote on 2024-04-27, 14:31:

wierd_w, I fully agree with your point. My current SBEMU on CMI8738 test system does not have any PCI or ISA NIC adapter installed, so I decided to use interrupt 5 over 7 for the SB16 emulation as it is completely free. If I add some NIC adapter I may switch to default interrupt 7 for the SBEMU. It all depends on current configuration, free system resources and sometimes luck with the settings. "Plug and pRay"... wasn't it just about windows? No? 😁

crazii, can you recommend me some online available literature or reference books/documents, 'cause I haven't dabbled with low level DOS programming at all even back in the times when the good old DOS was still "alive"? If you prefer, you can send me PM to avoid generating unnecessary "spam posts" in the thread. Thank you!

I didn't do 'low-level' programming back in the day either. I read some beginner books on QBasic and FOXBASE+ in junior high, and later had fun with Turbo C - That was a time I was playing DOS games with little knowledge about sound cards or video cards.
One of the most helpful was the built-in help of Borland C++ 3 IDE, with all library functions and keywords, some with sample codes. And once Borland C++ was my favourite, when I had lot of fun with 0b800h video buffer, and real mode segments and far pointers 😁. The knowledge source is more 'fragmented' nowadays and you may not read any books for real, when Google is your best friend. I can PM you tomorrow with some sites, hope it helps.

wierd_w wrote on 2024-04-27, 13:15:

I agree with you over preference for IRQ5 over 7, and for the same reason. I really do not understand why or how it became 'defaults' at 7. That only makes sense if you are doing dumb stuff with the parallel port, or have it disabled all together. (So that you can do stuff with say a network card living on irq 5. But if you ask me, it's more sane to disable a com port to get IRQ3, and put the nic there. The lpt port is infinitely more useful.)

For some reason though, every modern emulator wants to set it on 7, and it seems sbemu has just adopted that convention.

I've always set soundblasters on 5 though.

Incidently, and tangentially I also prefer IRQ5. SBEMU seems to run more stable with IRQ5 vs IRQ7. On my laptop, IRQ7 works, but the sound is a bit choppy, whereas IRQ5 works perfectly, no choppiness or stuttering at all.

@crazii:
I also am confused as to why the first NoLTO build didn't work. I'm going through exhaustive tests to see if it isn't something on my end. (eg, boot clean with only JEMMEX loaded, with and without setpvi, changing IRQs, changing HDMI32i version, Sound Blaster types, using -F22050 vs -F44100, with and without -P0, etc) but so far nothing is making the first "fix" work. And, the second one ("volatile") works perfectly on all the settings I try.

zyzzle wrote on 2024-04-27, 23:46:

Incidently, and tangentially I also prefer IRQ5. SBEMU seems to run more stable with IRQ5 vs IRQ7. On my laptop, IRQ7 works, but the sound is a bit choppy, whereas IRQ5 works perfectly, no choppiness or stuttering at all.

It depends on your hardware/BIOS config, it is possible that IRQ7 is shared by your other devices. But I think there's something can be done to make it better: auto detect the spare IRQ 5/7 to gain max compatibility.

zyzzle wrote on 2024-04-27, 23:46:

@crazii:
I also am confused as to why the first NoLTO build didn't work. I'm going through exhaustive tests to see if it isn't something on my end. (eg, boot clean with only JEMMEX loaded, with and without setpvi, changing IRQs, changing HDMI32i version, Sound Blaster types, using -F22050 vs -F44100, with and without -P0, etc) but so far nothing is making the first "fix" work. And, the second one ("volatile") works perfectly on all the settings I try.

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.

crazii wrote on 2024-04-27, 19:18:

I didn't do 'low-level' programming back in the day either. I read some beginner books on QBasic and FOXBASE+ in junior high, and later had fun with Turbo C - That was a time I was playing DOS games with little knowledge about sound cards or video cards.
One of the most helpful was the built-in help of Borland C++ 3 IDE, with all library functions and keywords, some with sample codes. And once Borland C++ was my favourite, when I had lot of fun with 0b800h video buffer, and real mode segments and far pointers 😁. The knowledge source is more 'fragmented' nowadays and you may not read any books for real, when Google is your best friend. I can PM you tomorrow with some sites, hope it helps.

Excuse my inappropriate phrase. By "low level DOS programming" I didn't mean using an low-level (assembly) programming language, but writing code to control the hardware at low level. Thanks for the sources cited regarding this type of 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.

Now back on the topic.

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.

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.

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