开云体育

Thanks so much for another great RPR scan, the 311 set is very handy to have!
I can hardly wait for that 366 scan, it will answer a lot of questions.
the page link is here:

I notice it doesn't seem to tie to the general main page at all.

thank you for all the hard work!
-walter

--
Walter Shawlee 2
Sphere Research Corp. 3394 Sunnyside Rd.
West Kelowna, BC, V1Z 2V4 CANADA
Phone: +1 (250-769-1834 -:-
We're all in one boat, no matter how it looks to you. (WS2)
All you need is love. (John Lennon)
But, that doesn't mean other things don't come in handy. (WS2)

Chuck,

I've been using all sorts of LAs since the beginning of 90s in the reverse engineering for the systems with scarse or no technical documentation. Simply at the start I had my own home built machine initially based on Intel FlexLogic ICs (they had the fastest clock rate in 1993) then switching to Altera FLEX/APEX families. Then at the beginning of 2000s HP/Agilent LAs with a deep memory became available at the bargain prices. I talk mainly about the arcade machine HW (as this role goes I analyze the chipset architecture in details and re-produce its functional analogues for the FPGA/semicustom IP implementation) which are not the simple uP based HW (Tek is a such example). So, I know something about the reverse engineering bringing the concrete examples ;))

Everyone in the embedded "professional" hacking knows IDA. This is not a panacea as a cross-platform disassembler, but almost and certainly the best of all. But since there is a lot's of the dynamic code in the FW (especially when ppl translating from C++), which can't be analyzed statically (by the disassembler), this runtime can be only analyzed on the working maching by using the LA even without any built-in inverse assembler. So the synergy of both are required to understand the code architecture. Getting the architecture, control and data flow and symbolizing the source is the most important steps. Also we shouldn't forget that the source can be actually compiled by not a very optimal compiler generating the spagetty code.
From all the above, the current example (Tek 6802 base platform) is quite simple, HW is all documented and it can be analyzed statically. But due to the code volume superimposing the calls will be necessary and there the LA will be undispensable.

Back to the oscilloscope, I've got 2445a CAL01 re-calibrated. This time I got it right (digital scopes unfortunately are quite useless). Still CAL02 gives the LIMIT error. But what I also noticed is that when I put the time cursors to the 1st and 11st vertical line the displayed frequency/period gives the precise value in seconds. However, it seems that when I just put them one division apart or a few, then I do have the error in the displayed delta T. Negative if both cursors are to the left from the center and positive when both to the right. It seems like there is a problem with the DAC linearity or something in its path.
IMHO this kind of error then hits back in CAL02.

What do you think?

Thank you again and all the Best,

Maxim

On Sat, Oct 13, 2018 at 06:47 AM, Colin Herbert wrote:

Is this in store or non-store mode? I have seen horizontal jitter on my 468 in
storage mode and there is a thread on this forum where I asked about it. I
haven't had a definitive answer to this yet, though I have been suspecting the
caps in the A19 Time-base/Power supply board. I will be interested to see what
happens with your 468.
Colin.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of lop pol
via Groups.Io
Sent: 13 October 2018 13:14
To: [email protected]
Subject: [TekScopes] 468 horizontal jitter

I'm working on my second 468 and I noticed some horizontal jitter. There is no
jitter from the rear vert signal output. What does that mean? What I'm
wondering is what is being bypassed when looking at a wave form on another
scope through the rear output? Should I be looking somewhere in the CRT
circuit of the 468 for the cause of the jitter? The jitter is ALMOST
unnoticeable until 10x mag is turned on then its very pronounced.

Thanks guys

Its in non store,store and XY mode. I see 50mV of ripple on the emitter of Q560 when 10x mag is on along with 200mV spikes that coincide with the jitter I see.

I have been designing and debuging embedded systems for more than
40 years. I started with the 8008, and have designed and programmed
hardware for the 8080, Z80, 8085, 8086, 80188, 80186, ..., 68000, 68010,
PIC, ARM, ..... Believe it or not, but they are all substantially similar,
some a little more similar than others.

However, whenever anyone tells me that a Logic Analyzer, with an internal
disassembler probe, will ease the job of understanding anything, I know
immediately that they don't know what they are talking about.

The state of LA disassembler probes never reached a point where useful
work could be done, and are in fact a tantalizing way of wasting money.
It seems like it should be possible, was sold as the software engineers
panacea, but it never is.

The largest problem is that the disassembler probes for given microprocessors
always lags the deployment of those microprocessors, and the fast evolution of
new processors means that the art is always running away from your investment
in probes.

A far better way of understanding an assembly program is to use a
good disassembler, that allows you to use your own labels for data and
jump addresses, and it is generally free. Plus, the software interface to
the hardware processors is surprisingly slow to change, and simple and
cheap to adapt.

Software emulators, debuggers, and disassembler/decompilers, have largely
supplanted the disassembling Logic Analyzer, and they did so back in the days
of the Data General Eagle, and DEC's VAX..

I don't think anyone was recommending using 6502 tools on a 6802. I think
it was simply either someone showing a parallel, or mistaking my mention of
the 2465's 6802, for the more famous "02" processor the 6502.

-Chuck Harris

maxim.vlasov@... wrote:

Is this in store or non-store mode? I have seen horizontal jitter on my 468 in storage mode and there is a thread on this forum where I asked about it. I haven't had a definitive answer to this yet, though I have been suspecting the caps in the A19 Time-base/Power supply board. I will be interested to see what happens with your 468.
Colin.

Hello Raymond,

I see the comment ;) Well we are not jailbreaking the new iPhone herein with all the possible and impossible protection switched on ;))

