> It is also my opinion Mac OS 9.2.2 is the greatest OS, and Mac OS, ever, but not everything that is possible in earlier Mac OS versions is possible in Mac OS 9.2.2.
I had fun with hypercard on MacOS 9. At work, even. The boss was into rapid prototyping, and I cooked up some damn productive stacks in a hurry.
It runs on the Cube and under OS 9 emulation on the new stuff.
Hypercard scripters did cool things that most users don't do today. And without those monster data centers.
MacOS 9 was awful, a product of a rather unpleasant era for Apple really. I wanna say through 9.2.1 maybe even through to 9.2.2 the OS had a nasty habit of corrupting your disk. Hardware-wise Apple used CMD64x based IDE controllers so when OS9 wasn't screwing with your data the hardware itself would.
There absolutely were animations e.g. when closing a Finder window, but they were much lighter weight. As far as I'm concerned System 7 was probably the zenith.
Mac OS 9 was certainly not rock solid as far as crashes were concerned, but very much better than System 7, that was clear to me. Maybe it is my rose-tinted glasses colouring my memory but I also remember that there were very few small bug, you know the just annoying kind, than I have today with macOS 15, there may be fewer hard crashes, but the number of paper cuts have increased by many orders of magnitude.
I remember it crashing a lot but maybe that's because I came of age around the OS 8/9 era. IIUC OS 9 had no memory protection so it's not exactly a surprise it was fragile.
To me it’s the opposite, System 7 crashed all the time and MacOS 9 was rock solid. System 7 was a mess until 7.6, at which point it was basically MacOS 8. And the UI was way more pleasing, the system 7 one had a 80s vibe to me.
> In my case, first I tried using the latest Python 3.13.9 both from Windows 7 (bad idea due to resource fork loss) and macOS 10.14.6 Mojave, but neither worked: it seems like that version of Python was just too new. I then retried with Python 3.8.10 instead (which I chose thinking it might be more period-appropriate for the script's age) on Mojave, which worked flawlessly.
Ah, classic Python. Removing features [0] and breaking perfectly working software just because the feature is old, ugly, and not widely used.
StarMax series (and the 4400) seemed to be about as close to CHRP as we got. My off-brand StarMax clone (PowerCity) had a PS/2 and an ISA port. Ran BeOS well, and had a quirk that I could hear a tight loop on the speaker.
Kinda sorts. The systems that the "MacOS on CHRP" thing ran on had a very strange looking device tree, with some bizarre combination of PC and Mac peripherals.
Refer to the "Macintosh Technology in the
Common Hardware Reference Platform" book for more information, if you're curious about the Mac IO pieces.
The Motorola Yellowknife board seems remarkably similar to this system, as well as the IBM Long Trail system (albeit with Long Trail using a VLSI Golden Gate versus a MPC106 memory controller). Both of them use W83C553 southbridges and PC87307 Super I/O controllers.
The architecture is kind of weird, but the schematics on NXP's website can probably elucidate a bit more on the system's design.
A fun "do-it-yourself" question for people who've always wanted to learn about the baroque architecture of the PowerPC Mac and the classic Mac OS: where is hardware support for specific models implemented?
I have an iMac G4 1.25 GHz. Originally, it was a 1GHz, but I swapped out the motherboard for a later model. For a while I've been wondering if I would had been better off with an earlier motherboard capable of booting OS 9 natively. Compared with using OS X's classic mode, this would omit the overhead of running a whole other OS and leave me with more resources to run OS 9 apps and games. I don't get a whole lot of use out of the earlier OS X software that I have on there...
Maybe in the future I won't have to make that choice! I'd much rather dual boot OS 9 off a different partition, but that hasn't been supported on the 1-1.25GHz models (Thanks Steve...) and no one has gotten it working properly. Maybe now it will be possible! A man can dream...
I remember that yes, expensive operations could take a while, but the interface was much faster than my M1 Max Studio for the sole reson you actually do not have to wait for animations.
And not just for the reasons that animations were sparse, they also never blocked input, so for example if you could see where a new element would appear you could click there DURING the animation and start eg typing and no input would be lost meaning that apps you used every day and became accustomed to would just zip past at light speed because there were no do-wait do-wait pipeline.
My most durable memory is all the reboots due to programs crashing. Didn't help that a null pointer deref required a system reboot - or that teenage me was behind the keyboard on that front.
Preemption is a very nice OS feature it turns out (particularly once multi-core rolled around). Still, I recall os 8 and 9 being generally snappier than windows 98 (and a lot snappier than early builds of OSX)
One of my early Macs was a Performa 638CD with no dedicated FPU. I had upgraded to a Performa 6400 (which felt like an absolute dog despite its size) but finally had an opportunity to move to the PowerComputing PowerTower Pro 225. What a beast! I hate to say it, but it was probably my favorite Mac I'd ever owned before the first iMac.
The Megahertz wars in the 1990s made it really difficult to understand relative performance across even the same ISA like this, and I think computers with the 603 CPU were a bit of a wrench in people's perception of the Mac.
The 180 or 200MHz 603e with 16k L1 cache in that Performa 6400 wasn't slow by any stretch, but it probably didn't have L2 cache. Coupled with the gradual transition to PPC native code of the OS and apps, these machines were often a little mismatched to expectations and realities of the code.
Meanwhile that PowerTower had a 604e with 32/32k L1 and 1MB L2 cache. That was a fast flier with a superscalar and out of order pipeline more comparable to the Pentium Pro and PII.
I have a PowerCenter Pro 210 in my basement right now! It's not quite as nice as the newer architecture in the PowerTower Pro machines, but it runs MacOS 7.6.1 wonderfully. It is more than enough for classic Mac games of that era - and a joy to use.
The later PowerCenter Pro’s could run with a 60 MHz FSB whereas the PowerTower Pro’s were usually 45-50 MHz FSB. There are a variety of tasks where my PowerCenter Pro 240 outruns my PowerTower Pro 250 for precisely that reason.
As an European, Classic Macs (and current ones) were just for arts/writting people. If you knew what CMYK was in order to print a newspaper, you were a Mac user.
I emulated Mac OS 7 under XP times, and i was impressed that you could get far faster speeds emulating the M68k (and partially the PPC) compared to Intel X86 without any hardware accelerating chip (IntelVT) or kernel modules trapping X86 instructions running it at native speeds.
I mean, PPC and M68k chips where much easier to emulate than X86 on itself.
On software, Classic Mac users can just resort to IRC and Gopher clients and visit the public https://bitlbee.org IRC servers in order to connect 'modern' accounts and being proxied to a Mac IRC client. And for Gopher, you have gopher://hngopher.com, gopher://magical.fish and the like.
Sadly you don't have an easy TLS library as Amiga users have (AmiSSL) where even modern web can work on it (and IRC over TLS, Gemini...).
Altough... if Amiga m68k emulators run fast with the Rosetta like tech for PPC... you would just fire up Workbench and then AmiSSL. Crude, but it would work. If not, here in the Apple subdir
you can get, maybe, some TLS enabled browsers:
Ardi Executor. There's a recent fork at GitHub. You can run m68k binaries seamlessly. You don't need propietary MacOS parts, just the software.
But if you are some software preserver, having a libre option to run legacy media it's always good for historical reasons. I am a daily libre software user but I emulate ancient machines with propietary stuff just for curiosity. As it not a personal computing device I find it fine. It's just an historical toy and not my computing device. And, well, if you want to create libre engines for old Mac games (ScummVM, SDL ports...), for sure you need to at least emulate the old OSes and run the propietary game in order to compare the output and correctness.
Also, it already exists "Mac" for x86. It was Rhapsody DR2 and it could run Classic Mac software and NeXT one too. It was like a blend of these two. OSX it's like NeXT Step concept 2.0, with few traces of Mac Classic.
Qemu will run it fine.
> It is also my opinion Mac OS 9.2.2 is the greatest OS, and Mac OS, ever, but not everything that is possible in earlier Mac OS versions is possible in Mac OS 9.2.2.
I had fun with hypercard on MacOS 9. At work, even. The boss was into rapid prototyping, and I cooked up some damn productive stacks in a hurry.
It runs on the Cube and under OS 9 emulation on the new stuff.
Hypercard scripters did cool things that most users don't do today. And without those monster data centers.
HyperCard is one of my all time favourite memories of Mac OS.
Not only that, everything felt _snappy_. No wasteful animations to add 0.28 ms to every interaction.
MacOS 9 was awful, a product of a rather unpleasant era for Apple really. I wanna say through 9.2.1 maybe even through to 9.2.2 the OS had a nasty habit of corrupting your disk. Hardware-wise Apple used CMD64x based IDE controllers so when OS9 wasn't screwing with your data the hardware itself would.
There absolutely were animations e.g. when closing a Finder window, but they were much lighter weight. As far as I'm concerned System 7 was probably the zenith.
Mac OS 9 was certainly not rock solid as far as crashes were concerned, but very much better than System 7, that was clear to me. Maybe it is my rose-tinted glasses colouring my memory but I also remember that there were very few small bug, you know the just annoying kind, than I have today with macOS 15, there may be fewer hard crashes, but the number of paper cuts have increased by many orders of magnitude.
I remember it crashing a lot but maybe that's because I came of age around the OS 8/9 era. IIUC OS 9 had no memory protection so it's not exactly a surprise it was fragile.
To me it’s the opposite, System 7 crashed all the time and MacOS 9 was rock solid. System 7 was a mess until 7.6, at which point it was basically MacOS 8. And the UI was way more pleasing, the system 7 one had a 80s vibe to me.
W95 and W98 werent' much better until W98SE. Linux distros were rough but mega-stable.
> In my case, first I tried using the latest Python 3.13.9 both from Windows 7 (bad idea due to resource fork loss) and macOS 10.14.6 Mojave, but neither worked: it seems like that version of Python was just too new. I then retried with Python 3.8.10 instead (which I chose thinking it might be more period-appropriate for the script's age) on Mojave, which worked flawlessly.
Ah, classic Python. Removing features [0] and breaking perfectly working software just because the feature is old, ugly, and not widely used.
[0] https://github.com/elliotnunn/tbxi/issues/1
Max frustrating. If I were writing tbxi again it would be in Go.
Misread as “Mac mini M4” and was going to be _very_ impressed.
Honestly this is still pretty insane.
[dead]
StarMax series (and the 4400) seemed to be about as close to CHRP as we got. My off-brand StarMax clone (PowerCity) had a PS/2 and an ISA port. Ran BeOS well, and had a quirk that I could hear a tight loop on the speaker.
Kinda sorts. The systems that the "MacOS on CHRP" thing ran on had a very strange looking device tree, with some bizarre combination of PC and Mac peripherals.
Refer to the "Macintosh Technology in the Common Hardware Reference Platform" book for more information, if you're curious about the Mac IO pieces.The Motorola Yellowknife board seems remarkably similar to this system, as well as the IBM Long Trail system (albeit with Long Trail using a VLSI Golden Gate versus a MPC106 memory controller). Both of them use W83C553 southbridges and PC87307 Super I/O controllers.
The architecture is kind of weird, but the schematics on NXP's website can probably elucidate a bit more on the system's design.
A fun "do-it-yourself" question for people who've always wanted to learn about the baroque architecture of the PowerPC Mac and the classic Mac OS: where is hardware support for specific models implemented?
In concentrically encrusted layers
I have an iMac G4 1.25 GHz. Originally, it was a 1GHz, but I swapped out the motherboard for a later model. For a while I've been wondering if I would had been better off with an earlier motherboard capable of booting OS 9 natively. Compared with using OS X's classic mode, this would omit the overhead of running a whole other OS and leave me with more resources to run OS 9 apps and games. I don't get a whole lot of use out of the earlier OS X software that I have on there...
Maybe in the future I won't have to make that choice! I'd much rather dual boot OS 9 off a different partition, but that hasn't been supported on the 1-1.25GHz models (Thanks Steve...) and no one has gotten it working properly. Maybe now it will be possible! A man can dream...
This is really cool, the kind of content great to see here.
That's impressive but early macOS were pretty awful UX; I think the UI thread was everything.
I remember clicking and waiting.
I remember that yes, expensive operations could take a while, but the interface was much faster than my M1 Max Studio for the sole reson you actually do not have to wait for animations.
And not just for the reasons that animations were sparse, they also never blocked input, so for example if you could see where a new element would appear you could click there DURING the animation and start eg typing and no input would be lost meaning that apps you used every day and became accustomed to would just zip past at light speed because there were no do-wait do-wait pipeline.
My most durable memory is all the reboots due to programs crashing. Didn't help that a null pointer deref required a system reboot - or that teenage me was behind the keyboard on that front.
more the fault of MB of ram and HDDs being quite slow to be honest.
> I think the UI thread was everything.
How would you have done it?
Preemption is a very nice OS feature it turns out (particularly once multi-core rolled around). Still, I recall os 8 and 9 being generally snappier than windows 98 (and a lot snappier than early builds of OSX)
I’ve been waiting for this post.
I run OS 9 on my lamp iMac G4 but now I want to try 7.6.1!
yes, multiple Macs within arms reach right now!
++ BBEdit
One of my early Macs was a Performa 638CD with no dedicated FPU. I had upgraded to a Performa 6400 (which felt like an absolute dog despite its size) but finally had an opportunity to move to the PowerComputing PowerTower Pro 225. What a beast! I hate to say it, but it was probably my favorite Mac I'd ever owned before the first iMac.
The Megahertz wars in the 1990s made it really difficult to understand relative performance across even the same ISA like this, and I think computers with the 603 CPU were a bit of a wrench in people's perception of the Mac.
The 180 or 200MHz 603e with 16k L1 cache in that Performa 6400 wasn't slow by any stretch, but it probably didn't have L2 cache. Coupled with the gradual transition to PPC native code of the OS and apps, these machines were often a little mismatched to expectations and realities of the code.
Meanwhile that PowerTower had a 604e with 32/32k L1 and 1MB L2 cache. That was a fast flier with a superscalar and out of order pipeline more comparable to the Pentium Pro and PII.
Oh believe me. I owned it. It felt slow even at the time.
Yup. Recall the far better cycle efficiency of the 100 MHz hyperSPARC.
Consumers didn't grok cycle efficiency, pipeline depth, or branch prediction miss pipeline stall latency.
I have a PowerCenter Pro 210 in my basement right now! It's not quite as nice as the newer architecture in the PowerTower Pro machines, but it runs MacOS 7.6.1 wonderfully. It is more than enough for classic Mac games of that era - and a joy to use.
The later PowerCenter Pro’s could run with a 60 MHz FSB whereas the PowerTower Pro’s were usually 45-50 MHz FSB. There are a variety of tasks where my PowerCenter Pro 240 outruns my PowerTower Pro 250 for precisely that reason.
As an European, Classic Macs (and current ones) were just for arts/writting people. If you knew what CMYK was in order to print a newspaper, you were a Mac user.
I emulated Mac OS 7 under XP times, and i was impressed that you could get far faster speeds emulating the M68k (and partially the PPC) compared to Intel X86 without any hardware accelerating chip (IntelVT) or kernel modules trapping X86 instructions running it at native speeds. I mean, PPC and M68k chips where much easier to emulate than X86 on itself.
On software, Classic Mac users can just resort to IRC and Gopher clients and visit the public https://bitlbee.org IRC servers in order to connect 'modern' accounts and being proxied to a Mac IRC client. And for Gopher, you have gopher://hngopher.com, gopher://magical.fish and the like. Sadly you don't have an easy TLS library as Amiga users have (AmiSSL) where even modern web can work on it (and IRC over TLS, Gemini...).
Altough... if Amiga m68k emulators run fast with the Rosetta like tech for PPC... you would just fire up Workbench and then AmiSSL. Crude, but it would work. If not, here in the Apple subdir you can get, maybe, some TLS enabled browsers:
gopher://bitreich.org/1/lawn
and
gopher://happymacs.ddns.net/1Vintage-Mac-Software-Archive
MacSSL:
https://github.com/demoniccode12/MacSSL
Usenet will work fine without any TLS, and there's tons of content out there.
It was because of QuarkXPress and Photoshop. In the same way WordPerfect and Lotus 1-2-3 were dominant for business computers.
Wish someone would try to create native MacOS classic on x86 hardware.
There are so many Unix or Linux ABI compatible kernels like the recent Moss written in rust.
Ardi Executor. There's a recent fork at GitHub. You can run m68k binaries seamlessly. You don't need propietary MacOS parts, just the software.
But if you are some software preserver, having a libre option to run legacy media it's always good for historical reasons. I am a daily libre software user but I emulate ancient machines with propietary stuff just for curiosity. As it not a personal computing device I find it fine. It's just an historical toy and not my computing device. And, well, if you want to create libre engines for old Mac games (ScummVM, SDL ports...), for sure you need to at least emulate the old OSes and run the propietary game in order to compare the output and correctness.
Also, it already exists "Mac" for x86. It was Rhapsody DR2 and it could run Classic Mac software and NeXT one too. It was like a blend of these two. OSX it's like NeXT Step concept 2.0, with few traces of Mac Classic. Qemu will run it fine.
https://lunduke.substack.com/p/hands-on-with-1998s-rhapsody-...
It would be great if somebody tried to create an opensource version of Rhapsody DR2 that ran on X86 baremetal.
Would not even need to be binary compatible. Source compatible API would be enough.
Rhapsody DR2 is more like Classic Mac than any current MacOS.