开云体育

On Tue, Oct 16, 2018 at 06:37 PM, Raymond Domp Frank wrote:

I'm just dropping and would like to comment as follows

Oops!
This sentence should read:

I'm just dropping *in* and would like to comment as follows

Raymond

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
the instructions.

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.

-Chuck Harris

Raymond Domp Frank wrote:

On Tue, Oct 16, 2018 at 07:03 PM, Chuck Harris wrote:

Two further points I would like to make:

Maxim,
A few times during your conversations, I was on the verge of suggesting to brainlessly follow the calibration instructions, no interpretation allowed and just doing it again from the start of the Calibration chapter until either everything was ok or it wasn't but you were sure you followed the instructions strictly and completely. I thought it too early for you to dive in and understand/map what was happening. It is more difficult to understand convoluted designs than sound, logical and straightforward ones and it doesn't take much to recognize that the 24X5A/B's firmware design has a bit of spaghetti in it.

Many of us have fallen into the trap that Chuck and I mentioned.

A few days ago, I called you an optimist for intending to reverse engineer the software but you've made great strides and I fully concur with Chuck that it would be great if you found the time and motivation to take things further - after getting through that little calibration job.

Raymond

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.

Not heartening....

Harvey

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
the instructions.

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.

-Chuck Harris

Gentlemen,

I've managed to pass CAL02 like a sharm! Yesterday I've replaced U2420 and had no time to continue. Today I've checked the alignment following Chuck's recommendation. The scope was aligned. But when I went and checked the DAC settings, I could see that they are well calibrated for the whole swing of 2.500V, but now on top they are CENTERED! Perfectly centered. From -1.2501V to +1.2500V!! And before the 1st and after 11th vertical line there is a very little space where I can slide the time marker.

On the calibration signal side, TEK is 1MOhm (not 50 Ohm) terminated and what is required and displayed on the sceen must be output as the HIGH level of the square wave. Zero must be set as the low level of the square wave.

So, the problem was in the marginal performance of the TL084 quad opamp!

Tomorrow I'll try running CAL03, but IMHO it will go w/o any problem,

Thank you very much for all the support and help!

Best regards,

Maxim

On Tue, Oct 16, 2018 at 10:55 AM, Raymond Domp Frank wrote:

A few days ago, I called you an optimist for intending to reverse engineer the
software but you've made great strides and I fully concur with Chuck that it
would be great if you found the time and motivation to take things further -
after getting through that little calibration job.

Chuck & Raymond,

Honestly I haven't planned to get so much involved into the scope repair and calibration "adventure". Hoped that it would be fast and easy. But turned out to be different. Tomorrow, I'll upload the first 32K of the ROM disassemble version -04. This ROM can be disassembled in 4 chunks 32K each. It would be interesting to understand how the work area is stiched in the presence of the ROM options.
I can't commit in continuing working on this project, but at least my little contribution could be used by someone as the stepping stone, like Chuck mentioned. Also wanted to thank you guys for the great help and a very interesting technical discussion. I'll calibrate my scope first and then have a look at 7D20, which also requires some attention, however 7D20 is more of an artifact, IMHO.

Thank you again,

All the Best,

Maxim

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.

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.

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.

In very many ways, they were a lot like me.

-Chuck Harris

Harvey White wrote:

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
at all.

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.

at all...

Harvey

-Chuck Harris

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.

Not heartening....

Harvey

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
the instructions.

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.

-Chuck Harris

There is nothing wrong in coding in ASM or mixing the ASM and C. Sometimes the code structure is well defined and you see immediately that everyone using the same calling conventiones between the routines (how registers and work area is used). I prefer this to "hacking the code together" method. IMHO one of the big differences in HP of 80s (I've looked inside of quiate a few HP ROMs) and Tek (my second experience after 7D20) is that HP used the power of their computer division, IMHO.
Therefore in case of HP the platforms were heavy, but easily scalable thanks to the OS9 derived thing embedded almost in every HP product. It brought the common code architecture, APIs, notion of "applications" or pluged-in software and also a very decent multitasking with storage and networking. However, on the user end it was a disaster (I have a few HP boxes on my table from the first DSO series in 80s without any single dial and unified panel accross whole line of products for LAs, oscilloscopes, generators, spectrum analyzers). I admire the HP intergrated basic, HPIB and many other bells and whistels but to use it effectively one needs to type on it like on the typewriter ;)
However, Tek designed their products to be handy, easy and comfortable to use. As a user, I've found that the using Tek products of 80s was intuitiive. But now also it looks like for every platform it was a gigantic effort to bring the GPIB connectivity and the control interface unification (to be on par with HP). And they hit the OS imposed limitations hard when they have switched to WIntel platform later on. (HP was toying with HP-UX & PA-RISC in their flagship products quite successfully until they were swallowed by the WinXP wave with the same UI problems).

Also it seems that TEK system guys were picking each time a different CPU and platform according to the resources needed(from Motorola as one of their primary design partners).

