vsharun wrote on 2025-06-03, 08:24:

In my case 200fc 300fc 1d 0f was enough for pgusinit and scream tracker. Also I may confirm scream tracker does not require any […]
Show full quote

In my case 200fc 300fc 1d 0f was enough for pgusinit and scream tracker.
Also I may confirm scream tracker does not require any DMA, coz it plays perfectly without LDRQ line connected. With LDRQ line connected on Asrock - scream tracker okay - everything else - loooooong init and no sound.

I sent my whole bunch of Asus Z87/Z97 boards for soldering LDRQ1, may you please check

Copy code to clipboard

1sudo lspci -vvv | grep -A20 'I/O ports'

on your Asus board, maybe important ports claimed by some other PCI device(s) - this may explain why we see no ISA PnP working.
This also may further explain why you may not bother for LPC whole range 300 FC decode, because important ports (VGA you mention earlier) are decoded earlier on PCIe.

I haven't checked Scream Tracker yet. The GUS mode itself works, just for some reasons it cannot detect any RAM and I don't think the soldering was the problem after inspecting with a magnifier. I even replaced the SPI PSRAM chip with another one yet the problem persists.
From what I can tell through the schematics the PSRAM only had connection with the Pico's GPIO pins that are being used for SPI, yet I'm not sure if there's a way to test the status of the communication between the Pico and PSRAM (as well as the PSRAM's integrity) without going through GUS protocols...

On the other hand, SB mode (and FM) works perfectly fine on that system when I tested it with DIGPAK's SETD/SETM.

LSS10999 wrote on 2025-06-03, 08:47:

On the other hand, SB mode (and FM) works perfectly fine on that system when I tested it with DIGPAK's SETD/SETM.

You'll lack of stereo SFX, coz SB dsp 2.0 only. Polpo said there's SB16 quite easy to implement in PicoGUS HW but still no FW with it. I found some ESS1688's for quite attractive prices locally - ESS1868 -ish but nonPnP, with sb pro 3.01 DSP by default.
Scream Tracker uses GUS memory for instruments - you may check is it work for you this way.

vsharun wrote on 2025-06-03, 09:06:

Scream Tracker uses GUS memory for instruments - you may check is it work for you this way.

Does Scream Tracker require ULTRAMID beforehand?

Right now the card can't detect any valid amount of RAM in GUS mode, and ULTRAMID refused to load because of this. The system will hang (or cause JEMM Invalid Opcode) if launched ULTRAMID a second time.

I don't think the problem is with the PSRAM as I inspected the soldering and couldn't find any problem, and even replacing it with another one doesn't fix.

Considering the card worked in SB mode in my case I think both IRQ and DMA are working as expected.

vsharun wrote on 2025-06-03, 09:06:

Polpo said there's SB16 quite easy to implement in PicoGUS HW but still no FW with it.

Not sure if this means the card will have to become physically longer (16-bit slot) to accommodate high DMA.

