Jump to content

DukeRaoul

Members
  • Content count

    97
  • Joined

  • Last visited

About DukeRaoul

  • Rank
    InsanelyMac Protégé

Contact Methods

  • Website URL
    http://

Profile Information

  • Interests
    Power Mac G5 reincarnated as C2D: <br /><br />GA-EP43-UD3l<br />Pentium Dual-Core E2220 2.4GHz -> 3.03GHz stable<br />GSkill 4GB DDR2 800 (4x 1GB dual-channel)<br />EVGA GeForce 8800GS<br />Syba SD-LUC-4F-G Firewire PCI card<br />Seagate 160GB 7200RPM SATAII<br />Seagate 500GB 7200RPM SATAII<br />Pioneer 16x DVD-RW +DL<br />Power Mac G5 case (modded obviously)<br />OCZ 500W psu<br />Acer 20" LCD on DVI
  1. This worked for me too (mostly) on an HD 5770 and ALC888 audio. Just got the 5770 and it's doing great, but it knocked out my ALC888 from any sound option except for front audio / headphones. Found this post, and used the driver and instructions from cue8chalk's post above, and it is working right again... Except when I put the system through sleep / wake once or twice, and my rear-green audio disappeared from System Prefs. I noticed there was no sound, so I checked there first and it was gone again, but the Line Out-Black option was there, so I picked it and switched the jack to get sound back. Any ideas why my audio jacks would be disappearing or changing around? Also thanks for the good work - any sound from the onboard rear jacks is better than HDMI audio for me.
  2. DukeRaoul

    The Fermi "Freeze" Discussion (Possible solutions?)

    Possible fix for these cards, if the problem is related to HDMI Audio in the card causing the KP/freeze: http://www.insanelymac.com/forum/index.php...p;#entry1596208 If you are using VoodooHDA, it is very likely picking up HDMI Audio from your GTX460. If you could at all get by without using HDMI audio and use the onboard sound instead, try blocking the HDMI audio from loading in VoodooHDA with the linked method above. Note that I cannot confirm for sure that HDMI audio is causing the freeze issue, but from reading the boards many people seem to think it is. Also I didn't get a 460 so I can't test myself to help out (ended up getting an HD 5770, not as good but more compatible). The VoodooHDA-HDMI audio skip thing is basically done by using the special driver posted to the above link, which is recompiled to include a device-skip key in the Info.plist - you use lspci or System Info to find the vendor/device ID of the HDMI AUDIO component of your card, then put the IDs into the skip part of the Info.plist .... read the linked post above thoroughly for the details.
  3. DukeRaoul

    The Fermi "Freeze" Discussion (Possible solutions?)

    It's good that people are finding workarounds to that issue, but I would not recommend using the iTunes visualizer. Have you ever checked Activity Monitor while the visualizer is running? It uses up a lot of CPU power, far more than it uses your video card. I actually use the visualizer (sometimes) as a CPU stress-test to verify overclocking stability - iTunes Classic visualizer, FPS limiter off, low quality off. With all the limitations off, the visualizer can get my dual-core CPU up to 80 or 90% of max continuously. With the FPS cap on, it certainly uses less but it's still significant. Other readers are posting that this could be caused by an HD Audio component of the HDMI... maybe try disabling VoodooHDA or any other audio drivers as a test for that? I would like to test this myself, but I don't actually own a 460 yet - waiting for Crysis 2
  4. DukeRaoul

    Apple G5 Front Panel Connector Layout

    -Neo's method worked fine for me on a board with no built-in firewire, except that I had to connect my "FW Ground" on the front panel to my LED ground on the motherboard to get my LED to light up on the G5 case front. The power button worked both ways, either connected to the Power Button ground or the LED ground, but the light only came on when LED ground was used. This is on a GA-EP43-UD3L mobo. /offtopic Found a dude selling G5 front panel cables for 8 bucks on eBay! http://cgi.ebay.com/Apple-Power-Mac-G5-Fro...#ht_1897wt_1141 Having one of these should make it real easy to wire up all the connections, since it gives you wires directly out from the front panel with no modding necessary, except for splicing the wires from the cable to your mobo headers' wires.
  5. Check it out y'all, G5 Front Panel cables are on eBay right now for 8 bucks / free ship! http://cgi.ebay.com/Apple-Power-Mac-G5-Fro...#ht_1897wt_1141 I don't know about all that jazz with taking out the wires, but my approach will be just chop the end off and splice the wires to the proper PC headers. 1 cable, branching out to multiple areas in the case from the front panel. I was going to try DiaboliK's method, and I even sawed a small IDE connector in half to do that, but the premise of soldering 18 wires onto those connectors in such a tiny space put me off to procrastinate until it never happened yet. But a proper plug from the original cable will do it, I'm sure.
  6. DukeRaoul

    Team Fortress 2 CRASHES

    Don't use 10.5 Leopard - barely playable due to {censored} driver-software interaction in 10.5.8 with nvidia cards Don't use 10.6.4 default nvidia drivers, either get the Graphics Update for 10.6.4 or update to 10.6.5 Those two things above are related to Nvidia driver problems mostly. Works good now in 10.6.5 Unless you have some other problem....
  7. OK, I have created a guide based on this DSDT patch to the HPET IRQs to fix Firewire problems, with more about how to use IORegistryExplorer and manage the IRQs with DSDT. AFIK, all credit goes to Laqk for finding this fix, but if someone else posted elsewhere I couldn't find it. So thanks again, and I linked my post to this one. My post on Firewire - HPET - DSDT fix is here: http://www.insanelymac.com/forum/index.php?showtopic=237750
  8. After a few days of hard work/research, I fixed my Firewire by changing the IRQ's that the HPET device uses in DSDT. Primary credit for this info goes to Laqk for defining the method to do this for USB and SATA conflicts with the HPET (HPET steals the other devices' IRQ's a lot). Some folks have attempted to fix this issue by deleting AppleHPET.kext, but that isn't necessary with this fix. Prerequisites: working DSDT and knowledge of editing it, plus use of IORegistryExplorer Here is Laqk's guide to patching the HPET's IRQs in DSDT: http://www.insanelymac.com/forum/index.php?showtopic=206313 That's what you do to fix your Firewire. Basically, you have to free up some IRQ's that the HPET is using so Firewire can have one. First get IORegistryExplorer and look at your HPET device, and locate the Property called "IOInterruptSpecifiers" - this is what I believe are the IRQs for each device. Click the arrow to see the values under it. You will probably see either 2 or 4 sets of data values, which are the IRQs that HPET is using in OSX. Mine has 4 values, but my DSDT only specified 2 values with "IRQNoFlags". My DSDT specified 0 and 8, but in IORegistryExplorer HPET was using (hex values) 08, 14, 0b, and 0c which are IRQs 8, 20, 11, and 12 in decimal format as DSDT uses. So DSDT is trying to get HPET to use IRQs 0 and 8, but 0 already got used by something else, so 8 was the first it got, then it went somehow to 20, then 11 and 12. The high value of 20 took over the spot for Firewire in my case. Now to find free IRQs to substitute into DSDT.... Using IORegistryExplorer, search for your IRQs by entering "iointerruptspecifiers" into the Search bar up top (you may need to expand the search options with the little funny button to the right, just check all the boxes to search more areas). This should show all the areas (devices) in bold that have a Property "IOInterruptSpecifiers" so that you can see what IRQs are being used by OSX. This is a tedious process, but I opened Textedit and copied down each device name and the hex value for its IRQ. IOreg shows the hex values like this: <09 00 00 00 05 00 00 00> ... and I just looked at the first 2 numbers (09) to find the IRQs - comparing this to the IRQs defined in DSDT seemed to validate this, mostly. I honestly don't know what the other numbers after the first 2 are about. For now, just ignore them, and maybe somebody more knowledgeable will come along to enlighten me. See the attached file below for my IRQ scratch-pad (RTF document, needs downloading to view properly). One problem I ran into was the IDE1 device appears to be using every IRQ from 0 to 16, plus 19 (13 hex). I chose to ignore that and take the risk of assigning some it had, only if no other device used it. My reasoning was to hope that it couldn't possibly use them all, and that it was some kind of placeholder thing. Basically, from my listing of used IRQs, I found that 3, 5, 7, 10, 14, and 15 were free IRQs except for being "used" by that IDE1 device that I chose to ignore. In my DSDT, there were originally several other things claiming several IRQs at once, like LPT and ECP parallel ports. I deleted the entire sections related to PS2M, PS2K, LPT1, and ECP1 to free up the IRQs since I don't use those ports. Deleting other things in DSDT that claim IRQs will also help this process, but be sure that it's not something you need in there! To fix up the HPET's IRQs in DSDT, I used Laqk's method to increase the "IRQNoFlags" entries from 2 to 4, and I tried to match them up with the values shown in IORegistryExplorer as closely as possible while remaining under IRQ #16 (iasl won't let you go over IRQ 15). DSDT was showing 0 and 8, and 8 was the first to be used by OSX for HPET, so I changed the first DSDT IRQNoFlags entry to 8 instead of 0. Then I went up from there to the next one, 0b hex / 11 decimal for DSDT, then for the next entry I used the next higher shown in IOreg, 0c hex / 12 dec. The other IRQ used by OSX was 20 (14 hex), but you can't go that high in DSDT, so I used the highest free IRQ of 15. This is what I ended up with for my HPET entry in DSDT, after all of that procedure above: Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (ATT4, ResourceTemplate () { IRQNoFlags () {8} IRQNoFlags () {11} IRQNoFlags () {12} IRQNoFlags () {15} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) After compiling the AML and rebooting, the Firewire is working. Same after sleep/wakeup, reboot, etc. Looking into IORegistryExplorer now shows that Firewire is using IRQ 20 that was previously used by HPET. And the HPET is now using the 4 IRQs defined for it in DSDT. It may be important to note that it didn't work the first time I tried changing the HPET IRQ values in DSDT - I first used the first "free" IRQs in order I found them (3, 5, 7, and 10). It worked when on the 2nd try I changed the IRQNoFlags 4 values to closely match what IORegistryExplorer had before. Originally 08, 14, 0b, 0c (hex) from IOreg -----> into 08, 0b, 0c, 0f after DSDT change to 08, 11, 12, 15. HW specs relevant: GA-EP43-UD3L motherboard SD-LUC-4F-G firewire PCI card Apologies if this guide is hard to read or understand - it's hard to explain! IRQs_in_use.rtf
  9. Laqk Thanks for posting this info - finding your guide with Google allowed me to fix my Firewire issue. Since you don't have Firewire mentioned here, I'm going to make a new topic to help people with similar Firewire issues like mine and link to your fix here. My main purpose is to make a more noob(ish)-friendly guide, explaining the ioregistryexplorer use to find the free IRQ's needed, etc. Many folks have postings on this board and the other Project site with their "Unable to list Firewire devices" woes, but they are just resorting to hacks like deleting AppleHPET.kext which is not good. Thanks again!
  10. DukeRaoul

    Cmedia 8738

    Just wanted to post a successful result with a card I haven't seen mentioned here yet: http://www.newegg.com/Product/Product.aspx...N82E16829270006 SIIG Soundwave 7.1 PCI Audio card - uses CMI8768 chip, working great with Cmedia 8738 kext. Using the version 0.6.4 (dated Nov. 8 2009) of the CMI8738 kext, and it's working in 64-bit snow. This is a little bit higher-end card than some of the cheapo 10 dollar cards available with the 8738 chip. I'm hoping it will last well - bad reviews of the cheaper cards drove me to find this one. So far it works and sounds great.
  11. DukeRaoul

    G4 File Server

    Put it on your network. Wireless router + PowerMac G4 via Ethernet = Wireless G4 File Server. System Preferences - Sharing - Check "File Sharing"
  12. DukeRaoul

    Connecting an Electric Guitar to the Mac or PC?

    Go with a FireWire connection if at all possible! I used to use a USB sound card for audio-in (guitar, mixer, whatever) and it would periodically cause problems because of the high latency. Being a longtime Mac user, I already had some FireWire devices around, so I looked into getting a sound input on that bus. After a bit of research, I found the Behringer FCA202. It is just about the most affordable way to get high-quality audio into the FireWire port of your Mac or PC. Since it uses a full-duplex connection (data travels in and out simultaneously) it can send and receive audio at the same time, and you have near-zero latency. It's great. USB is only half-duplex, meaning it can either send or receive data but not both at once. That Behringer box has 4 1/4" audio ports, so you can plug your guitar directly into it. Then you can run Garageband or any other program with amp simulations and effects to make your computer a live music machine. Check it out here: http://www.amazon.com/Behringer-FCA202-Fir...e/dp/B000F8WED8
  13. "theMacElite" wow, so that's where StrangeDogs went... I used to be a member of that old site, and my G4 PowerMac is still running the flashed 9800Pro AGP card that their forum helped me create. And I also owe them thanks for pointing me here, as their board was the first place I heard of a "hackintosh" on a thread called "Hackintosh faster than a G5 ?!?" back in the deadmoo days...
  14. DukeRaoul

    10.5.8 deep sleep problem?

    Odd issue here - wondering if anyone else has experienced it... I have SleepEnabler, VoodooUSBEHCI, and OpenHaltRestart in /Extra. They are all doing their job there well. Also I have added FakeSMC from netkas instead of dsmos, etc. To make "automatically restart after power failure" reappear in Energy Saver prefs, I had to add my ISA Bridge device ID to AppleLPC.kext. That's the background info. My system will go to sleep (S3 deep sleep, not hibernate) properly, and then wake from sleep properly, with everything working right, ONCE per boot-up session. But if I then go to sleep a second time, it will not wake up properly. Instead it half-wakes, and the monitor never comes back on, the fans all go WHOOOSH steadily, and I have to hold down the power button to turn it off. It has taken a lot of work just to get sleep going - it last worked on system 10.5.3! Thanks to SleepEnabler's author and SuperHAI for the USBEHCI. But this sleep once, hang second time issue is utterly mind-bottling! How can it work once perfectly, then fail completely the second time? Little more background... system is Intel 975X chipset based, ICH7R southbridge, 99.7% vanilla/retail install (via LTL's method) and I have a zero-errors optimized DSDT.aml loaded.
×