It would be good to hear from someone who was coding the boxes @TEK about how the things were. However, the absence of the C compilers didn't stop the Tek to have so many different product lines. Also in embedded world of 80s using Prolog, Pascal, Modula, LISP to code the emedded applications was done routinely.

When you look at the code generated for 680x types of processors even the bad compiler does the good job. The answer is in the minimalistic register count and almost no register recycling (to avoid load-storing the working registers from/to the memory). The counter example - I8080/8085/Z80 where the large register file and not very orthogonal instruction set required a hand coding (or ASM coder would always have an upper hand against any C compiler).

When first time I opened my 2445a, I hoped very much to see 6809 but someone decided putting 6802 instead.... IMHO, taking more expensive 6809 would help Tek to increase the code density use more elegant bank switching mechanism and avoid repeating the same routines over and over.

Digital computers were being programmed before Tektronix even
was founded. And, for more than 40 years before tektronix did much
with them. Their early computer endeavors used late manufacture
minicomputers... The PDP-11, for example, in the P<something> that
was the precursor to the 7854 DSO.

The knowledge was already there, multitasking realtime operating
systems were already there, "C" was already there. The discipline
known as software engineering was already well established.

They were even late to the party with microprocessors. What did they
do with 8008's?

The advent of the microprocessor was a late comer to the field of
computing.

-Chuck Harris

Tom Miller wrote:

Gentlemen,

I've got 2445a successfully calibrated today! It works fine. In a summary the scope can be calibrated in sessions as Chuck has explained. This is exactly how I did it. One after another calibration routine. And at the and no FAIL 04 any more! It all works.

As promised, I've put the listing inhere:
/g/TekScopes/files/2445a%20FW%20listings%20ROMs/2445a_lo32K.lst

It represents the first 32K of the low 64K EEPROM (there are 4 parts in total). It's more interesting since it has all the facilities, the work area initializer and the messages for the on screen display.
Also the free ROM space is filled by the SW interrupt code. I.e. in the case of the wrong jumping SW interrupt will be generated. But SW vector is the same as the RESET. I.e. Tek guys this way tried to debug the FW and see whether it will reset occasionally.

Special thanks to Chuck, Raymond, Siggi, Harvey, Mark, Craig!

P.S As a side reading found an interesting HP journal issue from 1987 explaining about how they have built their boxes:
www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1987-04.pdf
Article starts on the page 12. They say about the UI concept similar to LA box, which is a totally different product. The memory layout and system/SW/FW architecture is covered. Though it could be interesting....

On Wed, Oct 17, 2018 at 10:05 PM, <maxim.vlasov@...> wrote:

P.S As a side reading found an interesting HP journal issue from 1987
explaining about how they have built their boxes:
www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1987-04.pdf
Article starts on the page 12. They say about the UI concept similar to LA
box, which is a totally different product. The memory layout and system/SW/FW
architecture is covered. Though it could be interesting....

Also, don't miss the very relevant article on software reliability starting at page 35...

Raymond

On Wed, 17 Oct 2018 at 16:05 <maxim.vlasov@...> wrote:

I've got 2445a successfully calibrated today! It works fine. In a summary
the scope can be calibrated in sessions as Chuck has explained. This is
exactly how I did it. One after another calibration routine. And at the and
no FAIL 04 any more! It all works.

Awesome, congratulations!
This has been one of the more epic repair threads I've seen here recently,
it was fun to see some of the firmware disassembled. Super-fun to see the
firmware matched my calculation to within 2/4096.
Did you measure the +1.36/-1.24V references after your repair (and DAC
re-calibration)? I'd be most interested to know what the final values of
those reference voltages were against the centered +1.25/-1.24 DLY REF
output.
Apparently 0.5% from the calculated value is too far out, but the -1.25V
value on the schematics is still 0.25% out - the truth is out there!

I'm sure your 244A will give you decades of faithful service from here. My
2467 is my go-to for general spelunking because it operates like it's part
of my anatomy. The digital scopes only come out at need.

On 17/10/18 02:24, maxim.vlasov@... wrote:

It would be good to hear from someone who was coding the boxes @TEK about how the things were. However, the absence of the C compilers didn't stop the Tek to have so many different product lines. Also in embedded world of 80s using Prolog, Pascal, Modula, LISP to code the emedded applications was done routinely.

And more... Both Tek and HP used Smalltalk embedded in test instruments. Plus Tek also produced Smalltalk workstations.

On Wed, 17 Oct 2018 13:05:05 -0700, you wrote:

Gentlemen,

I've got 2445a successfully calibrated today! It works fine. In a summary the scope can be calibrated in sessions as Chuck has explained. This is exactly how I did it. One after another calibration routine. And at the and no FAIL 04 any more! It all works.

Congradulations.

As promised, I've put the listing inhere:
/g/TekScopes/files/2445a%20FW%20listings%20ROMs/2445a_lo32K.lst

