Just to tell you quickly how we’re doing; these aren’t instructions. We’ll provide pictures and clear instructions in a subsequent piece when we’re finished.
- We pulled out the Duron and the motherboard. As I said earlier on the website, the Duron’s L1 bridges were all smudged up, and looking at it normally, I feared that
one or more of the contact point had been obliterated but a look under Joe’s magnifying glass showed otherwise.
- We then began implementing what we saw in the July 19th Anandtech article. We were aware that the other folks had done quite a bit more, and we weren’t entirely clear why the July 19th article seemed much simpler than the others, but we decided to take that route first.
- Cutting the traces on the motherboard was no big deal. The last of the four was a little tougher, but nothing too bad.
- Soldering wires onto the motherboard was a bit tedious, and it probably would be best to have two people to do this; one to hold the wire while the
other did the momentary solder. Other than that, unless you cannot find anybody with a steady hand and a little soldering experience to do this, this is no major project fraught with terrible risks.
- Soldering wires to the DIP switches was even easier.
- What we both found the most harrowing was what we thought would be the easiest part: connecting the dots. We were using a micro-tip conductive pen.
Well, that microtip looked about as delicate as a sledgehammer for this operation. We were putting a tiny little glob on the head of the tip, but that glob looked like a boulder in comparison to what we were covering.
This is irritating, not dangerous or risky or permanent. It’s easy to wipe away mistakes.
- All in all, moving very slowly and carefully (with quite a bit of picture taking) about an hour. It’s not something you’d want to go into mass production
with, but not too bad for one board.
- Then the fun started.
- The machine would not boot on many settings. Eventually, we found a few that would, but only at 600Mhz.
- We thought perhaps the multiplier were locked and had fun with the conductive pen, but that didn’t help.
- I went back and very, very closely read the Anandtech article, along with the tweakers.net and Hironji articles. What you need to do is do everything in
the July 12th AND July 19th article, plus rely on either of the other articles for a few details. We had just done what was in the July 19th article. All blame for that rests solely on my shoulders; I fluffed through the usual fluff and didn’t catch the indirect references
to the earlier project. (More on this later.)
- So we have to solder on some wires to make jumpers. Joe will do that shortly if he hasn’t already.
- We have a rather odd settings problem (maybe). The order of the Override jumpers as described in the Anandtech article is 2,1,4,3. The order on our production AZ11 is 1,2,3,4. Makes a big difference getting this to work, but we know how to handle that.
- In all honesty, unless cost or the challenge of doing this is a huge factor, we don’t see the point of going through this when you can just buy an A7V or KT7.
It’s nowhere near as bad or dangerous as you might otherwise think (once you get clear instructions). I will have no qualms about doing something along
these lines in the future should it become necessary, even by myself. However, if you can just buy a package shortly that will do it for you, it’s really not worth the bother, but due to the time and inconvenience, not because it is dangerous or risky.
This Is Not Creative Writing Class
Writing detailed, idiot-proof instruction is tough. Technical writing is never easy. You have to be concise, exact, supply all the necessary details, and cover all the contingencies and questions that might be asked. If you don’t do it, though, people can’t follow it easily. At best, vague and unclear instructions waste time. At worst, people get stranded.
None of the pieces describing these operations contained particularly good instructions. The Japanese and Dutch instructions can be at least partially excused due to the language difficulty, but we found ourselves going to the other websites to get important details that were missing from the Anandtech article. That’s poor work.
Technical writing is not a literary exercise. If you buy a VCR, do you want to know about the author’s quest to get the proper information? Do you want to know how he felt about it? No!! You want to get the VCR to work.
The task here is to get this to work, not rewrite the Odyssey. I find it so ironic that many of the pieces I get from you are much better pieces of technical writing than what you find from the website writers. Even most of the “badly written” pieces are fine with some trivial editing for phrasing and spelling. Do you know why? You know what good instructions do, and you follow it. You may talk about your experience, but you keep that
separate from the “how-to.”
That’s all I ask from these pieces. If you must describe your quest (even though most readers couldn’t care less about it), at least clearly separate or distinguish the “How-To” from your quest for self-expression, and include all the necessary details. To do otherwise is sloppy and lazy, and inconveniences those who have to follow it.
I’m not writing this to smack people. We started this in good faith expecting the instructions to get the job done, and they didn’t, which caused a decent amount of inconvenience and stress. It’s never fun doing these kinds of these, and wondering if we had caused permanent damage. If we had problems following this, we’d bet a lot of you would, too. We just want people to take a little more time and care writing these kinds of instructions to spare the people trying to follow them a lot of grief.
Complaining is easy; doing something about it is something else. When we finish this, we’ll write what we think will be a proper “How-To” for doing this. When we’re done, you judge which you would rather follow.