Well, we can start it in a few ways.

Method 1
by using the real-time INVASM with the logic analyzer: connect the probes to the CPU address/data/control. The first is to set the breakpoint at the DAC and CD4051 multiplexer register decode and trace this to the rouine executable. We have to make sure, that the routine in question doesn't run from RAM but from the ROM. The instruction fetch will be identified as well as the area where it was called from. Then we have to trace back the stack and find our from where the I/O routine which controls the DAC was called. This method is called "bottom up HW signature".

Method 2
by using IDA disassembler. We have to find a symbol data in the code and the references linking the DAC/ADC comparator and 4051 multiplexer select (at the low level) with the high level message labels reading LIMIT, CAL0x and the step number. This method is called "top down symbol search".

There is a 3rd one, but it will require the ROM emulator upfront, where the modified ROM code can be placed (however the checksum routing must be identified and disabled first).

To me, the 1st or the 2nd method would require around 10-20 hours to understand the FW code structure. More detailed analysis, however, likely require some testing.

However, I do hope, that Tek guys have placed some hooks in their code or they write to the CPU BUS connected device to display more detailed data. For example, by how much one of the parameters is off. Likely such a discovery can be made by looking at the TEK code.

Thank you,

Maxim

On Sat, Oct 13, 2018 at 11:57 AM, <maxim.vlasov@...> wrote:
Hi Maxim,

the routine in question can be easily identified by LA and disassembled

Has anyone ever called you an optimist before?

Raymond

6802 shares the 6800 instruction set, however for the inverse assembler for HP/Agilent 165xx, 166xx and 167xx still a different adapter is required due to the slightly different bus timing (or one can be made by using a simple 5V tolerant CPLD). Mostek/WDC 650x & Motorola 680x are completely different animals architecture wise.
The TASM PC (for DOS) cross assembler can be used to compile and link the code natively for 6802/6800. IDA disassembler will re-create the disassmbled code to the level of the original source (or sometimes even better documented). HP/Agilent INVASM will disassemble in real-time all the event driven routines, for example interrupts, insitu on the running oscilloscope.
By disassembling and recompiling the original source (disassembly done automatically by IDA) the generated ELF (embedded linker file with symbol data) can be loaded into the HP/Agilent 16505A or Agilent 167xx software analyzer suite to display the statistical distribution and recurrence of the service routine calls. This sometimes very handy to analyze the real-time FW. I've done a few projects in the past for 68040/PPC in that way.

IMHO, there is no need to complicate the life with 6502 tools since they'll provide no help with 6800.

On Sat, Oct 13, 2018 at 02:13 PM, <maxim.vlasov@...> wrote:

I can observe that when 1 MOhm input on the scope is selected, the square
waveform signal delivered by the BNC cable has a visible overshoot on the
rising edge. So, likely the C105 & C205 have to be adjusted too.

That is only natural with that setup, i.e. a basically open-ended 50 Ohm cable driving the 1 MOhm input with a signal having higher-frequency content.
Adjusting the input capacitance (often resulting in *de*normalizing) won't help and will be counterproductive. The input capacitance very rarely needs adjustment over a 'scope's lifetime. Readjusting basically is done only to make sure both channels are equal so you can swap probes between channels and sometimes between 'scopes.

Raymond

I'm working on my second 468 and I noticed some horizontal jitter. There is no jitter from the rear vert signal output. What does that mean? What I'm wondering is what is being bypassed when looking at a wave form on another scope through the rear output? Should I be looking somewhere in the CRT circuit of the 468 for the cause of the jitter? The jitter is ALMOST unnoticeable until 10x mag is turned on then its very pronounced.

Thanks guys

Chuck,

I read again the input capacitance adjustment procedure for CH1/CH2. I have no 15pF normalizer and the high voltage calibration generator.

I can observe that when 1 MOhm input on the scope is selected, the square waveform signal delivered by the BNC cable has a visible overshoot on the rising edge. So, likely the C105 & C205 have to be adjusted too. I wonder if this overshoot could potentially contribute to the CAL02 LIMIT problem on the channel 1 & 2.
However, when calibration CAL03 routing with other channels 3 & 4 the scope also throws the LIMIT error.

