I was noticing that in the Device Manager, the sound driver, National XpressAudio, also contains a PCI bridge. Is the built-in sound PCI based? I figured that this could be why I couldn't hear sound in DOS. There is no National/Cyrix DOS driver that I'm aware of which would be used to setup MPU-401. Unisound shows that all the I/O, IRQ, etc assignments are correct. I've tried the BIOS settings of Enable/Disable MPU-401 and Enable/Disable Joystick.

In Win95, there's no midi sound being output from the speakers if I select to use the External Midi Port in Control Panel / Multimedia. The midi playback progress bar does progress however.

Next, I tried re-installing all the National MediaGX drivers from their all-in-one setup suite, which then placed duplicate audio devices in Control Panel / Multimedia / Devices : "audio devices" and "MIDI Devices". I couldn't figure out how to delete one of these duplicates as removing the sound card device from Device Manager, then restarting, still yielded the duplicate. The duplicate is not shown in the attached photos. Nonetheless, after the existence of the duplicate, paying back the midi file will now hard freeze the system if External Midi is selected from Control Panel / Multimedia.

I've given up on this for now and am using an ISA ESS sound card. Maybe someone else will have better luck. If anyone is able to get the MPU-401 working, particularly with a CHIL & PHIL, could you share your drivers?

HI. I don't know how your computer works, but I have a WYSE terminal that has an AC97 audio chip and uses Virtual System Architecture (VSA) to emulate a SB 16 + MPU 401. There is no SB 16 nor MPU 401 on the system, actually not a single game port at all. All of this emulation is made at a low level in BIOS.
Your Cyrix CPU has this SB16 embedded and is using the same VSA system. Something might be wrong in the BIOS VSA.
Can you share your BIOS dump?
Upload it to some file hosting server and provide a link!

Hi. Here's the BIOS.

On my Advantech board I was able to install Creative SB16 drivers in pure DOS. But the MIDI/Joystick port has been omitted on these boards. I had a ECS P5GX-M but didn't try MIDI on that one. When I'm home I will dig up the BIOS for the Advantech (POS 7551).

For completeness, I should mention that some of the discussion relating to MPU-401 on Cyrix MediaGX systems was also posted by me in the following thread, again without resolution: Re: Sound Blaster 16 Clones This was back in Jan 2024.

Rawit wrote on 2024-08-15, 08:04:

On my Advantech board I was able to install Creative SB16 drivers in pure DOS. But the MIDI/Joystick port has been omitted on these boards. I had a ECS P5GX-M but didn't try MIDI on that one. When I'm home I will dig up the BIOS for the Advantech (POS 7551).

Yah gut reaction on seeing title was something like "Ahh dang, some internal loopback he's gotta try and break out of, these highly integrated solutions are a PITA"

Here is the bios for the Advantech POS 7551 & 563. I don't see a MIDI port option in the BIOS so I'm afraid it's of little use.

Rawit wrote on 2024-08-15, 17:07:

Here is the bios for the Advantech POS 7551 & 563. I don't see a MIDI port option in the BIOS so I'm afraid it's of little use.

Your bios has the Joystick disabled, and there's no MIDI port base address. You can change this with this tool Award BIOS editor:
https://drive.google.com/file/d/1rDQnzsF2aS5g … ew?usp=drivesdk

feipoa wrote on 2024-08-15, 00:05:

Hi. Here's the BIOS.

Filename

ECS-P5GX-M-v1.zip

File size

153.74 KiB

Downloads

10 downloads

File license

CC-BY-4.0

I have looked at the BIOS and everything looks good. I've started to disassemble it with IDA to see how it works. The BIOS Boot Block is only 8kb long but it takes some time to trace every function. Then there is the VSA ROM that it must be fine, and finally there must be the settings for the VSA virtual registers. This are important to be set right for any hardware to work properly.
I have included the disassemble IDA files (as much as I had time to disassemble) in the link below and a tool for easy BIOS editing if you wanna check what settings can be made.
When I'll have time I will trace further the execution of this BIOS. I'm interested in this VSA system.

Regards.
Ștefan.

https://drive.google.com/drive/folders/1rC1e5 … 494nA5wwZTeqzxo

