• 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.

Mac 68K Speedup tips here

Unknown_K

Well-known member
I would put a PPC card into a 68K only if absolutely needed. I have a Daystar 601-100 in one of my 950s because the AVID system needed PPC and 4 Nubus slots to work leaving me few options.

I also have a Quadra PDS 601-66 sitting around.

The faster 68k's would run 68k code faster then a 601 would in emulation, most PPC code would run better on a 604+ CPU. There is realy little need for a slow 601 in a 68k Mac.

 

Maccess

Well-known member
Post your Mac 68K Speedup tips here:
3) Get a slotless cache card for your Quadra CPU, or if you can't get the slotless cache card, get a PDS cache card, but that may prevent you from using other PDS Cards.
What are slotless cache cards? Can they get you money from broken banking machines?

Actually, it's a serious question - never heard of these, and I've been fiddling with Quadras and such for years. What have I missed? I am intrigued.
A slotless cache card fits in between the 68040 socket and the 68040 Chip. You'll end up with a processor that looks a like the G3 with some chips sticking out the side of the heatsink. Adds 128K of 68040 L2 cache (an 040 feature that is officially unimplemented. Thanks, Apple.). It's very rare. I think Sonnet, MicroMac, or Daystar made them once.

For a 25Mhz Quadra, a QuadDoubler (which replaces the 68040 CPU is better) since it replaces the CPU with a 50Mhz 040 and adds a 128K cache. They don't work in 33Mhz Quadras (maybe someone was able to hack them to work?)

Another intriguing slotless device was the Allegro 030 which replaces a socketed 16Mhz CPU with a 33Mhz 030. It was sold for use with IIx, IIcx, and SE/30. It won't work in an LCII, or LCIII, because these use a different form factor 030. Also very rare.

About the fast hard drive item: Has anyone tried running a 68K Mac off a flash drive? There were SCSI Memory Card readers, and an internal one here, with the low prices of flash drives (2GB CF at $20) these look like viable, fast alternatives to SCSI hard drives. Here's another manufacturer of solid state drives and CF adaptors.

 

ianj

Well-known member
The workaround is to use a router between your Internet connection and your MacTCP using Macintosh, and to assign a static IP address to your MacTCP running Mac. Not a major obstacle, as any Macintosh that cannot run Open Transport is not well suited for Internet use anyway. And, odds are that you'd be using a more recent machine for web surfing, thus assuring that you probably have a router anyway.
Another big advantage of Open Transport is being able to access file servers running OS X 10.4 (using OS 7.6 and AppleShare 3.8.3). My primary Mac is a G4 running 10.4.10 (as noted, 68Ks can only do certain things in today's world) and not being able to properly share files between the two machines was a huge inconvenience before I found out about AppleShare 3.8.3. Open Transport simply makes it much easier to deal with modern networks and the Internet on a 68K Mac. Not to disparage those that can't or don't run it, but saying Open Transport has no advantages for 68Ks is overlooking a lot.

 

Quadraman

Well-known member
I would put a PPC card into a 68K only if absolutely needed. I have a Daystar 601-100 in one of my 950s because the AVID system needed PPC and 4 Nubus slots to work leaving me few options.
I also have a Quadra PDS 601-66 sitting around.

The faster 68k's would run 68k code faster then a 601 would in emulation, most PPC code would run better on a 604+ CPU. There is realy little need for a slow 601 in a 68k Mac.
Speed Doubler alleviates the problem of the slow emulation built into the 601 based machines.

 

ChristTrekker

Well-known member
Speed Doubler alleviates the problem of the slow emulation built into the 601 based machines.
I've long wondered how Speed Doubler managed to do what it did. I can understand substituting various function calls with optimized algorithms that execute faster. But to achieve that marked an improvement would mean Apple's designs were bad to the point of incompetence.

 

Quadraman

Well-known member
Speed Doubler alleviates the problem of the slow emulation built into the 601 based machines.
I've long wondered how Speed Doubler managed to do what it did. I can understand substituting various function calls with optimized algorithms that execute faster. But to achieve that marked an improvement would mean Apple's designs were bad to the point of incompetence.
I think it was because Apple still had some Quadras on the market concurrently with the Nubus PPC machines and making the new machines blow the old ones out of the water under emulation would have meant Apple getting stuck with a lot of leftover 040 machines.

 

trag

Well-known member
Speed Doubler alleviates the problem of the slow emulation built into the 601 based machines.
I've long wondered how Speed Doubler managed to do what it did. I can understand substituting various function calls with optimized algorithms that execute faster. But to achieve that marked an improvement would mean Apple's designs were bad to the point of incompetence.
Apple's emulator ran as an interpreter. It would take a 68K command, translate it, execute the code, then discard the translation.

Connectix's emulator ran as more of a compiler, or at least a caching interpreter. It would translate chunks of code and keep the translation around to be executed. Because most code contains a great many looping structures which are executed over and over again, this scheme saves buckets of interpretation time. Speed Doubler's emulator only needs to interpret a loop of code once and then it executes as many loops as required. Apple's emulator would interpret the loop of code every time through the loop, over and over and over and over.

 

tomlee59

Well-known member
So, Apple's approach *was* bad to the point of incompetence. Seems as if their emulation engine was a quick and dirty hack.

 

Blessed Cheesemaker

Well-known member
Apple's emulator ran as an interpreter. It would take a 68K command, translate it, execute the code, then discard the translation.

Connectix's emulator ran as more of a compiler, or at least a caching interpreter. It would translate chunks of code and keep the translation around to be executed. Because most code contains a great many looping structures which are executed over and over again, this scheme saves buckets of interpretation time. Speed Doubler's emulator only needs to interpret a loop of code once and then it executes as many loops as required. Apple's emulator would interpret the loop of code every time through the loop, over and over and over and over.
Thanks, I always wondered how it worked. Using it on my PPC's with OS 7.6, SpeedDoubler was great...however, my experience with RamDoubler always led me to view Connectix products with suspicion, especially whenever I had stability problems. Connectix had great "hacks", and I say that as a compliment. At a certain point, software hacks can only compensate so much for a hardware issue (i.e., the solution to RamDoubler is to buy more RAM...back when RAM was $$$, even for 8mb, paying $49 for RamDoubler was quite deal).

Nevertheless, my 68k speedup tip is to always run the earliest OS you can on the fastest platform you got. I run 6.0.8 on a IIsi, and I run 7.1 on a Quadra 700. If you need to go online, OT and 7.6.1 are your best bet. I find that 7.6.1 runs well on both the IIsi and 700, but of course, nowhere as speedy as 7.1 or 6.0.8.

 
Top