deomsh

Tested latest version WDMHDA.022 on Windows 98 FE with ACPI. According to the logs CORB/RIRB interface is working. Further same as earlier regarding Disable&Enable driver. Further no troubles, just tested Mute on main output: not working on my Codec VT_1705. I added two logs while playing. Wdmhda.022_N68_VT1705_WIN98FE_ACPI_DirectX_7.0_DUT.zip Added: logs with Windows 98 SE. Although looking all the same after Disable&Enable regarding changed Memory Address of hda.sys, MID&RMI are still working! WIN98SE_NO_ACPI_DX_9.0c_Wdmhda.022.zip

Stands FE for First Edition?

Still Mapped to 0xF0020000, but read is no longer 0xBDF7 but seems to be normal (to me) after forced install of ACPI and Q233017. It's all in the latest log's.

I had a long conversation with Google AI on this, could possibly be noise in combination with timing/ chipset/ WIN98FE issues. The probabilities in the statistics of the LLM predicted things will become better if I used ACPI on WIN98FE. After a longer process this was really the case for Wave. Only MIDI is not working anymore after Disabling/ Enabling hda.sys. Interesting are the Read-outs of WPCREDIT ('Idea' from Google AI). Some comments are above my level, maybe you can use it. I also tried 'Low' DMA (set to max 16MB), but no difference. More clear for me now. This would be VERY nice, in the past I tried VDMSound with Watler's HDA2.DLL, but Prince of Persia 1 never played me Midi. Not from your driver, or do have you plans to rename to hda2.dll? This was an inactive registry entry mentioned in DxDiag report: 20 43 61 72 64 20 6E 61 6D 65 3A 20 B0 03 0D 0A 20 20 20 20 44 72 69 76 65 72 3A 20 48 44 41 32 2E 64 6C 6C 0D 0A 0D 0A Card name: ° Driver: HDA2.dll I removed the inactive entry before current tests. WIN98FE_ACPI_DX7.0_DUT_WDMHDA_021.zip Google AI on STATESTS and ACPI with WDMHDA.021 on WIN98FE.ZIP BTW conversation is mainly in Dutch, I asked my AI-Agent to translate to American English. Dutch readers can (try to) read both versions. If someone cannot read md-files, just use Total Commander (No-nag-shareware) with the md-Lister Plugin. Note on 'Google AI': still now and then hallucinating, but if asked if 'something' is 'true' or so, the LLM is correcting earlier statements. Seems things are becoming a little bit better.

Without Audio driver: no error if running DxDiag (empty log). I tested with DirectX 8.0 and DirectX 8.1 both. Only difference found: DirectX 8.0 gives no blue screen, general HResult error only. No problems with Playback or Volume noticed. I found no special WDM-related updates in case of Windows 98FE. The two you mentioned before won't install on Windows 98FE. WIN98FE_Wdmhda.021_DX5.1_DX8.0a_DX8.1a.zip Edit: after initial problems I succeeded to install DirectX 7.0a on Windows 98FE. Everything is, or seems to be fine! BTW DxDiag_WDMHDA.txt doesn't log tests as OK, but ALL tests on both DirectSound and DirectMusic where good! However, no Kernel mode mentioned with DirectMusic? WIN98FE_WDMHDA.021_DX7.0a.zip

As such Volume Control initiliazed without problems during install and worked for me (WinPlay3 has no volume slider). Good idea, I will try to test. But to me it seems DirectX related, not there in the N68 log's with the original DirectX 5 on that board (as far as I can see). I will try to install higher DirectX versions one by one on the N68 installation, to see if there is a version-relation. Or is your driver not supposed to support Windows 98 FE? In that case my testing makes no sense. Just thought it could be of some use to you. Personally I was interested to see if your Headphone polling was working with HDAWDM.021

