• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Wombat (650, 800) board overclocking limitations

jessenator

Well-known member
There could be registers in the chip set by the ROM (or machine ID) which affect memory timing.

It could run off the system clock. It could have other clock inputs. It could internally generate clocks, although that last one is less likely.

It would be fairly straight-forward, though tedious to identify the oscillators on the board and see if MEMC IC takes input from any of them besides the system clock.
Jeez... You had right all along :D

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!
 

cy384

Active member
Only one way to find out, I suppose
Z4ZocbM.gif
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 interested

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)
 

Nathan_A

Well-known member
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 interested

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.
 

jessenator

Well-known member
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 got impatient excited and wanted to test the WombatLegSpeedBump [Gestalt ID 51 + 20 Mhz oscillator + 40Mhz CPU] tonight...

config table[...]
Code:
@bump40Config    dc.w    %0000001011111100
wombat-hax               -----001011110100

refresh table[!]
Code:
@dj40Refresh    dc.w    597    [0000001001010101]
wobat-hax                      [----001001010101]

ENHHZXtl.jpg
e4d5Dmyl.jpg
v36auzYl.jpg
WZ175qUl.jpg


I think we're in business 🤩 We're running the correct DRAM refresh register!
 

trag

Well-known member
I mean, we know that 650s and 800s both can do 660 (what the heck is that number to be measured in anyway, Hz? KHz?), but now we're moving beyond. I mean, an 840av can go to 48Mhz clock / 722 refresh it seems...

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.
 

jessenator

Well-known member
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.
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?
vsrnWkQ.png


Going off of this calculation in the module:
(Refresh = (MHz * 15.6 ) - 27)
The Universal module comments at the refresh table:
DRAM refresh cycle times assuming a 15.6µs refresh period
 

jessenator

Well-known member
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
 

CC_333

Well-known member
I'll be following these developments with much interest :)

I think I have a Centris 650 which (I hope) is in fairly good condition that I could perhaps try this on one day.

c
 

trag

Well-known member
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.
 

trag

Well-known member
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.
 

jessenator

Well-known member
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
 

jessenator

Well-known member
I'll see if my brain is running on enough cylinders to attempt the math again 🤣

Attaching OKI datasheet for convenience
 

Attachments

  • M514400D-OKI.pdf
    521.6 KB · Views: 0

jessenator

Well-known member
50*15.6 = 780 - 27 = 753
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
1628271143323.png
 

trag

Well-known member
So is the question now: can the memory controller handle a refresh of 753 (780)?

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.
 

jessenator

Well-known member
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:
…updates for the Q840 and 660. That's when they added the CURIO chip which has ethernet, serial and SCSI on one chip.

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.
 

jessenator

Well-known member
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):
XqEJkS5l.jpg

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.

l8R9G31.gif
Y1MuAmf.gif
c5Fbc1q.gif


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.
 
Top