deomsh

@bmw I really ment the value you found under XP! Just for the sake of experiment, and see if Windows will do anything with it. Today I had some spare time and liked to test another MS-DOS player, Mplayer, on my ´new´ H61-board. I googled around, but could´t find a download location until I came across this thread. The player inside mplayer_dos.zip is really nice, worked out of the box with CWSDPMI.EXE. I played my favourite testfile DRUMLOOP.WAV. But also a Youtube-MP4! Nice sound and good video. First the audio lagged behind, but after loading SMARTDRV everything was okay. In case you want to continue: here is the link to April 12, 2019. You can use CWSDPMI.EXE from JUDAS21C. Just unzip mplayer_dos.zip in some folder and copy CWSDPMI.EXE in the same folder were MPlAYER.EXE resides. Only for use in Real mode! https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware/?do=findComment&comment=1162272

@MisutaaUrufu Before I will try to answer your questions, please provide following information first: 1) What version of Parallels for mac you're using? 2) Is there a PCI-Card with yellow exclamation mark in Device Manager of Windows 95 OSR2.5? If it's there, is the Memory Address F0140000? And: no IRQ-conflict?

@bmw Just for the record: I assume pcipatchB=$3C10 did nothing? Was the new value reflected in INTELHDA.EXE? Which IRQ was reported by Device Manager for the High Definition Audio Controller in that case? Regarding USB audio: never used one. On MSFN "cheap $3" devices are mentioned, but @Ruthan reported one as "crap". I came across CMI6206 cards (only from China) for about $20.

@sweaterfish I assume you've tried pcipatchB=$7900 already together with HDAICOUT.HDA (Step 4)?

@jaclaz Today I did some more tests to find out which bytes of header+GUID of a LNK-file gives trouble with Grub4DOS. During this experiment I came across lzma! First I will describe the experiment, than I will give the print-screens. Prerequisite are 17 files in the range 4-20 bytes, I named them to their amount of bytes, with extension LNK. Most easy on a FAT-volume with fat mkfile. With write I wrote (without raw!) the 'right' amount amount of bytes of the header+GUID of a LNK-file to each file, always one less. It appeared that the gzip-error popped up only during writing 20 and 19 bytes. From the 18 bytes file down to the 13 bytes file, no writing problem, but with debug on there was a warning: Grub4Dos switched to raw, because of detection of lzma-data which couldn't be decompressed. From the 12 bytes file down to the 4 bytes file NO warning. Afterwards I'd try to read all files with cat --hex (without raw too): same problem with the 20 and 19 bytes files, like in my previous post about this subject. Same warning (with debug on) as during writing in case of the 18 bytes file down to the 13 bytes file. From the 12 bytes file down to the 4 bytes files no warning too (to fit on the print-screen I switched debug off earlier). the issue must be *somewhere* here: https://github.com/chenall/grub4dos/blob/master/stage2/dec_lzma.c It seems (to me) that the file format has not any fixed signature bytes: https://svn.python.org/projects/external/xz-5.0.3/doc/lzma-file-format.txt http://fileformats.archiveteam.org/wiki/LZMA_Alone so it is a mis-detection of some kind. I will try to read your sources, but I (almost) never cared about file-headers, so I have not so much to say about this subject for now. I have red the post, I hope someone will respond - on your post on the vol-command & label still no comments (when I have finished FATMKDEV.G4B, a generalization of my earlier RD2HD-files, I will report in that thread if I found new issues).

@Wunderbar98 I am very happy with your contribution, I am looking now for a way to use two quotes only in case of spaces in PATH1/FILE1, instead in all individual parts containing spaces. In FATCOPY.G4B version 0.3 (forthcoming!) using only two spaces gives undesirable results: the whole root of DEVICE1 is copied, I am afraid with the /s-switch things will be even worse. I have to anticipate too how potential users (if any) will try to use the command-line. If FATCOPY.G4B is ready, I will move on with FATMKDIR.G4B, FATDEL.G4B (both FAT-only) and FATLSDIR.G4B (for all file-systems supported by Grub4Dos). During my holiday this summer I made the first versions on my smartphone with Limbo Android/X86 (I had no PC around). I am not sure if FATREN.G4B is really worthwhile, but the Grub4Dos-program FAT gives the interesting possibility to move a file to another directory. With my batchfile-approach this could be generalized to all files in directory, or groups of files using "*"-wildcards. So very difficult to resist such a project (for me ). By the way, do you know a tool to make EXT3, EXT4 and ReiserFS partitions inside Virtual Box 6.0 on a VHD? So far I succeeded only with EXT2, and (unexpected) with Reiser2FS after I installed Suse 8.2 from an old DVD.

