[...] perhaps some installed 7447s have more stability at 2GHz than others, perhaps mine do not, others perhaps do.

Correct. The probable reason yours and @GaryN's didn't work, and the probable reason @Knezzen's worked, is a matter of what we call Silicon Lottery. There is something else called Processor Binning. I found one of the MacRumors PPC threads I go on and on about those, and the custom 7448 dual 2.0GHz upgrades. To understand processor binning, and why it matters, refer to this comment, and about silicon lottery (plus a lot else), check this comment instead.

In short, @Knezzen won the lottery! But all of you may acquire and try more 7447 processors with the highest binning, until you win that same lottery. From experience, I will say your chances are very good with very few tries. Also keep in mind there are 3 main different MDD coolers (go for copper if you can, else the pure aluminium one. The other one reportedly freezes MDDs during stress, according to House of Moth, whose links describing this I no longer have), and they matter and differ a lot, but if you can LCS it with a silver base, that would be best, but not at all needed. I would also recommend, again, going for 7448 processors (if you find them) with the highest binning, and getting those instead, because the Sonnet MDX daughtercard can be used without requiring an interposer board, unlike with the stock MDD daughtercards. The 7448s also run cooler.

Anyway, be happy that you guys even have access to an MDD, let alone MDX daughtercards! I couldn't find the latter even when in Germany for 2 whole years of stalking eBay and the like. If you can find an MDX card, you can find A TON of 7448s! I know I did. Keep looking!

I actually have one now running nicely,

the only parts i would like now are

the 1.42ghz processor or some other upgrade from 1.25ghz just because i can
and a vst to rtas wrapper for using those sweet vsts in pro tools

thanks for all your help tho dudes

Just as a note; mine is still running stable at 2ghz in my MDD. It’s what I have used ever since I did the overclock. No issues at all.

I think I need to cut down on the caffeine.

Never! Great write up, lauland!

"Jabbernaut for m68k new attempts"
https://system7today.com/forums/index.php?topic=3802.msg16829;topicseen#msg16829

I plan to add notes about all the mistakes I made in the first attempt, and how I, in many cases very haphazardly, solved them...at some point...

----

The main key was the fact that CodeWarrior, like pretty much all Mac compilers, has a feature that compilers on pretty much every other platform don't have: Recursive include file directories.

Open any project in CodeWarrior and go to the project settings and then "Access Paths".  Look at the directories and for each line you'll see a checkmark, a little folder kinda icon, what it is relative to ("Project", "Compiler", etc) and finally the actual path.

I had absolutely no idea that the little folder kinda icon was a button!  And what it does is toggle if that particular directory is searched recursively or not.  I've used CodeWarrior since it came out and I never knew that.  I'd never ever clicked on it.  I thought it was just saying "This is a folder" or "This folder exists", etc.

----

This very rarely has any effect...in fact, it only does when you have two include files with the same name...in different directories...and one (or both) of them is (are) in subdirectories inside that folder.  If you're coding right, you have unique filenames for each include file whenever humanly possible.

...but...it can happen...and it does happen with GUSI.  (Grand Unified Socket Interface...I think).  It is a package of functions for Macs that implements something closely resembling the standard Berkley Unix socket api...and other functions that are needed to do this.  This was extremely useful for porting software for the Mac.

The thing that had me pulling my hair out, and barking up many wrong trees, were two (or more?) files named "time.h".  Most Mac C libraries do NOT include a "sys" folder with, among other things, "sys/time.h".  Look in the source of a lot of software that originated on *nix and you'll see #include <sys/time.h>

Many Mac compilers DO have a time.h, they just don't put it in a subdirectory called "sys".

I was getting very strange compiler errors revolving around GUSI's sys/time.h and CodeWarrior's time.h...in fact, sys/time.h INCLUDES time.h!  So...cutting to the chase, if you use GUSI in a CodeWarrior project and you have that little "recursive include file directory" icon turned on for the GUSI headers, just about no matter what you do, you end up with a circular reference. 

Most well written headers have something like #ifndef MYNAME_H" "#define MYNAME_H", then their actual content, and finally an "#endif".  By doing this, they ensure their content is only included once, regardless of how many times they are included.

So...with the "recursive include file directory" trick, if you have something like that, you'll see it saying it can't find definitions...if the header DOESN'T have the "#ifndef MYNAME_H", you instead get warnings/errors that things are being redefined.  Either way, if you don't know that somehow something like sys/foo.h, if it has #include <foo.h> in it, ends up including ITSELF, you will go crazy like I did.

----

The other key, and less irritating, is that CodeWarrior will ignore the path files had when you added them to a project the first time...and find them AGAIN, going just by the name (ignoring the path), every time you make changes to the "Access Paths".  So if you carefully dragged "time.h" from the GUSI folder to the project...then removed the GUSI folder from your "Access Paths" (or reordered things), the "time.h" you see in the project will be SOME OTHER file with that name...the first one CodeWarrior can find looking through all the directories...blah blah blah blah.  You can imagine how this bit me, before I saw it doing it, and my carefully constructed project file contents changing before my eyes...

With Jabbernaut, this was happening because the "Zoop" folder contained several different versions of the MacZoop framework.  They were all there because it wasn't clear which one was needed for which Jabbernaut project file.  So, when trying to build it, you could end up having a source file that is part of one version of Zoop including a Zoop header from a different version, etc etc.  Until I figured out that the only Jabbernaut build that actually worked used Zoop 2.5, and removed all the other versions and optional add ons from the "Zoop" folder, things were very confusing.

----

I will spare you how I FINALLY completely accidentally figured those out, because, as you can plainly see, I am EXTREMELY VERBOSE. 

I planned on posting the above explanation to system7today, but am trying to pace myself because I know, when I am in the right mood, I can end up completely dominating conversations, and driving everyone slightly(?) crazy.  And the last thing I want is to make system7today (or anywhere else) into a "laulandtoday" ego echo chamber.

I probably shouldn't speak unless spoken to...eh?

I'm going to shut up now!