deomsh

Working on Windows 95 OSR1a too. Really nice @ABCDEFG :

@ABCDEFG before running the fix I only had to adapt XNVFIX.BAT to my Program Files drive-letter. XnView v2.13 seems to run out of the box on a clean system, without SH95UPD: @cov3rt about posting images: above image is a slightly cut 1920x1200 print-screen, pasted into Irfanview and saved as *.png and then drag-and-drop into the post. This one has filesize of 78KB, even less is possible with png.

I have seen the list of exports of SH95UPD during search. My phrase 'continue' and mentioning an older version of KernelEx was more ment as a (maybe possible?) 'direction'. I am not a programmer, so I have no real idea if patching other Windows 95 dll's, like SH95UPD is doing in case of SHELL32.DLL, is possible.

Thanks for clarification @SweetLow I tried one last time running MTRR_RST.EXE inside Windows on this board, but this time without HDA2.DLL loaded. My idea was if this was possible, I maybe could activate HDA2.DLL during restart from command-line. I got a nice MS-Error Dialog while running MTRR_RST.EXE inside Windows, I believe Runtime Error 103, but saving print-screen failed because of crash. I will look if I can prepare one of my C200-boards. The only I posses that needs pcipatchB=$7900, so maybe a candidate for further testing. No problem, thanks a lot. Earlier I couldn't find this Datasheet. The NoSnoop bit is indeed present, at the usual offset on Intel-chipset's. WPCREDIT is quite old. But I mentioned Craig Hart's PCI32 Tool because textual dump's should be easier to compare. But it does not seem of use for now, at least if your reboot-problem has been solved? Funny move But seriously: errors can be quite productive. Maybe try Foobar in case of Audio files, some versions can play 32-bits audio files with 16-bits output. I did some tests on my system with the stopwatch my youngest son lent me almost 9 years ago, but no measurable lagging in this case (as far I can see): Did you try stabilizing measures mentioned in this thread? I am unsure about this, did you compare with the Controller Chapters' in Intel's High Definition Audio Specification? I have no detailed knowledge of these things, if you want me study it, I will try. But will take a few weeks... Good, also the 'somehow nice HDA2-intro' while playing music should have something to do with this. Although I was told 'normal' drivers simply muted the analog audio-stream until the buffer(s) are filled up. I wasn't aware of other values than $0 or $1. Can you please tell a bit more about this subject?

You are fully right @ABCDEFG However with KernelEx 4.5.2, I installed temporarily on my non-XMS Ramdrive-Windows 98SE installation, original XnView v2.13 with WebP is working 'out of the box': So maybe you can continue with SH95UPD? During searching for this tool, I found out SH95UPD is based on an older version of KernelEx: v0.3.2a. I am not sure if I ever used SH95UPD before.

@cov3rt I can't find any file with the link: BTW if you want to to post a screenshot: simply paste in your post. @ABCDEFG I looked into the dependencies of WEBP.DLL in Plugin-directory of xnview v2.13, I found two missing in my version of KERNEL32.DLL:

I am willing to test, so please provide such a sample webp file, or a link where i can find one. Better also a screenshot of what I have to expect.

Sure, I was not able to install latest version of SHELL32 DLL, coming with IE 4.01 (if I am right about 4.01), because of installation issues of IE4 on my non-XMS ramdrive. But in print-screen in post of @ABCDEFG you can see he should have a later version. Simply copying that version of SHELL32.DLL to %winbootdir%\SYSTEM as a workaround is not possible, Windows is not starting anymore in that case. In the print-screen I copied in the missing dependency BEFORE if got things working with SH95UPD (you should be aware of SH95UPD, because of your contributions in that thread on MSFN, although years ago). So xnview 2.13 is running on my system with patched SHELL32.DLL v.4.00.1111. As you can see in the Dependency Walker part of the print-screen, the earlier missing export is added to my version of SHELL32.DLL. Missing export was originally only showed AFTER using the xnview v2.13 mod of @ABCDEFG , but not anymore with patched SHELL32.DLL.