I had a look at the datasheet for the Geode CS5530 (AIUI essentially the same as the Cyrix Cx5530 after National Semiconductor bought them) and on page 121 is a block diagram for the audio-related SMM traps. It's not clear what the appropriate action for MPU-401 should be. On page 8, XpressAUDIO is described as VSA technology for "industry standard 16-bit stereo synthesis and OPL3 emulation", essentially emulating an SB16 with OPL3 in SMM (System Management Mode, think SBEMU running in ring -2 so it's transparent to the OS), but there's no mention of MPU-401. The block diagram on page 1 or 6 has the "Audio/Codec/MPU interface" connected to an AC97 codec, which itself has no UART for the MPU-401.
It'd be interesting to trace pins 12 and 15 from the game port to see where they end up. Perhaps contact Phil of PhilsComputerLab as he has (or at least had) the same motherboard?
Anyway, I have an Avalue ECM-3412L 3.5" SBC with a Geode GX1 (essentially a die-shrunk MediaGXm) and its BIOS does have the option to set the MPU-401 base address even though it doesn't have a port for it or a game controller. It works fine as an SB16 with OPL3 in DOS, no drivers needed (just SET BLASTER appropriately).

I'm also using a GX1 chip (PGA) on my board. Could there have been some change between the GXm and GX1 which is preventing proper operation of the MPU-401? Knowing me, I'd have already tested the GXm chip to confirm this condition.

I have a spare, non-cased, ECS P5GX-M motherboard I can trace those pins on, but not until the fall. I'm generally not doing any hobby related activities this summer; too many other things going on during the summer.

feipoa wrote on 2024-08-19, 23:33:

Could there have been some change between the GXm and GX1 which is preventing proper operation of the MPU-401?

I'm not an expert in this but I don't think so. The status bits for the SMM traps are set on the CS5530 south bridge. The CPU initialisation code in Linux treats the GXm, GXLV, and GX1 identically (apart from their ID). The Linux sound driver actually just identifies it by PCI ID, determines the port/IRQ/DMA configured (by the BIOS), then loads the SB16 driver. Hmm... it has this comment:

1 * XpressAudio(tm) is used on the Cyrix MediaGX (now NatSemi Geode) systems.
2 * The older version (VSA1) provides fairly good soundblaster emulation
3 * although there are a couple of bugs: large DMA buffers break record,
4 * and the MPU event handling seems suspect.

Perhaps @StefanPutureanu can read the disassembly of VSA1 and work out what's suspect about it 😀

jtchip wrote on 2024-08-19, 23:23:

I had a look at the datasheet for the Geode CS5530 (AIUI essentially the same as the Cyrix Cx5530 after National Semiconductor bought them) and on page 121 is a block diagram for the audio-related SMM traps. It's not clear what the appropriate action for MPU-401 should be. On page 8, XpressAUDIO is described as VSA technology for "industry standard 16-bit stereo synthesis and OPL3 emulation", essentially emulating an SB16 with OPL3 in SMM (System Management Mode, think SBEMU running in ring -2 so it's transparent to the OS), but there's no mention of MPU-401. The block diagram on page 1 or 6 has the "Audio/Codec/MPU interface" connected to an AC97 codec, which itself has no UART for the MPU-401.
It'd be interesting to trace pins 12 and 15 from the game port to see where they end up. Perhaps contact Phil of PhilsComputerLab as he has (or at least had) the same motherboard?
Anyway, I have an Avalue ECM-3412L 3.5" SBC with a Geode GX1 (essentially a die-shrunk MediaGXm) and its BIOS does have the option to set the MPU-401 base address even though it doesn't have a port for it or a game controller. It works fine as an SB16 with OPL3 in DOS, no drivers needed (just SET BLASTER appropriately).

