Snow Leopard on Unsupported PowerPC Macs

[z970]

This project is now over 5 months underway, and although we have accumulated additional information, we still have not achieved a satisfying end product, outside of several scripts and doctored components. I have a proposition to this situation.

I don't foresee any significant progress being made if we continue trying to process several builds all at once, on top of managing each one's individual intricacies and nuances. It's too much to deal with, even for a coordinated group effort.

Similar to the suggested testing hardware mentioned in post #1, I propose that development efforts be focused upon getting one mostly pre-established build to full functionality, with another build serving as a "helper" build to source bits and pieces from to aid in this goal.

I propose that build 10A190 be used as the base environment as it is the last available with (relatively) reliable boot support at the vanilla kext and kernel level, with build 10A222 potentially being used as a source to inject select components such as the Cocoa-rewritten Finder and other pieces as the eventual need arises. Once a semi-reliable operating environment has been built using this method, we can then move on to merging certain components of 10.5.8 into it based on level of updatedness, which may or may not contain the side effect of fixing certain bugs all on its own.

At the moment, we ought to focus primarily on the Late 2005 G5s as the targeted hardware platform due to their PCIe interface, which currently boasts better support than AGP in vanilla 10A190. Once a desired end product has been achieved, we can then move on to AGP support in prior machines (which again, may or may not end up fixed right out of the gate just by the previous merging of 10.5.8).

Overall, I believe that this will present a focused and stage-organized alternative to the dominant development model so far, and is certainly at least a better equipped method going forward for the workload this requires.

Thoughts?

 

[Rikintosh]

I fully agree.

Currently we can compare the volunteers in this post with musicians and their instruments, in an orchestra, trying to play a song, but each one is playing a different song, at a different time, so it ended up becoming a mess. We need the conductor, we need exactly what z970mp said.

Someone needs to design a course of steps, so everyone who wants to help will know exactly what to do.

A small example:


- Download build 10a222. Install on your PCIe. Report what happened.

'- From the reports, create a list of what needs to be done to fix.
'--- Can it be fixed by modifying any text file?
'--- Can it be fixed by using part of another build?
'--- Can it be fixed by Xcode?

Once the necessary changes and corrections have been made, create an auto installer patch with the creation date in the name (example, patch-09.23.20) for organization. After a few patches, create a complete dmg image of the system for lay people who want to test. These images can be called "Mark" (example: SL.PPC-Mark-II.dmg).

In the end, when the system is stable on the target platform, just recreate the system installer, using pacifist. So the next step is to change the target platform for AGP machines.

 

[Hughmac]

As a non-developer I have been astounded by the efforts and successes of this project, and I thank you all for your good work.
As said above, a concerted and organised effort with one build might yield even better results

Cheers

Hugh

 

[NikolaPPC]

We need some file server where we can upload & organize new SL builds, books, documentation, behaviour notes, change logs etc.., so the new people who are testers or have the knowledge in this area can join and be up to date with the testing and making of this OS.

The information is scattered all over this thread, and it is tiring to list through it all.

This is all my personal opinion.


Cheers, Nikola!

 

[z970]

@Rikintosh That is a perfect analogy to what's going on here. All teams need coordination to find success.

I think your given example was also a very good starting point for job delegation.

@NikolaPPC A dedicated Macintosh Garden page will suffice for this purpose. We can condense all useful information thus far into the description as separate categories, similarly to how Mr. @alex_free constructed PPCMC 7's entry. And of course, thanks to the Garden's file sharing nature, exchanging different builds and their versions will be very easy to do.

It ought to be structured akin to post #1, albeit in a curated, relevant fashion (i.e., 10A261+ is irrelevant at this particular stage in time, each build preceding that gets a dedicated description box of different sectors and areas of hardware and software support along with current status, exploded development timeline, current user delegation, etc.).

Similar to the current situation with TenFourFox, the wiki here should be an all-comprehensive wealth of information, and the Macintosh Garden page should be an "optimized" rendition built to be a central summary only for what is currently directly relevant. Essentially like a parent and child, at least in computing terms.

