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.
I’m adding an appended post here with a note on my own testing using the 10A96 build entirely and choosing, for now at least, to forgo the 10A190 build:

Given my own testing work within 10A96 whilst also reading through the many experiences and findings from other testers here (how swapping frameworks in 10A190 reveals how that build appears to be much more touchy about making frameworks/extensions alterations), I’ve been idly thinking about what probably happened in between day 96 and day 190 during the development cycle.

Sometime within that window, the executive decision came down to drop most, if not all further PPC development. Once they made that decision, subsequent energy and attention left the PPC architecture for complete focus on finalizing a stable Intel release.

Barring access to those intervening nightly builds, I’ve been operating on an approach/strategy to improve upon 10A96 in any of the ways we can and considering 10A190, 222, etc. to be spare parts bins in those instances where a tiny bit more PPC code got pushed through.

With the 10A96 build, which I’ve been running (delayed for several weeks as I waited for a replacement DC-in board), I’m finding its overall stability is surprisingly good, even robust — even if the many early glitches of the Cocoa-written Finder and other UI/UX features are holding it back from looking and behaving as polished as the subsequent public release and updates we all came to know and use.

tl;dr: This is a long-winded way of throwing forward the idea that we find later versions of the UI/UX which can be, I guess, back-ported (unsure if that’s the correct word here) to the 10A96 build — which may ultimately be the most stable PPC build underneath. This may be where our energies might be best spent.

Thoughts?
 
Ok, after a lot of research, I found that after build 190, the ppc code is still in the system (btw, a lot of ppc code is still in the system even after it was officially released) later versions do not work, simply because they stopped compiling the GUI for ppc . By swapping files with version 190 files, the system can be booted.

I am studying to find out what files these are. If all goes well, we may have a version very close to the final version, for ppc.
 
For those folks who’ve been working on trying out later-versioned kexts and frameworks found in 10.5.8 over the versions found in 10.6.0 (per the table in the wiki post), are you able to report how each swap positively impacts the performance and/or stability of running 10A96 or 10A190 beyond solely “10.6.0 still works”? Having that knowledge is just as important — perhaps even more so — as just seeing if a newer kext/framework works.
 
Tested the build 190 on the powerbook g4 17 1.33ghz (radeon 9600 64mb). As expected, without support for hardware acceleration on the video card. No wifi, bluetooth or ethernet.

My first impression is that the system is very unstable, slow, and unreliable. At the first boot, the machine froze. In the second I managed to work. The finder has graphical glitches, and stops responding randomly, just like any software you run (it may randomly stop responding). Even to turn the machine off, the machine randomly does not turn off, it just stays on with a black screen.

I will start playing around exchanging files and see what I can do.
 
  • Like
Reactions: ChrisCharman
Tested the build 190 on the powerbook g4 17 1.33ghz (radeon 9600 64mb). As expected, without support for hardware acceleration on the video card. No wifi, bluetooth or ethernet.

My first impression is that the system is very unstable, slow, and unreliable. At the first boot, the machine froze. In the second I managed to work. The finder has graphical glitches, and stops responding randomly, just like any software you run (it may randomly stop responding). Even to turn the machine off, the machine randomly does not turn off, it just stays on with a black screen.

I will start playing around exchanging files and see what I can do.
Really appreciate the effort you are making, thanks :)

Cheers :)

Hugh
 
Last edited:
I have been trying to install 10.6 on my iMac G4 from 10.5.8, but have not succeed. Even though I was able to bring it up from Tiger to 10.5.8. I have bid the DVD installer 10.5 from eBay and will try again. I am also going to upgrade my HDD to SSD and install more ram as my iMac at the moment has 1.25 GB DDR Ram to 2 GB and my iMac is with 1 Ghz. I wonder if it's too old or less power to install 1.6?. Anyone could help to explain it to me. I'm new to Mac. But I have found the iMac G4 in my partner's waldrobe. It was borken for almost 10 years and I just fixed till it works again. Thank you.
118595108_615644435821599_3333348338445498058_n.jpg
 
Last edited:
Tested the build 190 on the powerbook g4 17 1.33ghz (radeon 9600 64mb). As expected, without support for hardware acceleration on the video card. No wifi, bluetooth or ethernet.

My first impression is that the system is very unstable, slow, and unreliable. At the first boot, the machine froze. In the second I managed to work. The finder has graphical glitches, and stops responding randomly, just like any software you run (it may randomly stop responding). Even to turn the machine off, the machine randomly does not turn off, it just stays on with a black screen.

