• 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

demik

Well-known member
Just throwing out a few stupid ideas around:

If the issue is the SCC, the good thing on the Wombat board is that it's a standalone SCC and not a combo chip like in earlier Macs. On my wombat boards, the chip is Z0853008VSC which should be the 8 MHz version.

So either the chip is clocked too high and do strange things, or it just respond too late and there is collisions on the bus. Can someone measure how fast the SCC chip is clocked ? You will need either a logic analyzer or an oscilloscope.

Two things to try: clock the SCC which a different clock source, or try a faster ones. They are still produced and go up to 16 Mhz: Z0853016VSC
Faster versions do have a lower bus latency.
Datasheet is here: http://www.zilog.com/docs/serial/ps0117.pdf, pinout is page 12

The pin to check is #23 (PCLK)
 

jessenator

Well-known member
Can someone measure how fast the SCC chip is clocked ?
Sadly my Fluke can't measure beyond mains voltage/amperage frequencies... but it is plausible to assume that, while not produced, the planned SpeedBump max of 40 MHz is what the divider is based upon? thinking a maximum baseline bus speed of 40 MHz then.

That would make the divisor a round 5, for setting the Zilog to its 8 MHz spec. a 44 MHz overclock would set the SCC to run at 8.8MHz, and a full 9 MHz at an overclock of 45MHz...

Originally, I thought it would be based on 33 MHz, as that was the max production speed of the Wombats. This yields a divisor of 4.16666... and when overclocked to 44 MHz the SCC would be 10.56 MHz, kind of a lot for the chip I would imagine.

And since it still runs stably on the Quadras at that speed, I would be more inclined to believe it was based indeed on 40 and not 33. I'd love to be corrected here, though :)
 

dougg3

Well-known member
Alright, this is what I got:
pin 13: 5V initially at boot and dropped down to 3.3V~2.5V (don't have a scope)
pin 46: same

Interesting...I feel like that would happen if you were accidentally looking at one of the address or data pins, because they would be constantly toggling between 0 and 1 so your multimeter would read somewhere around 2.5V as an average voltage. It's also possible I'm wrong and there's some kind of legit reason for what you're seeing. Just in case, here is a screenshot of my programmer board design, it shows each pin's number (I hope this screenshot doesn't screw up this forum page!). The red highlighted trace is 5V, and it goes through pins 1 and 46. You can also see pin 13 because it has the "13" in the middle of the hole. At a minimum, at least one of pins 1, 13, and 46 should be reading as 5V...

Programmer.png

One thought I had on removing solder from the filled mounting holes: My thought was to flux and add new solder to them, and wick and either use an iron/pencil and braided wick, or my desoldering vacuum pump.

Any opinions on which method would be better, less harmful? My biggest fear is borking the small traces. This is one area I haven't had much practice on (or really, scrap boards with this on it to practice.

Oh man, that's a tough question. I think adding some extra solder is a fantastic idea and will help you remove the old stuff no matter which method you choose. I've had pretty good luck with a vacuum desoldering gun, but they're expensive. I feel like wick will also work, but you'll definitely want to be careful not to heat it up too long or you'll lift the pad -- it would be better if you could practice on something else first. As for the hand pumps, I've always had a tough time using those personally.

I've never tried them on this type of problem, but one thing that might be useful is something called "desoldering needles" which you can find cheap on eBay (I linked to a random one that claims to ship from the US). There are some YouTube videos demonstrating them. They are hollow stainless steel tubes of various sizes with a plastic handle. They're usually meant for removing something that has already been soldered. Because the tubes are made of stainless steel, the solder won't stick to them. Basically the idea is you heat up the solder on one side until it's molten all the way through, then push the tube over a pin but through the hole on the other side, and then let the solder cool. The tube will keep the pin and the hole separated. In my kit, and in the one I linked, it appears that one of the "needles" is not hollow (the smaller red one) -- maybe it's meant for exactly this kind of application. It seems like if you heat the solder up on one side, and push the needle through on the other, you should end up with a cleared hole. Just a crazy idea anyway! I reserve the right to be wrong :)
 

jessenator

Well-known member
At a minimum, at least one of pins 1, 13, and 46 should be reading as 5V...
ha! well, I just took another read and I'm getting ~4.8–4.9V at pin 13 human error is the trickiest of them all, isn't it? :V

one thing that might be useful is something called "desoldering needles" which you can find cheap on eBay
Second time they've been recommended! I might do well to get a set.

I actually used my stimmy to patron Circuit Specialists earlier in the year, so I've got both hot air and a vacuum desoldering gun in the arsenal.

I'll see if I can't find a thrift shop that might have some junk boards. I suppose I could also try on the non-booting 4400 board I have... it had a battery leak and though I couldn't see broken traces, something else on there might have gone kaput. There are several groups of unused pin header pads(?) on it.
 

dougg3

Well-known member
ha! well, I just took another read and I'm getting ~4.8–4.9V at pin 13 human error is the trickiest of them all, isn't it? :V

