Seeking Dove Marathon 030 Racer with cache for Plus/SE Accelerator Info (JED files, pics, or existing work!)

[Phipli]

With the 32-bit RAM upgrade, performance is almost on par with a stock SE/30, although the prototype remains unstableView attachment 93906

Yeah, onboard RAM makes a huge difference. I'm surprised it doesn't benchmark faster due to the RAM speed, although I prefer Norton System Info due to the greater granularity of the tests. And the cats.

 

[luRaichu]

You've not limited to System 6 though, as official support is up to 7.1 using later (Extreme Systems and universal versions of GemStart) software?

Hey, thanks for the tip about GemStart. 7.1 runs stable on my upgraded Plus with that driver

 

[Phipli]

Hey, thanks for the tip about GemStart. 7.1 runs stable on my upgraded Plus with that driver

I was confused I usually use my similar cards on 7.0.1 and 7.1

 

[luRaichu]

Are you sure the Mercury 030 can only access up to 4MB of RAM? It appears the 68030 MMU isn't being disabled.

 

[CC_333]

Are you sure the Mercury 030 can only access up to 4MB of RAM? It appears the 68030 MMU isn't being disabled.

It might be a limitation of the ROM.

c

 

[luRaichu]

In that case, Linux or NetBSD might be able to use it.

 

[Builder68]

Are you sure the Mercury 030 can only access up to 4MB of RAM? It appears the 68030 MMU isn't being disabled.

The short answer is no, it cannot. This is not purely an OS or ROM limitation.

The logic of the Mercury 030 is designed to operate strictly within the memory map defined by the ROM. This is not a limitation of the 68030 CPU itself, but rather a result of the address decoding logic implemented in the accelerator's PLDs, which only respond to the 24-bit address space (16 MB) legacy of the Macintosh Plus.

Expanding beyond the 4 MB RAM limit is technically feasible and is a feature seen in other accelerators for 68000-based Compact Macs. By decoding higher address lines, you can map additional SRAM into the higher address space above 16 MB. This memory would remain invisible to the OS because it resides outside the memory map initialized by the ROM.

This is where the Connectix Virtual software becomes essential. Virtual is able to detect and configure the 68030’s internal MMU to map these high-memory physical addresses and translate them into a logical space that the OS (System 7) can utilize. As long as the hardware decoding exists to 'select' the RAM at those higher addresses, the MMU bridges the gap between the 24-bit Mac Plus architecture and the 32-bit capabilities of the 030.

I think the logical path to implement this feature is to first take a deep dive into the logic of a 68030 accelerator board for the Macintosh Plus/SE that implements it. By grasping how this is done, we can then adapt the Mercury's logic accordingly. As far as I know, there are no open-source projects out there that have reverse-engineered any accelerator boards (For the Macintosh Plus/SE) with these capabilities.