Thank you,

Maxim

On Fri, Oct 12, 2018 at 07:06 PM, Chuck Harris wrote:

Not that it matters much, but Tektronix used the 68B02
microprocessor here, rather than the 6502. They are both
substantially similar

Depends on what you call "substantially similar". Yes, the 6502 derives from the 6800 (6802) but architecturally, it is much simpler (it was developed to save costs against the 6800 with the 6502's deficiencies being called "features" by some). The 6802 had a single supply voltage and a single-phase, like the 6502 and was a more integrated thing than the original 6800.
For starters, the 6502 had a very different programming model with 1 accumulator against the 6800's 2, an 8-bit stack pointer with a hardwired address space vs. the 6800's 16-bit. Obviously, opcodes were different. It had a few advantages as well (as an example, the 6502 had a BCD mode AFAIR).
Many (cross) assemblers can be used for both families with appropriate settings.

Raymond
In all, it's far less orthogonal than the 6800's architecture but much more so than Intel's 8080 and everything Intel that followed (until today).

Hello Siggi,

Thank you for your excellent explanation. I also assume that performance wise the system is almost in spec but just slightly below the margin. Therefore I wanted to start from changing the OPAMPs since their leakage will contribute a lot to the final precision of the voltage generation at the output. I've looked at the possible replacement of MC14051, but apart from TI CD4051 in the plastic package I don't see anything else. So, for the moment, I'll try to check the passives for the leakage and then replace TL084. Interestingly enough the service manual states that the JFET input stage opamp must be LF374, however in the real o-scope I have TI TL084.... So I've ordered both.
For the moment I'm very reluctant to change the DAC (which is PMI marked) to the Analog Devices part. But IMHO if the calibation signal is really 0V to whatever requested V, and everything else is in spec I can only assume that the improvised mutlichannel DAC and the ADC are out of spec.

Thank you again,

Maxim

P..S. I can potentially completely reverse engineer the FW, but I have no time and motivation for this yet since skipping the LIMIT error woudn't make the instrument more precise.
For someone, who is interested in reverse engineering, now on e-bay it's possible to buy 16500A/B/C logic analyzer with 16550a card (or even 16510a/b) for next to nothing. 6802 inverse assembler can be downloaded directly from YAHOO groups HP/Agilent forum. IDA disassebler has the 6800 instruciton set extension so the routine in question can be easily identified by LA and disassembled. But this requires a significant amount of time and knowledge about the TEK hybrids to understand the routine in the detail. IMHO one of the possibilities would be to try finding/discovering some detailed diagnostics to be displayed on the screen if the LIMIT error is encountered (likely this is hidden somewhere by Tek but not documented). Same goes for some additional features as the calibration variables mark-up and manipulation. Also easy backup via the interface. For example, one could develop an I2C EEPROM manipulation routines to store and recall the calibration data while the SRAM is under repairs.

Strictly speaking, a square wave that goes from zero to
some voltage is not DC. The term "wave" should be a clue
to that.

It is an AC signal with a DC offset.

I don't remember, did I call it AC? I don't think I would
have done that, being the pedant that I am.

-Chuck Harris

Raymond Domp Frank wrote:

Or, "Square Wave".

-Chuck Harris

Harvey White wrote:

On Fri, 12 Oct 2018 16:22:55 -0700, you wrote:

On Sat, Oct 13, 2018 at 12:54 AM, Chuck Harris wrote:
Chuck,
Re.

No, DC puts out a DC voltage, Square wave puts out a selectable
frequency square wave signal.

In daily speak, we often use "AC" for any non-steady signal level but that is only true if the signal changes polarity at times. Strictly speaking, a non-steady voltage/current between 0 and another level of the same polarity *is* DC. I almost got confused by this (as well)...

A useful term is "pulsating DC", or perhaps unipolar pulses, if you
wish.

Harvey

Raymond

I plan on doing the requested 366- knobs but I think I will do the 670- PCB assemblies first. It is quite large so it is going to take some time.

Based on requests we have scanned the 311- resistors and it is now on tekwiki.org. It is 701 pages

Sorry for the crappy language ("...between 0 and another level of the same polarity...") in my previous message. I hope what I meant is clear.

As regards the web interface idiosyncrasy that I reported: Those seeing the messages in their mail client see the correct representation, as I edited and meant it, at least with my Thunderbird email client that is so.

Raymond

On Sat, Oct 13, 2018 at 12:54 AM, Chuck Harris wrote:
Chuck,
Re.

No, DC puts out a DC voltage, Square wave puts out a selectable
frequency square wave signal.

In daily speak, we often use "AC" for any non-steady signal level but that is only true if the signal changes polarity at times. Strictly speaking, a non-steady voltage/current between 0 and another level of the same polarity *is* DC. I almost got confused by this (as well)...

Raymond