I will start playing around exchanging files and see what I can do.

If you have the energy and time, try 10A96 in lieu of 10A190 and compare notes. It may seem counter-intuitive, but this build appears to be more stable on PPCs than the later build.
 
  • Like
Reactions: ChrisCharman
Hi @B S Magnet and everyone,

RL has been keeping me away at present but I'm not gone.
BSM I've been following the same path as you and I came to the same conclusions you have,
the 10A96 seems to be one of the final PPC "aware" releases all that came after ( at least after 10A190 ) have PPC code
that was still not removed at the time but was not maintained anymore.
I also feel it's faster than Leopard. Your thoughts?

Looking forward given what we have found so far I think we can get "workstation" G4s and G5s working fully with some
parts from 10.5.8 if needed as long as we have PCIe or PCI Geforce's on our systems, all other options
( powerbooks and iMacs ) will have some limitations unless we can find some way of getting the graphical
components of 10.5.8 working in our SL betas.

On the software side using SL ( even betas ) give us more options for building SL only software
as I've posted before ( Cord for example ) and browsing is ok because we still have TFF ( working great )
and @wicknix is still pushing Arcticfox for SL ( the beta for PPC Leopard
runs fast and more or less stable ) so if we can also get @internetzel to help with directions/insight
it will be great to have LWK working again :)

Best regards,
voidRunner
 
I spent some time today experimenting with trying to get QE working on a 2004 iBook G4 12" (PowerBook6,5) basing off of the pre-built 10A190 image.

I started by doing a clean install of 10.5.4, dumping the kexts with kextstat and ioreg -l. I noticed that my system (Mobility Radeon 9200) was using ATIRadeon8500.kext and ATIRadeon8500GLDriver.bundle.

I coped these to my 10.6 install:
Code:
ATIRadeon.kext
ATIRadeon8500.kext
ATIRadeon8500DVDDriver.bundle
ATIRadeon8500GLDriver.bundle
ATIRadeon8500VADriver.bundle

and deleted the kext cache.

On boot of 10.6, none of these kexts loaded themselves, but I was able to manually load ATIRadeon8500.kext using kextload, and it successfully started with no KP. However, it did not enable QE. I then tried to kextload ATINDRV.kext (without copying it to /S/L/E on 10.6):

Code:
kextload -t ATINDRV.kext

but got the error:
Code:
Validation Failures:
    Info dictionary missing required property/value:
        OSBundleLibraries

On my 10.5 kextstat, I noticed the following was loaded:
Code:
com.apple.driver.ndrv.ATY,Via.0x16091cbc (1.0.0b94)
but this does not appear on 10.6.

What's missing in the chain to load the GLDriver.bundle parts? Is this the fault of ATINDRV.kext?
 

Attachments

  • 10.5-kextstat.txt
    8.1 KB · Views: 155
  • 10.6-kextstat.txt
    8.6 KB · Views: 148
  • ioreg.zip
    62.6 KB · Views: 251
Does anyone have a change log for these builds?

There isn’t a complete change log available publicly but seed notes for each seed detailing some of the changes were made available to developers at the time and some of these were leaked, mainly via websites like ‘appleinsider’ and ‘Worldofapple’ et al. Unfortunately as these were covered by NDA under the developer licence agreement they were subsequently removed. I have managed to locate some of the seed notes for a few of the preview builds and will upload them to the thread when i get a chance.
 
  • Like
Reactions: B S Magnet
Hi @B S Magnet and everyone,

RL has been keeping me away at present but I'm not gone.
BSM I've been following the same path as you and I came to the same conclusions you have,
the 10A96 seems to be one of the final PPC "aware" releases all that came after ( at least after 10A190 ) have PPC code
that was still not removed at the time but was not maintained anymore.
I also feel it's faster than Leopard. Your thoughts?

The build of Finder on 10A96, which I understand is the first Cocoa Finder, is undoubtedly faster than the 10.5.8 Finder.

I experience this variation between spending hours on the 10A96 build on my A1138 DLSD, and then when hopping onto my A1139 DLSD with 10.5.8, it feels sluggish by contrast. I am ascribing this to Finder and probably other components having already been re-written in Cocoa for the early SL. It would be nifty to know what else was re-written in Cocoa in 10A96 and what remained as Carbon.
 
Excuse me if I say something stupid, I'll just share my reasoning, which may open your minds.

