When paired with a DRAM controller typical of the period the 68030 usually takes about five or six clock ticks to read a 32 bit quantity from RAM. If we assume 5 clocks then the maximum memory bus performance of the SE/30 is: 16Mhz X 4 = 64MB / 5 = 12.8MB/s.

Click to expand...

I can't claim to be authoritative on this, but I've been playing around with the 030 timing diagrams, reading a bit, and wrote a little test code, and here's what I've found:

Guide to the Macintosh Family Hardware says:

In the Macintosh SE/30, a card in the 68030 PDS can access system RAM and ROM at the same rate as the main processor: 15.67MB per second.

Click to expand...

AFAICT, that corresponds to 4 clock cycles per 32bit read, which seems to match the memory access diagrams I've been looking at.

And that assumes all aligned accesses.

I wrote some test code earlier this week which is doing RAM to RAM copies at slightly over 5.2MB/s. Since that's 2 ram accesses, that's about 10.4MB/s throughput. The test flushes the data cache and does 8 32bit copies, of the form:

looping every 256KB. At the end of 256KB, it flushes data cache (probably inadvertently blowing the instruction cache in the process by calling the _FlushDataCache trap rather than manually manipulating the CACR), and repeats the loop 1000 times.

I might go back and refine the test a bit and see if I can account for the missing 1/3rd of the bandwidth, but if the instruction cache is blown and the instructions need to be refetched, combined with looping and cache flushing overhead, it seems approximately in the right ballpark.

But, this might be pretty close to real world performance, since this is pretty much what the BlockMove() OS trap does (BlockMove has some extra code to handle unaligned access, 24 vs 32bit addressing, etc.), which is used most everywhere as the "fast" memory copy. Unfortunately, BlockMove() flushes the instruction cache for compatibility with 68000 code, since it's used to move CODE (and other executable) resources into memory and executed. They added BlockMoveData() as a way to indicate it's just data, not executable code, but adoption was not ubiquitous, and thanks to abstraction layers, you might not know it's data, so have to err on the side of caution. Plus, unaligned accesses.