YMF firmware size fix, PCM/Effect buffer size fixes, other minor changes

[jiyunomegami]

This works with YMF754 now. Both onboard and PCI cards.
The "size" of the firmware in the OSS header file was the number of 4 byte dwords, not the size in bytes...
Maybe the YMF724/YMF744 have the firmware in ROM since they appear to work without installing it.

[crazii]

Cool. I'm still stuck with the DOOM crash (some improvements but not done), so I don't have time to test with my desktop, I'll do it later. :)

[jiyunomegami]

I get crashes in Duke Nukem 3D on startup, the setup.exe runs OK and you can test sound FX.
No crash if I revert your changes done from Feb 5 onwards:

Revert "use DPMI std method to enable/disable interrupts."
Revert "*NEW HDPMI NEEDED* add new IRQ routing to improve compatibility"
Revert "add gopint.c from djgpp source."
Revert "fix on gopint.c and enable MAIN_ISR_CHAINED."
Revert "gcc inline assembly: always use size suffix to avoid stupid bugs."
Revert "disable MAIN_ISR_CHAINED for it is not complete yet."
Revert "fix and enable MAIN_ISR_CHAINED again."
Revert "remove initial test code: test.c; tiny optimize mixer_speed_lq: omit malloc/free, add size to avoid overflow."
Revert "improve resampling interpolation."
Revert "bugfix on low frequency interpolation, i.e. skyroads."

All changes can be seen here (revert of the above reverts):
41b0050

[crazii]

OK, thanks. I'll test it again. BTW do you use the latest HDPMI32i.EXE in the zip? There'll be problem if it is not used, which is indicated in the *NEW HDPMI NEEDED* notes.

EDIT: I should've at anyone involved the source code, when I updated the HDPMI source code. This new change might also fix your NIC problem.

[crazii]

But there's some bugs in HDPMI that I have commit yet, plz wait until I get it done.

[jiyunomegami]

OK.
I tried using HDPMI32i.EXE from UserBuild_2024.02.08_01-48. It still crashes.
I doubt this info is useful, but just in case:
After the line "Loading palette/lookups." from D3D:

hdpmi: fatal exit 0007

Exception 0E in ring 0
client CS:EIP=6838:00000246 SS:ESP=008F:00B700BF

[EIP]=26 8B 07 E8 2D FC FF FF F6 C4 04 AB
[ESP]=000E 00C0 0200 0000 0048 0000 5B02 0000
0000444C=5AAC 0000 D000 FFBF FFE4 FFFF F300 0000
...

[jiyunomegami]

Wait, after pulling your latest changes "add new HDPMI API call." etc. it doesn't crash!
Uploading to to mTCP FtpSrv after quitting D3D still causes a crash. It might be the ODI drivers.

[jiyunomegami]

Just ignore this if you are busy:
I sort of ported the Linux PCI detection and setup code, only because I thought it would make the YMF754 work.
Would something like this be useful?
In my fork I added a /PCI option. If you run sbemu /PCI2 it will print all the PCI devices (with DBG_Logi) and exit, like this:

*** PCI TREE ***
00:00.0 8086:0100
00:01.0 8086:0101 IRQ11 INTB# [bridge]
00:02.0 8086:0102 IRQ11 INTB#
00:14.0 8086:1E31 IRQ11 INTB#
00:16.0 8086:1E3A IRQ10 INTB#
00:1A.0 8086:1E2D IRQ3 INTB#
00:1B.0 8086:1E20 IRQ14 INTB#
00:1C.0 8086:1E10 IRQ11 INTB# [bridge]
00:1C.4 8086:1E18 IRQ11 INTB# [bridge]
  03:00.0 10EC:8168 IRQ11 INTB#
00:1D.0 8086:1E26 IRQ3 INTB#
00:1E.0 8086:244E [bridge (subtractive decode)]
  04:00.0 1073:0012 IRQ11 INTB#
00:1F.0 8086:1E49
00:1F.2 8086:1E00 IRQ15 INTC#
00:1F.3 8086:1E22 IRQ5 INTD#
00:1F.5 8086:1E08 IRQ15 INTC#

