• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

What Mac OS Version is best for PPC Macs that are bad at 68k emulation?

3lectr1cPPC

Well-known member
One thing I've heard before on these forums is that on systems with poor 68k emulation speed due to lacking cache (like the Performa 6200CD, PowerBook 5300, 1400/117, etc), later versions of Mac OS like 8.1 and 8.5 will run better than 7.x due to being less reliant on 68k code. I decided tonight to give this a try on my 117MHz PowerBook 5300. First, I timed a bootup from its main system folder, which is OS 7.6.1. It's what I use on it normally. I got about 1:43 to boot up to the desktop, with timing starting when the happy mac icon appears. Then, I transferred over the OS 8.5 system folder from my PowerBook 3400, which is a pretty clean and non-bloated folder, besides for a custom theme. It took just over 3 minutes to reach the desktop!

I know that there's more to performance than boot time, but it's what's going to be noticed the most when running the system, at least for me, as the 5300 isn't a quick laptop either way. Any thoughts on this?

Specs:
117MHz PowerPC 603e with no L2 Cache
64MB RAM (Maximum for this laptop, best case scenario)
3.2GB Toshiba HDD (4200 RPM)

I also tried the same test on my 3400c/200, which should have much better 68k emulation speed, as it has a proper L2 cache. 7.6.1 also booted faster on that system as well. One note on both of these is that the 7.6.1 install on both systems has Speed Doubler installed, while 8.5 was not. I'm going to repeat the test with speed doubler off, but I remember not noticing a big difference after I installed it. It probably affected things a bit, but not by over a minute in the startup time.
 

Phipli

Well-known member
The issues with the 6200 and PB 5300 aren't quite the same, you're mixing up your caches.

The 6200 had a PPC 603 processor which had very little Level 1 cache and this made it struggle with 68k emulation allegedly because it couldn't hold the emulator in cache. The PB 5300 has more L1 cache in its PPC 603e chip and no Level 2 cache (I can't remember - did the top model have an L2???).

Speed with 8.6 isn't boot time, its how fast software runs. The OS is way bigger than 7.6.1 and so takes longer to boot. It also takes more RAM. I'd only run 8.6 if I had... at least say 40MB RAM?

Given the limited resources on a 5300, I'd normally run it on 7.6.1 with SpeedDoubler to be honest.
 

3lectr1cPPC

Well-known member
Alright, thanks for the input. I was aware of the discrepancy between the 2 but I wasn’t sure what that affected. The top end 5300 doesn’t have any L2, that would be the 1400 where the top 2 models do but the lower end one doesn’t. I’ll do some more testing later with running software to see how fast things are between the systems, I’ve got plenty of RAM to my disposal so that shouldn’t be an issue.
 

MrFahrenheit

Well-known member
Norton Utilities has a benchmark program called System Info. I think the one from NU 2.0 wasn’t PPC native, but perhaps even the one from 3.x.

Running the 68k benchmark will allow you to know how each OS emulates the 68k.

You’ll know if a benchmark is under emulation or not if it reports the CPU as a PPC or a 680x0 (usually 68020).

A benchmark will provide more useful comparisons over anecdotal “this feels faster, this feels slower”.
 

Phipli

Well-known member
Norton Utilities has a benchmark program called System Info. I think the one from NU 2.0 wasn’t PPC native, but perhaps even the one from 3.x.

Running the 68k benchmark will allow you to know how each OS emulates the 68k.

You’ll know if a benchmark is under emulation or not if it reports the CPU as a PPC or a 680x0 (usually 68020).

A benchmark will provide more useful comparisons over anecdotal “this feels faster, this feels slower”.
The only issue is that the benchmark runs pure CPU functions as either as 68k or as PPC, but what you're comparing between 7.6.1 and 8.6 is how much of the toolbox / OS has been written in PPC. It will show how well the emulator runs, but not how well the OS, a mixture of 68k and PPC, runs.

Sadly it is something that is quite difficult to measure. Its probably one for scrolling through documents, file copies and game framerates perhaps?
 

3lectr1cPPC

Well-known member
Program launches as well. During general use, the things that you're going to notice the most are boot time, window draw speed, snappiness, application launches, and file copies. I'd like to do more testing, but my 5300 has decided it feels like throwing out bus errors instead of booting right now, so I can't. That darn thing just never stays running!
 

Phipli

Well-known member
Program launches as well. During general use, the things that you're going to notice the most are boot time, window draw speed, snappiness, application launches, and file copies. I'd like to do more testing, but my 5300 has decided it feels like throwing out bus errors instead of booting right now, so I can't. That darn thing just never stays running!
Mine is a terror for bus errors too. I'd forgotten that. I don't use it as much as my 1400 and Pismo.
 

3lectr1cPPC