I think at best SBPro and OPL3 should be implemented eventually as things evolve, and this can be done while still physically being a 8-bit card (HKZLab's ES1868/1869 card is a good example).

LSS10999 wrote on 2025-06-03, 11:58:

Does Scream Tracker require ULTRAMID beforehand?

Nay.

LSS10999 wrote on 2025-06-03, 11:58:

vsharun wrote on 2025-06-03, 09:06:

Polpo said there's SB16 quite easy to implement in PicoGUS HW but still no FW with it.

Not sure if this means the card will have to become physically longer (16-bit slot) to accommodate high DMA.

I think at best SBPro and OPL3 should be implemented eventually as things evolve, and this can be done while still physically being a 8-bit card (HKZLab's ES1868/1869 card is a good example).

Not sure, how many DOS games has 16 bit samples ? Most 8 bit or less IIRC. Duke3d and Doom both 8bit for sure.
About SB16 in PicoGUS - it was something about DSP IIRC, which is less compatible with SB Pro, but easier to implement (or implemented in DOSBox).

Nope. Scream Tracker cannot detect my card at all while in GUS mode. I'm using v2.2.0 firmware.

Setting the card to any other port than 240 in GUS mode (e.g. 220) would make GUSDRAM and ULTRAMID not detect the card even after changing the ULTRASND environment variable to reflect to the newly set values.

I don't have a spare Pico to test for ruling out whether my current Pico board has any flaw...

Again, the card works perfectly fine in SB mode as I tested a few games with it, so certainly the LDRQ1# I brought out on my P8B75-M worked as expected after setting up (including clearing the bit for GPIO23 to restore LDRQ1# functionality).

LSS10999 wrote on 2025-06-03, 16:17:

Again, the card works perfectly fine in SB mode as I tested a few games with it, so certainly the LDRQ1# I brought out on my P8B75-M worked as expected after setting up (including clearing the bit for GPIO23 to restore LDRQ1# functionality).

Glad to hear. What configuration register (may you please share HOWTO) where you switch GPIO23 -> LDRQ1 functionality ? I suppose some setpci thing ?

vsharun wrote on 2025-06-03, 16:50:

Glad to hear. What configuration register (may you please share HOWTO) where you switch GPIO23 -> LDRQ1 functionality ? I suppose some setpci thing ?

The GPIO configuration register is in its own address space, but you'll need to read a few PCI configuration registers to get the info about where it is.

Read the content of register 48h of the LPC controller (D31:F0). Notice the bits other than bit 0, which determines the base address of the GPIO configuration register.

On my boards this register reads 0x501 means GPIO configuration space starts at 0x500. As such, this creates a problem with using WSS. Interestingly, tools like AIDA16 will incorrectly believe that WSS is present because of the GPIO configuration space. Haven't tested whether this space can be moved elsewhere if a WSS card is to be used (or simply use another common address than 0x530 for WSS if possible).

(NB: Similarly there was another configuration space for ACPI registers, which can be found in register 40h. On my boards that configuration space resides in 0x400 range.)

After getting the base address of GPIO configuration space, read 4 bytes from the port at the base address (e.g. 0x500). Each bit corresponds to a GPIO so you need to pay attention to bit 23. If it's set, it means LDRQ1# is being used as GPIO and you need to clear that particular bit.

The code I'm using to check the LDRQ1# state is here. It checks the output of the GPIO_USE_SEL register and will try to clear GPIO23 bit if found set.

Some caveats:
- My code currently simply tries to enable the GPIO configuration space if not enabled (by register 4Ch). However, it's completely possible for register 48h to be 0x0 in this circumstance which can lead to issues. You can always manually read and alter the relevant configuration registers before doing the init. Since I don't have a board on which this is the case, I'm not sure whether a manually defined GPIO configuration space will work for modifying the GPIO_USE_SEL register.
- On newer PCHs, the bit 0 of register 4Ch indicates whether the GPIO configuration registers are locked. In that case you cannot make any change to GPIO configuration registers, as it's designed to only allow SMM code to do so in this state. This bit is not in use in earlier chipsets (e.g. ICH7), though.

LSS10999 wrote on 2025-06-03, 17:24:

- On newer PCHs, the bit 0 of register 4Ch indicates whether the GPIO configuration registers are locked. In that case you cannot make any change to GPIO configuration registers, as it's designed to only allow SMM code to do so in this state. This bit is not in use in earlier chipsets (e.g. ICH7), though.

Ou, nasty feature registry locking. I read some years ago about something similar regs that protects reading SMI region or flashrom... Then it would need to modify the BIOS/UEFI to skip locking the register.
BTW my tool SMB http://rayer.g6.cz/programm/programe.htm#SMB supports also simple interactive debug mode for PCI and IO also with simple scripting (via /dbg scriptfile) like this one:
http://rayer.g6.cz/programm/smbdemo.txt

LSS10999 wrote on 2025-06-03, 17:24:

.... indicates whether the GPIO configuration registers are locked.

I suppose Asus wouldn't do that in Z87/Z97 series. Coz success story with LPCSB and Maximus VII Gene where LDRQ1 was programmed as GPIO.
Anyway will check it out in few weeks when I get back my boards LDRQ1 soldered to the TPM and cables done.
I'll return back with more nomenclature working out of the box/tweaking rqrd/tweaking possible at all/issues. For Asus boards 7-8-9 series I suppose ISA PnP init ports decoded in some way to somewhere and only non PnP cards are suitable. Like PicoGUS in SB mode.
UPD: I also have P5Q where unisound detects the card, no sound though, because of GPIO23.

vsharun wrote on 2025-06-04, 07:02:

I suppose Asus wouldn't do that in Z87/Z97 series. Coz success story with LPCSB and Maximus VII Gene where LDRQ1 was programmed […]
Show full quote

I suppose Asus wouldn't do that in Z87/Z97 series. Coz success story with LPCSB and Maximus VII Gene where LDRQ1 was programmed as GPIO.
Anyway will check it out in few weeks when I get back my boards LDRQ1 soldered to the TPM and cables done.
I'll return back with more nomenclature working out of the box/tweaking rqrd/tweaking possible at all/issues. For Asus boards 7-8-9 series I suppose ISA PnP init ports decoded in some way to somewhere and only non PnP cards are suitable. Like PicoGUS in SB mode.
UPD: I also have P5Q where unisound detects the card, no sound though, because of GPIO23.

So far on ASUS boards LDRQ1# is configured as GPIO23 but not locked, so it can be changed back.

GPIO configuration lock bit is only something on newer PCHs. Haven't checked when exactly the lock bit was introduced but at least ICH7 datasheet lists that bit as "reserved".

LSS10999 wrote on 2025-06-03, 17:24:

The code I'm using to check the LDRQ1# state is here. It checks the output of the GPIO_USE_SEL register and will try to clear GPIO23 bit if found set.

May you please do release on github or on vogonsdrivers (publish binaries) ?
I have no clue (and not me only) with compiling things. But 30+ years in using command line utilities.

vsharun wrote on 2025-06-04, 10:15:

May you please do release on github or on vogonsdrivers (publish binaries) ?
I have no clue (and not me only) with compiling things. But 30+ years in using command line utilities.

Here. I think I should have done that earlier.

I'm using Arch Linux and the Makefile was tailored in a way that you can just run "make" after installing openwatcom-v2 from AUR to get the binaries.

LSS10999 wrote on 2025-06-04, 11:18:

I'm using Arch Linux and the Makefile was tailored in a way that you can just run "make" after installing openwatcom-v2 from AUR to get the binaries.

Thanks. Challenge accepted and done: made both OpenWatcom2 (from openwatcom.org, includes important wcl binary) for your toolkit and djgpp (for sapphisa.c) both working/compiling under WSL2 linux64
https://github.com/andrewwutw/build-djgpp/releases
^^^ this djgpp accepts binary format 0b... -ish prefixes (unlike vanilla djgpp with gcc 3 which is not, see attached erorr), required for sapphisa.c to be built. While change 0b to 0x format and use old gcc the binary is 83kb instead of 183kb by the latest djgpp (oh, newer djgpp includes i586-pc-msdosdjgpp-strip which makes it 86kb, pretty).
$ ../djgpp/bin/i586-pc-msdosdjgpp-gcc --version
i586-pc-msdosdjgpp-gcc (GCC) 12.2.0
I expect bunch of Asus boards with soldered LDRQ1 will arrive this weekend: Gryphon Z87, Z97M-Plus, P5Q, Z87-C.
WIll return back with findings which ISA PnP port blocked: I have soldered IOW# line B13 on ISA slot and will take a look by oscilloscope is spamming these ports are coming thru the bridge.

Hm, that prefix 0b seems it was added quite recently to C23 standard but it was implemented in gcc probably since 2008. I personally wouldn't use this and rather rewrite it as 0x hexa constant to be more portable to older compilers.
To reduce binary EXE size you should:
1) compile with -Os
2) strip -s your.exe
3) upx -9 your.exe (upx is the ultimate executable packer, opensource...)
this should result in 50-60kB for a simple cmdline utility that use just libc...

