Jump to content

MisutaaUrufu

Member
  • Posts

    3
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by MisutaaUrufu

  1. 5 hours ago, deomsh said:

    @MisutaaUrufu

    MS-DOS has no quirks, 'PCI_quirks' are used in Linux-code to have a defined name for a PCI related problem. In case of HD-audio controllers quirks are for instance related to the so called "No Snoop"-mechanism.

    Did you try the version in Mplayer_dos.zip too?

    Besides: none of the four MS-DOS players I tested gave sound in Virtual Box 6.0 (Judas21c, Judas21d and two versions of Mplayer mentioned in this thread).

    I meant "quirks" as in the behavior was odd and unexpected; I didn't mean it in the technical sense, my apologies.

    I didn't try mplayer, no, but considering you mention that none of them gave sound through DOS in Virtual Box, I imagine the same would go here as well.

    5 hours ago, deomsh said:

    @MisutaaUrufu

    HDAICOUT.HDA is ment to sent specific verbs if the standard verbs sent by the driver (HDA2.DLL) fails.

    As you can see in HDACFG.INI your Codec isn't identified yet. CODEC_VID=$1AB8 CODEC_DID=$0001 is not a known HDA-codec. Maybe a modem? Unless the codec is correctly identified, nothing can be done. In the first attachment of your later post the codec is identified as VendorID=6840 DeviceID=1. Still unknown to me, maybe a fake id. for Parallel's Virtual HDA-codec.

    Although HDA2.DLL is ment for Win.3x only, it's tested on Windows 98SE and Windows ME, I can't remember if I tested Windows 95/Windows98FE, but it's is likely to work if their are no Memory/IRQ-conflicts.

    That is the correct codec, as far as I can tell.. Vendor ID 1AB8 is identified as Parallels Desktop, and their other simulated hardware devices follow a similar convention. Likewise, changing the codec value gets reset on next boot by the TSR anyhow (it's blocked out with Fs before the driver is loaded by Windows). There is no "modem" attached to the virtual machine; only a simulated PCIe ethernet card (a Realtek model).

    The parallels log file for the virtual machine indicates that the HDA device is being activated, but that the VM is making an invalid read at an incorrect address. — If I let it run for too long it'll actually build up a hefty log file just filled with the "invalid read" lines. (It reached 9GB at one point. 9GB of just that one line.) — I'm thinking this may be concerned with HDAICOUT and the widget addresses in HDA configuration.

    The odd thing is the number output in the INI by HDAUtil for the Subsystem ID is different than the one populated in the HDA configuration by the TSR. But changing it has no effect as the TSR resets the value on boot.

    5 hours ago, deomsh said:

    @MisutaaUrufu

    Can you provide a link to the download page? In the past I used a 32 bits program, only compatible with Windows 7. I need it to open the xml-attachment in your other post.

    I can do you one better. Seeing as the download page had to be accessed in convoluted fashion via the wayback machine on the internet archive, I took the liberty of uploading the installer directly to the archive itself for ease of access:

    Microsoft High Definition Audio Utility 64-bit : Internet Archive

    5 hours ago, deomsh said:

    @MisutaaUrufu

    I am not an expert either, in my opinion nothing can be done on the codec-level until the codec is correctly identified in HDACFG.INI.

     This means that the so called "Immediate Command" communication-mechanism is not working with HDA2.DLL in combination with your HDA-controller.

    Try timings 1000 or 2000 (milli-second!), but I doubt things will change.

    Settings in pcipatchB will only work if there are RW (Read/Write) registers in your Parallel's VM-HDA-controller PCI-register. I am afraid that's unlikely. I have only tested Virtual Box: their VM-HDA-controller PCI-register is Read-only, so al values are fixed. You can try to write to the registers from Windows with INTELHDA.EXE. Just go to the pci-tab. If you double-click on a register, a dialog will be opened to give new values. If they actually do NOT change, that register is Read-only. You can try all the (four digits) register-entries.

    But first I would suggest to disable temporarily ALL devices, especially Network, except the bare minimum. Be sure in Sound the HDA is selected. Monitor HDALOG.TXT if lines containing F0 give any other response.

    You seem to know a lot more than I do on this particular topic though.

    I will try removing the network card from the VM and see if that has any effect later on, but I highly doubt that will change anything.

    5 hours ago, deomsh said:

    @MisutaaUrufu

    In the User Manual of Parallel 16 I found there is an option for AC'97 too.

    Unfortunately AC'97 support no longer works in Windows 95 on Parallels. They deprecated support for "legacy" systems a few years back, so whilst the VM does simulate an AC'97, it's behavior has changed from how it worked when Windows 95 was an actively supported configuration. They no longer provide sound drivers either (only video). I've tried numerous generic drivers with no luck; they install, and Windows says they work, but no sound is passed to the main OS, and the parallels log just spits out "[pcm_out] reset inside DMA" every once in a while if audio is "playing" in the VM. — This log output is infrequent, compared to the HDA log output.

    This is why I am trying to get the HDA2.dll driver working in the first place. AC'97 support is broken, but I at the very least can confirm that some sort of interaction with the HDA controller is happening (the soft crackle through earbuds/headphones when audio attempts to play). In theory, if I could get the configuration correct, I could get audio out. However, it is sounding as if I may need an entirely custom configuration to communicate with Parallels' implementation of HD Audio.

    Off topic: Ironically, Parallels provides an OS/2 driver for sound. It's just Windows 2000 and earlier they don't provide.

  2. 1 hour ago, deomsh said:

    @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?

    1. Parallels Desktop App Store 1.5.0 (Roughly equivalent to version 15 or 16). — VM is configured as a generic Windows VM rather than a 95 VM (as 95 VM support is deprecated and official audio support no longer exists; Generic Windows Machines allow use of the Intel HD Audio device.)
    2. There is, and the memory address is F0140000 with no IRQ-conflict.

    More notes:

    • Attempted running without HDAICOUT.HDA, as well as with the generic copies hosted here. No luck.
    • Similar to others, codec values in HDACFG.ini are different before and after Windows boots. Mine are all $FFFFFFFF.
    • Setting Verbinterface to $0 prevents the desktop and taskbar from displaying; Windows hangs at my wallpaper, requiring a forced reboot.
    • Changing the timing values to 250+, and setting the pcipatchB to various values, so far, has not worked.
    • Attached are the codec files exported by Microsoft HD Audio Utility (x64) from Windows 10, in INI & XML format.
    • HDALog contains various entries that are all 0s, though roughly 50% of entries have non-zero values.

     

    Update:

    • Attempts to play audio directly in Media Player returns that all audio devices are in use.

    HDA_Codec.ini HDA_Codec.xml

  3. Hey, sorry if I seem unintelligible on this topic; Drivers & Audio are out of my wheelhouse when it comes to computers, but would anyone here know how to go about getting the HDA driver working in 95 OSR2.5 in Parallels for Mac? — Parallels for Mac doesn't offer support for audio on deprecated systems, but I can set the VM to a "generic" Windows OS, which provides Intel HD Audio support. However, I've been pouring over forums and different config steps, and I'm not really sure what to do.

    The chipset presented by Parallels is the Intel ICH10 with Intel HD Audio, Vendor ID 8086 & Device ID 293E, which are correctly detected by the driver when installed (I verified this by comparing it to a Windows 10 VM's DID & VID). However, beyond that sound doesn't work, neither in DOS mode nor in Windows.

    Both act like it works, but with "quirks"; DOS mode will just be like "yeah sound is playing" when I tried test utilities from another form thread on the driver, whereas in Windows, the media player and the system sounds window will get "stuck" in a playing state, but the progress scrubber will not move (in media player) and it must be "stopped" manually. — But there's no sound at all when this happens.

    Method of install:

    HDATSR -> AUTOEXEC.BAT
    Custom INF installed for the PCI card.
    HDA Sound as default output device.
    Min & max virtual cache set to low
    'wave=hda2.dll' in System.ini

    I've tried various adjustments, deleting HDAICOUT.HDA (after backing it up of course), changing values in HDAcfg. I'm not sure if there's something I'm missing, if ICH10 is too new for this driver, or if Windows 95 has a weird quirk (everywhere I've read it seems like people have tried this with Windows 3.1 or Windows 98SE, and have assumed it will work with 95 as a result.).

    Here's my HDAcfg, for reference:

    [ALLHDA]
    $00FC=$293E8086
    
    [HDA]
    TSR=TSR FOUND
    PCI_VID=$8086
    PCI_DID=$293E
    
    [BUSMASTER]
    myPCIHI=$0012
    myPCILO=$1000
    aPCIHI=$0011
    aPCILO=$1000
    aPCI=$00111000
    
    [HDA_293E8086,04001AB8]
    cardmemoryregistersLO=$0000
    cardmemoryregistersHI=$F014
    Mytimer=1
    Verbinterface=$1
    wait1=$100
    wait2=$100
    pcipatchB=$0000
    PCI_BUS=$00
    PCI_DEVICE=$1F
    PCI_FUNCTION=$0
    GCAP=$2201
    VMIN=$00
    VMAJ=$01
    GCTL=$0001
    CODEC BITMAP=00000001
    CODEC Index=$0
    CODEC_VID=$1AB8
    CODEC_DID=$0001
    CODEC_REV=$100100
    CODEC_NODEINFO=$010001
    CODEC_AFG_GPIO_CAP=$C0000004
    CODEC_AFG_SUBSYSTEM_ID=$1AB80101
    CODEC_AFG_PM_SUPPORT=$0F
    CODEC_AFG_PCM_DEFINITION=$1E07FF
    CODEC_AFG_F000B=$01
    SleepingWidget=$02
    VolumeWidget=$14
    OutputWidget=$02

    Note that most of these values reset on reboot; only the widget values can persist. What is above is a "stock" config (I deleted the one i modified and let HDATSR rebuild the config, and these are the values it presented).

    Another note is that I was going to try the Microsoft HD Audio Utility to try and compare the data between Windows 10 and the HDA configuration file, but I only have access to 64-bit copies of Windows outside of 95, and the only version shared online is the 32-bit version, which refuses to install on 64-bit systems (it will say to download the 64 bit inversion instead).

    I was able to find an archived version of the 64bit installer of HDAUtil via a url punched into wayback from the extracted contents of the 32bit MSI. I have HDAUtil if this helps.

    Would anyone be able to point me in the direction of troubleshooting here? Like I said, this falls out of my area of expertise.

×
×
  • Create New...