Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
View attachment 2370068

After 4 years, yesterday i finally fixed my PowerBook G4 and decided to test the 10.6 PowerPC developer beta and after playing a bit with 10.6 10A190, I was able to develop a patch set to enable QE/CI for my ATI Mobility Radeon 9700.

All binaries are from 10.5.8 and I had to re-add the 9700 kexts and bundles, downgrade OpenGL.framework, QuartzCore.framework and CoreGraphics.framework. Both QuartzCore and CoreGraphics required stubs to load properly.

I think these patches should work for other AGP GPUs if combined with the correct kexts and bundles but I can't test since this PowerBook5,5 is the only PowerPC machine I have.
This is excellent, well done! Can you please provide a clear step-by-step so that this can be repeated on other machines and then added to the wiki?
 
This is excellent, well done! Can you please provide a clear step-by-step so that this can be repeated on other machines and then added to the wiki?

Seconding this!

Also, not quite clear on how to implement a stub to load those frameworks.

As I didn’t itemize them in my testing of 10A96 (Table 4), it means (and without pulling out my 10A96 mule, which is mothballed at the moment) these are frameworks which were nested originally inside a higher-level framework, correct? If not, then on what directory path do they reside in 10.5.8?

As for the Radeon 9700 kexts, the versions you uploaded — 1.5.48 — comport with my earlier testing, so that checks out.
 
  • Like
Reactions: Larsvonhier
This is promising, I will try it.

Do you think we could get ATI 1900XT (i.e. PCIe) to be supported?
Those patches should work for any GPU supported by 10.5 when paired with their kext and bundles from 10.5.8.
Seconding this!

Also, not quite clear on how to implement a stub to load those frameworks.

As I didn’t itemize them in my testing of 10A96 (Table 4), it means (and without pulling out my 10A96 mule, which is mothballed at the moment) these are frameworks which were nested originally inside a higher-level framework, correct? If not, then on what directory path do they reside in 10.5.8?

As for the Radeon 9700 kexts, the versions you uploaded — 1.5.48 — comport with my earlier testing, so that checks out.
You just have to copy the correct kexts and bundles from 10.5.8 to 10A190 /System/Library/Extensions/ then replace the framework folders attached to my earlier post on their respective locations.

/System/Library/Frameworks/OpenGL.framework
/System/Library/Frameworks/QuartzCore.framework
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework

I'm still testing these patches but so far i only found some Finder crashes due to the QuartzCore downgrade that I'll try to fix today.
 
Those patches should work for any GPU supported by 10.5 when paired with their kext and bundles from 10.5.8.

You just have to copy the correct kexts and bundles from 10.5.8 to 10A190 /System/Library/Extensions/ then replace the framework folders attached to my earlier post on their respective locations.

/System/Library/Frameworks/OpenGL.framework
/System/Library/Frameworks/QuartzCore.framework
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework

I'm still testing these patches but so far i only found some Finder crashes due to the QuartzCore downgrade that I'll try to fix today.

Thanks for the clarification.

Between my reply and yours to mine, I remembered I had a backup archive on my file server of the SL-PPC work I did with 10A96.

Aside from the 1.5.48 series of Radeon kexts mentioned earlier (in my testing, bringing over all AGP kexts from 10.5.8 — ATI and Nvidia alike — was a given, as Builds 10A96 and 10A190 omitted all AGP GPU kexts), it appears the nested CoreGraphics.framework was the version I’d brought in from 10.5.8 (1.409.8), along with a couple of others:

1713615074114.png


[Note: Anytime I set aside the 10A96 extension or framework, I did so by appending the origin, as seen above.]

What I didn’t change — on paper, at least — were OpenGL.framework and QuartzCore.framework:

1713615234571.png


I think I remember why:

When I did kext/framework swap-out testing from 10.5.8, I did so one at a time. If memory serves, I returned each of these two frameworks to the 10A96 version because a mismatch of one from 10A96 and the other from 10.5.8 — or vice-versa — would have prevented the WindowServer from initializing correctly (or, possibly, there was a hang or kernel panic I could see during verbose boot).