I believe that the ATI driver itself is not incompatible. What happens is that in the kext, there is a kind of table with several silly numbers (1.0, 1.2, 1.27) beside the libraries that the driver requires to work. From what I researched, the kernel of mac os x BEFORE loading a driver, it checks if there are any dependents that are written in kext (xyz.OIF) and their respective versions. The versions are these stupid numbers, but in fact, they are not stupid, they are a requirement. Each of these versions is directly linked to a darwin kernel version, for example, if it's written 1.2, it means that it requires mac os 10.4, if it was written 1.3, it means that it requires mac os 10.5, if it was 1.3.2, it would mean osx 10.5 .8. Well, the numbers I just wrote are just illustrative, they are not exactly these, but if you research how the Darwin Nucleus (major version, minor version) works, you will understand what I'm talking about. It turns out that the drivers present in osx 10.5, say that they only support 10.5. When the nucleus of 10.6 tries to load, he sees that it is written that the drivers were made for 10.5 and does not load them, so theoretically, just edit the kext and change the numbers for numbers that match darwin's version 10.6 so the kernel would load the drivers correctly.
 
Last edited:
After some more testing, I did some additional comparisons between 10.5 and 10.6 related to ATIRNDRV.kext, AppleNDRV.kext and found them to be exactly the same binaries.

I tried changing the version numbers around as Rikintosh has suggested, but the kext still will not load automatically. However, when the ATIRadon8500.kext is loaded manually, I'm seeing it registered in ioreg... but still no QE. I tried killing loginwindow to restart the GUI, changing resolutions, etc... still no dice.

