RayeR wrote on 2025-05-27, 15:38:

>Registers don't just set themselves
Yes, but it's a bit needle in a haystack, don't expect it would be in hidden setup menu but anywhere else in the code...

Amisce looks like the program required

LSS10999 wrote on 2025-05-27, 11:45:

myne wrote on 2025-05-27, 11:35:

Gpio is a safe setting, I assume.

I'm take a quick look at the bios.
Latest version I assume?

Yeah the boards are on the latest versions. I did not see any GPIO related options in BIOS though there may be hidden menus...

Could be barking up the wrong tree, but I assume the registers will be set in a PCH area

1---------- Z97M-PLUS-ASUS-2903.RPT
2|038|PchSpiWrap     |B716A6F8-F3A1-4B8E-8582-5A303F1CDD64|0029B008|00072D|DRVR|
3|045|PchInitDxe     |DE23ACEE-CF55-4FB6-AA77-984AB53DE823|002B1058|008006|DRVR|
4|046|PchSmiDispatcher|B0D6ED53-B844-43F5-BD2F-61095264E77E|002B9060|00275E|DRVR|
5|047|PchReset       |BB1FBD4F-2E30-4793-9BED-74F672BC8FFE|002BB7C0|000F9A|DRVR|
6|049|PchSerialGpio  |FC1B7640-3466-4C06-B1CC-1C935394B5C2|002BD760|0008CC|DRVR|
7|051|PchSmbusDxe    |E052D8A6-224A-4C32-8D37-2E0AE162364D|002BE620|00103B|DRVR|
8|053|PchSpiSmm      |27F4917B-A707-4AAD-9676-26DF168CBF0D|002C0188|001651|DRVR|
9|054|PchSpiRuntime  |C194C6EA-B68C-4981-B64B-9BD271474B20|002C17E0|00167D|DRVR|
10|055|PchSmbusSmm    |59287178-59B2-49CA-BC63-532B12EA2C53|002C2E60|000EEB|DRVR|
11|009|PchSmbusArpDisa|643DF777-F312-42ED-81CC-1B1F57E18AD6|00669480|000DA0|PEIM|
12|024|PchInitPeim    |FD236AE7-0791-48C4-B29E-29BDEEE1A838|0069A740|009980|PEIM|
13|025|PchResetPeim   |FF259F16-18D1-4298-8DD2-BD87FF2894A9|006A40C0|000B22|PEIM|
14|027|PchSpiPeim     |AA652CB9-2D52-4624-9FAE-D4E58B67CA46|006A52B0|00149E|PEIM|
15|028|PchUsb         |6B4FDBD2-47E1-4A09-BA8E-8E041F208B95|006A6750|00059E|PEIM|
16|029|PchInitSmm     |D7B10D4E-67E6-4C74-83E9-F9AF0ACC33CC|006A6CF0|002F4D|DRVR|
17|042|PchMeUma       |8C376010-2400-4D7D-B47B-9D851DF3C9D1|006D4FB0|000ECE|PEIM|
18|009|PchSmbusArpDisa|643DF777-F312-42ED-81CC-1B1F57E18AD6|00769480|000DA0|PEIM|
19|024|PchInitPeim    |FD236AE7-0791-48C4-B29E-29BDEEE1A838|0079A740|009980|PEIM|
20|025|PchResetPeim   |FF259F16-18D1-4298-8DD2-BD87FF2894A9|007A40C0|000B22|PEIM|
21|027|PchSpiPeim     |AA652CB9-2D52-4624-9FAE-D4E58B67CA46|007A52B0|00149E|PEIM|
22|028|PchUsb         |6B4FDBD2-47E1-4A09-BA8E-8E041F208B95|007A6750|00059E|PEIM|
23|029|PchInitSmm     |D7B10D4E-67E6-4C74-83E9-F9AF0ACC33CC|007A6CF0|002F4D|DRVR|
24|042|PchMeUma       |8C376010-2400-4D7D-B47B-9D851DF3C9D1|007D4FB0|000ECE|PEIM|

Possibly init?
Anyone see anything obvious?

Eh, too hard without the board.

if you can dump the registers on pg 463 that should help find it

https://www.intel.com/content/dam/doc/datashe … 7-datasheet.pdf

On my P8B75-M the GPIO_USE_SEL register reads B9FBF9FF on startup. Bit 23 is set. Clearing that bit would make it B97BF9FF.

It seems the adapter does work to some extent. I built this card for testing the ISA communication and it seems with its decoder set to 220h, writing to that port (1 byte for now) from the system does make the card output something. Originally I set it to 80h and nothing went through. Probably because it was configured to forward to PCI, which is being managed by GCS register (3410h, see page 296 of the aforementioned 7-series PCH datasheet) that I haven't figured out how to access/modify it.

