• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

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

Bolle said:
Oh crap, I totally forgot about that...
The GALs are available over here on the PLD archive and see the attachment for the schematics if the RAM board.
Click to expand...
Thanks to the invaluable help of @JC8080 , the schematics for the Mercury 030 RAM board shared by @Bolle have finally been corrected. I've tested them with the RAM ICs (AS4C1M16E5) used in the standalone 4MB RAM board for the 128/512K, and it simply works!

Moreover, it works with the EDO version of these RAM chips. This is a big deal since I haven't been able to find authentic FPM versions (the ones I bought on Amazon turned out to be fake).

JC8080 bought a Mercury board with the RAM expansion a few years ago. Coincidentally, he bought it from the person who posted some nice pictures of it on Reddit. I actually contacted the original owner a few weeks ago, but he told me he had sold it. It turns out the buyer was JC8080!

If anyone would like to make an exact replica of the original RAM board for the Mercury 030 accelerator, or even integrate it into the Performer accelerator board, whether using the original 30-pin SIMMs (80ns or faster for 0 wait state) or these high-density RAM ICs, it can now be done!

The corrections are as follows:

Pin 4 of RU1A needs to be pulled up, so it should be connected to pin 1 or pin 10. If left floating, it corrupts the output pulse used by the synchronous part of the FSM for RAM refresh.

CLK for RU9 is CLK_30. (CLK_30 and SM_CLK16 are the same signal but are driven separately).

The "Big One": This had me scratching my head for months! Pin 12 of RU9 is actually DSACK1 for 32-bit data transfers, so it is connected to the other DSACK1 output generated on the accelerator board (pin 12 of U4). Checking the equations, it makes perfect sense: these two outputs are never driven by the PLDs at the same time. The DSACK1 from the RAM board only becomes active when the Fast RAM is being accessed; otherwise, it is tri-stated (the same thing happens with DSACK1 from the accelerator board for 16-bit onboard RAM accesses). DSACK0 is generated exactly like DSACK1 from the RAM board, which now seems pretty obvious since both DSACKs must be low for 32-bit word transfers.

That’s it for now!

It is important to add that the only driver that has worked for me (with or without the 32-bit RAM expansion) is the DOVE Racer 030. None of the "Gemstart" drivers out there seem to work in my prototypes. Interestingly, the "External Data Cache" functionality now seems to be activated when selected (the driver icon now shows the word CACHE); I don't know yet if it makes any difference.
 
Last edited:
What's the maximum amount of memory the Mercury 030 can address?
How would you integrate the RAM expansion logic into the Performer? At a glance, the Mercury 030 GAL U3 seems slightly different than the Performer's GAL U3.
 
luRaichu said:
What's the maximum amount of memory the Mercury 030 can address?
Click to expand...
4MB. The way it works is by replacing the system RAM with 4MB of 32-bit RAM. It only 'switches' back to the system RAM for a small 32 KB region at the top where the video buffer resides. This logic can work on any early Mac that uses the stock Macintosh Plus ROMs.

Other Total Systems accelerator models can handle up to 16 MB of onboard RAM. Connectix Virtual is a must in order to access that extra RAM.


luRaichu said:
How would you integrate the RAM expansion logic into the Performer?
Click to expand...

Just add the schematics shared by Bolle (with the corrections mentioned) to your Performer schematics. All signals are labeled accordingly to match the original schematics (PDF file) which you can find on his GitHub page.

It is up to you whether you want to implement the original RAM ICs (30-pin SIMMs) or the RAM ICs I tested.

Here are the schematics for the new RAM ICs:


RAM.png

Let's say the hard part is the PCB layout for the Macintosh Plus and SE that integrates the new components. I made a custom PCB layout (currently in the prototype stage) for the Macintosh 512K that also integrates the SCSI I/O interface and the option of use stock or custom ROM ICs (ROM-INATOR)

Mercury_Reloaded.png

I would like to call it 'Mercury Reloaded.' It's more appropriate than 'Performer Fusion,' since the Mercury 030 board was intended for the Macintosh 128/512/Plus, while the MM Performer can't be installed on a Macintosh 128/512K.

The U7 chip is optional; the 16 MHz clock can be fed to it from the logic board, just the same way the Mercury board did.

luRaichu said:
At a glance, the Mercury 030 GAL U3 seems slightly different than the Performer's GAL U3.
Click to expand...

Yes, you're right! There is a little difference in how it handles the NOFC signal. I used the GAL dumps from the Mercury board; I haven't tested the MicroMac Performer GALs yet.
 
Last edited:
I’m certainly not an expert in 68030 architecture (I’m sure others here could give a more precise technical breakdown) but this is a really interesting question. Honestly, I asked myself the exact same thing when I first started digging into this project.

In my opinion, the short answer is no: 0 wait-state DRAM doesn’t strictly negate the need for a cache. However, at 16 MHz, it makes the lack of a cache much less painful than it would be at higher clock speeds.