Well-known member
C0AE6023-C46A-4367-96BF-EAC243E4F2C9.jpeg
All I did was switch the boot folder in system picker a couple times! I’ve even recapped its DC board, but it still doesn’t like me :(
Might be time to recap my other dead AC adapter that I know has bad caps. Tried with extensions off and it threw error type 10.

Oh, and yes, it definitely is a 117MHz 5300ce system board, I had to swap in the 5300c screen because I broke the ce ribbon cable…
Edit: 24V PSU is kicking out 23.37 volts. Too low?
 
Last edited:

Steve_G

Well-known member
7.6.1 is the minimum i'd run on any PPC, 8.1 for systems with more ram but a slower CPU. And yeah, later versions should run faster to a point due to the 68k code replacement.
 

NJRoadfan

Well-known member
If 68k applications are performing poorly, find a copy of Connectix Speed Doubler. It includes a replacement 68k emulator that is faster then Apple's.
 

Snial

Well-known member
My L2 cacheless PowerBook 1400cs/117 can dual boot with System 7.5.3 on one SD partition and Mac OS 8.1 on another SD partition. In addition it has 3 more 750MB HFS+ partitions that System 7.5.3 can't use. I have 16MB of RAM with VM turned on and no cache for both OS's.

I understand that on the one hand, more of Mac OS 8.1 is PowerPC than System 7.5.3, but on the other hand, it's much bigger. For example, the IDE drivers on System 7.5.3 appear to be 68K only (as far as the partitions are concerned, unless they're replaced by PPC drivers, but I can't see why that would be the case because the HD was originally installed with the System 7.5.3 CD ROM for the PowerBook 1400, so if the PPC drivers existed then, they would have been supplied).

Mac OS 8.0 and 8.1 updated the IDE drivers. As a consequence they (subjectively) feel faster. A good way to describe it is that Mac OS 8.1 feels like it has more evenly balanced performance. For example, when an app needs to load or save to the HD; Mac OS 8.1 does it significantly faster; as is the case with other newly native APIs; while the OS overheads make everything a bit slower; and the PowerPC parts of the app are the same speed.

System 7.5.3 is a bit like watching an early 20th century hand-cranked moving picture where people seem to jerk along at 20 fps; whereas System 8.1 is like a watching an early 24fps Technicolor movie at a lower ISO film. 8.1 is smoother, more consistent and overall faster in operation, but at the same time with a bit more 'motion blur'.

We can understand why an emulator will have this kind of effect. Native code will run at full speed, but emulated functions and APIs will incur a relatively high speed penalty of several factors. For example, a 68K emulator on a PPC can't execute an instruction faster than the equivalent of:

ldr.w insReg, emulatedPc+ ;about 2 cycles at least.
add realPC, emulationBaseAddrReg, insReg<<shift ;1 cycle + pipeline flush.
emulated instruction that sets the condition codes, 1 to 2 cycles.
inline fetch and execution for Next instruction


Even with the 601 and 603(e)'s multiple execution units it will take 3 to 5 PPC cycles to execute the simplest 68K instruction. So, actual fat binary code will exhibit sudden speed ups and slow downs. e.g. a high-level PPC function which calls a 68K function that performs multiple, small PPC QuickDraw operations might be oddly jumpy vs a PPC function which repeatedly loads file data from a 68K IDE driver and then processes it might be more obviously jittery.

The effect of a lack of L2 cache exacerbates slow-downs due to emulation, but obviously the more PPC code there is, the more consistently smooth execution becomes.

Even more oddly, there are some features Apple moved to 68K emulation in Mac OS 8.1, because it improved performance!

 

Cory5412

Daring Pioneer of the Future
Staff member
The best OSes for this group of early PPC Macs are 7.6.1 and 8.1. I'll give you 9.1 on anything whose "tiptop" configuration can include over a hundred megs of RAM or like a 90MHz or more CPU. So, 6100, 6200, 7100, slow 7200s, 5200, PM-Perf 5200, PB5300, 1400, 2300, and most 8100s will fall into this group.

7.1-7.5 is a tire fire and you'll get bad performance simply because of how poorly fleshed out PPC support was. This is some of why the AWGS95 stayed on sale for so long, alongside the AWGS9150.

That said: +1 to what @Phipli wrote: Two different issues are being conflated here:
On the 6200 and 5200/75, there's only 16k total of L1 cache, which is IDd as the cause of slow 68k emulation. (That's on top of 7.5.x being a tire fire on PPC.) All of those machines have 256k of L2, so PPC code should be reasonably performant.