Haha, nice! That’s a good sign, because it means pin 13 is a “true” 5V pin and thus my choice of it as the /WE pin on the programmable SIMM is safe. Whew! If you don’t mind checking, what about pins 1 and 46? If trag’s theory is correct, one of them should be 5V and the other should be approximately 0V.

Second time they've been recommended! I might do well to get a set.

Ahh, cool! I’ve only tried them once and they definitely worked for removing a soldered component.
 

trag

Well-known member
Your analysis makes sense to me! Another thing we could do is power the machine on and see if any of the “5V“ ROM SIMM socket pins are actually reading as low on the multimeter. That would probably narrow it down quickly without knowing the pinout of the on-board ROMs.
That's a great idea. Narrows down the hunting nicely.
 

trag

Well-known member
Alright, this is what I got:
pin 13: 5V initially at boot and dropped down to 3.3V~2.5V (don't have a scope)
pin 46: same

I wonder if that's what you would get if the pin(s) is(are) cycling between 0 and 5V

Could be that both pins provide the disable.

Later edit: Ah, saw the follow up message. Suggests it is pin 46.

If you check pin 1, you might as well check pin 63 as well.

Another route for this is with the machine powered off, check continuity (resistance) between pins 1, 13, 46 and 63).

Three of the pins should have effectively 0 ohms resistance because they all connect to the 5V supply. The fourth pin should have a fairly high resistance to the other three.

$1.61 beats the pants off KEL and their PDS connector part... yikes. Thanks for that!

That's for the 64 pin ROM SIMM socket, not for the 040 PDS socket.
 
Last edited:

jessenator

Well-known member
Do you have the above benchmarks, but only for CPU/FPU instead of the aggregate system benchmark?
Tested on the vanilla/native Quadra 650 in MacBench v1, same system setup and everything for each test. The MacClip doesn't have switch settings for 34-37, but your mind can fill in the gaps : P
691Ez6K.gif
 

jessenator

Well-known member
So my brain is toast this week... I was out most of Tuesday and barely had enough mental faculties to test and make that chart, and I'm struggling to bring it all back in. I suppose, with this amount of baseline information, knowing a little more about some board and component behavior:

Which path do we take next (with the OG Centris board)?
  • Replace the SCC with a faster revision?
  • Replace the on-board ROM with a new SIMM?*
    • If we're going that far, do we make a new item in the machine table for an UberWombat?
  • Replace the on-board RAM and see how far the overclock can go?
    • Does this option require replacing the PLL as well?
See, how batty I am? Those two struck-out options really won't do anything, seeing as how the old, native Centris board doesn't even have the provision to operate like a WomBatman. I suspect that my native Quadra board has at least something, since I'm not seeing errors (beyond SCC) at 45 Mhz. It seems that the only way forward with as old of a board as this is, will be to make a new ROM.

*I know bbraun hacked/patched the ROM on their Centris/Quadra to allow for larger RAM modules. And I know the ROMinator exist for II-series Macs, but does/will anyone produce a new ROM SIMM with the Universal ROM?
 

demik

Well-known member
*I know bbraun hacked/patched the ROM on their Centris/Quadra to allow for larger RAM modules. And I know the ROMinator exist for II-series Macs, but does/will anyone produce a new ROM SIMM with the Universal ROM?
I've used a SE/30 ROM module from GGLabs to repair a 840av (long story short: I had the board without the ROM). You just have to split the ROM into 4 parts to flash each module.
It should work on the 800 as well.
 

jessenator

Well-known member
You just have to split the ROM into 4 parts to flash each module.
Hmm. Well I do have (edit) that same ROM SIMM —but it appears BMOW is out of stock of the programmer. I suppose I could put out a trading post want ad for someone to flash it for me, assuming the Universal ROM will fit on the 2MB version of it... That latest version of the Quadra ROM you mention might be the best way to test it without doing any hacking...
 

cy384

Active member
So I had some caffeine today (bad idea), and ended up writing some scripts to mess with ROMs. Since this is probably going to be a bunch of related little bits of stuff, I've made a new github repo for it (see the rom-hacking folder for details). A proper disassembly would be cool, but for now we only need specific little edits, so this works.

The punchline: easy to edit the djMEMC config settings table and build it into a new ROM file. Attached is a first experimental ROM which will always use the 40MHz configuration values. It boots in BasiliskII, so it will probably work in a real machine? I've been thinking about how to design a nice flash ROM that doesn't need an external programmer...
 

Attachments

  • always-dj40.ROM.zip
    466.3 KB · Views: 1

trag

Well-known member
Hmm. Well I do have (edit) that same ROM SIMM —but it appears BMOW is out of stock of the programmer. I suppose I could put out a trading post want ad for someone to flash it for me, assuming the Universal ROM will fit on the 2MB version of it... That latest version of the Quadra ROM you mention might be the best way to test it without doing any hacking...

If you have the file you need flashed and the PLCC package Flash chips I can flash them for you. It's a bit of a round trip though, shipping the chips both ways. That's assuming that you meant you have the GGLabs module with the socketed chips.

