Sonnet Doubler Allegro for Mac II

David Cook

Well-known member
I picked up a Macintosh II with a surprise inside: The Sonnet Allegro Doubler Mac II. The board has a 68030 processor fed double the native clock (15.6672->31.3344) which is marketed as 16 MHz -> 33 MHz.

Doubler FPU AMMU.jpg

Besides the speed bump, the other benefit is that the 68030 includes a built-in MMU. This overcomes the limited functionality of the black Apple MMU (upper left of the picture above) and thus a replacement 68851 PMMU is no longer required. If you have GAL-based 4 MB SIMMs and upgraded ROMs, then the Mac II can use more than 8 MB of memory.

There is a slightly futuristic heatsink on the CPU. Other people have reported pulling off the heatsink to discover the CPU that Sonnet used was not officially rated for 33 MHz. Maybe the heatsink is necessary for overclocked parts?

Heatsink.jpg

The underside is sparse. It has a 68020 pinout to connect to the 68020 socket on the Mac II motherboard. There is a similar Sonnet board with a 68030 pin connector for the SE/30 and IIx. They are not interchangeable.

Underside.jpg

My board would not post (no chime or display) when I received it. Some other people have reported similar fates. The middle area of the top of the board seems to have received a little less solder than everywhere else. I reflowed the pins and pads in that area. However, for me, the root cause was a loose external SCSI terminator that the eBay seller tossed into the Mac II case which apparently banged around during shipping. Notice a bent/lifted pin in the image below?

Borken.jpg

The Sonnet Doubler results in about a 50% boost in performance. That doesn't seem like a lot, but for a relatively slow computer it is noticeable.

Here is the advertisement from Sonnet.

allegro_macii_speed.gif

And below is what I measured. 148% in both cases! How honest. For comparison, @zigzagjoe 's Interware Booster clone for the IIx runs faster -- and includes a faster FPU.

Sonnet-Doubler-Symantec.jpg

The detailed ratings show that CPU clock boosters are limited by main memory performance.

Sonnet-Doubler-Symantec-Detail.jpg

Peeking at the performance of the 68030's built-in 256 byte data cache, we can see the full clock speedup when main memory is not involved. (The 68020 has an instruction cache but no data cache.)

1747520000033.png

I ran my tests on System 7.1 with the Sound Manager extension removed and with the Sonnet Allegro extension 1.2 added. Notice above, that the lack of an Allegro extension has a tiny negative effect on performance (the far left of the graph). I ran the tests multiple times to confirm the effect was real. The extension may also increase compatibility.

The Macintosh startup sound runs at double speed. But, no other sound issues were noted. Again, I removed Sound Manager as it likely plays the sounds from code in RAM, rather than the ROM location that the Allegro card knows to slow down for.

The floppy drive on this Mac II did not work, so I did not have the chance to test it. Other people have indicated that the floppy drive cannot be used for booting, as the Allegro extension (?) can't fix floppy disk access until after the extension is loaded.

All in all, it was fun playing with this. But, the limited boost is not worth the potential incompatibility in my opinion. Don't bust your bank account bidding this up on eBay.

- David
 

Attachments

  • 1747519963424.png
    1747519963424.png
    19.4 KB · Views: 4
  • Cache.jpg
    Cache.jpg
    71.6 KB · Views: 2

Bolle

Well-known member
and upgraded ROMs
Those are actually required to be able to use this CPU upgrade. The non-FDHD Mac II ROMs don’t work with 030 CPUs and you’ll end up in a reboot loop.

NICE! Tagging our resident cloners
Done already. There’s a GAL20RA10 on there that I already cracked and did draw schematics too, it just hasn’t materialized yet.
 

Byrd

Well-known member
Yes I've got one of these in my SE/30 - gives a really nice performance boost, but obviously a low cost accelerator with caveats (sound and HD floppy access). Mine started to get unreliable wasn't sure why but will check the legs as you've done wouldn't be surprised if one was loose.
 

max1zzz

Well-known member
Done already. There’s a GAL20RA10 on there that I already cracked and did draw schematics too, it just hasn’t materialized yet.
I swear you have clones on just about every accelerator known to man on the go :)
 

zigzagjoe

Well-known member
On the topic of unmaterialized designs... I flirted with the idea of making a Mac-II specific booster with the patch rom from the Diimo/DayStar adapters to sidestep the ROM issue. I don't have access to a MacII though so it has fallen by the wayside.
 

Powerbase

Well-known member
On the topic of unmaterialized designs... I flirted with the idea of making a Mac-II specific booster with the patch rom from the Diimo/DayStar adapters to sidestep the ROM issue. I don't have access to a MacII though so it has fallen by the wayside.
I would definitely be interested in that. The Mac II was one of household computers back then and I would love to upgrade it.
 

David Cook