It represents the first 32K of the low 64K EEPROM (there are 4 parts in total). It's more interesting since it has all the facilities, the work area initializer and the messages for the on screen display.
Also the free ROM space is filled by the SW interrupt code. I.e. in the case of the wrong jumping SW interrupt will be generated. But SW vector is the same as the RESET. I.e. Tek guys this way tried to debug the FW and see whether it will reset occasionally.

Special thanks to Chuck, Raymond, Siggi, Harvey, Mark, Craig!

You're welcome. You used which disassembler to do this?

Mine produces a different output, but it's not designed to create a
disassembled -> assembler listing (although I could tweak it so it
could), but it's designed to disassemble something so you can get an
idea of what it does to reverse engineer the program and then write it
in another language.

oh, and I wouldn't have written it that way (with the SWI). SWI is
fine, but the handler needs to just do a jmp to self, leaving the
stack intact. That way you have return addresses and the like to look
at. If all it does is reset, then that's fine, and somewhat
protective, but you never know why it did it.

Harvey


Harvey

P.S As a side reading found an interesting HP journal issue from 1987 explaining about how they have built their boxes:
www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1987-04.pdf
Article starts on the page 12. They say about the UI concept similar to LA box, which is a totally different product. The memory layout and system/SW/FW architecture is covered. Though it could be interesting....

On Wed, 17 Oct 2018 23:53:22 +0100, you wrote:

On 17/10/18 02:24, maxim.vlasov@... wrote:

It would be good to hear from someone who was coding the boxes @TEK about how the things were. However, the absence of the C compilers didn't stop the Tek to have so many different product lines. Also in embedded world of 80s using Prolog, Pascal, Modula, LISP to code the emedded applications was done routinely.

And more... Both Tek and HP used Smalltalk embedded in test instruments. Plus
Tek also produced Smalltalk workstations.

Any idea which ones were the TEK ones? I'm primarily interested in
the TM500, 468, and not sure about any other ones.

Disassembling the DM5010 indicates to me disorganized, but mostly
assembly programmed. If there was a high level language in here, it
wasn't obvious to me.

Harvey

On Wed, Oct 17, 2018 at 04:58 PM, Harvey White wrote:

You used which disassembler to do this?

Harvey,

I used IDA (Interactive DisAssembler created by Ilfak Guilfanov. There is a Wiki page), you can see the section of photos in this thread for the screen capture. it's a semi-automated disassembler. You see the bytevector in front of you at the beginning and you manupulate it by instructing it to convert the byte vector to code/data/table of immediate data or vectors. The tool then will try to start from this, go and disassemble the rest. When it's blocked again you go, explore, instruct comment and give the tool a go. So it's an itterative work. It has a long list of features for signature searching in code, text, etc. I use IDA from the end of 90s. It's by far the only tool to re-create the source quality disassembly.

On Wed, Oct 17, 2018 at 02:08 PM, Siggi wrote:

Awesome, congratulations!
This has been one of the more epic repair threads I've seen here recently,
it was fun to see some of the firmware disassembled. Super-fun to see the
firmware matched my calculation to within 2/4096.
Did you measure the +1.36/-1.24V references after your repair (and DAC
re-calibration)? I'd be most interested to know what the final values of
those reference voltages were against the centered +1.25/-1.24 DLY REF
output.
Apparently 0.5% from the calculated value is too far out, but the -1.25V
value on the schematics is still 0.25% out - the truth is out there!

Thank you Siggi. I had no time to re-measure the test points, I'll do it today. But now DAC is centered (pin 13 J119) between -1.250V and 1.250V, which is quite amazing. I hope that the results will converge with the LTSpice simulated values. After changing the op-amp I have noticed that the OPAMP instead producing -8.1V started pulling the -1.25V line more -8.8V. And everything worked after that.

On Wed, Oct 17, 2018 at 02:08 PM, Siggi wrote:

Did you measure the +1.36/-1.24V references after your repair (and DAC
re-calibration)? I'd be most interested to know what the final values of
those reference voltages were against the centered +1.25/-1.24 DLY REF
output.
Apparently 0.5% from the calculated value is too far out, but the -1.25V
value on the schematics is still 0.25% out - the truth is out there!

I've measured the +1.36/-1.25V test points today with two Agilent 34401A. So, the results are the following:

On the working o-scope the points are stable with a time (4 digits after the decimal point stay where they are, both meters agree).
TP-1.25 = -1.2498V (3mV off the simulation here: /g/TekScopes/photo/74577/0?p=Name,,,20,1,0,0 simulated 1.2468V, calculated -1.2469V, 0.24% off the target)
TP+1.36 = 1.3680V (6mV off the simulation. simulated 1.3619V. calculated 1.3620V, 0.44% off the target)

As highlighted before, the pin 13 of J119 is perfectly centered CCW=-1.250V, CW=1.250V

However, I haven't measured 14.2K and 13.0K resistors. They have bent legs, didn't want to damage or compromise them.