I tried with CPUSPD v2.0a, but first I got, while Desktop was still empty a blue screen with 'Fatal error OE at 0177:BFF8976B'. After pressing a button Windows loaded normally and seemed to work. Indeed everything quite slow, only copying files seemed to be normal speed. But MPlayer2 gave 'Error=80040256' - no working audio hardware. If I was going back to the command-line, everything was fine after enabling cache again with 'CPUSPD ce' and starting Windows. If I remember well I got these type of blue screens in the past (also with some SB-Live PCI drivers) - no chance to get sound afterwards. If I run the DOS_RM version of MTRR_RST.EXE from the command-line I couldn't start Windows with WIN, sent back on the command-line immediately. As a last test I thought it would be nice to enable the NoSnoop bit inside Windows with WPCREDIT and then try to run the Win9x version of MTRR_RST.EXE. So I first set value of SB600's HDA-Controller Register at 42h from 0x2 to 0x4: very loud hum from my headphones (if set back to 0x2 everything is fine). But running MTRR_RST.EXE with 42h at 0x4 gave HDA2's famous Runtime error 202, which is quite a heavy crash.

I will look into it (and on your site, if I remember well you have some tools or more info there). But: is what you just described possible too with WPCREDIT and then saving these settings to some reg-file?

Can you describe the test you run in more detail, if on the 'user side' something is possible?

Happy to hear, lucky you After I responded to your post, my idea's where going in such a direction too.