The PB5300/117 (and in fact all 603 Macs that aren't the 603@75) have 32k of L1 cache, matching all other PPC Mac through to the G3, but Apple shipped those (and a few other laptop models, and some of the other PowerMac models e.g. 6100 and 6360-6400) without an L2 cache, which makes them slow, at, well, "everything" but not exceptionally slow at 68k emulation in particular, as on the 6200/75.

Running the 68k benchmark will allow you to know how each OS emulates the 68k.

Fun fact on this, I think this is reflected in your benchmark files you gave me, the first Mac to beat a Quadra 700 at floating point is the 533MHz G3. 68k emulation is terrible on all Beige Macs, and we mostly put up with it is because the real target for most people was INTeger performance on a IIci, which the 6100 (and 6200 w/ SD8) can basically match. Anyone running a heavy floating point workload from "before FP was standard hardware" was hopefully paying close attention to software having been upgraded to PPC. Most of that software did get ported to PPC fairly quickly.

Sadly it is something that is quite difficult to measure. Its probably one for scrolling through documents, file copies and game framerates perhaps?
+1 to this. Mac OS 9.1 on my 6200 actually beats 6100 and 6200 benchmarks (Macbench 4, so ppc native, almost all subsystem) under 7.6.1/8.1, likely because 9.1 itself included better 68k emulation point (part of the point @MrFahrenheit was talking to and may well be why his G4@533 can finally outrun the Quadra 700 at floating point...)

But in actual use, the 6200 on OS 9 is just, absolutely awful, even more-so if you actually use it with like 1998+ era software. I can maybe imagine doing it back in the day if you had some kind of non-performance-sensitive, batchable work that needed OS 9, and would run well on the slower hardware and you also you wanted to offload from your main computer.

(There's not actually much that fits well within all these constraints... maybe ripping CDs or converting audio files or video files in quicktime or itunes?) (or maybe for something non-interactive, like if you wanted OS 9 for IP-based file sharing or printer sharing?)

Even more oddly, there are some features Apple moved to 68K emulation in Mac OS 8.1, because it improved performance!

That's extremely odd!

In fact, it's odd enough that I'd put money on: that literally isn't what was happening and LEM misunderstood or misread something, or the things listed there had never previously been PPC components of the OS. It wouldn't be the first really major thing LEM has been wrong about for 25 years.... (Scott Barber in particular...)

One of the components mentions replacing "core native" code with its own, my guess is that either 1. the core native code itself wasn't PPC native yet or 2. Apple hadn't yet written PPC-native version of $THING so it didn't really matter whether the "core native" code was PPC because handling of $SPECIAL_FEATURE (AV in particular) hadn't been ported to PPC at all.

A few of these stragglers likely survived into 9.2.2.

I wouldn't be too alarmed though, most of these things don't use FP and most of 'em don't don't aren't super performance-sensitive.
 
Last edited:

Snial

Well-known member
That's extremely odd!

In fact, it's odd enough that I'd put money on: that literally isn't what was happening and LEM misunderstood or misread something, or the things listed there had never previously been PPC components of the OS. It wouldn't be the first really major thing LEM has been wrong about for 25 years.... (Scott Barber in particular...)

One of the components mentions replacing "core native" code with its own, my guess is that either 1. the core native code itself wasn't PPC native yet or 2. Apple hadn't yet written PPC-native version of $THING so it didn't really matter whether the "core native" code was PPC because handling of $SPECIAL_FEATURE (AV in particular) hadn't been ported to PPC at all.

A few of these stragglers likely survived into 9.2.2.

I wouldn't be too alarmed though, most of these things don't use FP and most of 'em don't don't aren't super performance-sensitive.
You could well be correct, but also it's likely me misremembering some anecdotes I came across with regard to the NuBus PPC, 68K emulation era over the past 28 years. So, if I can shed a bit of light on my own lousy memory:

1. I might have the "more 68K code in a later Mac OS" misplaced, because perhaps it was the move from 7.1.2 on the very first PPC Macs in 1994 to 7.5 where they tried to improve performance by moving some PPC code back to 68K code.
2. The LEM article is linked, because it references the Appearance Manager. I remember fairly recently (in the past few years) coming across an blog post, which I think documented how a control panel had a bug that got fixed and then unfixed, because they reverted back to 68K code (or something like that). It might have been for Date and Time. But I can't find the actual blog post.
 

Phipli

Well-known member
To be honest, if something wasn't timing critical, being 68k wasn't a bad thing. It could be an advantage as the same program compiled for 68k would be smaller. Something like a Control Panel that set PRAM settings is better as 68k - save a few k and it doesn't need to run fast - all it does is present a UI to change a setting.
 

MrFahrenheit

Well-known member
PowerTalk? As in voice recognition? Wasn't it released with the Quadra 660 and 840, with System 7.1.2?
I think PowerTalk was the network component that allowed email to work in System 7 Pro

 

Phipli

Well-known member
I think PowerTalk was the network component that allowed email to work in System 7 Pro

Ah yes, I'm thinking PlainTalk of course. I'm getting muddled.
 

3lectr1cPPC

Well-known member
Lots of good info here, thanks everyone! My 5300 has decided to cooperate once again (swapped the hard drive for its original 750MB and the cable for good measure…) so I’d like to repeat my test (and do some additional testing) between 7.6.1 and 8.1 when I get the chance, but due to the way that the 5300 is limited, I suspect that performance won’t be much better on either.
 
Top