1073:0012 is the YMF754 and 10EC:8168 is the onboard RTL8168 NIC.

[crazii]

Just ignore this if you are busy: I sort of ported the Linux PCI detection and setup code, only because I thought it would make the YMF754 work. Would something like this be useful? In my fork I added a /PCI option. If you run sbemu /PCI2 it will print all the PCI devices (with DBG_Logi) and exit, like this:

*** PCI TREE ***
00:00.0 8086:0100
00:01.0 8086:0101 IRQ11 INTB# [bridge]
00:02.0 8086:0102 IRQ11 INTB#
00:14.0 8086:1E31 IRQ11 INTB#
00:16.0 8086:1E3A IRQ10 INTB#
00:1A.0 8086:1E2D IRQ3 INTB#
00:1B.0 8086:1E20 IRQ14 INTB#
00:1C.0 8086:1E10 IRQ11 INTB# [bridge]
00:1C.4 8086:1E18 IRQ11 INTB# [bridge]
  03:00.0 10EC:8168 IRQ11 INTB#
00:1D.0 8086:1E26 IRQ3 INTB#
00:1E.0 8086:244E [bridge (subtractive decode)]
  04:00.0 1073:0012 IRQ11 INTB#
00:1F.0 8086:1E49
00:1F.2 8086:1E00 IRQ15 INTC#
00:1F.3 8086:1E22 IRQ5 INTD#
00:1F.5 8086:1E08 IRQ15 INTC#

1073:0012 is the YMF754 and 10EC:8168 is the onboard RTL8168 NIC.

I went to bed early last night and just woke up. Today is Chinese Luna New year eve and I believe you have a similar date for new year, so happy new year 😄

Theoretically listing PCI is not part of sbemu and like some dos PCI drivers(i.e.some NIC diver) shipped with a stand-alone pciinfo.exe, I think you can build a stand-alone tool that comes with sbemu by default, create a new folder named tools or something and put the extra code and makefile in it and it's done.

Here's a reference of pciinfo which has a much similar function as you said,
#13 (comment)
But if might be better that we have one of our own so that we can customize the output any way we need.

Also Listing PCI devices could be done by using pcibios.h in mpxplay/au_cards, without using linux pci codes - but you can do what you see fit.

[jiyunomegami]

Happy new year!

I know there are various tools to get PCI info. Apparently even lspci has a dos port.
I use "Craig Hart's ([Veit Kannegieser's]) PCI+AGP bus sniffer" PCI.EXE.

I thought maybe the Linux stuff could be used for multiple sound cards that have the same driver, detecting subtractive decode bridges, etc.
Now I think only one card gets detected with pcibios_search_devices.
This may only be useful for testing. Normally you would only have one sound card in a machine.
Of course the Linux sound card drivers may be able to use it, but currently the ported drivers only depend on the functions of mpxplay/au_cards/pcibios.

[crazii]

Happy new year!

I know there are various tools to get PCI info. Apparently even lspci has a dos port. I use "Craig Hart's ([Veit Kannegieser's]) PCI+AGP bus sniffer" PCI.EXE.

I thought maybe the Linux stuff could be used for multiple sound cards that have the same driver, detecting subtractive decode bridges, etc. Now I think only one card gets detected with pcibios_search_devices. This may only be useful for testing. Normally you would only have one sound card in a machine. Of course the Linux sound card drivers may be able to use it, but currently the ported drivers only depend on the functions of mpxplay/au_cards/pcibios.

OK, what I mean is to use the pcibios_readconfig_* to enumerate all bus/dev/functions of pci devices, not pcibios_search_devices, pcibios_search_devices needs known device ids to work.
A triple loop will work but it needs a little bit additional parsing according to https://wiki.osdev.org/PCI

Actually usbddos has a pci.h/pci.c with some structure definitions i.e. PCI_HEADER could aid this: a triple loop that calls PCI_ReadDevice will get all the pci device informations. but I didn't port the two files to sbemu, because they have redundant/same functionality with pcibios.h.