It would not have occurred to me, given how I was testing singular components one at a time, to do those two together, simultaneously.

Without being able to readily test this at the moment (though given this, I may try to pull it from storage over this coming week), I do think you cracked the puzzle of hardware acceleration for AGP GPUs which none of us has been able to figure out over the course of, well, coming up on these four years.

If me, Chris, or another SL-PPC tester can manage to duplicate your results over the coming days, you may have found the missing link we searched for the whole time. It may attract more folks to try A Clouded Leopard — either build — on their PowerPC Mac. To be able to get the most out of the GPU, in situations where hardware acceleration can be tapped into, would be amazing. :)
 
Thanks for the clarification.

Between my reply and yours to mine, I remembered I had a backup archive on my file server of the SL-PPC work I did with 10A96.

Aside from the 1.5.48 series of Radeon kexts mentioned earlier (in my testing, bringing over all AGP kexts from 10.5.8 — ATI and Nvidia alike — was a given, as Builds 10A96 and 10A190 omitted all AGP GPU kexts), it appears the nested CoreGraphics.framework was the version I’d brought in from 10.5.8 (1.409.8), along with a couple of others:

View attachment 2370184

[Note: Anytime I set aside the 10A96 extension or framework, I did so by appending the origin, as seen above.]

What I didn’t change — on paper, at least — were OpenGL.framework and QuartzCore.framework:

View attachment 2370185

I think I remember why:

When I did kext/framework swap-out testing from 10.5.8, I did so one at a time. If memory serves, I returned each of these two frameworks to the 10A96 version because a mismatch of one from 10A96 and the other from 10.5.8 — or vice-versa — would have prevented the WindowServer from initializing correctly (or, possibly, there was a hang or kernel panic I could see during verbose boot).

It would not have occurred to me, given how I was testing singular components one at a time, to do those two together, simultaneously.

Without being able to readily test this at the moment (though given this, I may try to pull it from storage over this coming week), I do think you cracked the puzzle of hardware acceleration for AGP GPUs which none of us has been able to figure out over the course of, well, coming up on these four years.

If me, Chris, or another SL-PPC tester can manage to duplicate your results over the coming days, you may have found the missing link we searched for the whole time. It may attract more folks to try A Clouded Leopard — either build — on their PowerPC Mac. To be able to get the most out of the GPU, in situations where hardware acceleration can be tapped into, would be amazing. :)
Using the 10.5.8 CoreGraphics without stubs does cause a WindowServer crash since many other frameworks from 10.6 needs Some newer CoreGraphics functions that does not exist in 10.5.8 CoreGraphics. Stubs are making those functions return 0 to avoid missing symbols that end up in a WindowServer crash

When you downgrade CoreGraphics to 10.5.8 which includes the WindowServer, the OpenGL framework might need to match since CoreGraphics could use newer GL features and both are required to get QE/CI. The QuartzCore framework had to also be downgraded to 10.5.8 to avoid soma graphical glitches that I think are related to the introduction of the IOSurface framework that did not exist in 10.5.8.
 
When you downgrade CoreGraphics to 10.5.8…

Small nitpick, but handy for your future reference:

10A96 was released around the same time as the 10.5.3 update (end of May/early June 2008).
10A190 was released between the 10.5.5 and 10.5.6 updates (October 2008).

As 10.5.8 was released days before the Golden Master of 10.6.0 (10A432) (late August 2009), components from it are markedly newer than what was available for either of the PPC-capable SL-PPC dev builds.

Technically, they’re upgrades. :)

Lastly: how do you check whether a component is a stub of another component?
 

It's not easy to use on a PPC Mac since the tool was made to be used on a modern Intel Mac.

If you successfully compiled a binary of this tool which can run on an older system — either PowerPC Macs or Intel Macs able to run Snow Leopard natively — I would be delighted if you could attach it here to make it available for testing use by other folks involved with this project.

