** 7TH NEWS UPDATE **
Romy rev. 8 was uploaded to post #1. Functionally, it's the same as rev. 7 but should be more reliable on over-clocked motherboards. Previous versions of Romy used asynchronous reset on all registered outputs to simplify the logic and because I wanted to make earlier versions as bug free as possible. Rev. 7 worked fine @ 25 MHz but would probably not be able to run a 3 clock cycle @ 33 MHz. Due to shorter cycle timing Romy would have approx. 10ns less time to come out of reset and sample clock 90. (Even a 10ns GAL may not be fast enough when you factor in 10-15ns delayed AS assertion). So this version replaces asynchronous reset logic with AS negation and flip-flop logic to set all registers at cycle end.
Now, to make things a little more interesting here are my (CPU nodatacache) Bustest results for the 3 clock cycle!
68030 @ 25 MHz:
BusSpeedTest 0.19 (mlelstv) Buffer: 262144 Bytes, Alignment: 32768
========================================================================
memtype addr op cycle calib bandwidth
user $00E00000 readw 242.9 ns normal 8.2 * 10^6 byte/s
user $00E00000 readl 243.9 ns normal 16.4 * 10^6 byte/s
user $00E00000 readm 222.7 ns normal 18.0 * 10^6 byte/s
user $00E00000 writew 161.8 ns normal 12.4 * 10^6 byte/s
user $00E00000 writel 161.9 ns normal 24.7 * 10^6 byte/s
user $00E00000 writem 146.9 ns normal 27.2 * 10^6 byte/s
68040 @ 50 MHz (Romy @ 25 MHz):
BusSpeedTest 0.19 (mlelstv) Buffer: 262144 Bytes, Alignment: 32768
========================================================================
memtype addr op cycle calib bandwidth
user $00E00000 readw 201.6 ns normal 9.9 * 10^6 byte/s
user $00E00000 readl 201.9 ns normal 19.8 * 10^6 byte/s
user $00E00000 readm 206.5 ns normal 19.4 * 10^6 byte/s
user $00E00000 writew 120.5 ns normal 16.6 * 10^6 byte/s
user $00E00000 writel 120.5 ns normal 33.2 * 10^6 byte/s
user $00E00000 writem 121.1 ns normal 33.0 * 10^6 byte/s
Note: This time I've included write cycle benchmark results to give you a better idea of how fast the cycles are going from Romy's point of view. Do you suspect 68K read instructions execute more slowly than write instructions? Do you suspect Bustest calculates the results differently for read and write cycles? However, my Fast memory Bustest results are the same on both read and write!
Bustest does attempt to "compensate" for instruction execution time but it's very hard to make an accurate benchmark program because of:
MOTOROLA MC68030 USER’S MANUAL
11.1 PERFORMANCE TRADEOFFS
The MC68030 maximizes average performance at the expense of worst case performance.
The time spent executing one instruction can vary from zero to over 100 clocks. Factors affecting the execution time are the preceding and following instructions, the instruction stream alignment, residency of operands and instruction words in the caches, residency of address translations in the address translation cache, and operand alignment.