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.
Wombat (650, 800) board overclocking limitations
- Thread starter jessenator
- Start date
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
Well-known member
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
Well-known 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.
* 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.
cheesestraws
Well-known member
Yes, same, this is really interesting to follow along with from the audience
cy384
Well-known 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.
* 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
Well-known 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!
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:
jessenator
Well-known member
This is seriously some excellent work, cy384.
cheesestraws
Well-known member
Oh, very impressive.
cy384
Well-known 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.
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:
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.
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.
cy384
Well-known member
Ideally we don't want to wait longer than we have to, since that just makes all graphics slower. Anyway, it turns out that even with all the wait states I can turn on, it's still not waiting long enough, so there are eventually graphics glitches at 50MHz. Seems okay at 48Mhz, though!
I've been meaning to document my oscillator socket, so here's some pics that should make it fairly clear:
Here's the socket I started with (p/n 1107741-E but not really necessary, probably any similar socket will work) and some pins:
Add the extra pins and clip the ones on the ends:
Using some bits of wire, connect these pins:
Then solder it on top of the oscillator on the board:
View from the other side:
And with the oscillator:
Make sure you get the orientation correct!
I'll also stick these pics in my github repo for this project.
@cy384 Interesting that your photos show that your board still has a 88916DW55 installed. Do you think it would help to step up to a DW70 or DW80? I'm actually kind of hoping that the dW55 works just as well as the other two faster rated parts. Somewhere along the way I ended up with a reel of the DW55 part.
cy384
Well-known member
I've been trying to mess with the memory sizing code today and having a hard time of it! No real luck so far, but I've got a better handle on how it works.
I found a cool book at a local library; "Apple T-Shirts: A Yearbook of History at Apple Computer" which is a collection of internal development team tshirts. There's even a Wombat design! Unfortunately the images are tiny, but it's cool to see, maybe someday I'll clean it up and make an SVG or something.
I found a cool book at a local library; "Apple T-Shirts: A Yearbook of History at Apple Computer" which is a collection of internal development team tshirts. There's even a Wombat design! Unfortunately the images are tiny, but it's cool to see, maybe someday I'll clean it up and make an SVG or something.
MacKilRoy
Well-known member
This is a great thread, and incredible work!
There's a guy named Kay Koba who makes what he calls the 'Spicy Overclock' module, which has an adjustable oscillator for overclocking. I think his upper limit is just past 50Mhz on the adjustment, and it can step in 0.1Mhz increments. I've also seen mention of some 60ns VRAM being spotted in the wild. Those two things may help to bring you upto 50Mhz.
There's a guy named Kay Koba who makes what he calls the 'Spicy Overclock' module, which has an adjustable oscillator for overclocking. I think his upper limit is just past 50Mhz on the adjustment, and it can step in 0.1Mhz increments. I've also seen mention of some 60ns VRAM being spotted in the wild. Those two things may help to bring you upto 50Mhz.
jessenator
Well-known member
As soon as I can sort out *ahem* other things with my Centris board, one of those will be going in as well. As well as some other spicy things.
One thing to note—as far as I'm aware—without replacing the on-board memory (DRAM and VRAM), the 60ns memory modules won't run at that speed, making the exercise/expense of obtaining just the modules pointless. @trag is that correct? I know the IIsi had a unique situation where the the on-board and expanded DRAM had different allocations, but the dedicated-VRAM Macs are a different beast.
David Cook
Well-known member
Inspired by this thread, I just overclocked my Quadra 650 to 40 MHz.
1. I found it to be consistently slightly faster (1%) with stock ID 36 than resistor-modified ID 51. I assume memory is overclocked 36@40MHz vs 51@40MHz?
2. My Daystar 128K Quad Cache (aka FastCache Quadra) does not work in the overclocked configuration. The Daystar QuadControl v2.3 init hangs at startup. Unlike the IIci cache card, the Quad Cache card is not enabled until the software kicks in.
3. TattleTech 2.84 won't startup in System 7.5.5 when overclocked, but will in 8.1. Perhaps there is a gestalt or system bug in 7.5.5. Something to keep in mind if other programs have issues.
4. If the Quadra 800 is just a Quadra 650 with a vertical LED attacked, why does the Quadra 800 require 60 ns RAM but the Quadra 650 only needs 80 ns RAM? Is the stock Quadra 800 faster than a stock Quadra 650?
1. I found it to be consistently slightly faster (1%) with stock ID 36 than resistor-modified ID 51. I assume memory is overclocked 36@40MHz vs 51@40MHz?
2. My Daystar 128K Quad Cache (aka FastCache Quadra) does not work in the overclocked configuration. The Daystar QuadControl v2.3 init hangs at startup. Unlike the IIci cache card, the Quad Cache card is not enabled until the software kicks in.
3. TattleTech 2.84 won't startup in System 7.5.5 when overclocked, but will in 8.1. Perhaps there is a gestalt or system bug in 7.5.5. Something to keep in mind if other programs have issues.
4. If the Quadra 800 is just a Quadra 650 with a vertical LED attacked, why does the Quadra 800 require 60 ns RAM but the Quadra 650 only needs 80 ns RAM? Is the stock Quadra 800 faster than a stock Quadra 650?
jessenator
Well-known member
Cool! One day I'll come back to my Wombat ventures…one day.
1. That's interesting. I'd have to look back at the System 7.1 decompile files mentioned/referenced earlier in the thread to see what's happening. It was a planned gestalt. We know from the notes in the files there were planned 40 MHz "Frigidaire" (tower) and "Lego" (desktop) versions of the Wombat, but since they weren't produced officially, there may be non-final timings and other settings there. I'm not really qualified to elucidate there.
Maybe a closer look at the Norton SysInfo test scores could bring out some more info as to the ups and downs. There's definitely the problem of the vanilla 040 enabled not having those other gestalt IDs in it, but I couldn't say off the top of my head what those performance vectors could could be.
2. Sounds about right. I don't know where it is, but there should be an 040 cache thread with info, or Bolle might've chimed in earlier in the thread, but I believe the long and short is that the wait state config on the cache cards is definitely made to work with stock Quadras (not sure about the 840av, since it's a completely different beast), so 33 and below is likely the target.
3. Hm. I've actually never used the program on my Macs. I'm trying to recall what system version I was running when I ran TechTool Pro, but I'm sure as others test out software that we'll come across esoteric limitations to the overclock.
4. From a marketing perspective, it's to frame the 800 as a higher-end Quadra. In practice, it's due to the 800's on-board RAM being 60ns; I'd have to look, but I think one of mine is 60 and the other is 70 (one is a Centris, the other I never knew as it came to me bare), but again, it's been a few moons since I worked on them. What's odd is that 80ns seems to be uncommon. My Centris board has 70ns, so IDK. I have a vague recollection of someone saying it was one of the Centris (marketing) configs: lower end versions without AAUI, an LC040, and probably slower DRAM.
The clock speed isn't any different between a higher tier 650 and an 800. Both had 33MHz 040s and never sold any faster. Again, it might've just been marketing fluff: tower vs desktop
Similar threads
