All Activity
- Today
-
It would be cool if this turns into open source Intel drivers for legacy Windows. I ended up getting an I226-V Ethernet card for free, but it works with nothing below 10 as far as I know, so I just shelved it since I have no use for it. It would be cool if this could be made usable from like 2000-8.1 with open source drivers.
-
In latest release notes of Intel SGX DCAP, Intel anticipates ending service updates for Windows-based version of SGX by the end of 2026, and the final release will be in 2H 2026. However, Intel didn't release standalone version of SGX PSW 2.27.100.1 for Windows.
-
Microsoft now wants to be a good boy, a very good boy! https://www.windowscentral.com/microsoft/windows-11/windows-11-gaining-movable-taskbar-in-2026 I wonder what the odds are that the new taskbar will load WebView2?
-
It all depends on the motherboard and the USB 3.0 controller in the chipset. If you have a specific hardware in mind, please provide the model number of the device if it is a laptop/OEM PC, or the model number of the motherboard. Then I'll try to find something.
-
Um... Not sure what to read &/or infer into this, to be honest. On one hand, IT IS SUPPOSED TO GO UP EACH AND EVERY YEAR !!! No, it won't be an "exact" amount each and every year, won't be strictly "linear". But over the course of time, IT IS SUPPOSED TO GO UP. I can only speak for my own electric bill (Midwest USA). Here is each and every year's annual cost of electricity dating back to 2008 (the year after I bought this house since the first year wasn't a full year). I could even do previous home or apartments if you really want me to. I'm a spreadsheet nerd, I have these dating back to when I moved out of parents' home. Just going by the linear regression y-intercept trend line, that's $769.69 paid for electricity in 2008 and $1,087.03 paid for electricity in 2025. Annualized, that's only a 2.052% increase per year. That's below annualized inflation for the same time span of 2.940% per US CPI. Now then, on the other hand, just WHERE is your increase relative to that 2.940% US Consumer Price Index? Below? Above? By how much? But as far as "went up last year", I for one would personally HOPE SO. Because deflationary is years like 1926-1933, 1938-1940, 1949-1950, and 1954-1955 - I would NOT want to live through those years! That's REAL LIFE NUMBERS but I can only speak for Midwest USA. (ps - that was FUN!)
-
win vista+usb 3 drivters, how to integrate?
EliraFriesnan replied to sonnyblue's topic in Windows Vista
@mjd79, at this point only you can know, please tell, do we have a signed driver 3.0 that can be integrated? Thanks! -
I'd submit that "quality" is a different argument altogether. Quality is a function of price relative to inflation. If you build it CHEAPLY because the "market" only wants to spend so much, then of course the end result is going to be GARBAGE. "Junk In = Junk Out!" "You get what you pay for." Both apply.
-
2005 - 2015 computers quality was good. Newer and older ones are poorly built, outright garbage. @Monroe, thanks, interesting!
-
The "improving steadily" and at "faster pace of progress" is NOTHING NEW, in my opinion. So this should really surprise NO ONE. Think of a 1985 computer compared to a 1995 computer compared to a 2005 computer compared to a 2015 computer compared to a 2025 computer. Think of a 1935 refrigerator compared to a 1945 ... 1955 ... 1965 ... 1975 ... 1985 ... 1995 ... 2005 ... 2015 ... 2025 refrigerator. Here's one that I've always laughed at - think of a 1965 clothes dryer compared to a 1975 ... 1985 ... 1995 ... 2005 ... 2015 ... 2025 clothes dryer. Now think of "lint fires" and a clothes dryer burning down your house. MYTHS ASIDE, if your house fire is traced to your laundry room, YOU ARE INVESTIGATED FOR FRAUD. Because this isn't 1965 and clothes dryers simply do NOT catch your house on fire! No matter how loudly your grandmother claims that they do! Ask any fireman, ask any insurance claims adjuster. Think of any 1935 automobile compared to a 1945 ... 1955 ... 1965 ... 1975 ... 1985 ... 1995 ... 2005 ... 2015 ... 2025 automobile. Think of any 1935 <insert name here> compared to a 1945 ... 1955 ... 1965 ... 1975 ... 1985 ... 1995 ... 2005 ... 2015 ... 2025 <insert name here>.
-
I know very little about 'AI' ... just a little here, just a little there. I do know that my electric bill went up last year ... supposedly from all the data centers being built and coming online. This article is interesting and disturbing if all true. Just to add: The article came from here ... https://citizenfreepress.com/ Something Big Is Happening By Matt Shumer • Feb 9, 2026 https://shumer.dev/something-big-is-happening + Some points from the article ... For years, AI had been improving steadily. Big jumps here and there, but each big jump was spaced out enough that you could absorb them as they came. Then in 2025, new techniques for building these models unlocked a much faster pace of progress. And then it got even faster. And then faster again. Each new model wasn't just better than the last... it was better by a wider margin, and the time between new model releases was shorter. I was using AI more and more, going back and forth with it less and less, watching it handle things I used to think required my expertise. Then, on February 5th, two major AI labs released new models on the same day: GPT-5.3 Codex from OpenAI, and Opus 4.6 from Anthropic (the makers of Claude, one of the main competitors to ChatGPT). And something clicked. Not like a light switch... more like the moment you realize the water has been rising around you and is now at your chest. I am no longer needed for the actual technical work of my job. I describe what I want built, in plain English, and it just... appears. Not a rough draft I need to fix. The finished thing. I tell the AI what I want, walk away from my computer for four hours, and come back to find the work done. Done well, done better than I would have done it myself, with no corrections needed. A couple of months ago, I was going back and forth with the AI, guiding it, making edits. Now I just describe the outcome and leave. + Second point ... How fast this is actually moving Let me make the pace of improvement concrete, because I think this is the part that's hardest to believe if you're not watching it closely. In 2022, AI couldn't do basic arithmetic reliably. It would confidently tell you that 7 × 8 = 54. By 2023, it could pass the bar exam. By 2024, it could write working software and explain graduate-level science. By late 2025, some of the best engineers in the world said they had handed over most of their coding work to AI. On February 5th, 2026, new models arrived that made everything before them feel like a different era. If you haven't tried AI in the last few months, what exists today would be unrecognizable to you. + Some extra ... Amodei has said that AI models "substantially smarter than almost all humans at almost all tasks" are on track for 2026 or 2027. AI is now building the next AI There's one more thing happening that I think is the most important development and the least understood. On February 5th, OpenAI released GPT-5.3 Codex. In the technical documentation, they included this: "GPT-5.3-Codex is our first model that was instrumental in creating itself. The Codex team used early versions to debug its own training, manage its own deployment, and diagnose test results and evaluations." Read that again. The AI helped build itself. This isn't a prediction about what might happen someday. This is OpenAI telling you, right now, that the AI they just released was used to create itself. One of the main things that makes AI better is intelligence applied to AI development. And AI is now intelligent enough to meaningfully contribute to its own improvement. ...
- Yesterday
-
You have the Real Spirit! 1) Comparing 8086:0F04 only with WPCREdit with and without HDA.SYS will do no harm... 2) True according to 'sent $001F0011; got $40000005', but these are number of pin's only. Unknown if they are used in your laptop and how. I searched for ALC280 with GPIO. They are mentioned in https://lxr.missinglinkelectronics.com/linux+v4.9/sound/pci/hda/patch_realtek.c BTW look at ALC269 too. But most of the time mic-LED or mic-headset related? I also found a codec dump of 10EC0280: https://github.com/yehia2amer/Dell-Precision-T7610-Workstation-Hackintosh-Guide/blob/master/Linux ACPI %26 Sound Dump/asound/codec_dump.txt with 5 GPIO's mentioned. To me it seems almost equal to Block Diagram in Datasheet of ALC231 I have in my collection (ALC269 is a bit different). 3) I didn't mention verb '3F', only as payload in: '3B03F' (channel 0 L+R). I am not sure if your idea of '3Fxxx' is a good verb. For inputs I use 37xxx and for outputs 3Bxxx (both L+R together, more economical in HDAICOUT.HDA). About Sleeping Widget: if HDA2.DLL identifies the wrong codec (you mentioned Codec index $2 - probably your HDMI codec), I have seen earlier in this thread the codec is fully set by HDAICOUT.HDA, while the three Widget settings in HDACFG.INI where not working anymore, and WAVEOUT.EXE neither. Volume: no, there is only one Volume setting per DAC, so if there are 0x57 steps (87 decimal), max will be 57 (hex), so even above 3F (hex)! Power: if you used F0500 you are right if reponse was all zero. Still strange in case of a laptop. But: while debugging I would always Power up all nodes/ widgets. Better test without the two Reset Verbs too. Vendor Defined Widgets: always unknown, never see them mentioned in Datasheets. But now and then identified by Linux guy's (ALSA). But in case of ALC280 I found nothing special so far. For now I have two questions: 1) is the slider moving if you play a sound-file? Just to be sure... 2) Why concentrate on Pin-Widget $014? There are many other possibilities! I did a 'quicky' and made you a debug-version of HDAICOUT.HDA ment for ALC280 only. If you want to test, just rename. Further the usual procedure. ;;Debug-version_1_for_ALC280;HDACFG.INI:Codec_index=$0 Begin $0017FF00;AC_VERB_SET_CODEC_RESET; $0017FF00;AC_VERB_SET_CODEC_RESET;Always_twice! End Begin ;;Node 0x1:Audio_Function_Group $001F0500;AC_VERB_GET_POWER_STATE $00170500;AC_VERB_SET_POWER_STATE;Power up! $001F0500;AC_VERB_GET_POWER_STATE ;;GPIO: io=5, o=0, i=0, unsolicited=1, wake=0 ;; IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 $001F0011;AC_PAR_GPIO_CAP;CODEC_AFG_GPIO_CAP=5 $001F1600;AC_VERB_GET_GPIO_MASK;$00000000 $001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000000 $001F1500;AC_VERB_GET_GPIO_DATA;$00000000 ;$00171600;AC_VERB_SET_GPIO_MASK,00 ;$00171700;AC_VERB_SET_GPIO_DIRECTION,00 ;$00171500;AC_VERB_SET_GPIO_DATA,00 ;$001F1600;AC_VERB_GET_GPIO_MASK;$00000000 ;$001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000000 ;$001F1500;AC_VERB_GET_GPIO_DATA;$00000000 ;$00171601;AC_VERB_SET_GPIO_MASK,01 ;$00171701;AC_VERB_SET_GPIO_DIRECTION,01 ;$00171501;AC_VERB_SET_GPIO_DATA,01 ;$001F1600;AC_VERB_GET_GPIO_MASK;$00000001 ;$001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000001 ;$001F1500;AC_VERB_GET_GPIO_DATA;$00000001 ;$00171602;AC_VERB_SET_GPIO_MASK,02 ;$00171702;AC_VERB_SET_GPIO_DIRECTION,02 ;$00171502;AC_VERB_SET_GPIO_DATA,02 ;$001F1600;AC_VERB_GET_GPIO_MASK;$00000002 ;$001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000002 ;$001F1500;AC_VERB_GET_GPIO_DATA;$00000002 End Begin ;;node 0x2:DAC_1 $002F0500;AC_VERB_GET_POWER_STATE $00270500;AC_VERB_SET_POWER_STATE;Power up! $002F0500;AC_VERB_GET_POWER_STATE $002F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $00270610;AC_VERB_SET_CHANNEL_STREAMID,01 $002F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $002A0000;AC_VERB_GET_STREAM_FORMAT $00224011;AC_VERB_SET_STREAM_FORMAT;44.1kHz_16-bits $002A0000;AC_VERB_GET_STREAM_FORMAT $002B8000;AC_VERB_GET_AMP_GAIN_MUTE $0023B057;AC_VERB_SET_AMP_GAIN_MUTE;max_vol $002B8000;AC_VERB_GET_AMP_GAIN_MUTE End Begin ;;node 0x3:DAC_2 $003F0500;AC_VERB_GET_POWER_STATE $00370500;AC_VERB_SET_POWER_STATE;Power up! $003F0500;AC_VERB_GET_POWER_STATE $003F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $00370610;AC_VERB_SET_CHANNEL_STREAMID,01 $003F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $003A0000;AC_VERB_GET_STREAM_FORMAT $00324011;AC_VERB_SET_STREAM_FORMAT;44.1kHz_16-bits $003A0000;AC_VERB_GET_STREAM_FORMAT $003B8000;AC_VERB_GET_AMP_GAIN_MUTE $0033B057;AC_VERB_SET_AMP_GAIN_MUTE;max_vol $003B8000;AC_VERB_GET_AMP_GAIN_MUTE End Begin ;;node 0xC:Analog_Mixer $00CF0500;AC_VERB_GET_POWER_STATE $00C70500;AC_VERB_SET_POWER_STATE;Power up! $00CF0500;AC_VERB_GET_POWER_STATE $00CB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00CB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00C37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00C37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00CB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00CB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00CB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00CB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00C37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00C37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00CB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00CB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Begin ;;node 0xC:Analog_Mixer $00DF0500;AC_VERB_GET_POWER_STATE $00D70500;AC_VERB_SET_POWER_STATE;Power up! $00DF0500;AC_VERB_GET_POWER_STATE $00DB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00DB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00D37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00D37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00DB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00DB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00DB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00DB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00D37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00D37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00DB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00DB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Begin ;;node 0xF:Analog_Mixer $00FF0500;AC_VERB_GET_POWER_STATE $00F70500;AC_VERB_SET_POWER_STATE;Power up! $00FF0500;AC_VERB_GET_POWER_STATE $00FB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00FB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00F37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00F37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00FB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00FB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00FB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00FB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00F37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00F37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00FB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00FB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Begin ;;node 0x14;[Fixed]Speaker_at_Int_N/A? $014F0500;AC_VERB_GET_POWER_STATE $01470500;AC_VERB_SET_POWER_STATE;Power up! $014F0500;AC_VERB_GET_POWER_STATE $014F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $014F0900;AC_VERB_GET_PIN_SENSE $014F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01470740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $014F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $014B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $014BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0143B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $014B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $014BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $014F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down $01470C02;AC_VERB_SET_EAPD_BTLENABLE;External Amplifier Power-Down $014F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down End Begin ;;node 0x15;[Jack]HP_Out_at_Ext_Front? $015F0500;AC_VERB_GET_POWER_STATE $01570500;AC_VERB_SET_POWER_STATE;Power up! $015F0500;AC_VERB_GET_POWER_STATE $015F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $015F0900;AC_VERB_GET_PIN_SENSE $015F0700;AC_VERB_GET_PIN_WIDGET_CONTROL ;$015707C0;AC_VERB_SET_PIN_WIDGET_CONTROL;hp_amp_out_enable $01570740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $015F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $015B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $015BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0153B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $015B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $015BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $015F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down $01570C02;AC_VERB_SET_EAPD_BTLENABLE;External Amplifier Power-Down $015F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down End Begin ;;node 0x16;[N/A]Speaker_at_Ext_Rear? $016F0500;AC_VERB_GET_POWER_STATE $01670500;AC_VERB_SET_POWER_STATE;Power up! $016F0500;AC_VERB_GET_POWER_STATE $016F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $016F0900;AC_VERB_GET_PIN_SENSE $016F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01670740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $016F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $016B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $016BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0163B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $016B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $016BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $016F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down $01670C02;AC_VERB_SET_EAPD_BTLENABLE;External Amplifier Power-Down $016F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down End Begin ;;node 0x17;[N/A]Speaker_at_Ext_Rear? $017F0500;AC_VERB_GET_POWER_STATE $01770500;AC_VERB_SET_POWER_STATE;Power up! $017F0500;AC_VERB_GET_POWER_STATE $017F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $017F0900;AC_VERB_GET_PIN_SENSE $017F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01770740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $017F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $017B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $017BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0173B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $017B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $017BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End Begin ;;node 0x18;[Jack]_Mic_at_Ext_Rear? $018F0500;AC_VERB_GET_POWER_STATE $01870500;AC_VERB_SET_POWER_STATE;Power up! $018F0500;AC_VERB_GET_POWER_STATE $018F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $018F0900;AC_VERB_GET_PIN_SENSE $018F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01870740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $018F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $018B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $018BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0183B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $018B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $018BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End Begin ;;node 0x1A;[Jack]_Mic_at_Ext_Front? $01AF0500;AC_VERB_GET_POWER_STATE $01A70500;AC_VERB_SET_POWER_STATE;Power up! $01AF0500;AC_VERB_GET_POWER_STATE $01AF0800;AC_VERB_GET_UNSOLICITED_RESPONSE $01AF0900;AC_VERB_GET_PIN_SENSE $01AF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01A70740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $01AF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01AB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01ABA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $01A3B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $01AB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01ABA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End Begin ;;node 0x1B;[Jack]Line_Out_at_Ext_Rear? $01BF0500;AC_VERB_GET_POWER_STATE $01B70500;AC_VERB_SET_POWER_STATE;Power up! $01BF0500;AC_VERB_GET_POWER_STATE $01BF0800;AC_VERB_GET_UNSOLICITED_RESPONSE $01BF0900;AC_VERB_GET_PIN_SENSE $01BF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01B70740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $01BF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01BB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01BBA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $01B3B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $01BB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01BBA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End I hope I made no errors, but please check for yourself. The number of Verbs should just fit I suppose, but you can check with HDAICIN.TXT of course. HDAICOUT_DEBUG_1_ALC280.HDA
-
==================================================== Intel i219 (DEV_15B8) Windows XP SP3 driver from scratch (NDIS 5.1) ==================================================== Hi, I’m working on a Windows XP SP3 LAN driver for my Intel i219, written from scratch as an NDIS 5.1 miniport (i219.sys). I am very happy for any hints about the remaining missing pieces (especially i219 “PCH SPT” specifics). Here is what I already reach, the confirmed hardware facts, register notes, and the current Supported-OID list. ---------------------------------------------------- 1) My used lan adapter on Asrock z370 k6 board ---------------------------------------------------- - NIC: Intel i219 (i219-V2) - PCI Vendor/Device: 8086:15B8 - MMIO: BAR0 mapped at 0xDF400000, length 0x20000 (128 KB) - IRQ: legacy line 5, vector 97 (XP HAL/IOAPIC mapping) - MAC (observed / read from RAL/RAH): 70-85-C2-7E-28-B7 - Current driver build (“v45”) installs and STARTS cleanly in Device Manager and answers basic NDIS OID queries without crashing. ---------------------------------------------------- 2) Why i219 is tricky vs i218 ---------------------------------------------------- - i218 belongs to the older PCH-LPT / LPTLP (Lynx Point, 8-Series) family. - i219 belongs to the newer PCH-SPT (Sunrise Point) and later PCH families. Therefore: “patch only DeviceID” (i218 → i219) is not enough. A working i219 driver must use the correct i219-family MAC/PHY/NVM init logic (different from i218-family). ---------------------------------------------------- 3) Hardware inputs I treat as runtime data (must be read) ---------------------------------------------------- From PCI config space: - Vendor/Device ID (8086 / 15B8) - Command register (Bus Master + Memory Space enable) - BAR0 base + decoded size (here: 0x20000) - Interrupt pin/line (legacy) and optionally MSI capability - Power management capability (D0/D3) - Revision ID, subsystem vendor/device ID (for possible quirks) From MMIO: - Classic Intel GbE register model (“E1000-ish”) ---------------------------------------------------- 4) Minimal register map I’m using (layered bring-up) ---------------------------------------------------- (Full 128 KB MMIO window is huge; I focus on the layers needed for a real driver.) 4.1 Core control / status / PHY/NVM - CTRL 0x00000 (reset / link control) - STATUS 0x00008 (link-up bit etc.) - EECD 0x00010 (EEPROM/flash control) - EERD 0x00014 (EEPROM read) - CTRL_EXT 0x00018 (extended control) - MDIC 0x00020 (MDIO/PHY access) - FEXTNVM 0x00028 (PCH-family helper register) i218 vs i219 note: The register “existence” looks similar, but the correct init sequence and interpretation is family-path dependent (i218=pch_lpt vs i219=pch_spt). 4.2 Interrupts (currently I use polled mode) - ICR 0x000C0 (cause read/ack) - IMS 0x000D0 (mask set) - IMC 0x000D8 (mask clear) - (ITR is optional) 4.3 RX/TX engine registers Receive: - RCTL 0x00100 (RX enable + filters) - RDBAL 0x02800 / RDBAH 0x02804 - RDLEN 0x02808 - RDH 0x02810 / RDT 0x02818 Transmit: - TCTL 0x00400 (TX enable) - TIPG 0x00410 - TDBAL 0x03800 / TDBAH 0x03804 - TDLEN 0x03808 - TDH 0x03810 / TDT 0x03818 4.4 Address filtering tables (important for DHCP/ARP/multicast) - RAL0/RAH0 0x05400 / 0x05404 (RAR0) - MTA 0x05200 (multicast hash table) - VFTA 0x05600 (optional VLAN filter) Important: When Windows sets OID_802_3_MULTICAST_LIST, the driver must program MTA accordingly (or choose a safe fallback strategy). ---------------------------------------------------- 5) Supported OIDs in v45 (current list) ---------------------------------------------------- static const NDIS_OID g_SupportedOids[] = { OID_GEN_SUPPORTED_LIST, OID_GEN_HARDWARE_STATUS, OID_GEN_MEDIA_SUPPORTED, OID_GEN_MEDIA_IN_USE, OID_GEN_MEDIA_CONNECT_STATUS, OID_GEN_MAXIMUM_FRAME_SIZE, OID_GEN_MAXIMUM_TOTAL_SIZE, OID_GEN_LINK_SPEED, OID_GEN_XMIT_OK, OID_GEN_RCV_OK, OID_GEN_XMIT_ERROR, OID_GEN_RCV_ERROR, OID_GEN_RCV_NO_BUFFER, OID_GEN_TRANSMIT_BUFFER_SPACE, OID_GEN_RECEIVE_BUFFER_SPACE, OID_GEN_TRANSMIT_BLOCK_SIZE, OID_GEN_RECEIVE_BLOCK_SIZE, OID_GEN_VENDOR_ID, OID_GEN_VENDOR_DESCRIPTION, OID_GEN_DRIVER_VERSION, OID_GEN_VENDOR_DRIVER_VERSION, OID_GEN_CURRENT_PACKET_FILTER, OID_GEN_CURRENT_LOOKAHEAD, OID_GEN_PROTOCOL_OPTIONS, OID_GEN_MAC_OPTIONS, OID_GEN_MAXIMUM_SEND_PACKETS, OID_GEN_MAXIMUM_LOOKAHEAD, OID_802_3_PERMANENT_ADDRESS, OID_802_3_CURRENT_ADDRESS, OID_802_3_MAXIMUM_LIST_SIZE, OID_802_3_MULTICAST_LIST }; Numeric OID values (standard ntddndis.h definitions): - OID_GEN_SUPPORTED_LIST = 0x00010101 - OID_GEN_HARDWARE_STATUS = 0x00010102 - OID_GEN_MEDIA_SUPPORTED = 0x00010103 - OID_GEN_MEDIA_IN_USE = 0x00010104 - OID_GEN_MAXIMUM_LOOKAHEAD = 0x00010105 - OID_GEN_MAXIMUM_FRAME_SIZE = 0x00010106 - OID_GEN_LINK_SPEED = 0x00010107 - OID_GEN_TRANSMIT_BUFFER_SPACE = 0x00010108 - OID_GEN_RECEIVE_BUFFER_SPACE = 0x00010109 - OID_GEN_TRANSMIT_BLOCK_SIZE = 0x0001010A - OID_GEN_RECEIVE_BLOCK_SIZE = 0x0001010B - OID_GEN_VENDOR_ID = 0x0001010C - OID_GEN_VENDOR_DESCRIPTION = 0x0001010D - OID_GEN_CURRENT_PACKET_FILTER = 0x0001010E - OID_GEN_CURRENT_LOOKAHEAD = 0x0001010F - OID_GEN_DRIVER_VERSION = 0x00010110 - OID_GEN_MAXIMUM_TOTAL_SIZE = 0x00010111 - OID_GEN_PROTOCOL_OPTIONS = 0x00010112 - OID_GEN_MAC_OPTIONS = 0x00010113 - OID_GEN_MEDIA_CONNECT_STATUS = 0x00010114 - OID_GEN_MAXIMUM_SEND_PACKETS = 0x00010115 - OID_GEN_VENDOR_DRIVER_VERSION = 0x00010116 - OID_GEN_XMIT_OK = 0x00020101 - OID_GEN_RCV_OK = 0x00020102 - OID_GEN_XMIT_ERROR = 0x00020103 - OID_GEN_RCV_ERROR = 0x00020104 - OID_GEN_RCV_NO_BUFFER = 0x00020105 - OID_802_3_PERMANENT_ADDRESS = 0x01010101 - OID_802_3_CURRENT_ADDRESS = 0x01010102 - OID_802_3_MULTICAST_LIST = 0x01010103 - OID_802_3_MAXIMUM_LIST_SIZE = 0x01010104 ---------------------------------------------------- 6) Current OID behavior in v45 ---------------------------------------------------- QueryInformation highlights: - OID_GEN_SUPPORTED_LIST: -> returns g_SupportedOids[] - OID_GEN_HARDWARE_STATUS: -> NdisHardwareStatusReady - OID_GEN_MEDIA_SUPPORTED / OID_GEN_MEDIA_IN_USE: -> NdisMedium802_3 - OID_GEN_MEDIA_CONNECT_STATUS: -> cached LinkState (Connected/Disconnected) - OID_GEN_MAXIMUM_FRAME_SIZE: -> 1500 - OID_GEN_MAXIMUM_TOTAL_SIZE: -> 1514 - OID_GEN_LINK_SPEED: -> 10000000 (1 Gbps in 100 bps units) - OID_GEN_VENDOR_ID: -> derived from MAC OUI (first 3 bytes) - OID_GEN_VENDOR_DESCRIPTION: -> "Dietmar i219 XP skeleton v45" - OID_GEN_DRIVER_VERSION: -> 0x0100 - OID_GEN_VENDOR_DRIVER_VERSION: -> 0x00010000 (1.0 encoded as major/minor) - OID_GEN_MAC_OPTIONS: -> COPY_LOOKAHEAD_DATA | TRANSFERS_NOT_PEND (observed as 0x5) - OID_GEN_MAXIMUM_SEND_PACKETS: -> 1 - OID_GEN_MAXIMUM_LOOKAHEAD: -> 1500 - OID_GEN_CURRENT_LOOKAHEAD / OID_GEN_CURRENT_PACKET_FILTER: -> returns cached values (Lookahead / PacketFilter) - Basic stats OIDs: -> currently 0 (no counters yet) - OID_802_3_PERMANENT_ADDRESS / CURRENT_ADDRESS: -> returns 6 bytes MAC - OID_802_3_MAXIMUM_LIST_SIZE: -> 32 SetInformation highlights: - OID_GEN_CURRENT_PACKET_FILTER: -> currently stores PacketFilter only (hardware filter mapping still in progress) - OID_GEN_CURRENT_LOOKAHEAD: -> stores Lookahead (clamped to 1500) - OID_802_3_MULTICAST_LIST: -> stores up to 32 multicast MACs (but MTA programming is still in progress) ---------------------------------------------------- 7) Problems already solved ---------------------------------------------------- - Driver loads/starts (v45): -> Clean start in Device Manager, Initialize runs, MMIO mapping is real. - Reliable MMIO/resource discovery: -> Stable BAR0 mapping confirmed (0xDF400000 / len 0x20000). - Root cause of earlier NDIS crash identified: -> When I previously “faked” some OIDs via WinDbg, I triggered a crash in NDIS OID validation (bad/NULL/incorrect Supported-OID list handling). -> Fix direction implemented: - real SupportedOids[] array - real Query/Set OID engine with correct BUFFER_TOO_SHORT / BytesNeeded / BytesWritten. - XP NDIS signature differences handled: -> Adjusted NdisMMapIoSpace / NdisMUnmapIoSpace usage for XP/NDIS5 compatibility. ---------------------------------------------------- 8) What I still miss ---------------------------------------------------- Even though the driver starts and answers OIDs, I still do NOT have real network traffic working end-to-end: - No DHCP lease / no real RX/TX I can see. What I believe is still needed: 1) Correct i219-family (PCH SPT) PHY + NVM init sequence (this is where i219 differs most from i218). 2) Correct mapping of OID_GEN_CURRENT_PACKET_FILTER into real hardware filtering (RCTL + tables). 3) Correct implementation of OID_802_3_MULTICAST_LIST into MTA programming (or safe fallback). 4) Possibly: switch from polled mode to proper interrupt mode once the basics work. If anyone has experience with i219 on older OSes (XP/2003): - The minimal “must-do” i219 (PCH SPT) PHY/NVM init steps to get stable link + RX/TX. - Any known i219-specific register quirks that differ from i218-family. - Confirmation whether my minimal TX/RX + RCTL strategy is sufficient, or which missing bits are typically required. Dietmar PS: Where the technical details in my i219 XP driver thread come from, and how I verify everything with crazy WinDbg use. ---------------------------------------------------- A) Direct observations from MY system (WinDbg + runtime logging) ---------------------------------------------------- These facts are taken from my own XP test machine and WinDbg sessions: - PCI ID: 8086:15B8 (Intel i219-V2) - BAR0 MMIO mapping: base 0xDF400000, size 0x20000 - IRQ resources (legacy line/vector) - MAC address read/used by the driver (70-85-C2-7E-28-B7) - Which OIDs are queried by NDIS / TCPIP and what my driver returned (seen via breakpoints + stack inspection) - Whether frames are actually TX/RX (currently: driver starts, but traffic still missing) ---------------------------------------------------- B) Extracted from my own driver source code (current v45 skeleton) ---------------------------------------------------- These items are not “guessed”; they come straight from my current i219.c / i219.h: - The exact SupportedOids[] array (the list I return for OID_GEN_SUPPORTED_LIST) - My current OID Query/Set behavior (what I return/store) - Ring sizes / buffer sizes / the delayed bring-up strategy (late TX/RX init after 40s) - Which register offsets I currently touch (RCTL/TCTL/TIPG/RDBAL… etc.) and which bits I set ---------------------------------------------------- C) Public reference sources (open headers/docs) ---------------------------------------------------- I used publicly available sources for “static” definitions, i.e. register offsets, bit masks, and OID semantics: 1) Intel e1000 / e1000e style register offsets + bit definitions - Linux kernel: drivers/net/ethernet/intel/e1000e/ (hw.h, defines.h, etc.) - QEMU’s e1000_hw.h (also includes the classic register layout) 2) NDIS OID numbers (hex values) and structures - ReactOS ntddndis.h (matches Windows OID values and is easy to reference) 3) OID semantics (what Windows expects) - Microsoft documentation for OID_GEN_SUPPORTED_LIST, OID_GEN_CURRENT_PACKET_FILTER, OID_802_3_MULTICAST_LIST, OID_GEN_LINK_SPEED, etc. ---------------------------------------------------- D) Heavy WinDbg use, the extremely hard part ;)) ---------------------------------------------------- My main technique is breakpoint-driven “bisection” (binary search in control flow): - Set a breakpoint at the function I expect to run. - If it is NOT hit, move the breakpoint earlier (caller / dispatcher) until I find the last hit location. - The bug must be between the last-hit BP and the first-not-hit BP. - Only after I have narrowed it down do I inspect registers/stack/buffers. Typical breakpoints I use: 1) OID path: bp i219!I219MiniportQueryInformation bp i219!I219MiniportSetInformation bp NDIS!ndisMDispatchRequest Inside Query/SetInformation on x86 NDIS5, the OID value is the 2nd argument: - OID is at [esp+8] ? poi(@esp+8) I often dump the full stack to see all arguments: dd esp L20 Then continue: g 2) Driver bring-up / resources: bp i219!I219Initialize bp i219!I219LateBringUp bp i219!I219ProgramRxTx bp i219!I219WriteMacToRar0 3) RX/TX progress: bp i219!I219SendPackets bp i219!I219PollRxTx (then watch MMIO reads/writes and descriptor ring head/tail changes) If an OID is queried and packets still don’t flow, I focus on: - OID_GEN_CURRENT_PACKET_FILTER SET → must translate into RCTL + filtering (broadcast/multicast) - OID_802_3_MULTICAST_LIST SET → must program MTA (or enable a safe fallback) - Link state / PHY init (i219 “PCH SPT” path differs from i218 “LPT” path) ---------------------------------------------------- Reference links (for convenience) ---------------------------------------------------- Linux e1000e: - https://github.com/torvalds/linux/tree/master/drivers/net/ethernet/intel/e1000e QEMU e1000 register layout (e1000_hw.h): - https://git.zx2c4.com/qemu/tree/hw/e1000_hw.h ReactOS ntddndis.h (OID hex values): - https://doxygen.reactos.org/dc/d38/ntddndis_8h.html Microsoft OID docs: - https://learn.microsoft.com/en-us/windows-hardware/drivers/network/oid-gen-supported-list - https://learn.microsoft.com/en-us/windows-hardware/drivers/network/oid-gen-current-packet-filter - https://learn.microsoft.com/en-us/windows-hardware/drivers/n
-
I've chosen Gs Richcopy 360 for our Box to OneDrive migration, and it was fantastic, preserving permissions, metadata, and external sharing links perfectly, even with our complex nested structures. Handled 15TB smoothly with great support. Highly recommend it!
-
OK, too bad. I can't remember any useful information about testing with hardware from around 2000. Unfortunately, I haven't had such a 370/slot1 motherboard or something similar to test for a long time. Since there is probably no one here who knows KernelEx better than you jumper, the hardware could probably play a role. Maybe it's more the graphics card and its drivers, which in my experience can be a factor. My oldest boards have chipsets Via P4M800, PT880Ultra or Intel 915 - Graphic cards are NV 5900XT / 6600GT AGP for the VIA boards with drivers 82.16 or 82.69 . RT's browsers work here using these boards, but the browsers are extremely slow with this hardware. The speed becomes useful by suppressing advertising or deactivating Javascript. RAM (VRAM)? Mozilla recommended 512MB. This applies to XP. As is well known, it is said to have a more robust memory management than 98SE/ME. I read repeatedly about browser crashes due to low/little memory, that of course also applies to other operating systems. Perhaps we need to define a higher limit? SSE2 Processors were required since Firefox 49. So I'm assuming that this isn't important here.
-
My Browser Builds (Part 5)
NotHereToPlayGames replied to roytam1's topic in Browsers working on Older NT-Family OSes
We're veering off-topic, so I'll make this my closing remark. 10 is plenty for "browsing", per se. And having "fast internet" can sometimes cause more harm than good. I *intentionally* "throttle" my connection when streaming from my "tv provider" (I don't have a "tv", everything is streamed via computer or laptop). I "throttle" all the way down to 100 KB/s [so literally 1/100th of 10 MB/s] (I get buffer-lag at 75 KB/s but ZERO buffering issues at 100). This *forces* my "tv provider" to *STOP* sending me 4k resolution video streams! I have no use for 4k because it pegs my very old laptop's CPU at 100%. Why would I watch an hour or so here and there or an entire Sunday with the CPU pegged at 100% for the entire time? Would KILL this laptop in a matter of days. 100 KB/s seems to be perfect for 720p streaming "on the side" (more than fine for laptop display as "background" to real computer adjacently performing real tasks). That drops CPU to below 28%. 300 KB/s seems to be perfect if I want to "allow" my tv provider to send 1080p. At the expense of bumping the CPU up to around 35% and that's enough for the fan kicking up to a higher RPM occasionally. -
My Browser Builds (Part 5)
j7n replied to roytam1's topic in Browsers working on Older NT-Family OSes
10 MB/s is what I have and I am perfectly content with it, I could buy a replacemnt router with a gigabit port and get "up to" 300 Mbit, but I can't afford a decent mikrotik router. Only efficient old software can reach high speeds, not a web browser in typical use. -
My Browser Builds (Part 5)
roytam1 replied to roytam1's topic in Browsers working on Older NT-Family OSes
longstanding misskey.io issue will be somewhat fixed in next build. -
My Browser Builds (Part 5)
NotHereToPlayGames replied to roytam1's topic in Browsers working on Older NT-Family OSes
10-40 MB/s sounds slow to me. But I had to learn something new... From here: https://www.techcalc.org/blog/mbps-vs-mbps-download-speed-explained My wireless fluctuates between 46 and 66 MB/s. So yeah, 10 on a wired is a definite sad face. -
@deomsh thank you for all of this info! Notes below with @Drew Hoffman HDA.SYS renamed HDA.BAK for testing purely Watler's. 1) Noted! I will leave the PCI registers alone for now. 2) The AFG reports some GPI/O - please see codec response log file attached below for full verb parameter responses. Response on AFG is $40000005 (reports 5 GPI/O's). 3) Until now I only unmuted outputs, but tested also with combined output and input payloads as you mentioned using $00C3F03F (F:Set out+In_L+R, 0: Index 0, 3F: Unmute and volume to 3F). Also $0143F03F. No change with these. Sleeping Widget) I tried $02. No change with this. Volume) According to DAC1 at reset AmpOut is set to $57 which when checking steps settings is 0dB and unmuted. I maybe read somewhere that amp gain is added together if you also set it on mixer and pin widget (but maybe I am imagining this and instead it adds L+R channels?). I thought if I set $57 also on Mixer and Pin Widget the amp gain becomes $57 + $57 + $57 at LineOut.. I think I am wrong here maybe..? Power Verbs) At the beginning of testing I set $00170500 and also $0C and $14 to 70500 to power on the nodes to D0 state, however checking F05 readings in HDAICIN without 705 set at reset: all nodes showing $00000000 (D0 power state) so I assume not needed to be set. Maybe I am wrong here and reading $00000000 could also mean no reading at all, therefore the 705 verbs are required? So I tested with that but no difference in result. Further) That is great you have a quasi-universal HDAICOUT.HDA that works on multiple codecs! Hopefully I can help confirm some more codecs for this. Please see image here with quick lookup reference I made from GET verbs and the responses that helped me map this codec. I am lost at what the vendor defined audio widgets could be. Any idea for these? CODEC RESPONSES.TXT
-
My Browser Builds (Part 5)
nicolaasjan replied to roytam1's topic in Browsers working on Older NT-Family OSes
That's because I should be getting ~40MB/s. I'm connected here in a rather weird way via cable from the providers modem in the neighbouring house to my router and then via cable to my PC. -
@Damnation I think, it can be done for any Nic, as long as you have Linux, where you can spy. But it is soso crazy hard work. I notice for example, that I always get Bsod D1, which I cannot catch with Windbg, only when you make an offline check of it. It happens, when the lan cable is connected at boottime, but parts of the driver have not loaded to full, so happens this Bsod even everything is "ok". Now I understand, why on many compis there is always a big time delay, before you get connected via lan Dietmar