The 3.2GB version is the version from this thread - likely the one you downloaded via torrent was not prepared correctly by whomever created it.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Thanks to a “new” power brick made by Apple, I’m able to resume testing SL-PPC on my 15-inch DLSD PowerBook. (Non-Apple power adapters for whatever odd reason do not work, even as they work fine on the 17-inch DLSD.)
And no sooner after getting the system up and running again, picking up where I left off last, uhm, September, I promptly broke SL-PPC by trying to install the ARD Admin 3.4 update. This will break Window Server, hanging when RFBEventHelperd (part of the ARDAgent package) is invoked:
Anyhow, I’ll be re-installing SL-PPC next.
Testing is, uhm, fun.
And no sooner after getting the system up and running again, picking up where I left off last, uhm, September, I promptly broke SL-PPC by trying to install the ARD Admin 3.4 update. This will break Window Server, hanging when RFBEventHelperd (part of the ARDAgent package) is invoked:
Apr 27 04:33:26 glaciologia ARDAgent[878]: validate multiple error -6405
Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available.
Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available.
Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available.
Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available.
Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available.
Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available.
Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available.
Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available.
Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: unable to create event tap
Apr 27 04:33:37 glaciologia com.apple.launchd[1] (com.apple.RFBEventHelper[910]): Exited with exit code: 1
Apr 27 04:33:41 glaciologia com.apple.launchd[1] (com.apple.RFBEventHelper): Throttling respawn: Will start in 7 seconds
Apr 27 04:33:48 glaciologia RFBEventHelperd[914]: RemomveClientConnection - client port 1a03 not found
Apr 27 04:33:48 glaciologia RFBEventHelperd[914]: Window Server is not available.Anyhow, I’ll be re-installing SL-PPC next.
Testing is, uhm, fun.
Indeed, the 3.2Gb version booted right up (after being restored).
No welcome video but the music played during the account setup.
I didn't have time to really use it beyond create my user account, but initial impression was a very slow machine.
In any case, it will be fun to poke around with it.
The torrent came from https://archive.org/download/sl-10-a-190-system
The usable 3.2Gb version came from https://macintoshgarden.org/apps/mac-os-106-snow-leopard-powerpc-beta-10a190
Thanks to a “new” power brick made by Apple, I’m able to resume testing SL-PPC on my 15-inch DLSD PowerBook. (Non-Apple power adapters for whatever odd reason do not work, even as they work fine on the 17-inch DLSD.)
And no sooner after getting the system up and running again, picking up where I left off last, uhm, September, I promptly broke SL-PPC by trying to install the ARD Admin 3.4 update. This will break Window Server, hanging when RFBEventHelperd (part of the ARDAgent package) is invoked:
Apr 27 04:33:26 glaciologia ARDAgent[878]: validate multiple error -6405 Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available. Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available. Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available. Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available. Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available. Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available. Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: Window Server is not available. Apr 27 04:33:37 glaciologia com.apple.RFBEventHelper[910]: Tue Apr 27 04:33:37 glaciologia.private RFBEventHelperd[910] <Warning>: Window Server is not available. Apr 27 04:33:37 glaciologia RFBEventHelperd[910]: unable to create event tap Apr 27 04:33:37 glaciologia com.apple.launchd[1] (com.apple.RFBEventHelper[910]): Exited with exit code: 1 Apr 27 04:33:41 glaciologia com.apple.launchd[1] (com.apple.RFBEventHelper): Throttling respawn: Will start in 7 seconds Apr 27 04:33:48 glaciologia RFBEventHelperd[914]: RemomveClientConnection - client port 1a03 not found Apr 27 04:33:48 glaciologia RFBEventHelperd[914]: Window Server is not available.
Anyhow, I’ll be re-installing SL-PPC next.
Testing is, uhm, fun.
Hi @B S Magnet
Good to see your power supply issues have been resolved and you can resume testing!
Running 'otool -L' on the remote desktop binary indicates that the following libraries and frameworks would need to be updated, as well as the libraries and frameworks needed to fulfil the dependencies of said libraries and frameworks:
/Users/christopher/Desktop/Remote Desktop (architecture ppc):
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1290.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService (compatibility version 1.0.0, current version 309.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 29774.0.0)
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
/System/Library/PrivateFrameworks/Admin.framework/Versions/A/Admin (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 368.35.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 567.42.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 824.48.0)
I'm currently, slowly, updating frameworks and supporting libraries in one of my builds. Tedious but signs of light at the end of the tunnel. I'm focused on getting a more recent version of LoginWindow and the supporting security systems installed as LoginWindow, as well as providing the Login Screen, also plays a major part in the desktop display window management system of OS X.
I've been playing around with DarwinBuild as well on a copy of Mountain Lion that i have installed on one of my systems. I think i'll need to purchase a dedicated older intel mac that supports vanilla 10.6 in order to build anything useful though as trying to cross-compile from a different platform and architecture probably isn't going to provide the most useable results.
I'm not sure but it looks like the build 'Joey Johnston' uploaded to archive.org is an image of his own system that wasn't made bootable.
The version on MacintoshGarden is the dmg provided by @Larsvonhier early in this thread and is the most commonly utilised disk image used for testing, for those not patching the vanilla Developer Seed manually. It is an invaluable contribution, it does not include any patches further than the initial kext replacements however - these were discovered later.
Yes, the welcome video is either not included in this build, or simply doesn't play because of the missing video and OpenGL frameworks.
The 'blocky' images can be resolved by replacing ImageIO.framework as detailed previously in the thread. There are also some small tweaks, the same as used on 10.5, to force Quartz2D but i would recommend against disabling Beamsync on an eMac as the CRT may not function correctly.
The other tweaks should aid in 'smoothing out' the experience on the ATI Radeon 7500 somewhat. You will still experience some graphical glitches in the Finder as this build is very buggy with a partial cocoa rewrite versus 10A96.
WiFi will also not work without some file transplanting - this is a bit hit and miss depending on hardware but it does work in 10A096 so should be fixable in 10A190.
I will see to filing this in mind the next time should I make that attempt. Thank you.
I went ahead and completed a re-install of the system (principally by moving /System /Library and /mach_kernel and appending “_old” to them), leaving me with a semi-new build and my old /Users.
I may ultimately opt to go with a completely clean re-install at some point pending on how this goes. I’d like to get back to where things were before this ARD 3.4 install and probably follow along closely with what you’re doing presently (and minding how much more in-depth you are with it presently).
Thanks for the tips, as a side note this eMac uses the Nvidia GeForce 2 MX GPU, and I did recall seeing the kext for it load during verbose boot (NVDANV10Hal.kext) so in theory there should be some GPU acceleration available.
I'll have to dig through the thread a bit more to find the optimizations
I've now started to use several sparsebundles labelled VERS_Clean, VERS_Recent and VERS_Current; clean being a fresh install, recent being stable patches that i'm happy to keep and can restore from and current being the most recent frankenstein mess that i continue to tinker with and patch until it either becomes unfixable or enough time passes between tinkering sessions that my lack of note taking forces me to start again, due to the affects of time and age on my memory.
Nvidia cards have better support in 10A190 for whatever reason, it might be fruitful to play with the Nvidia KEXTs from Leopard and see if they improve anything - the missing and incomplete frameworks in 10A190 will still prevent a fully supported graphical system until the correct 'recipe' for patching is discovered to bring it up-to-date but each step in the right direction taken by testers helps us all understand what works and what doesn't.
This is brilliant planning and way ahead of my headspace.
Ideally i want to move it all onto an external Firewire drive so that the builds are portable and bootable on different machines.
I’m here to report that @wicknix ’s InterwebPPC works on SL-PPC!
I admit to cheating, in that I copied over my TFF profile over to InterwebPPC, but that basically only makes it a bit quicker on its feet.
The only beach ball comes up momentarily whenever opening a forum’s index page (with all the miniature avatars which need to be parsed and rendered).
I admit to cheating, in that I copied over my TFF profile over to InterwebPPC, but that basically only makes it a bit quicker on its feet.
The only beach ball comes up momentarily whenever opening a forum’s index page (with all the miniature avatars which need to be parsed and rendered).
On basically the one-year anniversary of when a lot of folks began to test the 10A96 image of SL-PPC for the first time, I managed to convince a moderator to migrate this thread over to the PPC forum, where more eyes can see it and where it probably should have been this entire time.
Mac OS X PPC 10.6beta Clouded LeopardThere was a small discussion on the PPC forum (in an unrelated thread) about what to call a Leopard/Snow Leopard hybrid OS such as this is becoming, to differentiate it from the Intel 10.6 - how about 'Mountain Leopard'?
Cheers
Hugh
I have just given this method another go on a fresh 10A190 install, with only ImageIO currently patched, and Wifi is now working on my iBook G4! There are still a few things that need looking into, like the menuitem displaying correctly for example, but at least internet access is functional. After spending the majority of my time in 10A096 recently it’s definitely nice to have functional wifi under 10A190 for a change.
This took a few days, but I went through and back-linked several key posts to the WikiPost section on workarounds/troubleshooting.
And while I was there, I began to give the WikiPost a readability/accessibility/usefulness overhaul (with thought to new folks who might want to get involved on their own). There is still more work I need to do with that.
And while I was there, I began to give the WikiPost a readability/accessibility/usefulness overhaul (with thought to new folks who might want to get involved on their own). There is still more work I need to do with that.
That’s a great update to the post. Really simplifies it all and lays out where basically everything is at, thanks for the effort.
Well… okay.
Following a weekend of poring over a lot of material which was borderline comprehensible (for someone who isn’t a hacker), I may be able to explain, at least in small part, the reason why hardware support for ATI/AMD Radeon AGP cards (like the Mobility Radeon 9700, or the 9800 Pro, and so on) can’t happen in Snow Leopard (even if the card happens to be on an Intel machine, such as with a Hackintosh build).
:deep breath:
It goes back to 2007–08, when Apple was developing the framework called OpenCL (Open Computing Language), which was intended to make it possible, when executing code written in OpenCL, to use not just the CPU(s)/CPU core(s), but also together with other processing components (like highly parallel GPUs, digital signal processors, and other dedicated components which would make possible hardware acceleration).
Prior to the development of OpenCL as a framework (and what would become an industry standard literally concurrent with when Snow Leopard was released), Leopard and earlier were not taking advantage of GPUs for hardware acceleration, despite Core Image status showing hardware acceleration for those GPUs whose drivers were provided in Apple’s kexts (e.g., ATIRadeon9700.kext).
This is because the code was only looking at, calling, and taking advantage of the the CPU and ignoring the on-board GPU whenever an OS-based, graphics-related action/command (like moving a window in Finder) was initiated. Leopard and Tiger could take advantage of a GPU’s hardware acceleration for tasks which called for the GPU specifically (such as Screen Saver, Chess, or a GPU hardware acceleration call in, say, VLC).
The development of OpenCL, as I understand it, not only did away with this “siloed’ approach to executing code (and doing away with the inefficiency of the kernel having to issue discrete commands for each discrete and specialized hardware component, like the GPU separately from the CPU), but it also occurred at around the same time the drivers being written by the GPU vendors (ATI/AMD and NVIDIA) migrated away from a specialized, GPU-oriented driver programming language called Brook (better known as BrookGPU).
BrookGPU, as @netkas relayed via their own blog, was the older driver coding language which, when drawing vectors/geometry-heavy images with the GPU, relied on a coding standard called Pixel Shader. Pixel Shader was phased out when OpenCL became the industry standard (again, adopted right when Snow Leopard was developed and released), and in Pixel Shader’s stead was a new standard called Compute Shader, which became the go-to after OpenCL’s widespread adoption.
Pixel Shader consequently became the legacy standard which newer cards could still parse when called by an application, but ATI/AMD and NVIDIA only began to include the ability for a video card to parse the newer Compute Shader starting with GPUs released after a certain point (ca. 2007–08) and declined to update drivers for legacy video cards to be able to parse Compute Shader. For ATI/AMD, that cut-off was the Radeon HD 4000 series and up, which was a PCIe card; below the Radeon HD 4000 (which included all the Radeon 9800, 9700, and 9600 cards, as well as HD 3000-series cards), Compute Shader was not added to updated drivers/kexts.
(Also, as I think I understand it, the Radeon X1900 XT and HD 2600 XT may have been the sole exceptions here, as these were OEM video cards sold specifically for the Mac Pro by Apple, and these do have hardware acceleration in Snow Leopard and later and were likely supported by special arrangement between ATI/AMD and Apple. But then again, this is only conjecture on my end.)
The tl;dr: unless one is running, say, a A1117 Power Mac G5 (with PCIe lanes) equipped with a Radeon HD 4000-series card or higher, then it appears very unlikely that running 10A96, 10A190, or any PPC-bootable build of Snow Leopard will yield hardware acceleration for the video card. Even the Hackintosh folk came to this realization at some point, probably in late 2009, that pre-Radeon HD 4000 video cards weren’t going to happen in an OpenCL-based Snow Leopard environment.
p.s.,: You all are welcome to check my work here, but I think this is the best distillation I can provide for all the reading and references I was able to scare up on this topic.
Following a weekend of poring over a lot of material which was borderline comprehensible (for someone who isn’t a hacker), I may be able to explain, at least in small part, the reason why hardware support for ATI/AMD Radeon AGP cards (like the Mobility Radeon 9700, or the 9800 Pro, and so on) can’t happen in Snow Leopard (even if the card happens to be on an Intel machine, such as with a Hackintosh build).
:deep breath:
It goes back to 2007–08, when Apple was developing the framework called OpenCL (Open Computing Language), which was intended to make it possible, when executing code written in OpenCL, to use not just the CPU(s)/CPU core(s), but also together with other processing components (like highly parallel GPUs, digital signal processors, and other dedicated components which would make possible hardware acceleration).
Prior to the development of OpenCL as a framework (and what would become an industry standard literally concurrent with when Snow Leopard was released), Leopard and earlier were not taking advantage of GPUs for hardware acceleration, despite Core Image status showing hardware acceleration for those GPUs whose drivers were provided in Apple’s kexts (e.g., ATIRadeon9700.kext).
This is because the code was only looking at, calling, and taking advantage of the the CPU and ignoring the on-board GPU whenever an OS-based, graphics-related action/command (like moving a window in Finder) was initiated. Leopard and Tiger could take advantage of a GPU’s hardware acceleration for tasks which called for the GPU specifically (such as Screen Saver, Chess, or a GPU hardware acceleration call in, say, VLC).
The development of OpenCL, as I understand it, not only did away with this “siloed’ approach to executing code (and doing away with the inefficiency of the kernel having to issue discrete commands for each discrete and specialized hardware component, like the GPU separately from the CPU), but it also occurred at around the same time the drivers being written by the GPU vendors (ATI/AMD and NVIDIA) migrated away from a specialized, GPU-oriented driver programming language called Brook (better known as BrookGPU).
BrookGPU, as @netkas relayed via their own blog, was the older driver coding language which, when drawing vectors/geometry-heavy images with the GPU, relied on a coding standard called Pixel Shader. Pixel Shader was phased out when OpenCL became the industry standard (again, adopted right when Snow Leopard was developed and released), and in Pixel Shader’s stead was a new standard called Compute Shader, which became the go-to after OpenCL’s widespread adoption.
Pixel Shader consequently became the legacy standard which newer cards could still parse when called by an application, but ATI/AMD and NVIDIA only began to include the ability for a video card to parse the newer Compute Shader starting with GPUs released after a certain point (ca. 2007–08) and declined to update drivers for legacy video cards to be able to parse Compute Shader. For ATI/AMD, that cut-off was the Radeon HD 4000 series and up, which was a PCIe card; below the Radeon HD 4000 (which included all the Radeon 9800, 9700, and 9600 cards, as well as HD 3000-series cards), Compute Shader was not added to updated drivers/kexts.
(Also, as I think I understand it, the Radeon X1900 XT and HD 2600 XT may have been the sole exceptions here, as these were OEM video cards sold specifically for the Mac Pro by Apple, and these do have hardware acceleration in Snow Leopard and later and were likely supported by special arrangement between ATI/AMD and Apple. But then again, this is only conjecture on my end.)
The tl;dr: unless one is running, say, a A1117 Power Mac G5 (with PCIe lanes) equipped with a Radeon HD 4000-series card or higher, then it appears very unlikely that running 10A96, 10A190, or any PPC-bootable build of Snow Leopard will yield hardware acceleration for the video card. Even the Hackintosh folk came to this realization at some point, probably in late 2009, that pre-Radeon HD 4000 video cards weren’t going to happen in an OpenCL-based Snow Leopard environment.
p.s.,: You all are welcome to check my work here, but I think this is the best distillation I can provide for all the reading and references I was able to scare up on this topic.
Last edited:
The Mobility Radeon X1600 in the 2006 iMacs and MBPs must also be part of the exception then, as well as the HD 2400 XT and HD 2600 Pro in the first Aluminum iMacs.
I ought to clarify: here are two (mostly overlapping) lists of those video cards which were not OpenCL-capable, but their drivers were maintained by the vendors to be able to parse Compute Shading* commands with Snow Leopard onward — and, thus, preserve continuing hardware support. Both of the cards you cited are on these lists.
* I know “compute shading” is not a proper noun, but for this conversation, I’m doing so to distinguish this as a standard.
I wonder if we could figure out how to get an HD 4670 or directive to initialize on PPC Snow Leopard then? They came in AGP.
I’ll leave that up to folks who’ve got a G5 (or maybe G4) tower and can do that.
I’m limited principally to SL-PPC testing with laptops (and my PCI-X G5 has a dying logic board and is already dedicated to being a multi-function file/network server).
This is a total and absolute shot in the dark but when I used an HD 2600 XT externally (with a MacBook) on Leopard and Snow Leopard, I used ATY_Init to initialise it.
However, iirc @LightBulbFun said that the drivers for the 2600 (and presumably newer Radeons) were compiled for x86 only, making the X1x00 series the newest to work on ppc in OS X.
Last edited:
Yeah, whether AMD and NVIDIA bothered to write big endian PPC drivers for specific video cards so to accommodate parsing compute shader data (namely, to accommodate professional customers who were running Quad G5s during the transition) is the big question some of y’all will need to test. And I hope y’all do!
I get the sense that unless a particular PCIe video card was merchandised and marketed to Mac users (again, accommodating both high-end, late G5s and early Xeons during that 2007 to 2010 transition window, give or take, and providing universal binary driver installers on the installation DVD, or from Apple online, if one of the kits was purchased directly from the Apple Store), then it is probably not going to work in a Snow Leopard PPC setting. That is to say: a model of later video card whose firmware could be flashed to work on a Mac may not have the updated, compute shader-friendly drivers to work its magic on SL-PPC.
But QE/CI are supported on low end GPUs such as e.g. the GMA 950 on the mini 1,1 under SL, both are clearly activated with CI hardware accelerated. Just to be sure that this was also the case on 10A190 I booted up a mini 1,1 from a PPC 10A190 install and it they are both clearly activated with CI hardware accelerated. Needless to say that for OpenCL, one obviously needs an OpenCL-supported card, so ≥HD 4XXX or ≥GF 8XXX; however no OpenFirmware or ppc kexts have ever been written for such cards though