The RAM expansion logic on the Mercury 030 uses standard asynchronous bus cycles via DSACK signals (which usually take a minimum of 2 or 3 clock cycles) . A proper cache controller (or even a RAM expansion using the synchronous STERM signal) can take advantage of the 68030's Burst Mode. So, while this accelerator with the fast RAM upgrade is snappy (running 2-2-2-2 timing) a system with a cache could theoretically be faster on memory fills by using burst mode.

Exactly how much faster is hard to say, considering these early Macs have to switch back every 1/16th of a second or so to access the screen buffer in that slow system RAM. I really don't know how that specific overhead balances out in real-world use.

I’d say the next feasible step up would be using SRAM instead of DRAM in synchronous mode. From what I’ve gathered, you’d need SRAM ICs rated at 35ns or better to handle the tight timing of 16 MHz burst cycles. On the plus side, the logic would actually be simpler than the actual DRAM controller since you don't have to worry about memory refresh cycles, which might even mean needing fewer GALs.
 
Last edited:
SRAM at that speed is still much more expensive than DRAM even today. And you would need to write your own logic, which is not something I understand.
 
Besides the corrections already mentioned, there is another subtle issue:

One of the PLDs on the original RAM expansion board is 25 ns while the other three are 15 ns. Coincidentally, this PLD outputs the four CAS signals.

This may well explain why I am experiencing instability issues with my prototype; a stress test or minimal thermal drift induced on the RAM ICs immediately causes the system to crash. That 10 ns delay difference is almost certainly intentional and part of the original design.

Screenshot 2025-12-27 at 5.14.31 PM.pngRU7),
 
A little progress:

It turns out there are no changes when 15 ns or even 10 ns GALs are used in the RAM expansion logic. Now the EDO RAM ICs are working with a proper RAM_OE signal generated in GAL RU7 (although these RAM ICs seem to work fine with the OE pin tied to ground as well).

I moved the RA8 and RA9 multiplexed address bits to a third 74257 to free up outputs in RU7 to implement RAM_OE.

If I cool down the RAM ICs with a gel freeze pack, Speedometer is able to finish all tests without crashing. My primary suspect for the instability is the RAM ICs themselves. I will buy a new batch of 60 ns and 50 ns chips to see if the problem is due to faulty RAM or write timings too tight. There are no perceivable differences in instability or speed when the ZERO WAIT jumper is closed.

You can certainly notice the speed boost provided by the 32-bit RAM.

I am attaching the latest schematics in case anyone would like to experiment with them!

For those catching up with the latest developments on this board:

Main Accelerator Logic: You can use the GAL dumps of U3, U4, U5, U6, and U7 from the MicroMac Performer or the equivalents from the TS Mercury 030. The GAL dump for U3 from the MMP is slightly different (it seems to gate the NOFC signal to DTACK), but I have encountered no difference in behavior using the version from the TS Mercury 030.

SCSI & ROM Logic (U8): U8 mirrors the logic from the Macintosh Plus to handle the SCSI I/O interface and implements the logic needed to use ROM-INATOR ROMs (JEDEC file attached). This sub-logic is rock solid. (If you intend to use it with a BlueSCSI V2 external, there is no need to populate the 110-ohm termination resistors).

RAM Expansion Logic: Use Bolle’s versions of RU6, RU8, and RU9. I am attaching my own version for RU7, which implements the optional RAM_OE signal for EDO RAM ICs.

Modular Implementation: If you are only implementing the RAM expansion for your own version of the MP accelerator on a Macintosh Plus or SE, you can safely discard the sections for SCSI, custom ROMs, and the U8 GAL IC.

There are some pull-up resistors included for experimentation purposes. The Plus LB PCB revision includes these, but they are not present on the 512K LB PCB. I added them just for testing.

One thing that bothers me about this RAM board is that it does not use buffers for the entire 32-bit data bus. I think it would do no harm—and would likely improve signal integrity—to also buffer D0–D15 by adding an additional couple of 74245s.

I would like to get feedback from anyone who has this RAM expansion board in working condition. How stable is it for you?

Finally, there is a SCSI expansion board for the TS Mercury that I would love to reverse-engineer just for fun. Does anyone out there have it? I don’t necessarily need the JEDEC files for its GAL ICs; it would likely be enough to reverse-engineer its connections to the accelerator board. I haven’t found a single photo of this board on the internet—only scans in a TS brochure.

That's all for now.
 

Attachments

Last edited:
You must log in or register to reply here.

Similar threads

Juror22
Dove Marathon 030 for Mac II - Does not boot, and needs repair?
Replies
9
Views
2K
Juror22
Juror22
zigzagjoe
Repair of a basket case DiimoCache030
Replies
5
Views
560
Bolle
Bolle
JC8080
Mac Plus/SE Performer accelerator build
2 3
Replies
41
Views
14K
obsolete
obsolete
Z
SE and SE/30 accelerators--discussion of new hardware development
2
Replies
37
Views
10K
Bunsen
Bunsen
Back
Top