Wombat (650, 800) board overclocking limitations

[trag]

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]

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]

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]

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.

 

[cheesestraws]

Yes, same, this is really interesting to follow along with from the audience

 

[Bolle]

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]

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]

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!

 

[jessenator]

I can now boot at 50MHz with no video issues!

This is seriously some excellent work, cy384.

 

[cheesestraws]

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!

Oh, very impressive.

 

[cy384]

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.

 

[trag]

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.

 

[cy384]

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

 

[trag]

@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]

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.

 

[Fizzbinn]

That sounds like an awesome book!

 

[MacKilRoy]

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.

 

[jessenator]

'Spicy Overclock' module

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.

I've also seen mention of some 60ns VRAM being spotted in the wild.

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.