If this isn’t possible, it would be really helpful for us if you could outline on what system (running which mac/OS X version) and build environment you used to compile the stub utility.

Additionally, the manner by which you tested SL-PPC’s frameworks, extensions, and other components for stub relationships using the utility would be doubly helpful for us to know. Namely, were you running the utility from a very recent Mac on the partition with SL-PPC mounted, or was it a bit more directly (i.e., run from within a booted SL-PPC)?

In short, if we can replicate exactly what you’re doing to yield your findings, it would help the project immensely. Cheers.
 
  • Like
Reactions: ChrisCharman
If you successfully compiled a binary of this tool which can run on an older system — either PowerPC Macs or Intel Macs able to run Snow Leopard natively — I would be delighted if you could attach it here to make it available for testing use by other folks involved with this project.

If this isn’t possible, it would be really helpful for us if you could outline on what system (running which mac/OS X version) and build environment you used to compile the stub utility.

Additionally, the manner by which you tested SL-PPC’s frameworks, extensions, and other components for stub relationships using the utility would be doubly helpful for us to know. Namely, were you running the utility from a very recent Mac on the partition with SL-PPC mounted, or was it a bit more directly (i.e., run from within a booted SL-PPC)?

In short, if we can replicate exactly what you’re doing to yield your findings, it would help the project immensely. Cheers.
What I had to do was use an older version of the Stubber tool without objc support because this version requires dlopening the binary which is not possible on a modern Intel Mac, copied the binaries from 10A190 to a Modern Mac running macOS Sonoma after using lipo to keep only the ppc7400 arch because Stubber doesn't like FAT binaries. Ran Stubber on Intel to generate the code file with the stubs then compiled the wrapped binary with the stubs code on 10.5.8 PPC using gcc.

The process is significantly harder than it sounds.
 
Thanks for the clarification.

Between my reply and yours to mine, I remembered I had a backup archive on my file server of the SL-PPC work I did with 10A96.

Aside from the 1.5.48 series of Radeon kexts mentioned earlier (in my testing, bringing over all AGP kexts from 10.5.8 — ATI and Nvidia alike — was a given, as Builds 10A96 and 10A190 omitted all AGP GPU kexts), it appears the nested CoreGraphics.framework was the version I’d brought in from 10.5.8 (1.409.8), along with a couple of others:

View attachment 2370184

[Note: Anytime I set aside the 10A96 extension or framework, I did so by appending the origin, as seen above.]

What I didn’t change — on paper, at least — were OpenGL.framework and QuartzCore.framework:

View attachment 2370185

I think I remember why:

When I did kext/framework swap-out testing from 10.5.8, I did so one at a time. If memory serves, I returned each of these two frameworks to the 10A96 version because a mismatch of one from 10A96 and the other from 10.5.8 — or vice-versa — would have prevented the WindowServer from initializing correctly (or, possibly, there was a hang or kernel panic I could see during verbose boot).

It would not have occurred to me, given how I was testing singular components one at a time, to do those two together, simultaneously.

Without being able to readily test this at the moment (though given this, I may try to pull it from storage over this coming week), I do think you cracked the puzzle of hardware acceleration for AGP GPUs which none of us has been able to figure out over the course of, well, coming up on these four years.

If me, Chris, or another SL-PPC tester can manage to duplicate your results over the coming days, you may have found the missing link we searched for the whole time. It may attract more folks to try A Clouded Leopard — either build — on their PowerPC Mac. To be able to get the most out of the GPU, in situations where hardware acceleration can be tapped into, would be amazing. :)

Welp, couldn’t wait. (Things I should have been working on today: I’m so sorry.)

Instead of pulling the A1138 mule from storage to try the OpenGL/QuartzCore mod, I cloned the mule’s backup over to a partition on my A1139. (This build, of course, is 10A96, not 10A190.)