This lead me to believe that maybe I had to load this kext before the GUI started. I resorted to creating a LaunchDaemon to load the kext early in the boot process. This results in ioreg setting the ATIRadeon8500, registered, matched, and active! But still no QE. :( Also absent is the kextstat entry for
Code:
com.apple.driver.ndrv.ATY,Via.0x16091cbc (1.0.0b94)
BUT!!! ioreg shows the ATIRadeon8500GLDriver and DVD Bundle driver as up and running. And these are all showing up in the same spot:
Code:
Root -> PowerBook6,5 -> MacRISC2PE -> pci@f0000000 -> AppleMacRiscAGP

I'm also missing these in ioreg compared to 10.5:
Code:
ATIR2002DContext  <class ATIR2002DContext, !registered, !matched, active, busy 0, retain 5>
ATIR2002DContext  <class ATIR2002DContext, !registered, !matched, active, busy 0, retain 5>
ATIR200Surface  <class ATIR200Surface, !registered, !matched, active, busy 0, retain 5>
ATIR200GLContext  <class ATIR200GLContext, !registered, !matched, active, busy 0, retain 5>
ATIR200Surface  <class ATIR200Surface, !registered, !matched, active, busy 0, retain 5>
but I'm not sure these are being used because they show as !registered.

I'm kinda at a loss now as to why the kext won't load on it's own, and why I don't see com.apple.driver.ndrv.ATY,Via.0x16091cbc... I can't seem to figure out who loads that guy on 10.5! I think if whatever dependency I'm missing was fixed, I'd have QE working.
 
After some more testing, I did some additional comparisons between 10.5 and 10.6 related to ATIRNDRV.kext, AppleNDRV.kext and found them to be exactly the same binaries.

I tried changing the version numbers around as Rikintosh has suggested, but the kext still will not load automatically. However, when the ATIRadon8500.kext is loaded manually, I'm seeing it registered in ioreg... but still no QE. I tried killing loginwindow to restart the GUI, changing resolutions, etc... still no dice.

This lead me to believe that maybe I had to load this kext before the GUI started. I resorted to creating a LaunchDaemon to load the kext early in the boot process. This results in ioreg setting the ATIRadeon8500, registered, matched, and active! But still no QE. :( Also absent is the kextstat entry for
Code:
com.apple.driver.ndrv.ATY,Via.0x16091cbc (1.0.0b94)
BUT!!! ioreg shows the ATIRadeon8500GLDriver and DVD Bundle driver as up and running. And these are all showing up in the same spot:
Code:
Root -> PowerBook6,5 -> MacRISC2PE -> pci@f0000000 -> AppleMacRiscAGP

I'm also missing these in ioreg compared to 10.5:
Code:
ATIR2002DContext  <class ATIR2002DContext, !registered, !matched, active, busy 0, retain 5>
ATIR2002DContext  <class ATIR2002DContext, !registered, !matched, active, busy 0, retain 5>
ATIR200Surface  <class ATIR200Surface, !registered, !matched, active, busy 0, retain 5>
ATIR200GLContext  <class ATIR200GLContext, !registered, !matched, active, busy 0, retain 5>
ATIR200Surface  <class ATIR200Surface, !registered, !matched, active, busy 0, retain 5>
but I'm not sure these are being used because they show as !registered.

I'm kinda at a loss now as to why the kext won't load on it's own, and why I don't see com.apple.driver.ndrv.ATY,Via.0x16091cbc... I can't seem to figure out who loads that guy on 10.5! I think if whatever dependency I'm missing was fixed, I'd have QE working.

Is the kernel running in 32bit or 64bit mode? The seed notes for 10A190 referenced a ‘known issue‘ with QE with at least the 64bit kernel but possibly both and I’m currently not aware which build patched all of the graphics issues with the earlier builds - there were Nvidia specific and ATi specific bugs ranging from graphical tearing, and ‘pink’ anomalies to Hibernation issues. I don’t think that full graphics acceleration was enabled until much later in the development process which is probably going to make progress more difficult.

‘...Graphics acceleration is not yet supported which may cause programs which require graphics acceleration to run incorrectly.’ - Snow Leopard Developer Preview build 10A190 Seed Notes #post374
 
  • Like
Reactions: jkchr1s
Hi @jkchr1s and @Rikintosh,

I don't have my DLSD with me right now but if I remember correctly I replaced AppleNDRV and ATINDRV
with the ones from Leopard.
In my case my laptops with Radeon 9600 and 9700 the kexts are loading after putting in the 10.5 versions
the only problem is we still don't have full QE/CI.

But things can be "optimized" on these machines:

1. To get QuartGL working enable it with osx86tools
2. also see posts number #169, #187, #381 and #443 .

Best regards,
voidRunner
 
@ChrisCharman I'm definitely running in 32-bit mode as this is a G4. Confirmed in uname -a.

I missed that point in the release notes... and I do recall that being a problem back in the Hackintosh days now that you mention it.

@vddrnnr thanks, I'll give that a shot. They appeared to only differ in version numbers, so that may make sense to restore all of those from 10.5. The binaries were the exact same.
 
@vddrnnr oh I see what you did in those posts... the combination of files/Info.plist mods I was using did not throw the warning when loading Radeon8500.kext, where the ATINDRV and ATIRNDRV kexts from 10.5 do. However, ioreg is now reporting the exact same thing as in 10.5, which is a good thing.

As you said, still no QE.. but the framework mods and release notes make me think this may not be easily solved. I get what you guys were all saying now... this stuff was probably fixed in Intel-only binaries.

I did manage to get OpenGL working as you guys did... but that doesn't help the community. I just thought I'd take some of the same steps back in the Hackintosh days to see if maybe I could come up with a different result. It seems odd that some PCI/PCIe cards are working but AGP cards are not. What's strange is OpenGL Extensions viewer tests pass, but I only get a black screen when I run the tests.

As you guys previously mentioned, I recall AGPGart as a key player in this for Hackintosh... but IIRC those devices were detected as PCI and not AGP, which is not what I am seeing in this configuration.
 
Last edited:
Hi @jkchr1s,

I think the problem in our case is dependencies in the bundles that are required to
get QE/CI working which have dependencies on specific versions of frameworks and libraries
that may be Leopard only.
One of the things I was not able to test until now is trying older versions of the kexts/bundles ( versions from before 10.5.8 )
and see if those load correctly because our SL 10A96 if from 2008 which is before the last Leopard versions
came out.

PS. this is for ATI cards. In the case of the geforce 5200 which works in PCI and not AGP maybe it is the other way
because in that case we have SL drivers

Best regards,
voidRunner
 
Last edited:
Anyone mind making a disk utility installable version of 10a96? Looking to give that a go on my G5. I think it would be ideal if we could port the cocoa finder from 10a190 to 10a96... as I had no issues with it. According to Geekbench my scores were higher in SL than in Leopard despite the lack of Quartz Extreme acceleration on the AGP FX5200 Ultra.
 
Anyone mind making a disk utility installable version of 10a96? Looking to give that a go on my G5. I think it would be ideal if we could port the cocoa finder from 10a190 to 10a96... as I had no issues with it. According to Geekbench my scores were higher in SL than in Leopard despite the lack of Quartz Extreme acceleration on the AGP FX5200 Ultra.

The disk drive in the SL works perfectly. The problem seems to be with the file system, not with the utility. It works perfectly in Leopard. Even the Leopard Disk Utility cannot verify the SL partition.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.