I took out my AMD test environment (ASUS B450M-A) again, and did some test with the ISA POST card I previously assembled and noticed these things:
- 4E/4Fh (the LPC-ISA bridge itself) can't be accessed regardless of the bit controlling it. The board did set it to enabled by default, though.
- 220h, 330h and 388h can be written as long as the bits responsible for decoding those I/O ranges are enabled. Those addresses do not require Wide I/O and my "lpcisa" will try enable as many addresses as possible.
- 1D0h (for PicoGUS) needs a normal (512-byte) Wide I/O range to work. Originally tried setting it as an alternative (16-byte) I/O range but it didn't work.
- Unfortunately sound cards (non-PnP ones that I can use for testing) can't be detected at all at the moment. Not even PicoGUS. Can't be certain yet, as the adapter I'm using for testing right now appears to have a loose ISA connector so I'll have to fix it, or just build another one... it was my very first v0.2 assembly and I had some mistakes back then, like the orientation of LEDs for negative volt rails...
- Considering this is also an ASUS board it's unlikely that ISA PnP cards would work. The ISA POST Card only supports 10-bit decoding (so up to 3FF).

Note: AM4 CPUs only have one LDRQ# signal (LDRQ0#) instead of two as in older CPUs/chipsets. Some ASUS boards (such as the B450M-A) seem to use a smaller, stripped down SuperIO chip (IT8655E) that does not take LDRQ# so LDRQ0# is easily accessible. On other boards that use normal SuperIO chips, in many cases they first route it to a (likely unpopulated) pull-up resistor (to +3V) then to the SuperIO (or first to the SuperIO then a likely-unpopulated resistor to +3V). In this case, one can access the LDRQ0# from the resistor pad, but the SuperIO can always access that LDRQ# signal if desired which can cause issues... Not to mention there are also boards which wired LDRQ0# directly to SuperIO without anything in between.