The usual crankypants of a waking OS finding itself in slightly altered hardware notwithstanding (specifically, wifi not working, since I’ve never tried to get AirPort working, much less an AirPort-native 802.11n Broadcom card in the PCMCIA slot), I duplicated educovas’s findings successfully. In my case, only two items — OpenGL.framework and QuartzCore.framework — required swapping, as the others they called out were in place already from earlier testing.


1713727351553.png


Not only was I able to verify it worked, via System Profiler (note how it’s still named glaciologia, the name of the 15-inch A1138), but I also decided to open VLC 2.0.10 to try a 480p video I’d used previously on the mule. As with the A1138 mule (sorry, I can’t help but keep calling its unusual hardware quirks as anything but, save for monster of Frankenstein, but nah), the video pulled up and performed the same as it would, relying on the CPU (as Apple intended).

But whereas getting video to play nicely on VLC versions built for PowerPC Macs has always been, well, a challenge, I opened the clip in a VLC playlist. At first, it was the (expected) choppy, unwatchable video. Then I opened preferences in simple view to check the video output module and noticed it was set to “Default” (whatever that is, probably CPU playback with no acceleration).

1713727206217.png


I set a manual override to OpenGL, then restarted the clip. Not only did it not stutter or drop frames, but it also zoomed out to full screen fluidly. There were no dropped frames. After the clip ended, I noticed the CPU load never exceeded 70–75 per cent. (Software video playback on QuickLook/QT7.7 works, but it typically spikes the CPU to the 95–99 per cent range.) Whether this is an indirect indicator that VLC is taking advantage of the GPU, or that VLC is lighter than QuickTime 7.7/CoreGraphics when relying on GPU playback, this was still pleasantly surprising to see.

I’ll need to figure out AirPort/Brcm43xx and the PCMCIA slot issue at another time (as even the internal AirPort card is not registering), but it looks like I have more table updating to do over on the wikipost — again, as time permits.
 
Welp, couldn’t wait. (Things I should have been working on today: I’m so sorry.)

Instead of pulling the A1138 mule from storage to try the OpenGL/QuartzCore mod, I cloned the mule’s backup over to a partition on my A1139. (This build, of course, is 10A96, not 10A190.)

The usual crankypants of a waking OS finding itself in slightly altered hardware notwithstanding (specifically, wifi not working, since I’ve never tried to get AirPort working, much less an AirPort-native 802.11n Broadcom card in the PCMCIA slot), I duplicated educovas’s findings successfully. In my case, only two items — OpenGL.framework and QuartzCore.framework — required swapping, as the others they called out were in place already from earlier testing.


View attachment 2370604

Not only was I able to verify it worked, via System Profiler (note how it’s still named glaciologia, the name of the 15-inch A1138), but I also decided to open VLC 2.0.10 to try a 480p video I’d used previously on the mule. As with the A1138 mule (sorry, I can’t help but keep calling its unusual hardware quirks as anything but, save for monster of Frankenstein, but nah), the video pulled up and performed the same as it would, relying on the CPU (as Apple intended).

But whereas getting video to play nicely on VLC versions built for PowerPC Macs has always been, well, a challenge, I opened the clip in a VLC playlist. At first, it was the (expected) choppy, unwatchable video. Then I opened preferences in simple view to check the video output module and noticed it was set to “Default” (whatever that is, probably CPU playback with no acceleration).

View attachment 2370603

I set a manual override to OpenGL, then restarted the clip. Not only did it not stutter or drop frames, but it also zoomed out to full screen fluidly. There were no dropped frames. After the clip ended, I noticed the CPU load never exceeded 70–75 per cent. (Software video playback on QuickLook/QT7.7 works, but it typically spikes the CPU to the 95–99 per cent range.) Whether this is an indirect indicator that VLC is taking advantage of the GPU, or that VLC is lighter than QuickTime 7.7/CoreGraphics when relying on GPU playback, this was still pleasantly surprising to see.