I think the best way is to add more functions to pcibios.h, otherwise there's might be more redundant codes, but if linux pci functions are used internally for specific sound card drivers to ease the porting, I think it could be OK.

The idea is that either pcibois.h be replaced totally by linux pci header or we add more functions to it. In such way the code is in clean shape for better maintenance.

[jiyunomegami]

In commit 1d4260a did you mean to add -save-temps to LDFLAGS?
With -save-temps, if I change something and recompile without doing a clean, the changes don't get applied.

Also with -flto=auto my linux pci code segfaults. If I compile only those files without -flto=auto it works.

commit 1d4260a973536a81b254c040f585b3f77de16a7e
Author: crazii <crazii.he@yahoo.com>
Date:   Mon Feb 12 19:12:15 2024 +0800

    build: optimization: enable -O2 and LTO; bugfix on JEMM QPIEMU call for -O2
    now with LTO, simple extern get/set functions will be optimized as MOV.

diff --git a/makefile b/makefile
index 98fec4a..e3f3521 100644
--- a/makefile
+++ b/makefile
@@ -7,8 +7,8 @@ VERSION ?= $(shell git describe --tags)
 
 INCLUDES := -I./mpxplay -I./sbemu
 DEFINES := -D__DOS__ -DSBEMU -DDEBUG=$(DEBUG) -DMAIN_SBEMU_VER=\"$(VERSION)\"
-CFLAGS := -fcommon -march=i386 -Os $(INCLUDES) $(DEFINES)
-LDFLAGS := -lstdc++ -lm
+CFLAGS := -fcommon -march=i386 -O2 -flto=auto -Wno-attributes $(INCLUDES) $(DEFINES)
+LDFLAGS := -lstdc++ -lm -save-temps
 

[jiyunomegami]

The -flto=auto is not a big problem. I found where it was crashing. Just one place. The code seems OK, but adding a 1 microsecond delay near where it crashes makes it work.

[jiyunomegami]

It seems that the Creative ctxfi and emu10k1x drivers do not like -O2, I have to use the old -Os option for all files or else sbemu crashes on startup.

BTW, I added /SCFM and /SCMPU options, to select different FM/MPU sound cards, and got rid of main_hw_fmport etc.
These options shouldn't depend on the Linux stuff so I will make a pull request sometime soon.

And, do you have an ALS4000 card?
It has an OPL3 clone in hardware, so I ported the Linux driver for it.
I can't seem to get it working with Doom or Duke 3D. They always crash on startup.
Descent and the Duke 3D setup program seem to work OK.

[jiyunomegami]

The au_cards/sc_ich.c driver also crashes with -O2.
I will remove -O2 and -save-temps in my pull request.
These flags are OK:

CFLAGS := -fcommon -march=i386 -Os -flto=auto -Wno-attributes $(INCLUDES) $(DEFINES)
LDFLAGS := -lstdc++ -lm

[crazii]

Can the problems be fixed when using O2? There was crash on startup and I fixed it, but it might need more test and fixes.
For now I can disable O2 and test ich/emu10k to fix it before enabling it.

I have 2 ALS cards bought from Japan, AW540 and AW200, but I don't know if any of them is ALS4000, and I never tested them.

[crazii]

Save temps can removed, there's one warning when enabling LTO.
You can try -flto without =auto, and remove -save-temps

[jiyunomegami]

I don't know what goes wrong with -O2. It might take alot of time and turn out to be a compiler problem.

AOpen AW200 should work with the ALS4000 driver.

AW540 is different, it has a ForteMedia FM801 chip.

[crazii]

OK. I'll check that when I have time.
it might be a bug of a compiler, or a bug of the code that is exposed with O2 - like the last one when I enabled O2.

I can test the AW200 when most of the compatibility problem are fixed.

[crazii]

-flto=auto doesn't work for the MinGW build of DJGPP, that's why the -save-temps are added.
I will use -flto, but there'll be warnings. Let me know if -flto has any problems.

[crazii]

tested sc_ich.c with O2 in VirtualBox and it didn't crash, but I'm too lazy to test it on my ICH laptops. LOL
and I don't have sbxfi or live cards to test the -O2 crash.