Yes, this SMI registers are being set by the VSA. Are somehow internals for the VSA. I have the source code of the VSA 2.. In the "inc" folder there is a "vr.h" file where are defined all the virtual classes and registers. This needs to be set after the VSA system is loaded, and can be set only once per system power up.
https://drive.google.com/drive/folders/1shVR9 … nDrGI1ILdhAUjee
Class 0x01, reg 0x03 is the MIDI base address virtual register. This is an input for the VSA to set the right MSRs for any memory trap to be effective.
The procedure for setting any virtual register is the same. You need to provide the VR class, the register and the data.
*************************************
MOV AX, FC53 // this is a specific VSA unlock code
MOV DX, AC1C // IO port for selecting a virt. reg.
OUT DX, AX // now the VSA is waiting for a class and a virt. reg. to be selected
MOV AH, 01 // audio class
MOV AL, 03 // MIDI base address register
OUT DX, AX // the MIDI virtual reg. has been selected
MOV DX, AC1E // IO port for the data
MOV AX, 0330 // MPU-401 base address
OUT DX, AX // set the MIDI virtual reg to 0330h
**************************************
This is what the BIOS should do after loading the VSA. The 0330h value must be taken from a NVRAM token. And NVRAM tokens are in the virtual CMOS... the function must be a little bit more complex than this.
BIOS might set the VSA regs by putting the info together in the EAX reg like this:
MOV EAX, FC530103 // unlock code + class + virt. reg.
OUT DX, EAX
***************************************
If all of this are good in the BIOS, then it must be a problem with the VSA code itself. As long as the virtual regs. for MIDI are there in the VSA I think that the interface should work.
It took me 4 months to reverse a full (64kb) WYSE SBC Boot Block to patch a faulty INT 13 ISR (OEM OS was using direct IO for IDE controll and I wanted to make it boot DOS 6). Your's is just 8k, it must be simple but I need time.

feipoa wrote on 2024-08-19, 23:33:

I'm also using a GX1 chip (PGA) on my board. Could there have been some change between the GXm and GX1 which is preventing proper operation of the MPU-401? Knowing me, I'd have already tested the GXm chip to confirm this condition.

I have a spare, non-cased, ECS P5GX-M motherboard I can trace those pins on, but not until the fall. I'm generally not doing any hobby related activities this summer; too many other things going on during the summer.

It might be that they have changed some MSRs registers and they've not updated the VSA. Get the datasheets for both of the chips and look for the audio MSRs if they are the same and at same address.

jtchip wrote on 2024-08-20, 00:26:

I'm not an expert in this but I don't think so. The status bits for the SMM traps are set on the CS5530 south bridge. The CPU in […]
Show full quote

feipoa wrote on 2024-08-19, 23:33:

Could there have been some change between the GXm and GX1 which is preventing proper operation of the MPU-401?

I'm not an expert in this but I don't think so. The status bits for the SMM traps are set on the CS5530 south bridge. The CPU initialisation code in Linux treats the GXm, GXLV, and GX1 identically (apart from their ID). The Linux sound driver actually just identifies it by PCI ID, determines the port/IRQ/DMA configured (by the BIOS), then loads the SB16 driver. Hmm... it has this comment:

Copy code to clipboard

1 * XpressAudio(tm) is used on the Cyrix MediaGX (now NatSemi Geode) systems.
2 * The older version (VSA1) provides fairly good soundblaster emulation
3 * although there are a couple of bugs: large DMA buffers break record,
4 * and the MPU event handling seems suspect.

Perhaps @StefanPutureanu can read the disassembly of VSA1 and work out what's suspect about it 😀

Disassemble the VSA will be helpful but I rather disassemble the entire DOS 6 OS 😁. DOS is very well compiled, every instruction does something useful. BIOS ROMs are very badly written. There is a lot of code that does nothing. Like:
************************************
MOV AX, 0 // set AX to 0
SHL AX, 8 // shift bits in AX to the left 8 times
SHR AX, 8 // shift bits in AX to the right 8 times
CMP AX, 0 // compare if AX is 0
***********************************
This is stupid, it just wastes CPU time, and there are some ROMs that use to obfuscate the code by using the stack to compute the next instruction to be executed. Usually the GUI (BIOS graphic user interface ) ROM does that to be harder to trace where the BIOS password is kept. "Security by obfuscation" is the word for this.
The BIOS in question (ECS-P5GX-M-v1) does this too. It doesn't use normal jumps. Is setting the Stack Pointer register to some offset in the code and then is using the "Return" instruction. (like the code have been called from somewhere) There is no stack available yet, but the Return is actually jumping to the offset in the SP. (Award did this just to mess with people's brains)
Meanwhile I have provided the source code for VSA 2 few posts above. It is not the same but is good for reference.