I haven't used the software for the TL866II+, but I know that the software on my EMP-30 programmer will interleave the data in a file across chips. So you load a file you want to program, tell it to interleave across however many chips, and it automatically divides up the file and let's you program each chip separately. I imagine other programmers' software do this too.

You might want to look at just getting a TL866II+ of your own. The base unit is about $60. A nice package with about 20 sockets is about $130. But you really just need the base unit with a PLCC-32 socket, I think.

Without spending any time shopping-optimizing, I think this would do the trick: https://www.amazon.com/XGecu-TL866II-Programmer-Support-Adapters/dp/B0859YRVM3

Although if you're going to be programming a lot of PLCC-32 this socket would be a nice addition: https://www.ebay.com/itm/193379506260
 
Last edited:

trag

Well-known member
The punchline: easy to edit the djMEMC config settings table and build it into a new ROM file. Attached is a first experimental ROM which will always use the 40MHz configuration values. It boots in BasiliskII, so it will probably work in a real machine? I've been thinking about how to design a nice flash ROM that doesn't need an external programmer...
You're probably way ahead of me on this, but there's a checksum comparison in the boot process. Does building the new ROM create a new checksum and store it in the necessary place? Or have you disabled the checksum test?
 

cy384

Active member
Does building the new ROM create a new checksum and store it in the necessary place? Or have you disabled the checksum test?
yes, I wrote a little script to calculate and insert a new checksum. (I just also checked with a deliberately incorrect checksum, it looks like BasiliskII will boot anyway, so maybe that's not a good test)

Entirely disabling the checksum verification code is also doable, but I kinda like leaving it in.
 

jessenator

Well-known member
You might want to look at just getting a TL866II+ of your own.
Interestingly enough, I bought one today, but neglected to edit/amend my post :D Thanks for the offer to flash them, all the same. Once it's here, I'll definitely need to put my study hall hours in to learn how to use it properly.

I'll need to order that 64-pin socket and maybe those desoldering needles, too. I don't want to bork the board before I actually get started?


The punchline: easy to edit the djMEMC config settings table and build it into a new ROM file. Attached is a first experimental ROM which will always use the 40MHz configuration values
This is most excellent! I'll do my best to be patient while my programmer makes its way to me. I am very eager to test it out!

Also I know the one script is meant to de-generate, but my sleepy brain just sees "degenerate" as in "filthy degenerates" and it makes me laugh.

Woo. Study time.
 
Last edited:

cy384

Active member
brief note on something to look at: the video driver for these machines checks the CPU speed, see DAFBDriver.a and search wombatspeed

maybe there are other drivers that also check like this
 

trag

Well-known member
@jessenator I finally loaded the software and started using my TL866II+ and I even read the manual all the way through. Gasp.

Sadly, the Xgecu software does not include a feature to deinterleave a wide .bin file for programming on narrower chips. For example, you have a 32 bit wide ROM file for the Wombat and need it deinterleaved across 4 8-bit wide Flash chips.

You'll need to write some kind of program or script to do that yourself as a separate step.

It shouldn't be difficult, but it is another step.
 

jessenator

Well-known member
You'll need to write some kind of program or script to do that yourself as a separate step.
Gotcha.
You just have to split the ROM into 4 parts to flash each module.
Do you have a workflow/script already in place for that I might be able to use? I don't trust myself to actually write anything that would actually, y'know, work : P


the video driver for these machines checks the CPU speed, see DAFBDriver.a and search wombatspeed | maybe there are other drivers that also check like this
Good catch. Does this have any bearing? (I'm just looking for patterns, not on what the code is actually doing—it's indecipherable to me...)
Code:
;
; Because Wombat uses a different clock chip, the TimingAdj value for Spike/Eclipse/Zydeco
;    doesn�t work on Wombat.  However, the TimingAdj adjustment value is simple to compute
;    based on the pixel depth and the clock divider.  So, the table represents the value to
;    to add to TimingAdj per pixel depth per clock divider.  The zeros in the table are
;    unused place holders.
;
DAFBWombatTimingAdjTbl
                Dc.w    32,16,8,4,2,1                        ; PixClk/1
DAFBWombatTimingEntry
                Dc.w    16, 8,4,2,1,0                        ; PixClk/2
                Dc.w     8, 4,2,1,0,0                        ; PixClk/4
                
DAFBWombatTSize    Equ        DAFBWombatTimingEntry-DAFBWombatTimingAdjTbl

I took your advice and started poking around again. PrimaryInit.a also has a TimingAdj value at line 2717. I don't know what to make of it, but there it is.
 

cy384

Active member
I don't know what to make of it, but there it is.
that's basically what I thought when I saw it, I was randomly skimming the code for other reasons.

it may be a lead on things to mess with if the djmemc changes aren't enough to improve the overclock. I'll note, as an aside, that the nubus interface has its own clock, so maybe if the onboard video stops working at some speeds, a nubus card could still function?
 
Top