Unfortunately at the moment the card's 7-segment output is not working correctly. Maybe the ATF16V8B was not properly programmed (it did show verify OK when programming though I can no longer re-verify as by default I've set lock bit on). But in its current state it's enough to tell whether ISA I/O has gotten through. Maybe I can later on experiment with this card on AMD boards once I get to fix its 7-segment output...
(EDIT2: It appears I have used the wrong type of 8-pin resistor arrays. All the resistor arrays I ordered for this one were bussed, whereas the 8-pin ones should be isolated. Need to look for more info on how to distinguish between isolated and bussed resistor arrays before ordering replacements to avoid making the same mistake...)
(EDIT3: Desoldered the wrong resistor arrays and used 16 1K resistors in their place. The card's 7-segment display is now working correctly and can be used for further tests.)

EDIT: Tried with a 82C929 card using 929INIT tool. After setting the appropriate address ranges the tool can detect the controller but codec initialization failed somehow. Maybe the codec (CS4231) is broken? At least this means ISA itself works but for some reasons ISA PnP isn't working (tested AD1815, YMF718 and ALS007). I wonder if range A00-AFF alone isn't enough for ISA PnP...

Sadly I don't have any non-PnP sound card that's in a good shape to test other ISA stuffs including DMA...

PS: PicoGUS seems to use 1D0-1D2 as control/data ports for configuration.

LSS10999 wrote on 2025-05-28, 07:03:

PS: PicoGUS seems to use 1D0-1D2 as control/data ports for configuration.

Definitely, I found my bat file with sapphisa custom init for picoGUS with 1d0 window. And while pgusinit was okay, no sound still.
I have no SFX/speech in vanilla Doom/LoL/Dune2 until I run fastdoom/duke3d setup and play some sfx (like fdoom13h -timedemo demo1 from autoexec.bat). Only after that SFX will apear in older titles.
Will play switching modes later on: like boot as SB2.0, init in fastoodm, then switch mode to GUS.

Alright. PicoGUS via o.2 adapter okay in ScreamTracker, hangs in doom/fastdoom/duke3d (any DMA and buffer settings, DMA channel 1)
No issues with SB 2.0+Intelligent MPU-401 mode though.

Afaik picogus had older separate FW and then they put all in one. I think that old sb fw doesn't need further sw configure, once I tried on old 386/486DLC playing mp3 files and it worked with just set blaster env.var.

RayeR wrote on 2025-05-28, 12:27:

Afaik picogus had older separate FW and then they put all in one. I think that old sb fw doesn't need further sw configure, once I tried on old 386/486DLC playing mp3 files and it worked with just set blaster env.var.

Yes, 'All in one' FW since 2.0 IIRC. I have FW 2.2 with mode switching on the fly.
GUS mode works only in ScreamTracker. Flawlessly. Excellent sound quality. Hangs everywhere else.
PicoGUS SB 2.0 mode works okay, no init required, just boots and works okay. Not detected by ScreamTracker though, nor automatically, nor via -st1
GUS mode requires explicit init.

LSS10999 wrote on 2025-05-28, 07:03:

Sadly I don't have any non-PnP sound card that's in a good shape to test other ISA stuffs including DMA...

Hit the same issue. 0.2 adapter, Asus Z97M-Plus:
1. sapphisa detects and inits bridge
2. unisound - no cards

I suppose this pin LDRQ1 is not functional at all. The soldering job was done this night. Next steps will be performed:
1. we will check by oscilloscope is there anything on LDRQ1 at all
2. will try non PnP card (I have adlib clone, PicoGUS in SB2.0 mode also fully functional from scratch) to make sure that port forwarding are okay.
if there's no signal in boardview LDRQ1 "exit" pin, we will solder to the IO LDRQ0.

Saw here tool for oscillating GPIO23 (someone detects LDRQ1 in that way), is there version for DOS ?

GPIO23 is shared with LDRQ1 on the ICH7.
You need the datasheet to see what pin and other signals it is shared with on the Z97.
Oh, the boardview I have for Z97M-PLUS 1.04 has it the same. GPIO23/LDRQ1 heading to SR71.

Makes me wonder if GPIO23 is consistent - and therefore possibly enableable on newer chipsets.

Assuming you have definitely soldered as shown, you need whatever software is in this thread to change the register settings to enable it.

rasteri wrote on 2025-05-27, 09:09:

I mean the ISA port pinout rather than the IT8888.

I've attached a (terrible quality) pic showing what I mean - your pinout is on the left, the pinout from wikipedia is on the right.

Unless I've gone mad (entirely possible).

OH you mean footprint. Yeah you're right it's wrong. No wonder why I was going mental about why yours looked so different and why I assumed the IT8888 pinout was wack. THANK YOU! Holy crap, that would have been a massive nightmare to find out later.

myne wrote on 2025-05-27, 09:32:

Oh. Shit. The footprint is probably my fault. The joys of not having the same numbers between footprints. It looks like my footp […]
Show full quote

Oh. Shit. The footprint is probably my fault.
The joys of not having the same numbers between footprints.
It looks like my footprint is 1-49, 50-98 A,B
But dartfrogs was ABCD.
And yes, it also looks backwards.

It's not your fault, it was the footprint from UltraLibrarian that was wrong. https://app.ultralibrarian.com/details/ac68fa … /EBC49DCWN-S420
It's my fault that I did not check the footprint and assumed it was correct. I contacted UltraLibrarian and told them the issue.

Thanks for the updated symbol!

~

Thankfully the prototype card I made was built using the schematic so that is correct as far as I'm aware. I was so terrified for a second the symbol was wrong 🤣. PHEW!

Also 2 layer is definitely possible, huge win on that part!

myne wrote on 2025-05-29, 05:43:

GPIO23 is shared with LDRQ1 on the ICH7.
Makes me wonder if GPIO23 is consistent - and therefore possibly enableable on newer chipsets.
Assuming you have definitely soldered as shown, you need whatever software is in this thread to change the register settings to enable it.

The path is quite complicated, rather than "(un)set the bit":
https://chatgpt.com/share/6837ff21-6c80-8002- … c7-a84f181ebecf

While board is mine, a friend made all soldering and cabling. I'll ask him to send this board to me for further experiments.
I have discussed this issue with my friend and he decided to resolder to the LDRQ0 first, complicated research - later.
I'll return back with results.

chatgpt isn't a reliable source.
This thread is.

Here's Rasteri's software: https://github.com/rasteri/dISAppointment

myne wrote on 2025-05-29, 07:23:

chatgpt isn't a reliable source.
This thread is.

Possibly maybe, setting bit didn't help either for the same Z97M-Plus.
I personally don't care about LPT ECP mode working on this motherboard, this is mostly concept: will LPC2ISA work at all on this mobo.

I don't think LDRQ1# is a requirement for ISA PnP, as DMA isn't involved in the procedure AFAICT. The question, however, is what else might be needed for ISA PnP to function, other than the few registers (such as 279, A79).

In case needed, my "lpcexp" tools is here: https://github.com/lss4/lpcexp
The "lpcisa" (or the identical but verbose "lpcisav") configures all the essential stuffs and will attempt to clear the bit for GPIO23 if found set.

On my B75 board it seems at least port forwarding is okay -- with the ISA POST card's address decoder set to port 220h it does show output when I write something to it.

I think most ASUS boards of that period (6-9 series, maybe later ones also) behave the same way.

LSS10999 wrote on 2025-05-29, 09:49:

I don't think LDRQ1# is a requirement for ISA PnP, as DMA isn't involved in the procedure AFAICT. The question, however, is what […]
Show full quote

I don't think LDRQ1# is a requirement for ISA PnP, as DMA isn't involved in the procedure AFAICT. The question, however, is what else might be needed for ISA PnP to function, other than the few registers (such as 279, A79).

In case needed, my "lpcexp" tools is here: https://github.com/lss4/lpcexp
The "lpcisa" (or the identical but verbose "lpcisav") configures all the essential stuffs and will attempt to clear the bit for GPIO23 if found set.

On my B75 board it seems at least port forwarding is okay -- with the ISA POST card's address decoder set to port 220h it does show output when I write something to it.

I think most ASUS boards of that period (6-9 series, maybe later ones also) behave the same way.

Is it possible some port regions are protected in some way ? This will definitely require some debug card.

Quite interesting unisound /CL output:

Win9x see anything?

myne wrote on 2025-05-29, 13:58:

Win9x see anything?

The board is ~450km away from me.
LDRQ0 didn't help BTW obviously.
We will check next exact ports routing for UNISOUND /CL which does simple PnP devices listing:

1#define CONFIG_ADDRESS 0x279
2#define CONFIG_WRITE_DATA 0xA79
3#define CONFIG_READ_DATA 0x203

UPD1: no luck, the same nothing. It seems that we may write something to port, but can't read or get some garbage (like FF's).
UPD2: ChatGPT narrows issue to motherboard design, where writes can be routed via substractive decoding AND at the same time reads of some regions can be hardwired to the MultiIO. And those ranges can be quite big with possible solution like disable multiio in some way, like disconnect configuration pins (obviously I wouldn't do that).

Lpc is a bus though.

You can't hardwire data selectively to one device and not the other.
Control pins like ldrq are obviously different.

Chatgpt, talking with the confidence of an expert, and the understanding of a parrot.

I'd check the soldering again.

vsharun wrote on 2025-05-29, 16:38:

UPD1: no luck, the same nothing. It seems that we may write something to port, but can't read or get some garbage (like FF's).

If using a POST card I don't think its contents can be read back, though I may be wrong. Writing values to the port does work as the POST card would show what I wrote.

If it's about reading/writing on ports used by the ISA PnP procedure... if the port used for reading doesn't work then it is a problem...

At least with P8B75-M and Z97M-PLUS there's nothing else on the LPC bus, so in theory nothing else should be actively interfering...

On very high end ASUS boards, however, there may be something else (e.g. TPU) on the LPC bus that provides additional controls and sensors, and may get in the way (e.g. getting FFs when reading certain register values from 4E/4F), yet nukeykt's LPC Sound Blaster worked on a Maximus VII Ranger that does have such a TPU, so accesses to other ports like the ones used by sound cards may not being affected if not actually used by the TPU...