I’ll need to figure out AirPort/Brcm43xx and the PCMCIA slot issue at another time (as even the internal AirPort card is not registering), but it looks like I have more table updating to do over on the wikipost — again, as time permits.
That's cool! I've looked at QuartzCore from 10A96 and it looks mostly similar to 10.5.8. I think it might not be needed for this build since it does not have IOSurface yet. All my work is on 10A190 so I'm not sure what's needed or not for 10A96.

Do you know if sleep works properly on 10A96?
 
  • Like
Reactions: ChrisCharman
That's cool! I've looked at QuartzCore from 10A96 and it looks mostly similar to 10.5.8. I think it might not be needed for this build since it does not have IOSurface yet. All my work is on 10A190 so I'm not sure what's needed or not for 10A96.

I’m not sure what function IOSurface serves. If going by name and timing alone, this makes me think it was related to the earliest versions of what became iOS, as the earliest versions of the OS for iPhone, before it came to be called iOS, was built directly from the same source code as Leopard. IOSurface suggests something adjacent to the HID of a touch-capacitive screen.

My memory about QuartzCore, meanwhile, was incorrect: I thought earlier I had to bring that over from 10.5.8 to restore QuickLook functionality, but a search through this thread’s archives confirms it was the manual installation of QuickTime 7.7.0 for Leopard which restored that function. My bad!

Do you know if sleep works properly on 10A96?

It does, insofar as how i have my G4 laptops configured:

I use the old SmartSleep.prefPane (2.6) to have my laptops go directly to hibernate, not sleep. Hibernate and wake from hibernate works in 10A96.

Yah, this may be the coffee equivalent of using an espresso machine to make an Americano instead of dumping a spoonful of Nescafé crystals into a mug of hot water, but I came to prefer having the machine state preserved as I left it if I had to remove a battery or open it for maintenance.

In my experience, the late PowerPC laptops are extremely forgiving about hibernating. The A1139 I used today had, in 2020, been disassembled and was waiting a few months for a replacement power board. After installing the replacement and powering it on, the system restored from hibernate without a hitch. :)
 
IOSurface

Share hardware-accelerated buffer data (framebuffers and textures) across multiple processes. Manage image memory more efficiently.

Overview

The IOSurface framework provides a framebuffer object suitable for sharing across process boundaries. It is commonly used to allow applications to move complex image decompression and draw logic into a separate process to enhance security.



Source: https://developer.apple.com/documentation/iosurface
 
  • Like
Reactions: B S Magnet
Screenshot 4-28-24 12.59.39 AM.png


So, after a lot of work I got build 10A222 booting on PPC.

Hundreds of binaries lost ppc support and had to be downgraded to 10A190 and older Like Preference Panes, most of /Applications, /bin, Kexts and some apps in CoreServices like Finder. Also had to write a kext to stub a couple kernel symbols required by the old IONDRVSupport kext and compile /usr/sbin/notifyd from AOSP.

I haven’t tested much this build and patches so I don’t know how stable it is.

I’ve imaged a patched install including some updated files and apps, QE/CI, WiFi and Bluetooth patches. This image should hopefully work with all PowerPC Macs that were supported by 10.5.8.

 
View attachment 2372550

So, after a lot of work I got build 10A222 booting on PPC.

Hundreds of binaries lost ppc support and had to be downgraded to 10A190 and older Like Preference Panes, most of /Applications, /bin, Kexts and some apps in CoreServices like Finder. Also had to write a kext to stub a couple kernel symbols required by the old IONDRVSupport kext and compile /usr/sbin/notifyd from AOSP.

I haven’t tested much this build and patches so I don’t know how stable it is.

I’ve imaged a patched install including some updated files and apps, QE/CI, WiFi and Bluetooth patches. This image should hopefully work with all PowerPC Macs that were supported by 10.5.8.


Holy …. That’s awesome news… AND IS THAT GRAPHICS ACCELERATION I SEE?!
 
  • Like
Reactions: ChrisCharman
View attachment 2372550

