Jeez... You had right all along
It just took a numpty [me] to go the long way around connecting the dots like a madman with string and pins at a cork board!
-
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.
Wombat (650, 800) board overclocking limitations
- Thread starter jessenator
- Start date
It just took a numpty [me] to go the long way around connecting the dots like a madman with string and pins at a cork board!
are you in the US? since I have no use for it now, I'm willing to send you my macclip so you can test out clock speeds without needing all the oscillators, send me a message if you're interestedOnly one way to find out, I suppose
it looks like gestalt 51 will work for 7.5.3 and later, so that's probably the one to go with (so just remove the resistor(s) on the board)
I've been wanting MacClips for my 650, 7100, and 8100 (I also want to OC my 650 to 40+ Mhz). So, if you happen to have extras you're willing to sell, I'm happy to buy them. That said I don't want to impede the exploration/experimentation happening here.
Only have the one, someone was selling a pile of them on ebay for $5 each last year (must have found some old stock).
I got
config table[...]
Code:
@bump40Config dc.w %0000001011111100
wombat-hax -----001011110100refresh table[!]
Code:
@dj40Refresh dc.w 597 [0000001001010101]
wobat-hax [----001001010101]
I think we're in business
We're running the correct DRAM refresh register!
It think it is the number of clock cycles between refreshes. 40 MHz / 660 = 60606 Hz. 1/60606 Hz = 16.5 uS, which is about the amount of time recommended between memory refreshes. (My memory says 16.6 uS, but I used to do DDR2 professionally, so I could be confusing them. I'm too lazy to check a datasheet)
As you make the clock speed faster, that number needs to be larger to maintain a constant 16.5 uS, otherwise you start refreshing more often than you need to and lose performance.
E.g. 50MHz / 660 = 75757Hz 1/75757Hz = 13.2 uS
Working backwards: 1/16.5 uS = 60606 Hz; X / 722 = ~60606; X = 60606 * 722 = 43.75 MHz.
Looks like they may have had a target of 45 MHz for the speed bump.
If you want to target 50MHz then 50MHz / X = 60606 Hz; X = 50 MHz / 60606 Hz = ~825 for 50 MHz.
Not trying to contradict the obviously more knowledgeable person in the conversation
help me understand, if you would.Does this all mean these estimates are off base?
Going off of this calculation in the module:
The Universal module comments at the refresh table:
Code:
; DRAM refresh cycle times assuming a 15.6µs refresh period <H25>
; (Refresh = (MHz * 15.6 ) - 27). Fractional parts are rounded DOWN <H25>
@djRefreshTable
@dj20Refresh dc.w 285 ; (20MHz * 15.6µs) - 27 <H25>
@dj25Refresh dc.w 363 ; (25MHz * 15.6µs) - 27 <H25>
@dj33Refresh dc.w 487 ; (33MHz * 15.6µs) - 27 <H25>
@dj40Refresh dc.w 597
I still think it's the number of clock cycles between refreshes. I assume there's a counter in the memory controller which takes that value, counts down 1 for each clock cycle and refreshes the DRAM when it hits 0.
However, I may have done the math wrong. I overlooked that 15.6uS figure. Try redoing my calculations using 15.6uS instead of 16.5uS.
There shouldn't be an integer offset (-27) involved unless....
They're offsetting each bank's refresh from the other banks by some number of clock cycles.
That's probably not it. You need a pretty intelligent memory controller looking ahead for that to be better than all at once.
So, I would guess that -27 is just a safety factor. They calculate the proper number of clock cycles between refreshes and then subtract 27 for margin. I have no idea why they would choose 27 though. I would expect a number sliding with the number of clock cycles to keep a constant time.
Unless it takes the memory controller 27 clock cycles to set up the refresh for some reason. That would make some sense.
However, I may have done the math wrong. I overlooked that 15.6uS figure. Try redoing my calculations using 15.6uS instead of 16.5uS.
There shouldn't be an integer offset (-27) involved unless....
They're offsetting each bank's refresh from the other banks by some number of clock cycles.
That's probably not it. You need a pretty intelligent memory controller looking ahead for that to be better than all at once.
So, I would guess that -27 is just a safety factor. They calculate the proper number of clock cycles between refreshes and then subtract 27 for margin. I have no idea why they would choose 27 though. I would expect a number sliding with the number of clock cycles to keep a constant time.
Unless it takes the memory controller 27 clock cycles to set up the refresh for some reason. That would make some sense.
Dug out a datasheet for that generation of DRAM. For detailed explanations, Micron's are really the best I've found.
The requirement is refresh every 64ms, but refresh only occurs 1 row at a time. For memory with 4096 Row addresses, that converts to .064/4096 = .000015625 = 15.625uS.
Most DRAM contains an internal ROW or RAS counter, so the memory controller just needs to send the refresh command every 15.6 uS and the DRAM does the rest.
Seems like it would get refreshed too often for smaller memory sizes that might have less than 12 rows.
The requirement is refresh every 64ms, but refresh only occurs 1 row at a time. For memory with 4096 Row addresses, that converts to .064/4096 = .000015625 = 15.625uS.
Most DRAM contains an internal ROW or RAS counter, so the memory controller just needs to send the refresh command every 15.6 uS and the DRAM does the rest.
Seems like it would get refreshed too often for smaller memory sizes that might have less than 12 rows.
Going off the register:
Alright I'll add back the 27 and it gets me there:
40,000,000/624=64102.564102564
1/64102.564102564=0.0000156 or 15.6μs
Alright I'll add back the 27 and it gets me there:
40,000,000/624=64102.564102564
1/64102.564102564=0.0000156 or 15.6μs
So is the question now: can the memory controller handle a refresh of 753 (780)?
Or
Is it a question of the DRAM being able to handle that refresh rate?
Or is it late, I'm tired, and I'm barking up the wrong tree when you've already told me "it's that tree over there?"
50*15.6 = 780 - 27 = 753
Or
Is it a question of the DRAM being able to handle that refresh rate?
Or is it late, I'm tired, and I'm barking up the wrong tree when you've already told me "it's that tree over there?"
50*15.6 = 780 - 27 = 753
I'll see if my brain is running on enough cylinders to attempt the math again 
Attaching OKI datasheet for convenience
Attaching OKI datasheet for convenience
I did the math based on your formulas (I think) using 15.6µs and have come up with the same refresh number (without the offset amount subtracted): 1/15.6 = ~64102.56 hz ; 50/64102.56 = ~0.000780 (780)
Even without the offset, it looks like we're within the same window of tolerance for the other overclocks
If if can handle a number larger than 511, it should be able to handle any number up to 1023.
I could be wildly wrong, but I envision a refresh counter in the memory controller being set at initialization time. The counter must have enough bits to count a large enough number to handle the countdown.
8 bits would give 0 - 255. 9 bits => 0 - 511, 10 bits => 0 - 1023.
If it definitely supports any number larger than 511, then it certainly (well almost) must support numbers up to 1023.
Gotcha. Well, if that's sorted, I suppose that it's a matter now of testing incrementally up (or down) to see where any failure points manifest.
Tangentially related, reading back through some old posts across what remains of the net: some sources indicate that the 840av's 48MHz limitation was the serial ports. The 840av (and 660av) use a different path for serial, as you mentioned, trag:
it's like with each successive Quadra/Centris iteration, they kept consolidating chips into new ICs—so the SCC IC is present in the Wombat, as well as Quadra 700, IIci, and I'm not sure how far back. I wonder where the SCC is getting its timing from… it's reasonable to expect the serial ports will become a limiting factor, unless there are other timings set/sent to the SCC depending on the system configuration.
Something interesting. Since I was running the Wombatris (IDK what I'm gonna call this) at the 'stock' frequency of the CPU, I decided to simply use the lower surface area heatsink (with a thermal pad(?) of sorts taken from a 486 I think):
At first I was putting my fan on it, just because it was already wired up. For the more recent round of testing, I opted to remove it and run MacBench 1, 4 and Norton SysInfo. All completely fine and stable.
When I shut down the computer I had a touch of the top-of-the-bottom of the heatsink and it was HOT. Didn't have my IR thermometer handy, but it 'felt' like somewhere around 50C. I mean, that's not 'high' like I would think about with my modern PC, but I wasn't expecting that. With the fan on it, it dropped considerably, to what felt like around body temp/barely detectable, so like ~32-36C
I'll definitely switch it to the higher-surface-area heatsink that I have when it comes time to test the overclock frequencies in addition to the fan. The fan mount in the photo above is actually meant to slot right in to these 'better' heatsinks.
At first I was putting my fan on it, just because it was already wired up. For the more recent round of testing, I opted to remove it and run MacBench 1, 4 and Norton SysInfo. All completely fine and stable.
When I shut down the computer I had a touch of the top-of-the-bottom of the heatsink and it was HOT. Didn't have my IR thermometer handy, but it 'felt' like somewhere around 50C. I mean, that's not 'high' like I would think about with my modern PC, but I wasn't expecting that. With the fan on it, it dropped considerably, to what felt like around body temp/barely detectable, so like ~32-36C
I'll definitely switch it to the higher-surface-area heatsink that I have when it comes time to test the overclock frequencies in addition to the fan. The fan mount in the photo above is actually meant to slot right in to these 'better' heatsinks.
Similar threads