@bmw Well done! Indeed, last two digits of W21 are the one-byte value of 8-bits register 42h. Earlier you said you tried all values I gave you. To be sure try pcipatchB=$4200 once again. Your observations regarding last two digits of W21 are interesting, but I do not know what to do with this register. Should be Register 3Ch. The SB600 documentation call´s this register "Interrupt Line", a 8 bits RW register (so Read/Write!). The text is cryptic:"This register is used to communicate to software the interrupt line that the interrupt controller is connected to. It is not used by the HD Audio controller". I have no idea´s about this register (I am not a PCI-device programmer, even worse: I am not a programmer at all ). But feel free to try several IRQ-values with pcipatchB. You can also use INTELHDA.EXE to change the value on the fly by typing in new values (Only in RW-registers of course). Al values in HEX (register-address is in hex already)! If there is no immediate change regarding output of HDA2.DLL, maybe it´s following is a good procedure: boot Windows with HDA2.DLL active, change with INTELHDA.EXE a register value you like, Reboot to MS-DOS => Exit to restart Windows 98SE (like sweaterfish did) and look if anything changed in HDALOG.TXT. Also watch the IRQ-value of the High Definition Controller in Device Manager. I hope this will give any results, otherwise I think it´s better to look for another solution like USB-audio.

I am sorry I didn't make myself clear. I need a hex dump of the registers of 1002:4383. Should look like the PCI-tab of INTELHDA.EXE, but in a bit different fashion. You will have used the program pci32.exe. You have to run from a command-prompt following command: [PATH]\pci32 -D > ATIDUMP.TXT (not case-sensitive) I do not know where you unzipped the download. Say if you choosed location C:\PCISNIF than the command will be C:\PCISNIF\pci32 -D > ATIDUMP.TXT Below is the original information from my chipset, the dump is the second part (made in 2017 with an old MS-DOS version while using new PCIDEVS.TXT). Bus 0 (PCI), Device Number 20, Device Function 2 Vendor 1002h ATI Technologies Inc Device 4383h IXP SB600 High Definition Audio Controller Command 0006h (Memory Access, BusMaster) Status 0410h (Has Capabilities List, Slow Timing) Revision 00h, Header Type 00h, Bus Latency 20h Self test 00h (Self test not supported) Cache line size 64 Bytes (16 DWords) PCI Class Multimedia, type Unknown! Subsystem ID 76621849h Unknown Subsystem Vendor 1849h ASRock Inc Address 0 is a Memory Address (anywhere in 64-bit space) : FBFF4000h System IRQ 10, INT# A New Capabilities List Present: Power Management Capability Supports power state D1 Current Power State : D0 (Device operational, no power saving) Hex-Dump of device configuration space follows: 0000 02 10 83 43 06 00 10 04 00 00 03 04 10 20 00 00 ..ƒC......... .. 0010 04 40 FF FB 00 00 00 00 00 00 00 00 00 00 00 00 .@ÿû............ 0020 00 00 00 00 00 00 00 00 00 00 00 00 49 18 62 76 ............I.bv 0030 00 00 00 00 50 00 00 00 00 00 00 00 0A 01 00 00 ....P........... 0040 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................ 0050 01 00 42 C8 00 00 00 00 00 00 00 00 00 00 00 00 ..BÈ............ 0060 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 ..€............. 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ The first part is like the report you delivered. The program 'translates' the hexadecimal values with help of the database. But we need the hexadecimal values, to see if I can find any potential pcipatchB.

@jaclaz Thanks for the clarification of the blocklist command. I tried cat --hex --length=16 (hd2,0)284918+1 but no difference. See picture below, lines 2 and 3. In a file with the header of 4 bytes there was no problem reading with cat --hex. The next 16 bytes are the GUID according to https://github.com/libyal/liblnk/blob/master/documentation/Windows Shortcut File (LNK) format.asciidoc Here lies the problem, when I wrote the first 20 bytes to a 20 byte file with write : same problem as before. But when I tried this a second time to make a printscreen, I got Error 71 Attempt to write a gzip file. See picture below. The raw command seems to solve all problems, even with dd - I never used raw before. See second picture. First 3 lines to produce the file 20bytes.lnk, with header+GUID form a Windows Shortcut File. The later lines are for the dd-test, without and with raw. So you seems to be right that there is a connection with Grub4Dos treatment of gzip.