Well-known member
What part# of EPROM (or similar technology) would be needed to replace the Mac II ROMs? It might be worth upgrading the ROMs rather than side-stepping to be able to get the benefit of >8MB of RAM since the Doubler has a PMMU.

Anyone interested in making 4 MB or 16 MB SIMMs using the OR-chip trick?
 

zigzagjoe

Well-known member
What part# of EPROM (or similar technology) would be needed to replace the Mac II ROMs? It might be worth upgrading the ROMs rather than side-stepping to be able to get the benefit of >8MB of RAM since the Doubler has a PMMU.

Anyone interested in making 4 MB or 16 MB SIMMs using the OR-chip trick?
Out of curiosity were you able to test that the 030 MMU can be used? I'm not super familiar with the Mac Ii architecture, does the fake MMU stay in 32 bit (hardware addressing) mode unless explicitly set to 24 bit?

Later machines are always 32 bit hardware addressing (ie $90000 will becomes $F9000000) but the original LC and presumably Mac II are weird because of the 020.
 

ObeyDaleks

Well-known member
As far as I know, the Mac II with a ROM upgrade is still dirty and requires Mode32 regardless. Coupled with the PMMU, it allows the machine to address up to 68MB or RAM. I.e. you need both upgrades to address more than 8MB.

I believe you additionally need the SWIM upgrade to get 128MB capacity.

Of course, even with all that, you still need to score some PAL RAM. Mine has all the upgrades (and a Turbo 040 which makes the PMMU moot) and I was never able to find any SIMMs larger than 4MB. I don't think they exist.
 

David Cook

Well-known member
Out of curiosity were you able to test that the 030 MMU can be used?

Yes. With Mode 32 installed in the System, the Memory Control panel offers the ability to switch to 32-bit. I have the AMMU installed. It seems like the 68030 MMU overrides it.

As far as I know, the Mac II with a ROM upgrade is still dirty and requires Mode32 regardless.

Agreed. I was actually hoping that maybe we could install custom IIsi ROMs with the memory check disabled.

I believe you additionally need the SWIM upgrade to get 128MB capacity.

Yes. It looks like the most you can get without SWIM is 68 MB.

Of course, even with all that, you still need to score some PAL RAM.

Good point. Kai posted the gerbers for 4 MB RAM using an OR chip instead of a PAL. That would get us to 32 MB with a SWIM or 20 MB without.
 

David Cook

Well-known member
It surprises me that the IIx suffers from needing GAL/PAL memory but the IIcx does not. I always thought of the IIcx as simply a IIx with fewer slots. But, apparently they incorporated some other improvements as well.

It appears that 2Mbit EPROMs require 32 pins, whereas 1Mbit EPROMs only need 28. On the Mac II, there isn't physically enough room to squeeze in a 32 pin chip to replace the ROMs with 512KB IIsi versions. A carrier board would be needed. Instead, I wonder whether a 256 KB 32-bit clean ROM could be produced. The guys that know ROMs probably just need to trim the ROM 'directory' as I think it is otherwise universal.
 

zigzagjoe

Well-known member
It surprises me that the IIx suffers from needing GAL/PAL memory but the IIcx does not. I always thought of the IIcx as simply a IIx with fewer slots. But, apparently they incorporated some other improvements as well.

It appears that 2Mbit EPROMs require 32 pins, whereas 1Mbit EPROMs only need 28. On the Mac II, there isn't physically enough room to squeeze in a 32 pin chip to replace the ROMs with 512KB IIsi versions. A carrier board would be needed. Instead, I wonder whether a 256 KB 32-bit clean ROM could be produced. The guys that know ROMs probably just need to trim the ROM 'directory' as I think it is otherwise universal.
IIRC, MODE32 should work with the HMMU. Max RAM would be dictated by how large of a single contigious bank of RAM you could arrange though, so practically not the most useful.

I suspect that unless commanded otherwise the HMMU just remains in simple 32 bit passthrough mode so the 030 is able to work.

The IIsi ROM map is over 256K, so it's unfortunately already too big even without any resources.
 

David Cook

Well-known member
IIRC, MODE32 should work with the HMMU. Max RAM would be dictated by how large of a single contigious bank of RAM you could arrange though, so practically not the most useful.

Very interesting. You're saying if I throw in 4x4MB GAL SIMMs into both banks (32 MB total), I will get 16 MB of addressable memory in 32-bit mode (via MODE32) even without a PMMU? And, when I add the PMMU, it can map the other 16 MB to give me 32 MB?

So, to test if the Doubler's 68030 PMMU is truly active, I need to add those GAL SIMMs to see if I get 16 MB or 32MB?
 

zigzagjoe

Well-known member
Very interesting. You're saying if I throw in 4x4MB GAL SIMMs into both banks (32 MB total), I will get 16 MB of addressable memory in 32-bit mode (via MODE32) even without a PMMU? And, when I add the PMMU, it can map the other 16 MB to give me 32 MB?