So, after a lot of work I got build 10A222 booting on PPC.

Hundreds of binaries lost ppc support and had to be downgraded to 10A190 and older Like Preference Panes, most of /Applications, /bin, Kexts and some apps in CoreServices like Finder. Also had to write a kext to stub a couple kernel symbols required by the old IONDRVSupport kext and compile /usr/sbin/notifyd from AOSP.

I haven’t tested much this build and patches so I don’t know how stable it is.

I’ve imaged a patched install including some updated files and apps, QE/CI, WiFi and Bluetooth patches. This image should hopefully work with all PowerPC Macs that were supported by 10.5.8.


Good work!

It would be wonderful if you could share a readme-style recap of everything swapped out from 10A190 (and 10.5.8) to make 10A222 boot successfully.

[EDIT to add: Sharing a rundown of swap-outs and mods would go a long way to help others to be able to replicate your successful boot environment. This also makes it easier to other testers to adjust results to eke even better stability and, possibly, other novel compatibility combinations.]
 
Last edited:
  • Like
Reactions: ChrisCharman
Good work!

It would be wonderful if you could share a readme-style recap of everything swapped out from 10A190 (and 10.5.8) to make 10A222 boot successfully.

[EDIT to add: Sharing a rundown of swap-outs and mods would go a long way to help others to be able to replicate your successful boot environment. This also makes it easier to other testers to adjust results to eke even better stability and, possibly, other novel compatibility combinations.]
Fantastic work @educovas! I would also like to know what remains of 10A222 and what specifically was replaced from earlier builds, when you have the time to write this up. Your contributions are greatly appreciated. Thank you ☺️
 
  • Like
Reactions: B S Magnet
Can’t really write everything I’ve replaced because there are too many files so I’ve zipped the folder I have with all the files.
Since that includes everything, a lot in there is not necessary for actually booting like updated Safari and Quicktime, wallpapers, most Frameworks and PrivateFrameworks, bluetooth and WiFi files and maybe something else I might forget.

I’ll try to write from which version I’ve downgraded the files to but I’ll definitely forget something

10.5.8:
Graphics, WiFi and Bluetooth kexts
Bluetooth patches
Safari and QuickTime
Finder and related like QuickLook and Quartz
QE/CI patches like OpenGL, ApplicationServices, QuartzCore

10A96:
WiFi patches

AOSP:
notify-23

All the rest should be from 10A190


There is also IONDRVSupportShim.kext that’s the kext I wrote to stub the missing kernel symbols for the 10A190 kext to load with the d3 kernel.


 
Can’t really write everything I’ve replaced because there are too many files so I’ve zipped the folder I have with all the files.
Since that includes everything, a lot in there is not necessary for actually booting like updated Safari and Quicktime, wallpapers, most Frameworks and PrivateFrameworks, bluetooth and WiFi files and maybe something else I might forget.

I’ll try to write from which version I’ve downgraded the files to but I’ll definitely forget something

10.5.8:
Graphics, WiFi and Bluetooth kexts
Bluetooth patches
Safari and QuickTime
Finder and related like QuickLook and Quartz
QE/CI patches like OpenGL, ApplicationServices, QuartzCore

10A96:
WiFi patches

AOSP:
notify-23

All the rest should be from 10A190


There is also IONDRVSupportShim.kext that’s the kext I wrote to stub the missing kernel symbols for the 10A190 kext to load with the d3 kernel.


Thanks @educovas! I will download your modified 10A222 build and the zipped folder of replacement parts when i have a chance and do some testing ☺️
 
  • Like
Reactions: B S Magnet
View attachment 2370206In addition to the post #513, replacing /System/Library/SystemConfiguration/Apple80211Monitor.bundle with the 10.5.8 (10A96 might also work), seems to resolve the System Profiler and the greyed out WiFi menubar icon bugs.

Just in case, did anyone fix Network Sharing from 10.6? System Preferences crashes when I try to enable internet sharing there.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.