Thanks, point taken. I will make a new attempt. I tested on FAT and FAT32 so far, but NTFS gives the same results. Can you tell something more about the blocklist command please? The backslash is always provided by ls before a space, in my experience. I did some new test on NTFS, without spaces in Path/File and using TAB-autocompletion. I used two renamed IrfanView-lnk files, one from Windows 98SE, one from Windows 10 64-bit. Same strange output with cat --hex with different length´s. No difference. If I change first four bytes as you suggested, other bytes are looking fully normal now. For comparison I added the same amount of Lister´s HEX-views of the original files. @Wunderbar98 thanks for your comment. In Grub4Dos qoutes are taken, but starting only AFTER the first backslash. Combined PATH/FILE between qoutes is still a usefull hint, because I am working on a LFN-module to copy LFN´s in /PATH1/FILE1 to SFN´s in /PATH2/FILE2. I have made you nice picture of the possibilities. By the way, I found "read" case-sensitivity only on Linux file-systems I have tested. Further I have red that UDF should be case-sensitive too.

@sweaterfish Great idea to remove the modem, with surprising results. A big step forward in my opinion. It's good to know thats Codec Index gives indeed the status only, I have no boards with a HDA-Modem combination. Next you can try pcipatchB=$7900. The first digits of register W3C/w1 should be zero afterwards. I have been succesfull with this patch on a H61 board with (roughly) the same HDA controller registers. Leave the widgets on $03!

@bmw I am sorry to hear that. Dead end? Maybe. By the way, if you comment out wavehda=HDA2.DLL in SYSTEM.INI and start INTELHDA.EXE, is the widgets-tab giving non-zero $-values if you click the buttons? About Windows XP: can you provide the HDA controller register from inside XP? There are 32-bit versions of PCI-sniffer from Craig. Maybe this one: http://www.seascapesailing.com/tools/PCI n PCI32 sniff/

@bmw The last two digits of register W20/w2 are the content of register 42h. Possible values are: 00 up to 07 (8 possibilities). I thougt you have tested all values already? The first to digits of W1E/w1 should be read-only register 3Dh, only reflects the value of last two digits set in W22/w1. That register is writable and should be register 44h. According to the AMD SB600 BIOS Developer's Guide (page 22) the IRQ routing can be set with 44h. As far as I understand this subject their are 8 possibilities. Since we have seen 00 and 01 already, you can try pcipatchB with values $4402 up to $4407. Always reboot in between and watch HDALOG.TXT for non-zero responses.

@bmw That's sad, but yes please a new screenshot, at least I can compare them. @sweaterfish In the first line of the logs you can see AD1984 is detected too. I don't know why the driver switches to the Modem (14f1:2bfa is actually a named Thinkpad modem). Is there any change in HDALOG.TXT if you set in your Modem-version of HDACFG.INI (HDAcfg.001.txt), Codec Index=$0 , reboot and leave the Modem ON ?