Although I would keep conversation here because comments on MG cannot be edited once another user has commented afterward. This will also help to avoid page clutter there.

https://macintoshgarden.org/apps/snow-leopard-powerpc

 

[z970]

I have added rudimentary release notes condensed from reports of the time alongside each seed build within the first spoiler, under the "PPC COMPATIBILITY & PRELIMINARY NOTES" category.

This will make it much easier to select a base build, and create context for prior and succeeding versions.

Perhaps someone else can add the respective kernel versions.

 

[B S Magnet]

I propose that build 10A190 be used as the base environment as it is the last available with (relatively) reliable boot support at the vanilla kext and kernel level, with build 10A222 potentially being used as a source to inject select components such as the Cocoa-rewritten Finder and other pieces as the eventual need arises. Once a semi-reliable operating environment has been built using this method, we can then move on to merging certain components of 10.5.8 into it based on level of updatedness, which may or may not contain the side effect of fixing certain bugs all on its own.

At the moment, we ought to focus primarily on the Late 2005 G5s as the targeted hardware platform due to their PCIe interface, which currently boasts better support than AGP in vanilla 10A190. Once a desired end product has been achieved, we can then move on to AGP support in prior machines (which again, may or may not end up fixed right out of the gate just by the previous merging of 10.5.8).

You may certainly propose 10A190 be used as the “base environment”. And you may propose the A1117-series Power Mac G5s as a sole target system to build for.

But

I will formally object to its use given my assessment and also @vddrnnr’s assessment from working underneath the builds and finding that for the PPC environment, build 10A96 appears to have had the most PPC-parallel work applied to it, with 10A190 losing some of that stability and provisional support.

And

I will also formally object to the A1117 G5s (i.e., the PCIe G5s) being a sole target system to build for, for two reasons.

Reason 1: Several G4 and G5 systems have already demonstrated usability successes with one or more of the builds we have access to — often without dramatically significant adjustments. These include:

• the final G4 DLSD PowerBooks (which were clearly redesigned with the future in mind, but a future which did not come to pass);
• the final iBooks (alongside their cousin, the final PowerBook G4 12", tho 1.25GB RAM cap is probably pushing it for advanced use); and
• Power Mac, Xserve, and iMac G5s running with PPC970fx processors on up to the PPC970mp models of the A1117 period.

As one starts reckoning with equipment prior to about 2003, the adjustments have become far more significant if SL-PPC is to run at all (not too surprising given their earlier architectures). To close out all systems running SL-PPC reasonably well right now because they lack a PCIe bus would be shortsighted for the second reason.

Reason 2: By shutting out all testing to just PCIe Power Mac G5s (the PPC970mp series), which are few in supply and still spendy whenever they do turn up, you also lose a significant base of current testers (myself included) as well as future ones who’ve been invited to participate in developing a build of SL-PPC which just runs without a lot of tinkering. And right now, perhaps more than ever, the more folks we have tinkering, testing, and adding to our shared knowledge of a PPC-stable build(s) on a variety of later PPC setups, is precisely what this project needs to keep moving forward, slowly and steadily.

As I admonished someone a few posts back: “this is a marathon, not a sprint.”

It would be wise of us to stop treating this as a sprint, as doing so will leave us in cramps, exhausted, and plenty burnt out. In the long run, that is not a good plan. We’re all doing what we can by volunteering the free time we have, sharing the knowledge we bear, and using the equipment we have before us. That should be good enough.


EDITING TO ADD:

Also @z970mp, forgive me for being a bit direct here, but as I glance through the wikipost’s testing tables and notes, and also re-browsing through these the last 31 pages, I am struggling for the life of me to figure out what direct contributions you’ve applied to this project (i.e., what boxes you’ve installed SL-PPC on, what your findings were, what software did and didn’t work, and so on).

Like, perhaps I missed a crucial detail, but I do not believe you are in an experiential position at this time to suggest taking an executive lead or suggesting executive calls on this project (as opposed to an effective project management which comes with intimate knowledge of its workings), nor should anyone be trying to do so in a unilateral manner as with what you are proposing here.

Besides, you have FoxPEP and other projects with which you’ve been occupying your time. If you want to come work on SL-PPC, then do so by actually installing and testing it earnestly, and then reporting on your findings in the wikipost.

 

[z970]

@B S Magnet I agree with you; it's not a sprint. However, the idea was to organize what is currently being done so that progress will be smoother and less in disarray. As it happens, it is also possible that development will naturally advance faster in this way as opposed to 'everyone do what they can individualized and on their own'. What you suggest to advance this project is good enough - all I'm suggesting is a change in direction so that we can all benefit faster, while in a cleaner manner. - Because I'm going to be honest; I really don't see any useful end result, or completely plug-and-play image / installer arising out of this event if it continues exactly as it has for the past half-year. It just doesn't add up, at least not to me.

Regardless, I think you've indirectly hit the nail on the head... There is a disconnect here concerning not what the end result should be, but as to how those who wish to take part should most effectively spend time to achieve it. As I currently understand it, you seem to be treating 10A96 more or less as the end result in and of itself known as 'SL-PPC'. Where I'm coming from is that 10A96 and 10A190 are (rightly so) totally incomplete examples and using them in their present unfinished form on multiple models of AGP-based hardware to make final decisions for all PowerPC-based machines would make for an inaccurate final assessment, to say the least.

I proposed to temporarily focus all efforts on the PCIe G5s because that is presently the only family with full graphics support, irregardless of what that (again, only for the moment) means for the current pool of testers. In fact, as I see it, there is reason to believe that if it wasn't for the rest of the G5s being based upon the AGP standard, Apple may have included support for the PCIe G5s after all, given their evident similarities to the succeeding Intel iterations. What's important is if a cohesive final product can be created when these efforts become focused into an effective reticle, which is not to say it won't ever happen under the current method, but has not happened thus far. And again, that was the point.

-

As to your edit, what does it matter that I have not thus far 'contributed' to the project to the extent that yourself and others have? Speaking from a position where I have previously overseen and often singlehandedly composed multiple successful projects resulting in not only viable end products (two of which on their own offered extremely relevant experience to the topic at hand, lest we forget), but expansive public information resources as well, am I remiss in thinking that I lack the required "experience points" to dare suggest an alternative method to fashion a proven end product out of this project in its current state? Because even when given the best case scenario, we will still end up with an insecure 12-year-old OS only useful to a certain portion of a small enthusiast group surrounding a niche platform that the rest of the world has since moved on from almost 15 years ago.

Given the current perspective reality as a whole, I would think that whatever ultimately works best for the applicable market is preferred. But I digress.

Your second to last sentence; I appreciate that dismissal. If the others are in agreement, then perhaps I will take a crack at 10A96 / 10A190 in my own time in accordance with the proposed method alone, if that is what works best. Bigger horizons in life are rapidly making themselves apparent to me; regardless, I will find time to spend on this new endeavor, and if that ends up being my final "contribution" to the PowerPC community, then let it be so.

 

[Macbookprodude]

I don’t know. I also lack a Ti 1.0GHz box to test SL.

I could test it. It also worked on my G4 1.67 DLSD.

 

[B S Magnet]

Spoiler: Throwing this behind a an optional-to-view spoiler to spare folks who don’t need to see it

@B S Magnet I agree with you; it's not a sprint. However, the idea was to organize what is currently being done so that progress will be smoother and less in disarray.

For a development project, it really isn’t in any kind of disarray. Everyone who has tried it out and shared their experiences on the wikipost has been indispensable.

As it stands, this project isn’t a thing to be trying if one is shy with a terminal window. As for folks who are fine with digging into the system, the information has been demonstrably helpful for folks who’ve been applying their contributory work toward improved system functionality across multiple PPC systems.

As it happens, it is also possible that development will naturally advance faster in this way as opposed to 'everyone do what they can individualized and on their own'.

Your conjecture notwithstanding, what about the current pace do you find to be “slow” enough to somehow necessitate a “natural” speed-up? Under what metric? For what end?

It’s not as if this project is being pushed for a final release as if it were a product. To approach it as such isn’t constructive for the folks who’ve, again, been doing the work.

What you suggest to advance this project is good enough - all I'm suggesting is a change in direction so that we can all benefit faster, while in a cleaner manner.

So you have suggested.

You also solicit the suggestion with virtually no contribution to this project aside from, “Gosh, you all, this too slow for me, and it’s not a straightforward 1-to-5-step process for me to run Snow Leopard on my super-duper A1117 multicore G5. Pish.”

Because I'm going to be honest; I really don't see any useful end result, or completely plug-and-play image / installer arising out of this event if it continues exactly as it has for the past half-year. It just doesn't add up, at least not to me.

Your candour is noted.

For the folks who’ve been putting in the time and the work toward this project, by sharing what we know and learn along the way, the purpose for this project, at this time, is for us to understand how and why things work under the bonnet the way they do with a PPC-stable SL build and why there are stumbling blocks which are trivial in basic functionality, but may detract from a casual end-user experience (including bugs or issues with graphics acceleration or wifi cards). The why is extremely important here.

I proposed to temporarily focus all efforts on the PCIe G5s because that is presently the only family with full graphics support, irregardless of what that (again, only for the moment) means for the current pool of testers.

Your unsolicited proposal arrives as someone who’s volunteered little to no effort to investigate questions around any of the challenges raised around both the capabilities and limits of this PPC build. No one requested you or anyone else to come in here with a lasso to round up all these little dogies around the big ranch because it wasn’t orderly enough for your liking.

In fact, as I see it […] that was the point.

Thanks for your input.

As to your edit, what does it matter that I have not thus far 'contributed' to the project to the extent that yourself and others have?

Had you advanced any of your suggestions after having gotten involved and your hands dirty with the work over these last few months, even just a little bit, then you would have a much better grasp of what’s going on with our collective efforts.

Your hands are clean.

Nevertheless, you want to steer this project as someone who is, at best, behaving as a tourist and, at worst, as an armchair quarterback.

A working experience with the subject matter sort of matters. A lot.

First, do the work. Then, share what you discover in your experiments. Next, keep trying out new things. Add to the wikipost on page 1 with your test findings. Perhaps at some point the team can work to create a more thorough knowledgebase or even external wiki which might better organize conclusive findings into a streamlined how-to for folks wanting to try it out. If so, then maybe we can take into account some of your ideas as someone who’ve been applying the work.

At this time, we are not there, and I do not believe there is any value to rush that, either.

Speaking from a position where I have previously overseen and often singlehandedly composed multiple successful projects resulting in not only viable end products (two of which on their own offered extremely relevant experience to the topic at hand, lest we forget),

“Lest we forget…”

Hrm, you realize you weren’t recruited or hired by anyone to commandeer or traffic co-ordinate a project into which you’ve clocked virtually no labour or applied stake, yes?

am I remiss in thinking that I lack the required "experience points" to dare suggest an alternative method to fashion a proven end product out of this project in its current state?

Negligent? No. You are correct that you lack perspective on the project at this time.

Because even when given the best case scenario, we will still end up with an insecure 12-year-old OS only useful to a certain portion of a small enthusiast group surrounding a niche platform that the rest of the world has since moved on from almost 15 years ago.

I would call that a good start.

Given the current perspective reality as a whole, I would think that whatever ultimately works best for the applicable market is preferred.

As said previously, this project isn’t a product, and nothing involved with it needs to be rushed to a “market”, because that isn’t why the folks who’ve been working on this project in the first place are doing it. This is something you would have a grasp of knowing had you at least put some kind of minimum effort into testing and reporting on your findings in the wikipost.

Bigger horizons in life are rapidly making themselves apparent to me; regardless, I will find time to spend on this new endeavor, and if that ends up being my final "contribution" to the PowerPC community, then let it be so.

Announcing that you’re choosing to fall on your own sword if winds don’t blow your way isn’t a very good look.

 

[B S Magnet]

I could test it. It also worked on my G4 1.67 DLSD.

You ought to check in with @Larsvonhier, who mentioned in the wikipost that getting one of the SL builds to boot on the Ti 1.0GHz A1025 was successful, though hardware-accelerated graphics weren’t yet happening.

 

[z970]

@B S Magnet I think you misinterpreted much of what I said.

Either way, thank you for your time. I appreciate your presence.

 

[B S Magnet]

@B S Magnet I think you misinterpreted much of what I said.

Either way, thank you for your time. I appreciate your presence.

Nah. I understood just fine.

 

[Rikintosh]

It seems that things are tense here... So, I'll leave this photo of cute kittens to improve moods! 😄

 

[B S Magnet]

It seems that things are tense here... So, I'll leave this photo of cute kittens to improve moods! 😄

View attachment 961065

Imagining these kids as a litter of domesticated baby Snow Leopards.

 

[B S Magnet]

Question for all:

Do we have anyone here working on this project who is at home with compiling stuff via Xcode?

If there is, would anyone here want to give a few of these a run in Xcode to compile for PPC and see how they go?

Mac OS X 10.6 Source

Thanks!

 

[Rikintosh]

I am currently working on another project, when I finish with it, I will move to SL. But unfortunately I have no knowledge of xcode. My work so far has been only with logic and trial and error

 

[B S Magnet]

I am currently working on another project, when I finish with it, I will move to SL. But unfortunately I have no knowledge of xcode. My work so far has been only with logic and trial and error

That’s fair.

I mostly ever compile stuff using macports. I’ve managed to successfully compile one simple thing (G4fancontrol) with Xcode 3.2 for 10.6 10A96. I’m not a coder, so a lot of this is less than intuitive for me.

 

[Rikintosh]

That’s fair.

I mostly ever compile stuff using macports. I’ve managed to successfully compile one simple thing (G4fancontrol) with Xcode 3.2 for 10.6 10A96. I’m not a coder, so a lot of this is less than intuitive for me.

3.2? I thought SL supported xcode 4! Is the maximum version for ppc in SL 3.2? I tried to compile eduke32 for ppc, but it was total chaos, many outdated tools, and to obtain them it was necessary to compile them, a task that requires a lot of patience for someone who has a mere 1.33ghz g4. 4 days to compile gcc7. Unfortunately I was not successful

 

[B S Magnet]

3.2? I thought SL supported xcode 4! Is the maximum version for ppc in SL 3.2? I tried to compile eduke32 for ppc, but it was total chaos, many outdated tools, and to obtain them it was necessary to compile them, a task that requires a lot of patience for someone who has a mere 1.33ghz g4. 4 days to compile gcc7. Unfortunately I was not successful

There is a very specific build of Xcode bundled with the 10A96 Server build of SL — 3.2. Trying to install other versions of Xcode in lieu of the one which comes with that build, whilst one is using SL on PPC, won’t work.

I tried a copy of Xcode 3.2.2 (from the developer.apple.com site) on my 10A96 test build on my PowerBook, and it didn’t work.

So for sake of compiling the AOSP (Apple Open Source Project) content in the above link for SL-PPC, I think it would need to happen with Xcode 3.2.

 

[supremeleader573]

I have been following this closely, and I would like to make a contribution if I possibly can. I don’t have any G5 machines but I do have an MDD 2003 and a FW800 G4 and hopefully soon an iMac G4 (USB 2.0) which I could potentially use to test and/or develop for this project.

 

[NathanJHill]

Question for all:

Do we have anyone here working on this project who is at home with compiling stuff via Xcode?

If there is, would anyone here want to give a few of these a run in Xcode to compile for PPC and see how they go?

Mac OS X 10.6 Source

Thanks!

Yes this is fun stuff to poke through, but I do think we need to be thinking carefully about targeting our energy. That source code could be helpful but my experience was that a lot of Snow Leopard was PPC compatible already. The pieces that are intel only are crucial and not open source.

My hope was to figure out a way to pull the PPC compatible elements from a Snow Leopard release image and mix it in with the PPC compatible elements from Leopard 10.5.8. But the jump between Leopard and Snow Leopard didn’t lend itself to that. Never got it to boot. I still think about it and may try to tinker some more.

 

[B S Magnet]

Yes this is fun stuff to poke through, but I do think we need to be thinking carefully about targeting our energy. That source code could be helpful but my experience was that a lot of Snow Leopard was PPC compatible already. The pieces that are intel only are crucial and not open source.

So, in short, the components which make final SL builds (10.6.0, 10.6.1, etc.) actually function and are AOSP-based components can all basically be made to operate with a PPC build of SL (i.e., such as the developer preview versions we’re tinkering with now), and trying to compile them wouldn’t be helpful if somehow merging them into the 10.6.0d1 or 10.6.0d2 builds over the builds of AOSP-based components bundled with the d1 or d2 builds.

Does this sound about right?

 

[NathanJHill]

So, in short, the components which make final SL builds (10.6.0, 10.6.1, etc.) actually function and are AOSP-based components can all basically be made to operate with a PPC build of SL (i.e., such as the developer preview versions we’re tinkering with now), and trying to compile them wouldn’t be helpful if somehow merging them into the 10.6.0d1 or 10.6.0d2 builds over the builds of AOSP-based components bundled with the d1 or d2 builds.

Does this sound about right?

Well, I punched in my response from my iPhone, so I was trying to summarize and may not have been clear.

For starters, we know that the Snow Leopard mach kernel is different than the Leopard mach kernel. How different? Could we replace a newer Snow Leopard version of mach kernel onto one of the Snow Leopard dev images and get it to boot, for example? Sort of - it hangs at the WindowServer. The Snow Leopard kernel introduced definite changes and allowed for a 64-bit mode and grand central dispatch to handle multicore processors. It is PPC/386 code, likely for Rosetta purposes. (BTW, a Snow Leopard DVD will try to boot on a G5 but then come to a screen that says this OS is not compatible.)

I have a Snow Leopard 10.6.0 release DVD, which I hoped was maybe still sort of close enough to Leopard 10.5.8 to be workable. When I went through it to see what was PPC compatible, a huge chunk of the system was not, including for instance /System/Library/Extensions. And my experimentation was just trying to mix and match PPC files to copy over either from the Snow Leopard dev or final Leopard build. Some are workable (especially basic command line utilities and stuff), but the Snow Leopard beta wouldn't boot all the way in with the newer mach_kernel. Keep in mind, Snow Leopard rebuilt Finder in cocoa in Snow Leopard. That's likely a problem as the kernel may be expecting a different Finder altogether.

My hope was that we would find it fairly easy to take a final Snow Leopard dev, swap in some pieces from Leopard 10.5.8 (which are newer than the beta builds we have), and some pieces from an official Snow Leopard release to create some kind of Frankenstein option for our Macs. That hope has not born fruit.

Snow Leopard, especially the final versions, was built purposefully to exclude PowerPC. This wasn't a situation where you can trick the OS into thinking it is different hardware. Pieces of the OS are simply not PPC compatible, and many extensions include hardware kinds of support. I don't think Apple has made those open source.

The key to remember is that Leopard 10.5.8 is a more recent operating system than these Snow Leopard dev builds.

I'm still open to experimenting and trying new things. Maybe we can find a bare minimum of extensions needed to get Snow Leopard to boot with just enough PPC friendly elements from 10.5.8 and SL Dev builds copied over. Maybe there will be workarounds. Let's keep tinkering at least.

 

[MacPro2006VBox]

Any new progress since the last post? This thread has been quite dead since earlier this month.