I tested v021 on my three boards. All Windows 98 First Edition (I am currently working on Windows 98 FE for other reasons). On ACER I can see switching my Headphones-jack from Back to Front is logged (see the log of playing mp3 with WINPLAY3). On two boards DirectX 9.0c was installed, seems to have issues, but I am not sure currently if I must use a lower version on Windows 98 FE. BTW on all three boards resetting hda.sys with Device Manager was not possible: Yellow Exclamation Mark. I logged those trials too (except on N68). Wdmhda.021_WIN98FE_N68&VT1705_SB600&ALC662_C200&ALC662.zip

Interesting, noted. I looked into the thread of @Dave-H but two times no issue in case of ALC272 ( @Danielx and @isolar ) . At least not in case of HDA2.DLL. Not fully sure if Verbinterface=$1 in both cases.

A new version of Watler's Win3x HDA-driver already: HDADRV9Q Download from: https://watlersfiles.netlify.app/ New: software volume; possible to set volumewidgetmax in HDACFG.INI, section Volume (default is $007F007F); four HDA-controllers added with auto-setting of pcipatchB; pcipatchB should be supported in HDAICOUT.HDA too; Export of functions sglinf, setbvalue and strlog (API).

Something strange with your link: gives on Firefox 'https://github.com/andrew-hoffman/WDM' - so a (nice) 404. I copied the link with context-menu and pasted here to show. Not a big deal, because the shown 'text' is correct.

Thanks, now I understand on how you are using the phrase "polling". BTW my boards Front Panel is not connected, I always use the green connection at the back.

Congratulations, your WDMHDA v21.a is working now on my N68-board with codec VT1705. Also Master Volume is working. I made two set's of log's, one without Jack inserted (Fallback Playback-path is okay) and one with Jack inserted. I can not find a meaningfull difference in the log's in this respect. Is this logged somewhere? WDMHDA.21a.N68_VT1705.WIN982.zip BTW I added a log from a tool Isolar is working on currently, so you can see the Jack is really inserted in PIN-widget 1Ch.

Tested on Windows 98 SE (DirectX 9.0c), no difference in performance, everything as reported earlier. To me the two logs produced seems to be almost equal as with version WDMHDA.020. WDMHDA.20a.N68_VT1705.zip

As said, I am not a programmer - sorry my AI-agent has been wasting your time. He also said he could rewrite your code, I had 'only' to do the compilation myself. With my earlier experiences with AI modifying existing bootcode fresh in mind, I thought I would make you no competition But my N68/VT1705 is always ready for testing.

Was just adding search machine-info while you posted, see above. Same phrase: site:msfn.org 2026

Maybe I was too not looking good enough (my eyes are already aging), but I checked again. It's in the title only. Same on Edge (on my Smartphone too - Edge only there): BTW I used Brave (brave.com) with Private Search and inside Firefox/ Edge, so not their browser.

I do understand THAT already. To be sure I made myself clear: on Brave only the two mentioned gave Thai results (without filtering on dates). This I do NOT understand (lack of skills ).

