• 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

trag

Well-known member
dit: If I add any more SIMMs (tested with 32MB and 128MB, all I have at hand) it fails to boot and gives the sad chimes.

IIRC, bbraun also had a ROM modification to increase the upper memory limit so that it could use the full 520 MB possible. It may have had an issue where 264 was usuable by the system and the rest was available as a RAM disk. I can't remember that far back. There was a nice thread on his work regarding RAM in the Quadras about 10 years ago or so.
 

cy384

Active member
IIRC, bbraun also had a ROM modification to increase the upper memory limit so that it could use the full 520 MB possible. It may have had an issue where 264 was usuable by the system and the rest was available as a RAM disk. I can't remember that far back. There was a nice thread on his work regarding RAM in the Quadras about 10 years ago or so.
yeah, I've been looking at his page here and forum thread here. It's very interesting to see it failing like this, I wonder if it's because something has some hard-coded memory location on the assumption that no 68k Mac will ever have more than 256-ish MB. Or if it's just a failure in the memory sizing code because this one line change isn't completely correct. I don't think anyone else has gotten farther along.
 

cy384

Active member
So I managed to boot with a large RAM disk with 3x128MB plus the 8MB onboard. The memory extension/control panel crashes with a bus error, so the procedure here is kinda funky, I want to note it for the future:

* boot with 2x128MB and set the RAM disk to as large as possible
* shut down, add the additional 128MB
* boot with extensions off
* you'll get a popup asking to initialize or eject the RAM disk, neither work
* do a apple-option-escape to force quit Finder, it will restart the Finder and not bother you about the RAM disk

when I do this, I see that the memory configuration isn't using contiguous banks (here are the starting offsets for each bank):

* bank0: 0 (onboard)
* bank1: 4 (onboard)
* bank2: 8 (first half of first 128MB)
* bank3: 72 (second half of first 128MB)
* bank4: 136 (first half of second 128MB)
* bank5: 200 (second half of second 128MB)
* bank6: 264 (first half of third 128MB)
* bank7: 328 (skipped)
* bank8: 328 (second half of third 128MB)
* bank9: 392 (unused)

I think this would explain why I can't get it to boot with a fourth 128MB added. I want to extend wombat-hax-tool to show more information about some RAM and PRAM stuff.
 

trag

Well-known member
I don't have anything to add, but don't want you to think you're playing to an empty house. This is great work. I'm enjoying reading about it.
 

Bolle

Well-known member
While we’re at it, I’ll join the crowd of interested bystanders.
Really interesting stuff going on here. I am curious what other hardware settings might be there in ROM waiting to get messed with.
 

cy384

Active member
thanks for the support guys, it's appreciated. I had a little time to experiment today:

* under heavy CPU usage (raytracing for a long time), I think 46MHz is the max without locking up or crashing (48 and 50 are not very stable under load)
* I've been experimenting with Ghidra to disassemble parts of the ROM, it's a decent tool, but still requires lots of manual work
* hardware casualties: one of the pins on my oscillator socket was slightly loose, causing intermittent failure to boot (resoldered it), and the internal SCSI cable has become flaky (ordered a new one)

I think I've found the locations in the ROM where the VRAM timing is set, which I hope will fix the graphics glitches at 48+ MHz (going to replace "dafb33MHzConfigW" with "dafb40MHzConfigW", or even "dafbWaitConfig" which may be good for max speed). There's also the "DAFBWombatTimingAdjTbl" code, but I don't know what I'd want to do with that. Weirdly, the VRAM speed init code seems to be duplicated into four locations in the ROM, I wonder why?

Going to make a new ROM with these changes when I have some time this week.
 

cy384

Active member
I spent some time digging into the ROM to nail down the locations where the VRAM wait states are configured, and made a new ROM image. I can now boot at 50MHz with no video issues! I had some failures to boot at 48MHz (it would start loading the OS then stop making progress) but I need to mess with it some more to see if that was an ongoing thing or just a transient issue.

I would like to experiment more with exactly which value I set the wait states to, the declared values in the code are:

* 0x0200 for 33mhz
* 0x0A00 for 40mhz
* 0x0F00 for "turning on ALL wait-states"

For ideal performance, I think we want the fewest wait states.

Right now I'm running some CPU stress tests to confirm stability. Maybe I need some faster oscillators, why stop at 50MHz!
 
Last edited:

cy384

Active member
Aw, I spoke too soon, after an hour of hard CPU use, I start getting artifacts again (some random-ish orange-ish pixels). A big improvement, but this may be the real limit.

Edit: so I think we're basically tapped out on overclocking. From here I plan to work on the RAM detection, ideally writing a little code so it automatically detects small vs. large and can properly configure 4x128MB.
 
Last edited:

trag

Well-known member
For ideal performance, I think we want the fewest wait states.

I'm not certain how you intended that statement, so I may be stating stuff you already know. But to get faster performance out of the system as a whole, without causing video glitches, wouldn't you want more wait states for the video RAM?

Presumably, there's a fixed number of nanoseconds the VRAM needs to respond. As the clock speed goes up, the length of a clock cycle goes down. So to match a fixed period, like RAM access, as the clock speed goes up, number of wait states need to go up so that the product of clock period and wait states remains a constant.

ideally writing a little code so it automatically detects small vs. large and can properly configure 4x128MB.

That would be so cool. It's probably inherent in supporting 128MB, but remember, there are 64MB single banked SIMMs with the same issue.

The general case would be to check whether 12 X 12 memory chips are being used and enable support if they are.

BTW, amazing results on the 50MHz peformance, if only for several hours. Still very cool.
 
Top