On Tue, 16 Oct 2018 18:21:36 -0400, you wrote:
Tektronix seemed to have a habit, in those days, of trying to
be entirely "home grown". Think about it: They built their
own CRT's. They built their own hybrids. They built their
own knobs/chassis/trim/enclosures. They etched their own
boards, painted their own cabinets... They printed their own
manuals, and front panels. They invented everything they could.
Well, I think they also taught themselves how to program.
That could be good..... that could be EEEEVILLLLLLL.......
(it's a quote from a movie..)
Everything I have used where tektronix programmed the firmware
is buggy and awkward in some way or another, but works pretty
well over all. And, when you look at the code, it is a spaghetti
nightmare of unorthodox methods.
I'm finding that out.
It is truly amazing how much they did, and how well they did
using that frontier attitude. Rather than looking for an
outside expert, they simply said "I can do that!" And, rightly
or wrongly, they did.
Sometimes, wrongly. Seriously, would a bit of organization be too
much to ask?
In very many ways, they were a lot like me.
You are one person, you can learn, organizations learn very slowly, if
What I write as code now, and what I wrote, say, 20 years ago, are
very different things. It's a matter of both state of the art and
learning on my part, both what to do, and what NOT to do.
Not sure how much Tektronix (corporation) learned of each. Individual
programmers, yes. How much that influenced anything? No way to know.
Going from assembly to C (any structured language), and then to C++
(any object oriented language here). It makes a difference when you
learn how to use them.
Not to say that THIS is a completed process, either.
Also not to say that even if you know C++ (structured, object oriented
language), you're going to write good code.
Harvey White wrote:
On Tue, 16 Oct 2018 13:03:56 -0400, you wrote:
I think that they did the same thing on the DM5010, but that's a
guess. The software disassembly (so far) seems to be very
unorganized. That implies far more than one person working on the
project. I'll further bet that there were multiple instances of
"revisions" done by the "patch it" algorithm.
Makes me wonder how much of that software in similar equipment was
done the same way.
Two further points I would like to make:
1) Maxim, you made the same mistake many bright guys have
also made when trying to do a job aimed at wage drones.
You out thought the instructions, instead of following
2) I truly hope that after you finish your calibration you
will return to analyzing the ROM code. It would be very
useful to have a reverse engineered annotated assembly
code listing of the ROM. You may not be the one that fixes
some of the problems in this beast, but your notes may
encourage someone else to try.
I, for one, think a debugged 2465A/B that runs as smoothly as
the original 2465 would be a rare and precious treat to use.
I believe the 2465 family was developed by a "tiger team" of
engineers and programmers. When they finished, and the 2465
was selling smartly, they took their accolades and went on to
management, and to other scopes.
When marketing decided the 2465 needed some more bells and
whistles to remain current and marketable, the tigers weren't
available as a team anymore, so one or two of the former tigers
managed a team of new kids, and let them play.
It's purely conjecture on my part, but I think it is close
to the truth.