LSS10999 wrote on Yesterday, 14:47:

I took out my AMD test environment (ASUS B450M-A) again, and did some test with the ISA POST card I previously assembled and not […]
Show full quote

I took out my AMD test environment (ASUS B450M-A) again, and did some test with the ISA POST card I previously assembled and noticed these things:
- 4E/4Fh (the LPC-ISA bridge itself) can't be accessed regardless of the bit controlling it. The board did set it to enabled by default, though.
- 220h, 330h and 388h can be written as long as the bits responsible for decoding those I/O ranges are enabled. Those addresses do not require Wide I/O and my "lpcisa" will try enable as many addresses as possible.
- 1D0h (for PicoGUS) needs a normal (512-byte) Wide I/O range to work. Originally tried setting it as an alternative (16-byte) I/O range but it didn't work.
- Unfortunately sound cards (non-PnP ones that I can use for testing) can't be detected at all at the moment. Not even PicoGUS.

Quite interesting, MSI has B450 Tomahawk Max people throwing away here "Like new in box" with LDRQ0 populated to the resistor and 14pin TPM.
Have you tried Doom in Adlib music mode ?

vsharun wrote on Yesterday, 16:08:

Quite interesting, MSI has B450 Tomahawk Max people throwing away here "Like new in box" with LDRQ0 populated to the resistor and 14pin TPM.
Have you tried Doom in Adlib music mode ?

Sorry but no cards currently works at the moment. PGUSINIT cannot detect my card, and SETD/SETM cannot detect anything even with an actual non-PnP SB16.

I need to fix the adapter for the loose ISA connector issue, or build another one if nothing improves.

At least I could confirm these I/O ports do appear to work there, just you cannot probe the status of the LPC bridge itself since ports 4E/4F are never accessible for some reasons.