@bmw Thanks, I assume picture was taken with pcipatchB=$4207 ? (W20/w2 last two digits = register 42h or 66 decimal starting with register 0). Next I want you to repeat the procedure described in my post from April 9, 2019. But before disable HDA2.DLL with a semicolon in SYSTEM.INI: [drivers] ;;wavehda=HDA2.DLL (I allways use two semicolon's). I hope Judas will provide sound, so we can compare the settings of the HDA controller register.

@bmw I assume you ment setting Verbinterface=$0 ? In your HDACFG.INI the setting was Verbinterface=$1 already. Move on with $1. Next try pcipatchB=$4207 (I've been deducting that value from a Linux source). Also I like to see a printscreen of the PCI register of your HDA controller. For details how to get it, see my post of April 8, 2019 in this thread (Steps 1-3).

@bmw Good you found the codec, but that info is only usefull if the codec responds to HDA2.DLL. HPET isn't used, and should do no harm (at least not on the systems I have tested). There is a good Wikipedia article on this subject. Next you can try higher wait-time settings, say $500. Further pcipatchB=$4200, or $4201 or $4204. Also try Verbinterface=$0 (and in all combinations with the higher wait-timings and pcipatchB). In the mean time I will look in Linux sources if other SB600 chipset registers are mentioned (so called PCI-Quirks). My Asrock 960GM-GS3 has a SB600 HD-Audio Controller too, is working without HDAICOUT.HDA (but Watler gave me instructions for the main parts of the troubleshooting).

@Dave-H The two (semi-universal) versions of HDAICOUT.HDA I mentioned both sent (after an intitial Codec Reset) six SET-verbs to ALL widgets in range 02-1F (30 widgets). Widgets listen only to verbs they are programmed for (and must conform to Intel's High Definition Audio Specification), otherwise verbs are neglected. So those versions are not codec-specific. True is: your system needed HDAICOUT.HDA, doesn't work out-of-the-box without.

@Dave-H Hello Dave-H, good to hear HDA2.DLL is still working on your system. No stability issues? With all respect I doubt that your system needs a specific version of HDAICOUT.HDA in case of digital playback. My general version Hdaicout.hda.200 (April 29, 2019) gives the same SET-verbs as the first version I made for your system (Dave-H_Hdaicout.hda.200). Using analog inputs is a different thing - allways codec (brand)-specific.

@sweaterfish Good to know, but you can allways leave! HDACFG.INI should be longer without HDAICOUT.HDA, more like the one of @bmw HDA2.DLL communicates with a codec through the HD-Audio controller. HDAICOUT.HDA can provide GET-verbs (non-zero response in HDAICIN.TXT), or SET-verbs (allways zero's as response). Max. about 200 verbs. Good! Better don't use that driver together with HDA2.DLL Only for testing purposes. If we succeed, you can use VBEMP again, if MS-DOS is needed, in real mode or in DOS-box you can allways temporary disable HDA2.DLL in SYSTEM.INI with a semicolon before wavehda=HDA2.DLL I have the following steps in mind: 1) Tackle Thinkpad X61 hardware related issues. 2) Configuring HD-Audio controller register with pcipatchB in HDACFG.INI (and wait-timings or different Verbinterface if needed) 3) Retest Widget-settings in HDACFG.INI 4) Testing my general version of HDAICOUT.HDA (allready somewhere in this thread) 5) Writing a hardware specific HDAICOUT.HDA if needed Regarding Step 1: remove or rename HDACFG.INI and HDAICOUT.HDA, reboot and enter your BIOS-Setup. Go to Config => Power and disable all power-saving setting. Further look if your model has a Modem. According to Linux sources the Modem should be ON ("they share a bus" was said). Regarding Step 2: boot Windows and save HDACFG.INI as HDACFG.000, same for HDALOG.TXT. Then start INTELHDA.EXE and make a full printscreen of the HDA PCI-register. See for details my post of April 8, 2019 in this thread. Next Reboot to MS-DOS/Exit to Windows and provide HDACFG.001, HDALOG.001 and a second printscreen of the HDA PCI-register. Then upload your four files and the two printscreens.

@bmw Thanks for the Southbridge info, the graphics isn't important - as you thought allready. It's clear from your log's that the codec isn't identified. All reponses to the GET-verbs starting with 001F are zero's. Step 1) Can't find info about your Wyse Thin Client, but if you have a BIOS-Setup please remove all Power Saving settings (if any). If your device has a Modem: activate if found switched off. Step 2) Please try first higher values of wait1 and wait2, let's say: wait1=$250 wait2=$250 Step 3) If the codec still gives no response, maintain the higher wait-timings and add: pcipatchB=$4202 (details are in the SB600 Register Reference Manual page 230, Register 42h). After each new setting allways a full reboot is needed.

Steve said me to raise an Issue, I did in July, but still no comments. I ran into another strange issue while testing FATCOPY.G4B version 0.3 All copying is good, except Windows' LNK-files, gives "FAT Error: (1) A hard error occured in the low level disk I/O layer". I tried to read LNK-files with cat --hex /FILE with many versions of Grub4Dos. Only grub4dos-0.4.5b-2012-01-16 behaves as expected, all other version tested NOT: grub4dos-0.4.5c-2014-01-17 grub4dos-0.4.5c-2016-02-26 grub4dos-0.4.6a-2017-08-30 grub4dos-0.4.6a-2017-12-05 grub4dos-0.4.6a-2019-05-12 grub4dos-0.4.6a-2020-01-12 Since FAT 15/02/2015 didn't work with Grub4Dos 0.4.5, I can't downgrade my project! Some screenshots of my (dutch) Windows Verkenner.lnk (=Windows Explorer.lnk) All LNK-files tested gives some sort of weird behavior, some I took from my Windows 10 installation too.

