I don't understand why the -55 part would be considered a problem? That rating is the max in-spec speed rating of the 2Q_X clock line out of the chip, and I don't think that is the clock that's driving the CPU is it? I thought I saw in the datasheet that the 2Q_X clock is specifically not suitable for driving the clock of the 68040. I'd imagine that Q1, Q2, or Q3 are used to drive the CPU, and those are running at 44 and 45 Mhz in your case, which seems fine? Though anything running off the 2Q_X in your setup would probably have a very unstable clock.
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Wombat (650, 800) board overclocking limitations
- Thread starter jessenator
- Start date
jessenator
Well-known member
And here comes some MORE confusion to add to the heap!
I got the MacClip Jr from @cy384 today and did a few tests.
My converted-Centris-to-Quadra 650 (ID 36) won't even go to 43 MHz... At 43 I get a F line exception, but at least I get video. At 44 I get the same as I documented: no video at all.
Here's my results from Norton SysInfo benchmark:
I will repeat the tests with the Gestalt ID 51 tonight and see.
But back to your PLL, Mr Ksoft, yeah, that's some interesting stuff there... Well shoot
Now I really do want to test the on board RAM now. @trag I don't recall, sorry, but can I leave the in board banks empty (and use my higher speed modules)? Or do I need to solder on the chips you sent?
Unlike cy384's centris, mine has 80ns on-board, so that's hopefully the next place to start.
Interesting, and hopeful for my reel of -55 chips.
Some times chips are aggressively binned, and -55 doesn't perform above -55. Other times, they're selling, e.g., -55, -70 and -80 and they're all coming off the same wafer and all passing the tests for -80, but they sell some number of -55s so some of them get marked -55.
Impossible to know which is the case though, unless you worked at the fab, or have the wherewithal to characterize the chips.
Are you saying you've desoldered the on-board RAM?
I don't know if the machine will work without the on-board RAM or not. If the on-board banks are treated like the other banks by the ROM and the memory controller registers, then it should work. But the NuBus PowerMacs won't work without their built-in RAM, so something is up there.
If I misunderstood, then please explain and I'll try again...
Bolle
Well-known member
It is driving the CPU. The 040 needs two clock signals… one that’s running at the speed of the external CPU bus and another one twice the bus speed for internal operations.
jessenator
Well-known member
Oh nope, not yet anyway. I've still kept it stock aside from the input clock oscillator.
I wonder if that description file 'Universal.a' has anything... I'm not sure. I mean, we do know it will work with a single bank, as the lower tier Centris 650 only had the first bank populated for 4MB. But yeah, I suppose no banks is an unknown quantity for these.
I guess, unless there's some other avenue to try with my otherwise vanilla motherboard, I will test the new ram next. But please do correct me if there's something else I should try first.
Really? Thanks for the explanation. That makes the references in the datasheet about not using 2Q_X for the 68040 make even less sense to me.
So, I've always thought the "66 Mhz" and "80 Mhz" marketing claims on some 68040-based products to be complete bunk. Are the internals of the 040 actually clock-doubled from the bus speed?
jessenator
Well-known member
I didn't want to bust out the soldering gear tonight... I decided to ramp up from 40 MHz on the Vanilla Quadra 650 and see where I could get to.
This board has 70ns on-board RAM.
While I can boot and run Norton SysInfo benchmarking just fine, attempting to turn on AppleTalk hard froze the system (probably the conflict with serial, though my connection was via the SONIC / AAUI to ethernet transceiver). And if I enabled AppleTalk while running stably at 44 Mhz, it would freeze at boot (probably when AppleTalk / TCP/IP was loading).
Mr. Ksoft
Well-known member
After more extensive testing at 45mhz today, I found that it is not quite stable. Most stuff works fine, but I did find after more extensive playing around with MIDI over serial, that OMS would report serial overruns on more complex files. Since I do use MIDI a lot on that machine, it's kind of a deal breaker for me, so I've dropped back to 44mhz. There may have been other stability issues that I didn't find, not sure. Wondering if any difference would be made by modding the gestalt to the "speed bumped Quadra 800" one, but not really interested in doing the mod since my machine works fine. Not like I'm going to see much more of a speed increase going 1-2mhz higher... would benefit a lot more from a cache card...
jessenator
Well-known member
I'm starting to feel more and more like serial indeed is the limiting factor (as has been voiced before) *sigh*
My immediate thoughts are toward something like @cy384 has mentioned in their blog, about a custom ROM, somehow modifying the SCC's clock divider. I'm looking at the ROM source, but with ignorant eyes, it's just more pattern matching to see what I can find.
A second avenue, and much more involved is this (sadly, the updates from user italux were nuked. Last I recall, they had a prototype board that was being sent to an off-foum friend for validation).
68kmla.org
It's tangential, but related to a NeXT overclock for the Turbo Color slab, but as the Mac and NeXT machine innards are different, especially with respect to input and bus clocks, the page is only relevant in terms of CPU-to-PLL relations: as for other board components, it's not much use.
A third avenue, and much more involved (experiential), would be to create a hardware-derived interrupt/divider(?) for the SCC. As it was described to me: a device which would intercept the bus clock signal and transmit an acceptable signal to the serial controller and prevent it from sending an out-of-spec return speed, thus crashing the system(?) but that's for later, I think.
I feel a bit deflated by all of this—with more and more digging—that almost none of what I've speculated is by any means novel. The thought that the Gestalt ID tells the ROM to tell the djMEMC what to do was speculated almost three decades ago for one:
derived copied.
I can't seem to find the actual instructions for the serial port mod anymore. I swear that I found them at one point a few years ago, somewhere on the WaybackMachine, following some outdated links to pages later archived on AppleFool. The current incarnation of the modification pages simply says the method using a custom PAL the originator used was 'not meant for the faint-hearted.' And, well, quite. Maybe this is what the 'third avenue' is: something to set the multiplier?/divider? so it wouldn't crash. But then that lends more credence to the ROM modification—that there are instructions in ROM that can set those equations—and finding something in its capacious depths to altering it that way.
This. The SCC (and perhaps other components) just can't handle a bus speed of over 44 MHz. And as the current ROM is taking its timing from the PLL—and from what I understand it's not a matter of overloading the Zilog itself, but the actual serial ports' speed being read back as 'too fast' or just 'wrong,' this appears to be the upper register, barring modification of my Centris board with 60ns RAM, (which I'll do anyway), and then testing as a Quadra 800 SpeedBump, which I doubt has much in the way of headroom, but we'll reserve judgement for now.
My immediate thoughts are toward something like @cy384 has mentioned in their blog, about a custom ROM, somehow modifying the SCC's clock divider. I'm looking at the ROM source, but with ignorant eyes, it's just more pattern matching to see what I can find.
A second avenue, and much more involved is this (sadly, the updates from user italux were nuked. Last I recall, they had a prototype board that was being sent to an off-foum friend for validation).
Sonnet Quaddoubler project
Looking for a Quaddoubler at a decent price...now here is the caveat. I want to destroy it.......in the interest of reverse engineering one and then being able to get them at a decent price. Many cards have been reversed engineered in Amiga land and this would be a very beneficial one for...
68kmla.org
It's tangential, but related to a NeXT overclock for the Turbo Color slab, but as the Mac and NeXT machine innards are different, especially with respect to input and bus clocks, the page is only relevant in terms of CPU-to-PLL relations: as for other board components, it's not much use.
A third avenue, and much more involved (experiential), would be to create a hardware-derived interrupt/divider(?) for the SCC. As it was described to me: a device which would intercept the bus clock signal and transmit an acceptable signal to the serial controller and prevent it from sending an out-of-spec return speed, thus crashing the system(?) but that's for later, I think.
I feel a bit deflated by all of this—with more and more digging—that almost none of what I've speculated is by any means novel. The thought that the Gestalt ID tells the ROM to tell the djMEMC what to do was speculated almost three decades ago for one:
and what was mentioned by Marc Schrier, from whence the Gestalt ID table mentioned on page one was
I can't seem to find the actual instructions for the serial port mod anymore. I swear that I found them at one point a few years ago, somewhere on the WaybackMachine, following some outdated links to pages later archived on AppleFool. The current incarnation of the modification pages simply says the method using a custom PAL the originator used was 'not meant for the faint-hearted.' And, well, quite. Maybe this is what the 'third avenue' is: something to set the multiplier?/divider? so it wouldn't crash. But then that lends more credence to the ROM modification—that there are instructions in ROM that can set those equations—and finding something in its capacious depths to altering it that way.
Do you have the above benchmarks, but only for CPU/FPU instead of the aggregate system benchmark? I ask because I'm actually curious how the various systems in that list compare to each other in terms of performance without disk cache and/or SCSISD shaped performance benefits distorting the results. As it stands that Radius 81/110 machine looks pitiful in a way that it probably shouldn't 
jessenator
Well-known member
I did all my Quadra/Centris 650 tests with the same Quantum spinner on 7.5.3, same disk cache, as close as I could to same. I think the Q700 (not the sysinfo baseline), and maybe the 650/33/8.1 test was on the same setup. Might've been a blueSCSI...
I need to get Speedometer... I could easily do a run of MacBench 3 or 4 as well. In fact I think I kept a bench for the centris Gestalt...
I could do version 1 which may be 68k code only. I don't recall for sure.
I need to get Speedometer... I could easily do a run of MacBench 3 or 4 as well. In fact I think I kept a bench for the centris Gestalt...
I could do version 1 which may be 68k code only. I don't recall for sure.
Last edited:
cy384
Well-known member
So in reading the code and wondering how to get the other config settings going, here's another twist
* the changes in the source for speedbump are dated "9/26/93"
* there's some more changes dated "12/7/93"
* Centris 650 release date: February 10, 1993
* Quadra 650 release date: October 21, 1993
My machine (Centris 650) apparently has a ROM checksum of "F1A6F343"
There's some poor labeling online, but it looks like the Quadra 610 and 650 had another ROM, "F1ACAD13"
maybe the C650 ROM, or even the Q650 ROM, won't ever set the fastest config settings for the djmemc?
* the changes in the source for speedbump are dated "9/26/93"
* there's some more changes dated "12/7/93"
* Centris 650 release date: February 10, 1993
* Quadra 650 release date: October 21, 1993
My machine (Centris 650) apparently has a ROM checksum of "F1A6F343"
There's some poor labeling online, but it looks like the Quadra 610 and 650 had another ROM, "F1ACAD13"
maybe the C650 ROM, or even the Q650 ROM, won't ever set the fastest config settings for the djmemc?
jessenator
Well-known member
Sadly, no socket on the 650, and I'm fairly positive no on the 800. There are pins/pads for them, but are just filled with solder. Do we know the p/n for the socket? I don't even know if there's a jumper to enable the socketed ROM... has to be.
Yeah, there ought to be a jumper around there somewhere. We might be able to trace it out. We know what pin of the SIMM socket goes to the jumper. And we know the other end goes to the CE_ pins of the four ROM chips. There might be a resistor in the trace somewhere.
And when I say, "we know" I mean it is know which pin of the socket does that, but I don't remember. We can look it up or ask Doug. Or it might be in teh ROM pinout posted in the Wiki.
The socket is easy. I have over a hundred of them on hand. Theyre available from "The Connector People". There's a link in my thread about the X100 PDS socket.
I think it's possible that some of the newer systems don't need a jumper if you install the SIMM. For example, bbraun installed a socket onto a 650 and as far as I can tell, the ROM SIMM just magically worked. Now...whether or not there's some logic on the board that automatically disables the onboard ROMs, or the SIMM is simply overpowering the onboard ROMs, I'm not sure (I would hope it's the former and not the latter, but honestly I don't know...)
trag is right, the part number is Tyco 822021-2 and Connector People is where I bought mine.
trag is right, the part number is Tyco 822021-2 and Connector People is where I bought mine.
Right. I shouldn't post after 11PM.
The ROM SIMM automatically disables the on-board ROM when it is installed. The X100, X500 families have the same arrangement.
Chip Enable on ROM chips is Active Low. If you tie it High, the chips shut off.
On the IIci, IIRC, the jumper ties the on-board ROM CE_ Low. Remove the jumper, the on-board CE_s go high and the chips get out of the way of the SIMM. Of course, if you don't install a SIMM, then there's just no ROM available.
On later machines, Apple got really clever. The CE_ pins of the on-board ROM go to one pin in the ROM SIMM.
When there is no ROM SIMM installed, that one pin in the ROM SIMM Socket is unconnected and it does not affect the on-board ROMs, which, presumably are lightly tied low through a 4Kohm or similar resistor.
On the ROM SIMM, that one magic pin is tied to Vcc (5V). Install the ROM SIMM and now there is a connection from 5V to the magic pin, and back to the CE_ pins on the on-board ROM chips and they all stop working.
On the X100 and later machines, the magic pin is #116.
I don't know which pin it is in the 64 pin ROM, but looking at the pinout I bet it was 13 or 46.
Take an ohmmeter to 13 or 46 in the ROM SIMM socket pads, and I bet it has continuity with pin 10, 11 or 12 on the individual ROM chips. Although, there might be a current limiting resistor in teh circuit.
Not sure about 10, 11 or 12, because the ROMs on the 650 look like they're 40 pin PSOPs and I can't find a datasheet for that. 44 pin PSOP has CE at pin 12, but a ROM (as opposed to Flash) has no use for pins 1 and 44, so maybe CE drops back to pin 11, or, if they take out an address line (smaller capacity), maybe to pin 10.
I should check that on my 610. It would be useful to figure out which one it was, because I actually repurposed pin 13 to be the /WE pin on the programmable SIMM (the ROM-inator II is wired identically). The reason I chose it was because it was right next to the /CS and /OE pins. I’m guessing (hoping?) it’s not pin 13 for that reason. If it does end up being the actual pin that was used for disabling the onboard ROMs then the programmable SIMMs won’t disable them — and /WE won’t be held high either. Since it worked for bbraun I’ve always assumed the current design was okay…but I suppose that potentially goes back to our discussion in the other thread about behavior when /OE and /WE are both asserted simultaneously.
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.
jessenator
Well-known member
Brilliant. Sorry, I was wallowing so much, I neglected to process this (heh) correctly.
So if the ROM changes were made that much later, it makes sense that mine wouldn't have it: XC334U51CA2 decodes to late August 1993, hah! Might explain precisely why, like you said, your Centris can—and mine can't—get to 44 MHz. Also might be why mine has 80ns RAM and yours 70ns. Could just be availability during assembly.
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
$1.61 beats the pants off KEL and their PDS connector part... yikes. Thanks for that!
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.
Similar threads