These are two unrelated problems in my humble opinion. If you agree, let's first try to address the chipset with the NoSnoop bit set: if I am right this is the one with HDA-Controller 8086:0F04. Are you sure about the datasheet, or am I wrong? I have no opinions about NoSnoop as such: this is far above my level, members like @Drew Hoffman and especially @SweetLow should be able to comment on this. Through the years I did some preliminary investigations in PCI-mechanisms, if I remember well NoSnoop has something to do with use of the processor cache (?). First I looked in this thread for the phrase 'cold', indeed there are a few posts regarding differences of boot-behavior. In my (fully empirical) taxonomy I have: 1) Fully cold boot, after shutdown unplugged the power cable, then the power button pressed to unload capacitors/ emptying buffers and waiting at least two minutes before plugging the power cable back and booting; 2) Normal cold boot; 3) Hard reset, only possible if a reset-switch is available. Better not used from inside Windows, but safe if rebooted to MS-DOS command-line first; 4) Warm reboot with Ctrl+Alt+Delete from MS-DOS command-line; 5) Same from inside Windows, should be considered as safe. I your case I'd like to add: 6) Restart Windows after Exit to MS-DOS and restart Windows with 'WIN' (only ONE time loaded again - so two WIN's visible with 'MEM /a/c/p' afterwards in a MS-DOS Windows inside Windows); 7) Restart Windows after Exit to MS-DOS and restart Windows with 'Exit'. In my imagination you can try these Options 1-7, but in reverse order. Checking with headphones the Microsoft Starting sound, a small sound file with MPlayer2 of CD-equality, then a big one and in the end your last file (you didn't mention if this one was 'CD-quality = 44.1 kHz or 48 kHz?). Better write down everything. You also can try playing a fully empty WAV-file before, length ONE minute. They should be here or there on the web. In the past I did some experiments in this direction if Watler's driver crashed during playing a soundfile or if restarted not played as it was supposed to be. As a second pass I would suggest a PRECISE searching inside the HDA-Controller Registers with WPCREDIT (in 8-bits view) for differences. If you find nothing, then other registers mentioned in your chipset's datasheet which are 'looking' DMA-related. I am afraid there are too many... Maybe you can use Craig Hart's PCI32 tool to dump registers: https://www.majorgeeks.com/files/details/pci32.html . Then comparing the text-files with some tool. BTW better use a more recent pcidevs.txt, like this one: http://rh-software.com/index_pci.html I 'did' PCI-dump almost nine years ago for the last time, maybe you will have to try a bit to get it working... In my idea you are supposed to be able to be handle this sort of things. But if not, or you run into some problem, I will of course search and experiment on my system to provide as much assistance as possible. ; ------------------------------------------ P.S. hopefully you will get some idea's after the 'first pass', avoiding the 'second pass' - which will probably bring 'nothing'. I would bet the problem has something to do with not fully emptying the DMA buffer (1 MB?), so maybe the problem is withing *some* HDA2-mechanism. But this is just a non-educated guess.

Hi @ABCDEFG very nice job! Although it took me a long time to surpass next missing export (no IE4 on my system, and installation on my non-XMS Ramdrive gave problems). But in the end I succeeded with help of SH95UPD, version 007:

Thanks for the info. If you have used RLoew's SATAPTCH to patch your version of ESDI_506.PDR you should be 'good'. Otherwise better use original/ updated ESDI_506.PDR and patch again from command-line. About Setup: I assume you run Setup from MS-DOS command-line, so Setup is the using the Dos drivers, until Windows 'takes over'. If your Hard drive is SATA too, check if your CD-drivers are mentioned in CONFIG.SYS/ AUTOEXEC.BAT, with REM before is okay, even better. Sometimes Win9x needs these names as a 'hint' to 'find' a CD-ROM, even they are not loaded. Especially MSCDEX shouldn't be loaded before starting Windows of course.

Please be specific: which RLoew drivers, mention filenames.

Found this one archived: https://web.archive.org/web/20230506001046/https://kernelex.sourceforge.net/mediawiki/index.php?title=Category:Compatible_applications&redirect=no And: https://web.archive.org/web/20221206050710/https://kernelex.sourceforge.net/wiki/VLC_Media_Player

There are good topics on MSFN: https://msfn.org/board/topic/152471-kernelex-apps-compatibility-list-new/ Don't forget https://msfn.org/board/topic/105936-last-versions-of-software-for-windows-98se/ , https://en.namu.wiki/w/KernelEX and https://retrosystemsrevival.blogspot.com/p/list-of-working-windows-98me-kernelex.html?m=1 . There used to be a wiki from Schwups, can't find it anymore?

Maybe of use to you the print-screen of xnview v1.90 RC3, same as IPF in xnview v1.90.1: If you need the last part too: just ask, my RLoew non-XMS ramdrive installation is still available on my small USB-drive.

I will look into it, will take some time. Yesterday a project I am working at seemed to be going well, but later I discovered an error in my mod of grldr bootcode - so a drawback....

Not yet, but I tested today: v1.90 beta 1, beta 2 and beta 3 asked for STI.DLL, not part of Windows 95 as far as I can see (Imaging). But if I copied the three STIxx.DLL's I found somewhere to the xnview directory, xnview started normally. v1.90 beta 4 and beta 6 started without asking for STI.DLL, same for RC1 and RC2. But RC3 gave Invalid Page Fault in KERNEL32.DLL, like final v1.90 as reported earlier.

WOW, you are realy the new HDA2-San How did you 'get' the right Line-out Pin-Widget? Once you have established this, I can understand finding the Playback-path is possible with your Widget-parser. In my Excel-notes I had to make a - hopefully (more or less) educated - guess, if no experimental results were available. And even IF available, wiring of Ports of a Codec Integrated Circuit is still a choice of the Manufaturer, although some Datasheet's give (preferred) default Ports... Lately I searched Intel's High Definition Audio Specification during traffic, because this was one of your earlier questions I still didn't adress so far. I found following interesting statement in Section 7.3.3.7: 'Gain is a 7-bit “step” value specifying the amplifier gain, the actual dB value of which is determined by the “StepSize,” “Offset,” and “NumSteps” fields of the Output Amplifier Capabilities parameter for a given amplifier. After codec reset, this “Gain” field must default to the “Offset” value, meaning that all amplifiers, by default, are configured to 0 dB gain. If a value outside the amplifier‟s range is set, the results are undetermined.' I am not saying your mod is 'not good' or something like that! I was just wondering if above could be the case on your available codec's? Because you are the only one with a real IDT-codec in this thread so far (I found IDT bought three Audio-lines from STAC in 2006), could you provide one of your BIG HDAICOUT.HDA => HDAICIN.TXT's? So I can compare with the Datasheet. This would be quite nice. Because of my current projects I am constantly switching my headphones between computers. The (Realtek-driver) Dialog on Windows 10 is realy annoying: 'Which Device you just plugged in?'. Although Headphones are suggested, this is still a mess in my personal opinion: we live in 2026, not 2006, even no sound if a choice is not made (but maybe sound in full screen?)... Of course this doesn't apply to HDA2. On the other hand, if auto-switching give any problems a nice Delphi Dialog-screen in Windows 10' Realtek-driver style will be not so bad. There are many. Without any special order of preference: 1) Enabling Audio-CD input, if loopback is available. Personally I like analog CD-Audio more than digital. Especially useful if the CD/ DVD drive has no separate headphones-jack. I don't know how to find out which Port should be used. Once I made an example as a surprise to Dave-H, based on the Datasheet. Can be eanbled in HDAICOUT.HDA - see https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware-testing-thread/page/9/#findComment-1162932 2) Inserting a database of HDA-controllers. Currently there is always the same one showed (from Dave-H's system, April 7 2019 in this thread): Once I delivered my GENHDA16.INF, made a long time ago, modified after Watler criticized initial versions: https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware-testing-thread/#findComment-1161697 Earlier I started HDAWIN16.INF to include specific HDA-Controllers for read-out in Device Manager. I never published this version on MSFN, there doesn't seem to be any demand. I can't remember if I realy finished the INF-file, at least it worked on my - at that time two - available systems. Below the idea, maybe you can use the values, if you want to work on this part: ;; HDAWIN16.INF ;; 2017/12/30 ;; "Watlers World" 16-bit High Definition Audio Driver ;; Win3x/Win9x only ;; (c) Copyright 2017 Deomsh (...) [Manufacturer] %GEN%=GEN.Mfg %ATI%=ATI.Mfg %AMD1%=AMD1.Mfg %SIS%=SIS.Mfg %NVAMD%=NVAMD.Mfg %ULI%=ULI.Mfg %VIA%=VIA.Mfg ;%RDCS%=RDCS.Mfg ;%Teradici%=Teradici.Mfg %INTEL%=INTEL.Mfg [GEN.Mfg] %GEN_HDA.DeviceDesc%=HDA2,PCI\CC_0403 [ATI.Mfg] %ATI_SB450_HDA.DeviceDesc%=HDA2,PCI\VEN_1002&DEV_437B ;%ATI_SB600_HDA.DeviceDesc%=HDA2.Install,PCI\VEN_1002&DEV_4383 %ATI_SB600_HDA.DeviceDesc%=HDA2,PCI\VEN_1002&DEV_4383 %ATI_RS600_HDA.DeviceDesc%=HDA2,PCI\VEN_1002&DEV_793B %ATI_RS690_HDA.DeviceDesc%=HDA2,PCI\VEN_1002&DEV_7919 [AMD1.Mfg] ;%AMD_HDA_768/8111.DeviceDesc%=HDA2,PCI\VEN_1022&DEV_7445 ; AC97 (HDA unknown) %AMD_HDA_17h.DeviceDesc%=HDA2,PCI\VEN_1022&DEV_1457 [SIS.Mfg] %SIS_966_HDA.DeviceDesc%=HDA2,PCI\VEN_1039&DEV_7502 [NVAMD.Mfg] %NFORCE_HDA_MCP51.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_026C %NFORCE_HDA_MCP55.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_0371 %NFORCE_HDA_MCP61a.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_03E4 %NFORCE_HDA_MCP61b.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_03F0 %NFORCE_HDA_MCP65a.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_044A %NFORCE_HDA_MCP65b.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_044B %NFORCE_HDA_MCP67a.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_055C %NFORCE_HDA_MCP67b.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_055D %NFORCE_HDA_MCP72/78.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_0774 ;%NFORCE_HDA_MCP78b.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_0775 ; unknown ;%NFORCE_HDA_MCP78c.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_0776 ; unknown ;%NFORCE_HDA_MCP78d.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_0777 ; unknown %NFORCE_HDA_GF108.DeviceDesc%=HDA2,PCI\VEN_10DE&DEV_0BEA [ULI.Mfg] %ULI_HDA.DeviceDesc%=HDA2,PCI\VEN_10B9&DEV_5461 [VIA.Mfg] %VIA_VT82xx_HDA.DeviceDesc%=HDA2,PCI\VEN_1106&DEV_3288 [RDCS.Mfg] ;%RDCS_HDA.DeviceDesc%=HDA2,PCI\VEN_17f3&DEV_ ; DEV is unkown! [Teradici.Mfg] ;%Teradici.DeviceDesc%=HDA2,PCI\VEN_6549&DEV_1200 ; TERA1200 PC-over-IP Host [INTEL.Mfg] %C200_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_1C20 %C600_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_1D20 %C126_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_1E20 %ICH6_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_2668 %ESB_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_269A %ICH7_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_27D8 %ICH8_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_284B %ICH9_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_293E %ICH10a_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_3A3E %ICH10b_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_3A6E %3400_HDA.DeviceDesc%=HDA2,PCI\VEN_8086&DEV_3B56 (...) [Strings] (...) GEN = "Generic" ATI = "ATI Technologies Inc" ;AMD1 = "Advanced Micro Devices Inc." SIS = "Silicon Integrated Systems" NVAMD = "NVIDIA Corporation" ULI = "ULi Electronics Inc." VIA = "VIA Technologies, Inc." RDCS = "RDC Semiconductor, Inc." Teradici= "Teradici Corp." INTEL= "INTEL Corporation" GEN_HDA.DeviceDesc = "High Definition Audio Controller" ATI_SB450_HDA.DeviceDesc = "ATI SB450 HD-Audio Controller" ATI_SB600_HDA.DeviceDesc = "ATI SB600 HD-Audio Controller" ATI_RS600_HDA.DeviceDesc = "ATI RS600 HD-Audio Controller" ATI_RS690_HDA.DeviceDesc = "ATI RS690 HD-Audio Controller" ;AMD_HDA_768/8111.DeviceDesc = "AMD 768/8111 AC97 Controller" AMD_HDA_17h.DeviceDesc = "AMD 17h HD-Audio Controller" SIS_966_HDA.DeviceDesc = "SIS 966 HD-Audio Controller" NFORCE_HDA_MCP51.DeviceDesc = "NFORCE MCP51 HD-Audio Controller" NFORCE_HDA_MCP55.DeviceDesc = "NFORCE MCP55 HD-Audio Controller" NFORCE_HDA_MCP61a.DeviceDesc = "NFORCE MCP61a HD-Audio Controller" NFORCE_HDA_MCP61b.DeviceDesc = "NFORCE MCP61b HD-Audio Controller" NFORCE_HDA_MCP65a.DeviceDesc = "NFORCE MCP65a HD-Audio Controller" NFORCE_HDA_MCP65b.DeviceDesc = "NFORCE MCP65b HD-Audio Controller" NFORCE_HDA_MCP67a.DeviceDesc = "NFORCE MCP67a HD-Audio Controller" NFORCE_HDA_MCP67b.DeviceDesc = "NFORCE MCP67b HD-Audio Controller" NFORCE_HDA_MCP72/78.DeviceDesc = "NFORCE MCP78a HD-Audio Controller" ;NFORCE_HDA_MCP78b.DeviceDesc = "NFORCE MCP78b HD-Audio Controller" ;NFORCE_HDA_MCP78c.DeviceDesc = "NFORCE MCP78c HD-Audio Controller" ;NFORCE_HDA_MCP78d.DeviceDesc = "NFORCE MCP78d HD-Audio Controller" NFORCE_HDA_GF108.DeviceDesc = "NFORCE F108 HD-Audio Controller" ULI_HDA.DeviceDesc = "ULI HD-Audio Controller" VIA_VT82xx_HDA.DeviceDesc = "VIA VT82xx HD-Audio Controller" ;RDCS_HDA.DeviceDesc = "RDCS HD-Audio Controller" ;Teradici.DeviceDesc = "Teradici HD-Audio Controller" ; ?? C200_HDA.DeviceDesc = "INTEL C200 HD-Audio Controller" C600_HDA.DeviceDesc = "INTEL C600 HD-Audio Controller" C126_HDA.DeviceDesc = "INTEL C126 HD-Audio Controller" ICH6_HDA.DeviceDesc = "INTEL ICH6 HD-Audio Controller" ICH7_HDA.DeviceDesc = "INTEL ICH7 HD-Audio Controller" ESB_HDA.DeviceDesc = "INTEL ESB HD-Audio Controller" ICH8_HDA.DeviceDesc = "INTEL ICH8 HD-Audio Controller" ICH9_HDA.DeviceDesc = "INTEL ICH9 HD-Audio Controller" ICH10a_HDA.DeviceDesc = "INTEL ICH10r HD-Audio Controller" ICH10b_HDA.DeviceDesc = "INTEL ICH10 HD-Audio Controller" 3400_HDA.DeviceDesc = "INTEL 3400 HD-Audio Controller" (...) 3) Adressing stability issues of HDA2.DLL on Windows 9x. You never reported any, as far as I remember. Are your three systems FULLY stable? 4) Making a better version of WAVEOUT.EXE, without the annoying hickup's while moving the volume-sliders. Also a more logarithmic scale would be nice. My personal prefence would be to have ONE Volume slider, and another one for Balance, like in 'Options' of Windows 98' Mplayer2. 5) If available: making the Volume Knob Widget working. I never 'saw' one, will be most useful on laptops, I presume. My only avaiIable laptop is from work, but even using cmd as non-administrator is blocked for me, not to mention booting from an USB drive. 6) Enabling Vendor Specific Widgets. If you want to try, I can assist searching on the Internet in Linux- and other forum's. 7) Last but not least: full compliance to Intel's High Definition Audio Specification. Earlier I delivered a Report, made by pi (I believe at that time GLM 4.5). Although it is 'only' AI, can still be useful as suggestions for testing/ developing hypotheses. I think there is more, but can not remember currently. P.S. This morning I remembered the most important: 8) Make a setting in HDACFG.INI to force Codec index. For instance: 'Force Index=$0/1/2'.

Alpha-018.1 just tested on Asrock N68C-S UCC with HDA Controller 10DE:03F0 and codec 1106:4397 (i.e. VT1705) & Windows 98SE. Same problems as reported earlier.

Because I can't stand if 'things' are not working, I first checked the missing Export KERNEL32.DLL:InterlockedCompareExchange. It seems it is NOT available on Windows 95. Then I went down: highest version working on my installation is xnview v1.82.4. Version 1.90/ 1.90.1 and 1.90.2 didn't work: Invalid Page Faults in KERNEL32.DLL.

That's sad. Do you want to proceed with this driver, or are you finished? On the other hand there is WDMHDA in development of @Drew Hoffman(Windows 98 SE).