@bmw I will need full specs of the chipset. Good, no installation problems as such. SBx00 Azalia (Intel HDA) will be the HD-audio controller, not the HD-audio codec. Best upload your HDACFG.INI and HDALOG.TXT after booting, but without HDAICOUT.HDA so I can take a look.

First thing is true: the BIOS sets his Defaults in all hardware-related registers. Those values can conflict with what a driver expects. ACPI BIOS should not be a problem as such. So no difference with, or without HDAICOUT.HDA in the Windows-directory? What do you mean? What is your PC speaker doing in Windows 98SE: beeping or giving actual sound? This is a known problem, but can be related to the specific video driver too. Wat driver do you use for your X3100, VBemp? In case of testing Windows' Standard VGA (PCI) driver is the best choice. I did already some reading of chipset registers and of Linux-sources related to codec AD1984. I have a full set of steps in mind to troubleshoot HDA2.DLL on your Thinkpad X61, but pleas make up your mind if you are ready to run tests for (maybe) many hours. Please let me know.

@sweaterfish Nice you have taken interest in Watlers Win3x HDA-driver and trying to use it in Windows 98SE. I will try to support your Quest! Many desktops will run out of the box, especially the one with Realtek codecs, but success depends on the HD-Audio controller too, used by the specific chipset. Which steps are needed is not always to say beforehand. Once I had the idea to make a list of 'all' codes with their values for SleepingWidget=$.. & VolumeWidget=$.. & OutputWidget=$.. but without a community of testers I think it´s a waste of time. You´ve already done a great deal of work on your Thinkpad X61 - no installation problems, great! Once HDACFG.INI is set, following values can be changed (apart form setting [busmaster]-values): Mytimer= values 1 (default) or 0; Mytimer=0 needs HDARUN.EXE to produce sound (not needed in your case, as Sound recorder is playing) Verbinterface= $1 (default) or $0; two different ways to communicate with the codec through the HD-Audio controller wait1= value $100 is default; can be set higher if sending verbs to the codec needs more time wait2= value $100 is default; can be set higher if receiving verbs from the codec needs more time pcipatchB=$0000; changes ONE register of the HD-Audio controller PCI-register - up to $FFFF (changing register 100h is NOT possible) SleepingWidget= value $02 (default); powers up one widget, can be needed on Laptops VolumeWidget= value $14 (default); set the widget number that will set Volume - can be a DAC, a Mixer or even a PIN-widget OutputWidget= value $02 (default); set the widget that will receive Digital Audio from the HDA-link and convert to Analog Audio (DAC) - SP/DIF sends Digital Audio to output, not of interest for us. The three widgets are the most important settings. In that case their are more Audio Devices in the system, like modems or audio for HDTV. In that case their CODEC Index will show a higher value than $0 (cannot be set as far as I know) In case of reading a datasheet the most important part to start is the widget Function Block Diagram. The AD1984 gives this on page 1, but their numbers/interconnections in Table 5 on page 16! So read them together. Best is to try the simple stereo-channel, so DAC-0 => Mixer => Port A. Table 5 tells the DAC-0 is widget 03, connected to Mixer 07, connected to PIN-complex 11. According to Parameters on page 5, the DAC´s have output volumes, the Analog Mixers only input volumes. So I guess best to try is: SleepingWidget=$03 VolumeWidget=$03 (otherwise $07 but not likely) OutputWidget=$03 To use INTELHDA.EXE first study Intel´s High Definition Audio Specification http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf Chapter 2 and Chapter 7 both in depth (and a quick reading of Chapter 4 to have a global understanding of the difference between the two interfaces CORB and Immediate Command). I have never heard of this, can be some problem with the HD-Audio controller. First let´s neglect this and try the suggested HDACFG.INI settings and use "Restart in MS-DOS mode", in this stage please without HDAICOUT.HDA. Listen with Headphones if you hear the slightest tick´s or click´s during all bootup stages. Please report back and upload HDALOG.TXT and the version of HDACFG.INI after returing from MS-DOS mode.