So, to test if the Doubler's 68030 PMMU is truly active, I need to add those GAL SIMMs to see if I get 16 MB or 32MB?
Maybe. I am spitballing a bit here. I'm not exactly certain how much intelligence the early DRAM controller has (iirc, not much), however using 8x1MB was definitely an option so something allowed for an contigious 8MB of RAM with the HMMU. I suppose a first question is if 8x1 works with Mode32. There is a comment in the Mode32 readme about no longer hanging on reboot on a Mac ii without PMMU.

Normally the MMU is used to make a couple of disjoint memory banks look like contiguous RAM from the software side if the DRAM hardware can't do it for you. If you had a single large bank that ought to accomplish the contiguous requirement without the MMU. It's going to be a trial and error affair, I think, but disassembly of the ROM would probably shed some light too.
 

David Cook

Well-known member
This is more complicated than I thought. However, I think the ability to use Virtual Memory definitely indicates that the Doubler's 68030 MMU is active.

1747628114220.png
 

Bolle

Well-known member
On the topic of unmaterialized designs...
With having the PowerCache and Turbo040 adapter for the Mac II available I haven't been very motivated to move forward with it.

would be dictated by how large of a single contigious bank of RAM you could arrange though, so practically not the most useful.
The GLUE does some mapping on its own if programmed correctly but there's certain limitations to how you can combine different sized SIMMs on both banks.
Yes. It looks like the most you can get without SWIM is 68 MB.
The SWIM does play absolutely no role at all at how much memory the Mac II will support. The ROMs (identical with IIx and SE/30 ROMs) that came with what Apple called the "FDHD upgrade" are what makes it support more than 68MB. You can install those ROMs without actually replacing the IWM with the SWIM and still get support for 128MB.

The table over here is actually accurate. Without a PMMU (either a standalone one or via 68030 or 68040 upgrade) you're stuck at a maximum of 8MB. Once you've jumped through that hoop the next limit is 68MB and from there you need a IIx ROM.

It surprises me that the IIx suffers from needing GAL/PAL memory but the IIcx does not
The IIcx adds a GAL on the logicboard that is sitting between the DRAM control signals that the GLUE puts out towards the RAM to get around the "faulty" signaling sequence that sends higher capacity DRAM chips into test mode basically making them fail. The same is true for the SE/30.
 

zigzagjoe

Well-known member
With having the PowerCache and Turbo040 adapter for the Mac II available I haven't been very motivated to move forward with it.


The GLUE does some mapping on its own if programmed correctly but there's certain limitations to how you can combine different sized SIMMs on both banks.

The SWIM does play absolutely no role at all at how much memory the Mac II will support. The ROMs (identical with IIx and SE/30 ROMs) that came with what Apple called the "FDHD upgrade" are what makes it support more than 68MB. You can install those ROMs without actually replacing the IWM with the SWIM and still get support for 128MB.

The table over here is actually accurate. Without a PMMU (either a standalone one or via 68030 or 68040 upgrade) you're stuck at a maximum of 8MB. Once you've jumped through that hoop the next limit is 68MB and from there you need a IIx ROM.


The IIcx adds a GAL on the logicboard that is sitting between the DRAM control signals that the GLUE puts out towards the RAM to get around the "faulty" signaling sequence that sends higher capacity DRAM chips into test mode basically making them fail. The same is true for the SE/30.

Ah, sorry, that wasn't a criticism, it just reminded me of one of my own unfinished projects :)

I forgot - RAM bank location with a GLUE is controlled by a couple of VIA bits. So, it will depend on how that is set up by the ROM. Looks like HMMU switching is also controlled by a VIA bit, so presumably it defaults to 32 bit and isn't touched if a PMMU is detected. If virtual memory is working the 030 MMU is definitely in use.

I suppose the question becomes a) what happens with 16MB of RAM in one bank only with an unupgraded ROM. Does it set things up for a 4MB boundary, truncating the 16MB bank? I assume this behavior is what the upgraded ROMs improve upon.
 

ObeyDaleks

Well-known member
The SWIM does play absolutely no role at all at how much memory the Mac II will support. The ROMs (identical with IIx and SE/30 ROMs) that came with what Apple called the "FDHD upgrade" are what makes it support more than 68MB. You can install those ROMs without actually replacing the IWM with the SWIM and still get support for 128MB.

Ahh, thanks for the explanation. It makes sense, and honestly I always wondered why the SWIM chip plays a role in memory addressing. I think the confusion is that some of the literature refers to it as the "SWIM upgrade", which includes the IIx ROMs.

So, PMMU alone gives you 68MB, and ROMs give you additional addressing up to 128MB? Do the ROMs alone give you anything?
 
Top