Snow Leopard on Unsupported PowerPC Macs

[pc297]

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.

On Ubuntu Mate and Lubuntu PPC, this was made possible by Luigi Burdo's excellent work:

https://ubuntuforums.org/showthread.php?t=2274612

Using stock PC Radeon HD ≥ 4XXX cards on G5s. This does however require one PPC (as in OpenFirmware) card installed (and connected to a monitor).

Maybe if someone compiles ATY_Init for ppc? (see posts #466 and #469). Has anyone come across netkas's source code so far? Or if anyone either modifies the X1XXX ppc kexts to work with it or makes a ppc kext for it (that is, if the source code ever sees the light of day), maybe. Could be that it still would need an openfirmware card installed. But maybe not, at the end of the day, stock PC Radeon HD cards also work out of the box on Mac Pros on their own without any EFI card installed (however without the apple boot logo).

 

[B S Magnet]

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

This would be because the vendors (Intel, AMD, and NVIDIA) wrote their video card drivers with compute shader libraries built in, as compute shader drawing data would be what Snow Leopard, unlike with Leopard and earlier, would be sending to the GPU, as I understand it (OpenCL support would still be required of the Intel CPUs in Snow Leopard).

In other words, there is a different path, even a different rule set (if you will), to reach “CI/QE hardware supported” status for cards with drivers designed to parse pixel shader data only (which would be “CI/QE hardware supported” in Leopard) than with cards whose drivers are designed to parse both compute shader and pixel shader data (which would be “CI/QE hardware supported“ for both Leopard and Snow Leopard, as well as beyond, as the CPU architecture allows).

 

[B S Magnet]

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’m casually running file on both 10A96 and also on my (indefatigable) early 2011 MBP (which has run the same build of 10.6.8 since the day I first powered it on as an Apple refurb, with that SL build being carried over from a 2009 MBP which it replaced) — mostly to run side by side comparisons of which Frameworks survived as truly tri-architecture, with actual code within, by that late point (and whose version numbers are greater).

What I’m seeing in the tri-arch/UB Frameworks on 10.6.8 is many were, more or less, “set and forget” by Apple when the 10.6.0 GM was released: several frameworks were last touched/updated on 5 September 2009 (literally the evening I first powered on that 2009 MBP, which came bundled with 10.6.0).

All of that to say: I plan to go through each framework, much like you, but I want to try testing each of the September 2009-dated tri-arch frameworks in SL-PPC to see which ones actually work (and/or reveal a benefit). Pending on how that goes, I might examine the same with some of the kexts which survived to 2009 as tri-architecture and have a higher version number than SL-PPC.

 

[JoyBed]

Well, OpenCL isnt just a a GPU lib... it also supports CPUs and all the other stuff. There also exists a OpenCL runtime that uses our PowerPC CPUs to do OpenCL stuff. Maybe integrating that into the SL as a OpenCL backend will be a good idea.

 

[B S Magnet]

Well, OpenCL isnt just a a GPU lib... it also supports CPUs and all the other stuff.

Yes. This is what I was describing the other day.

There also exists a OpenCL runtime that uses our PowerPC CPUs to do OpenCL stuff. Maybe integrating that into the SL as a OpenCL backend will be a good idea.

It may be useful for optimizing some specialized tasks, but the AGP GPUs in G4s and G5s would not have PPC drivers which are recent enough to parse and execute OpenCL processes, yes?

 

[JoyBed]

Yes. This is what I was describing the other day.



It may be useful for optimizing some specialized tasks, but the AGP GPUs in G4s and G5s would not have PPC drivers which are recent enough to parse and execute OpenCL processes, yes?

Well, for now we can stick with the PowerPC OpenCL runtime if i manage to find it again. I dont remember any GPU with ppc drivers that had OpenCL capability tho, so maybe CPU is the only thing that will accelerate the OpenCL things in SL.

EDIT: Acording to all the data about nvidia card, ppc users were left out just before the CUDA/OpenCL on gpus was released... The highest nvidia gpu chip we have drivers for is g70 and OpenCL/CUDA starts at g80. IDK about AMD/ATI side of things tho. I see the CPU as only OpenCL possibility for now... With upgrades on the G4 macs(maybe by me :-D ) or with G5 macs it would be worth doing it that way.

 

[B S Magnet]

Well, for now we can stick with the PowerPC OpenCL runtime if i manage to find it again. I dont remember any GPU with ppc drivers that had OpenCL capability tho, so maybe CPU is the only thing that will accelerate the OpenCL things in SL.

EDIT: Acording to all the data about nvidia card, ppc users were left out just before the CUDA/OpenCL on gpus was released... The highest nvidia gpu chip we have drivers for is g70 and OpenCL/CUDA starts at g80. IDK about AMD/ATI side of things tho. I see the CPU as only OpenCL possibility for now... With upgrades on the G4 macs(maybe by me :-D ) or with G5 macs it would be worth doing it that way.

One big project at a time, as they say.

 

[PowerfulEra]

Just wondering back in the day i recall reading a modded hd 3870 ppc rom for our beloved g5s. I recall that the rom is modified fromm x1900gt? If anyone knows or has the rom somehow that would help us i guess

 

[B S Magnet]

Just a small update on the WikiPost:

I have done a bit of testing and added that to Table 4, the kext/bundle/plugin compatibility list.

We’ve hit the 70,000-character ceiling on the WikiPost! (Yikes!) I went ahead and cleaned up some of the formatting and copy to help bring the WikiPost back down beneath the 70K cap.

 

[B S Magnet]

To add to the discussion here, I was able to hack in iTunes 10.6.3 and QuickTime 7.6.4 into Snow Leopard. Works perfectly fine aside from Safari issues with the iTunes Store. Yes I’m aware the FX5200 Ultra doesn’t have acceleration aside from software CI. Might try the above kext to hopefully fix unmounting issues with removable devices. Very impressed with this project. View attachment 927116

Quick question, @MacPro2006VBox —

When you got iTunes 10.6.3 running here, do you remember whether you were running it from the 10A190 build or the 10A96 build?

 

[B S Magnet]

For those of you who’ve hesitated on testing SL-PPC because Radeon cards lack hardware-enabled Core Image and Quartz Extreme support, you may already have tried enabling Quartz2DExtreme with OSX86Tools.app (as found in the WikiPost’s attachments).

If you’re willing to put up with an occasional screen glitch (like when Cmd-Tabbing through opened applications rapidly), this tip here from the Hackintosh folks comes in pretty handy. (But a word of warning for anyone using a CRT: this won’t work for your setup.)

Re-draw of the screen with Beamsync permanently disabled and Quartz2DExtreme enabled (for 10.5 and 10.6, I think “YES” is the “-1” value found in ‘com.apple.windowserver.plist’), such as holding and moving a Finder window around in circles, really speeds up the re-drawing motion in Build 10A96. It’s best to make and save this change to the plist whilst logged in as System Administrator, followed by a reboot.

That, along with ShadowKiller.app (or the script called shadowless), should further improve overall screen response if you happen to be testing on a Radeon-equipped Mac.

 

[MacPro2006VBox]

Quick question, @MacPro2006VBox —

When you got iTunes 10.6.3 running here, do you remember whether you were running it from the 10A190 build or the 10A96 build?

I recall it was 10a190.. it was a bit too fragile to setup though, and the only thing that didn’t function (obviously) was the iTunes Store, which requires a newer build of Safari. I believe 10a96 would be a lot more stable in this regard. And actually when you’re hacking it in, you risk breaking your install. That happened to me the second time I tried it…. The first time it worked fine.

 

[ChrisCharman]

While i’ve been having success compiling and integrating a number of apple open source projects, i am now running into issues due to the differences between the developer builds of xcode and os x and the release versions for example missing xcrun. Though some of the missing files can be copied accross, being still ppc compatible, their dependencies are causing issues. Being in a chicken and egg situation with Libsystem currently, i’ve just ordered a 2008 Aluminium Unibody Macbook and a copy of retail 10.6. Hopefully i should be able to compile the projects that i’m having issues with on that system and then use those files to patch the custom build.

 

[ChrisCharman]

While i’ve been having success compiling and integrating a number of apple open source projects, i am now running into issues due to the differences between the developer builds of xcode and os x and the release versions for example missing xcrun. Though some of the missing files can be copied accross, being still ppc compatible, their dependencies are causing issues. Being in a chicken and egg situation with Libsystem currently, i’ve just ordered a 2008 Aluminium Unibody Macbook and a copy of retail 10.6. Hopefully i should be able to compile the projects that i’m having issues with on that system and then use those files to patch the custom build.

Also compiling the 10.6 kernel in DarwinBuild under Mountain Lion resulted in a kernel built only for x86_64 and i386, which is the exact opposite of what is needed. At least it did build the kernel though. I’m currently running my modified 10A190 install with the debug kernel which provides a much more verbose output for errors.

 

[treckin]

I have been building a "PowerMac" lab (aka, *collecting a lot of ewaste and pissing off the Mrs.*)

So far I have ~3.5 PM11,2s, a PM12,1, a few G4 iMacs, an eMac, plus a few G3 iMacs (300, 350, 600mhz flavors), and even a Macintosh (m0001) and a Mac Plus.

Just wanted to say "Hi", and that I am following closely and poking around along with you guys.

I have been diving through both Apple Open Source repository as well as dumping lots of the compiled kexts etc to text and skimming.

I am a hardware tinkerer by trade, so my sw/fw skills are pretty non-existent.

However, because of my background in HW I have noticed a few things:

G5 (assume G4 as well?) NB and SB have a LITTLE/big endianness translator, such that the endianness byte reversal is performed on the fly in HW at the controller.

Thus, drivers written for OS X 10.6.x.x expecting to be talking LITTLE endian to LITTLE endian over the bridges/hubs/switches to get to the GPU, may be byte-level inverted when they show up at the GPU because of this.

Potentially fixable but again, Im not much for SW, maybe it's not even an issue?

Anyhow, I have been archiving tons of documentation, I'll find a good place to host it and check back in.

 

[Raging Dufus]

*collecting a lot of ewaste and pissing off the Mrs.*

? ?

 

[Macbookprodude]

While I like this, how do we update to a newer version of safari or even 10.6.8 ?

 

[ChrisCharman]

While I like this, how do we update to a newer version of safari or even 10.6.8 ?

You don’t. If you want to update it you have to manually recompile the libraries and binaries yourself. I’ve been doing this for a good while now and haven’t even reached parity with 10A432 yet. As for Safari the only option would be to mirror what was done with Leopard Webkit using the last known stable nightly, which is a large undertaking on its own. All other Snow Leopard applications, unless the source code is open, will not be updated.

 

[B S Magnet]

Over the past week, I found something which might bring Finder functionality on 10A96 and 10A190 a bit closer to par with the final Snow Leopard version of Finder.

The 10A96 and 10A190 builds of Finder still calculate disk and file size in base2, just like Leopard and earlier, while 10.6.0 and later display in base10. At the time, back in later 2009, I remember how the switch to base10 calculations caused some minor crankiness from folks who weren’t used to this.

So, it turns out, someone actually wrote a short utility in C to enable one to switch between base2 and base10 Finder calculating. Of course, the source code is geared for x86 and x64, and not ppc (be so ppc32 and/or ppc64). But after looking through the code, it seems this largely concerns specifying the endianness of calls — at least, as far as I understand.

The wall I’ve run into, owing to how I’m not a software developer, is that I tried to give tweaks to the code to recognize big-endianness only and ppc devices, and then I tried to compile it with Xcode 3.2 (the 10A96 version). As you can guess, I am clearly out of my depth here, as several failed build attempts can testify.

Perhaps one of you with a little more knowledge in this area might want to give this a go? It’s pretty short and probably a lot more simple to parse by better-experienced eyes.

[EDIT: corrected the link to point to the 10.6 version and source code]

 

[Project Alice]

Over the past week, I found something which might bring Finder functionality on 10A96 and 10A190 a bit closer to par with the final Snow Leopard version of Finder.

The 10A96 and 10A190 builds of Finder still calculate disk and file size in base2, just like Leopard and earlier, while 10.6.0 and later display in base10. At the time, back in later 2009, I remember how the switch to base10 calculations caused some minor crankiness from folks who weren’t used to this.

So, it turns out, someone actually wrote a short utility in C to enable one to switch between base2 and base10 Finder calculating. Of course, the source code is geared for x86 and x64, and not ppc (be so ppc32 and/or ppc64). But after looking through the code, it seems this largely concerns specifying the endianness of calls — at least, as far as I understand.

The wall I’ve run into, owing to how I’m not a software developer, is that I tried to give tweaks to the code to recognize big-endianness only and ppc devices, and then I tried to compile it with Xcode 3.2 (the 10A96 version). As you can guess, I am clearly out of my depth here, as several failed build attempts can testify.

Perhaps one of you with a little more knowledge in this area might want to give this a go? It’s pretty short and probably a lot more simple to parse by better-experienced eyes.

[EDIT: corrected the link to point to the 10.6 version and source code]

View attachment 1775272

Does this utility basically just change a setting, and it keeps?
If so, in theory we could change the setting manually. OR We could boot whatever SL build on an Intel Mac. They are universal afterall. I’ve booted the one on my PMG5 on a MacBook. Then run the utility, and boot it back on a PPC Mac.

 

[B S Magnet]

I recall it was 10a190.. it was a bit too fragile to setup though, and the only thing that didn’t function (obviously) was the iTunes Store, which requires a newer build of Safari. I believe 10a96 would be a lot more stable in this regard. And actually when you’re hacking it in, you risk breaking your install. That happened to me the second time I tried it…. The first time it worked fine.

Thanks for verifying.

I think a framework (or even code inside the kernel itself) was revised for 10A190 which fixed an issue that prevented iTunes 10.6.3 to work in the 10A96 environment. Or, alternately, manually bringing in the handful of frameworks or private frameworks inside the iTunes 10.6.3 installation materials causes another framework bundled with 10A96 to stop working correctly.

As 10.6.3 was produced well after Snow Leopard went on sale, SL’s developers were likely not thinking about iTunes 10’s impact on the SL-devs. But this framework/kernel component, when changed by iTunes 10+, had the side-effect of also breaking the ability for 10A96 to click and open items and folders from Finder; automatic “disappearance” of file icons, and an inability for Finder to display second-line details (like file size or number of items in a folder).

By your verification, whatever this early bug was in 10A96 seemed to have been fixed by the time of 10A190, and this fix also happened to make running later versions of iTunes (like 10.6.3) possible. Even as-is, running iTunes 9.2.1 in 10A96 (the version bundled with 10A96) produces strange graphic glitches in the play display window. It’s a shame, too, since iTunes 10.6.3 is the Swiss army knife of iTunes versions, running from 10.5.8 up to 10.14.6 — covering G4s. G5s, Core Duos, Core 2 Duos, Xeons, and from Core i3s to Core i9s.

 

[Wowfunhappy]

As for Safari the only option would be to mirror what was done with Leopard Webkit using the last known stable nightly, which is a large undertaking on its own.

Actually though, have any of you tried rebuilding Leopard Webkit? It obviously builds on 10.5 PPC, and Tobias said the code could be built for 10.6 Intel relatively easily, so it seems like 10.6 PPC ought to be doable as well.

You won't get the latest version of Webkit, obviously, but it would be a heck of a lot more up-to-date than what comes with Snow Leopard!

(I don't own any PPC Macs, I'm just watching from afar! )

 

[B S Magnet]

WikiPost update:

From a 10A96 build running on PowerBook5,8 (the same testing setup I’ve used throughout this project), I completed all testing with the kexts, bundles, and plug-ins for this build. I updated Table 4 to reflect this. It will be up to someone else who’s been working with the 10A190 build environment to test remaining kext/bundle/plug-in functionality over there.

(If you plan to begin testing either 10A96 or 10A190, you’ll run into less frustration if you limit your testing to just one computer, rather than bouncing back and forth between different machines).

Also, some kexts/bundles in Table 4 are only activated in certain environments — such as IR functionality for iMac G5s (shipped with a remote control), or Macs running on NVIDIA video cards (like Power Mac G5s). Some NVIDIA kexts, in fact, were deployed for Intel and PPC separately, and you’ll see those with “[kext/bundle name]PPC” in the filename.

(Several machine-specific kexts/bundles (such as the purple ones in Table 4) appear to be unique to Macs whose “human interface devices” — like mouse, trackpad, keyboard, topcase power button, and so on — run on USB internal buses, such as mid-2005 iBook G4s and late 2005 PowerBook G4s. My testing, with the late 2005 DLSD PowerBook, limited me to testing USB-specific I/O functions. If you’re running earlier hardware, you probably won’t need to worry about testing those, but you will probably need to test the ADB-related kexts.)

As for Frameworks, I may not be going through this testing regime anytime soon, unless I can team up with someone who’s cosy with tweaking/modifying those (including rebuilding them from AOSP source code) and who’s been working through those already. Again, I’m only testing with 10A96. I don’t feel as confident with altering Frameworks, as they’re more fundamental for lower-level functionality.

From this point with testing, I plan to step back to being more of a lurker and I’ll continue to monitor this thread — as opposed to leading more testing (unless I can team up with a Frameworks-savvy person). I’ll be leaving my test PowerBook up and running with 10A96 indefinitely to assess how well it holds up over time in its currently-modified state. (It is running fairly well, though I did catch seeing Finder crash and reload once whilst idling).

 

[MacPro2006VBox]

WikiPost update:

From a 10A96 build running on PowerBook5,8 (the same testing setup I’ve used throughout this project), I completed all testing with the kexts, bundles, and plug-ins for this build. I updated Table 4 to reflect this. It will be up to someone else who’s been working with the 10A190 build environment to test remaining kext/bundle/plug-in functionality over there.

(If you plan to begin testing either 10A96 or 10A190, you’ll run into less frustration if you limit your testing to just one computer, rather than bouncing back and forth between different machines).

Also, some kexts/bundles in Table 4 are only activated in certain environments — such as IR functionality for iMac G5s (shipped with a remote control), or Macs running on NVIDIA video cards (like Power Mac G5s). Some NVIDIA kexts, in fact, were deployed for Intel and PPC separately, and you’ll see those with “[kext/bundle name]PPC” in the filename.

(Several machine-specific kexts/bundles (such as the purple ones in Table 4) appear to be unique to Macs whose “human interface devices” — like mouse, trackpad, keyboard, topcase power button, and so on — run on USB internal buses, such as mid-2005 iBook G4s and late 2005 PowerBook G4s. My testing, with the late 2005 DLSD PowerBook, limited me to testing USB-specific I/O functions. If you’re running earlier hardware, you probably won’t need to worry about testing those, but you will probably need to test the ADB-related kexts.)

As for Frameworks, I may not be going through this testing regime anytime soon, unless I can team up with someone who’s cosy with tweaking/modifying those (including rebuilding them from AOSP source code) and who’s been working through those already. Again, I’m only testing with 10A96. I don’t feel as confident with altering Frameworks, as they’re more fundamental for lower-level functionality.

From this point with testing, I plan to step back to being more of a lurker and I’ll continue to monitor this thread — as opposed to leading more testing (unless I can team up with a Frameworks-savvy person). I’ll be leaving my test PowerBook up and running with 10A96 indefinitely to assess how well it holds up over time in its currently-modified state. (It is running fairly well, though I did catch seeing Finder crash and reload once whilst idling).

Are you using Leopard’s Finder on 10a96?

 

[B S Magnet]

Are you using Leopard’s Finder on 10a96?

No, I’m using 10A96’s Finder with 10A96.