The PowerPC Mac is dead. 68K emulation is forgotten. John Neil &
Associates doesn't exist.
If you are using old Mac technology for whatever reason, and you have one of those stupid programs written in C that doesn't know how to run on the available hardware, but insists on a 68K floating-point engine in hardware, my PowerFPU emulator might be helpful.
The original Macintosh was designed to run on Motorola 68000 computers, which were integer-only. Apple was very visionary at the time, so they hired the student of a brilliant Berkeley mathematician to design a floating-point math package for them. He based his work on the IEEE-754 Floating-Point Arithmetic standard that is the basis for all modern computer hardware, but only existed in Intel chips in 1984. Apple called their math system "SANE" (Standard Apple Numeric Environment), and it was in the original Mac 64K ROMs.
Bye and bye the hardware folks caught up with the world standard, and the CPUs started executing floating-point math in hardware. Motorola was careful not to offend their biggest customer, so their hardware supported SANE almost exactly, and Apple adjusted their ROMs so they used the floating-point hardware if it was there, and software if not. The C compiler folks eagerly switched over from making Apple ROM system calls to using the hardware, for a tiny improvement in speed and a vast incompatibility with legacy hardware. C people think that way. They still do, as anybody who has ever tried using Linux knows well. My compiler just kept on using SANE calls.
Anyway, Apple got this notion of moving to "RISC" (Reduced Instruction Set Computer) technology, and migrated their system to the IBM Power architecture, which they negotiated a deal with Motorola second-sourcing IBM chips. Everybody was happy, because Apple had the best operating system, and IBM's workstations were the fastest RISC computers around, and they all expected to eat Intel's lunch. It didn't work out that way, because RISC is not the fastest technology when programs get big (but that's another story), and other factors are more important than raw speed in determining market share. Apple gave up on RISC and went with the market leader architecture.
When Apple was doing their PowerPC implementation of the Mac, they were very careful to make sure that it ran legacy 68K programs unchanged. That means they had to emulate the complete 68K instruction set. You put an old vintage Mac program into a PowerPC Mac, and it just works. Unless the programmers did something stupid, which many of them did. Anybody smart enough to program in C is bound to make other blunders too. It took people a long time to redo their programs to become "native" PowerPC, not all of it because of bad design; often it was just too hard to get the "3-5x" performance improvements Apple was promising for RISC, a problem I called "the RISC penalty." Anyway, part of the Apple emulator was designed to emulate the floating-point hardware, but there were some technical difficulties, so they left that part out -- recall that well-designed software checks to see if the hardware is there, and uses SANE if not -- but the connections were still there.
Emulation is necessarily slow, so some sharp Apple programmer got the idea of implementing a code recompiler version of the emulator. It was a poular idea at the time, and I tried to do the same thing about the same time. So did Connectix. All of us ran into the "RISC penalty" problem, and it was taking far longer to get around it than we planned, but Apple and Connectix had deeper pockets than I did. I abandonned my project, but not before Connectix heard of it and asked for a demo. I think they wanted to see how I solved the RISC penalty problem. Of course I didn't, so there was no deal, but they were interested in the floating-point emulation I came up with. I suspect I was farther into the Apple code than they were, and they didn't know about the built-in hooks. They offered a low-ball price for my floating-point emulator, and a few days later John Neil made a much better offer. I went with John Neil, and repackaged it as a control panel, which he marketed as "PowerFPU". Eventually all the active software vendors got their software converted to native code, and the market for PowerFPU died out. Apple abandonned 68K emulation entirely when they went to the x86 architecture. One of the things Apple learned from the Windows market is that the software developers make or break the hardware, and software vendors make their money on upgrades. Planned obsolescence forces users to spend more money. That scam only works for a while, as General Motors learned, but Apple isn't looking that far ahead.
I guess there is a very rare occasion for using older software designed for 68K+FPU. It's certainly not worth trying to make money off of, but if you are in that situation, I uploaded my PowerFPU control panel here for free download. This is unsupported, but all you need to do is drop it into your System Folder (Control Panels) and restart. Enjoy!
For those who care, I did not use C. There is quite a bit of PowerPC assembly language connecting it to Apple's emulator, but all the heavy lifting was written in CompileIt. It's not particularly fast, but speed is not what you use an emulator for.
It is also available on the Macintosh Garden archive here: http://macintoshgarden.org/apps/powerfpu
One unlucky user discovered that opening the PowerFPU control
panel disables it, requiring a re-install. Just install it and don't open
it, if you have that problem.
Tom Pittman
2007 October 8, MacintoshGarden link added 13 Jan 11