Personally I am happy with msfn. AND: it's still Sunday, maybe don't expect too much from the people who keep msfn running. I did some new tests with following string (NO quotes): site:msfn.org 2026 BOTH Google and Bing give the full Thai-connection. Images seems to be max 2 days old according to Bing (Google gives no images ??). Today this one is my favourite: It may be useful if members from other zones than North-West Europe check for themselves and report too (unsure if they should ask for a refund - isn't this a gift to help msfn staying alive? ). I checked Mojeek and Brave too. Only on Brave I could filter on specific date (very nice, better than the Big Two). After 23 march there are no results anymore on Brave. Both seem to give normal results, EXCEPT on Brave the following TWO (checked all six pages with search results): 1) msfn.org/board 2) msfn.org/board/index.php

I continued my conversation with Copilote, with following question: "In an earlier conversation today (on another browser) Copilot said Bing was still indexing msfn.org. Was this an error, or is it possible the AI-engine was so called 'hallucinating'?" The answer was interesting (at least to me, probably not to AstroSkipper ). Cited small part of Copilot's answer only: "The earlier answer you saw was not you imagining things — it was almost certainly a case of the AI giving an overconfident but incorrect statement. In other words: yes, that was a hallucination, and I can explain exactly why it happens in this specific situation. 🎯 Short, direct answer Bing used to index MSFN normally, but it no longer indexes new MSFN content reliably. If another Copilot instance told you “Bing is still indexing MSFN,” that was incorrect — a classic AI hallucination caused by outdated assumptions about how search engines behave. (......) Bing is still returning MSFN pages, but it is not indexing new pages beyond ~2025. (....)."

Because bing.com seems to behave differently from Google, I couldn't resist to have a small a conversation with Copilot on bing.com. See the attachment. Copilot on Google-indexing changes.md

Holland here (with Firefox 151.0.2 on Windows 10 64-bits): Google AI is aware of existence of msfn.org, but give NO links to msfn.org, which is strange. Searching with site:msfn.org "Windows XP": Bing.com gives results with "MSFN" "Windows XP" (NOT with "MSFN Windows XP" - which is a BAD search-phrase anyway): And with site:msfn.org "Windows XP":

Hello @Drew Hoffman I did long testing of VT1705 on my N68 board with WDMHDA Alpha-020 (returned to Windows 98SE - for other reasons). I studied codec.cpp on your behalf, but I couldn't find anything special. With help of Google AI I managed to use DebugView. To me it seems the problem is on the HDA-controller/ Driver level. See complete documentation in VT1705.zip below. I let my AI-agent analyse the log's from DebugView, seems to corroborate my idea. Today I asked my AI-agent to analyze your source code too. I had the luminous idea to ask for comparision with source code of HDADRVO11 (latest, published version - has absolutely no problems with my system). During the testing phase of this version Watler produced eleven versions. Because he is rather sparse with words (I believe I am not) I used my AI-agent to analyse changes. Everything runs in a (virtual) VSCode directory in Ubuntu, so my AI-agent from ai.pi studies earlier analysis/ log's/ code too). AI's analysis (GLM5 if I remember well) of WDMHDA Alpha-020 seems to make (some) sense to me, but in my language we say: "Een kinderhand is gauw gevuld" (in English probably: "Small things please little minds"). Maybe you can use the result of AI's analysis. VT1705 on N68 with WDMHDA.020 - source code compared with HDADRV9O11 .md VT1705.ZIP

Here you go, but as said: unspecific (Fatal Exception 0E) I will try to understand codec.cpp (as a non-programmer). But there is some sound on lowest volume level of mplayer2, only heavily distorted and 'transposed' one er more octaves lower - listening with Headphones (all reported earlier).

Although latest update WDMHDA Alpha-020 is probably not ment for VIA-codecs, I couldn't resist testing while working on Windows 98 FE installations. Same problems as reported earlier (N86/VT1705). DxDiag: after ignoring the warning there was a problem with Sound I got a non-specific Blue Screen with some problem on 0028:00000009 (non-fatal). Not sure if DxDiag was used earlier this way.

Watler provided a new version of his Win3x HDA-driver: HDADRV9O Download from: https://cute-crisp-779a84.netlify.app/index.html Highlights: After first boot CODEC_Index can be set manually in HDACFG.INI: useful in case of HDA-modems or HDMI-codec 'giving' wrong Codec index; HDAICOUT.HDA can have many more lines than earlier max of 256; HDAICOUT.HDA is extended with some scripting commands: jump/ label, conditional jump/ label for PCI-devices, conditional jump/ label with GET-verb and Response (so possible to send GET-/ SET-verbs for a specific HDA-controller or HDA-codec, even a specific sub-version). Also VolumeWidget can be set (IF working it should override VolumeWidget setting in HDACFG.INI); Example with free code to make your own extensions using new exported function(s) of HDA2.DLL (mytest.exe).