You are not logged in.

#1 2015-11-21 14:58:28

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,404

Lab Tested: First Generation Compact Mac Acclerators, MacUser March'88

Fabulous new posting: 68kMLA thread

I'm not sure I've ever seen this one. I'm curious how many generations of SE accelerators need to be identified. I'm thinking four, these pre-date use of the 25MHz 68020, much less the 68030. Second generation would be post 68020/25 leading up to RAM expansion capable accelerators. Third gen accelerators would be those supporting up to 8MB of RAM, pre-dating the 1991 release of MODE32. That fix along with Connectix' Compact Virtual allowed a fourth generation of Compact Mac accelerators to support up to 32MB of silicon disk VM.

Thoughts?



edit: ISTR mention of Maxima, but not Optima from Connectix. I wonder how many Accelerator companies nibbled away at the edges of Compact Mac addressing issues before the release of Compact Virtual and if they did so, how the did it?

https://en.wikipedia.org/wiki/MODE32

Last edited by jt (2015-11-21 16:21:08)

Offline

#2 2015-11-21 22:16:12

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: Lab Tested: First Generation Compact Mac Acclerators, MacUser March'88

I've never really been into accelerators much.  AFAIK, none of them addressed any of the 24bit addressing problems.  It required a complete replacement for the memory manager to allow >8MB RAM, and then patching a couple toolbox routines.  The one thing accelerators did run into was cache invalidation problems.  The 68000 had no cache, so the ROMs for those machines did not have to do any cache flushes at all.  The 68020 and 030 had combined data an instruction caches IIRC and the 040 had separate instruction vs. data caches.  Cache invalidation in general was important to MacOS and especially important with separate instruction vs. data caches because of the way resources were loaded into memory and executed.  The toolbox ended up taking a hit because of this, with BlockMove() for copying data around.  Initially, bits was bits, and caches weren't involved and you could just move data around without worrying about it.  When combined data and instruction caches were added, in order to maintain compatibility, BlockMove() had to flush the cache.  Given that the cache size of the 020 was pretty small, it wasn't that big a deal.  It was a bigger deal on the 030, and then even bigger deal with the external caches that were added.  Then with the separate instruction vs. data caches, you didn't want/need to flush both, so BlockMoveData() was introduced to prevent flushing the entire world.
Early accelerators often had to work around the caching issue, usually by just neutering the cache on the accelerator.  Otherwise, software changes were necessary to patch some of these calls to add invalidation.  It became easier with the Mac II and later, when the ROMs of those systems had already addressed the software side.

Offline

#3 2015-11-22 14:37:54

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,404

Re: Lab Tested: First Generation Compact Mac Acclerators, MacUser March'88

I wish more information were covered about memory configurations and possibilities in the Lab Test:
gallery_5272_107_1354312.jpg
The Turbo SE shows 64K on the MoBo, might that mean it only addresses the Frame Buffer portion of the installed memory? Some Accelerators have Sockets for SIMMs, some do not, some require the Mac's ROMs to be relocated to the Accelerator, some do not. Haven't worked out any correlation there as yet. Not all the pics are very representative on that note.

Looks like the SE version of my Radius16 was third fastest of the roundup, despite using only system memory. All of the ran at 16MHz. The second Accelerator generation would bring about distinctions like Radius16/25 in 68020 versions and 68020/68030 options implemented on a few of the first batch of 68030 capable Accelerators.

gallery_5272_107_998300.jpg
Looks like I was mistaken in my memory that the Radius16 required an INIT/Driver. How do you think Accelerators managed to get the system to ignore the CPU.
gallery_5272_107_1117423.jpg
Gotta dig up the thread(s) I posted with lab test article scans of Accelerators in a later time frame. Maybe just re-post them here?

Offline

Board footer

About ThinkClassic

ThinkClassic specialises in the maintenance, repair, restoration and modification of Vintage Apple and Macintosh computers. Ask questions and find answers about classic Apple desktops, laptops, accessories and peripherals.