开云体育

Thank you, Chuck,

I haven't touched the capacitors yet. I've tried all 3 AWGs and got the same result. CAL01 had to run again this time with 7834a, since the steps with the extenal DSO scope were not aligned correctly. Now it's fine, but still LIMIT error. I'll try using the high resolution HDO6034 scope at work to check the AWG output before connecting to 2445a in CAL02. But I can assume that it will be fine since all the equipement at work is fresh out the calibration lab.

To be more concrete I've thrown to IDA the 2465a ROM files. 160-3302-09 & 160-3303-09 are the part number downloaded from here:


The code structure is quite interesting. The bank switching routines are in the first 2K RAM working area. I've quickly found the voltage reference setting routine:
/g/TekScopes/photo/74577/22?p=Name,,,20,1,20,0

See the comments in the code. The 0xAC=172d code thrown in the DAC sets the reference voltage of 1.36V:
1ma*(4095-172)*4/4096=3831uA. Solving for x=TP2421 voltage:
x*14.2KOhm/13.0KOhm + 681Ohm*(4095-172)*0.004A/4096 = -x
x=(4095-172)*0.004A/4096*681Ohm/(1Ohm+14200Ohm/13000Ohm) = -1.247V

The above assumes that the DAC is calibrated for the 1mA reference current.

Here are some other examples of the DAC and the counter access:
/g/TekScopes/photo/74577/21?p=Name,,,20,1,20,0
/g/TekScopes/photo/74577/20?p=Name,,,20,1,20,0

The code is complex in structure due to the ugly banking implementation. There are similar sections in all four 32K ROM pages. DAC is accessed all over the place in byte fashion and also by direct 16 bit X or even S register store. The DAC work area in the first 2K of RAM is also used heavily and many locations are duplicated.

If completely stuck, then I'll try tracing the LIMIT error, but looking just at the ADC routine complexity (uses almost 200 bytes of various runtime data to do the conditional branching) likely it will consume all the time for several months...

Hi Victor,

Please, reserve me also 2 pieces of blue filter!

You can contact me at kmiklos at vnet.hu.

Thanks

Miklos

Hi Maxim,

The normalizer is just a resistor and a trimmer capacitor
in parallel, but in series with the center conductors of
a male and a female BNC connector. It is built in a little
Pomona box.

You can do the same thing with a scope probe, using the
probe's trimmer capacitor to square up the waveform on
one channel, and the C205 to square it up on the other.

I doubt it needs adjustment, assuming that you haven't moved
it already.

That CAL03 throws a LIMIT on CH3 and 4 makes me even more
certain that your problem is your generator.

-Chuck Harris

maxim.vlasov@... wrote:

If you have ever used a 7805, or LM309, LM319, or LM340, ... you
have already used current foldback.

-Chuck Harris

tinkera123 wrote:

PHK is an open source legend. His disassembler is available
for free on github.

PHK wrote the NTP routines for openbsd.

-Chuck Harris

Harvey White wrote:

On Sat, 13 Oct 2018 16:05:14 -0400, you wrote:

...

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

Hmmm, some people want money for those things, not that I begrudge him
the income, but I tend to go to open source.

That's what mine does, although I get tired of writing tools to make
tools....

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

The one in the DM5010 isn't, I think, and actually has internal RAM.
For analysis cases, all it does (of course) is to change the location
of some of the RAM.

Harvey

-Chuck Harris

There are many disassemblers that actually emulate the target
code to determine the exact way it operates... all in software.

CAL01 doesn't have much to do with CAL02.

Which attenuator settings give you the RANGE error when running
CAL02?

-Chuck Harris

maxim.vlasov@... wrote:

Okay, understand that now. I have played with/built many linear supplies, but none with much protection circuitry.
Thank you, Chuck.
Cheers,
Ian

On Sat, 13 Oct 2018 16:05:14 -0400, you wrote:

Harvey White wrote:

<snip>

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.

Now for the 6800 and such, you could find the most up-to-date probe,
so that becomes less of a factor for that generation of processors,
I'd think.

Possibly, most of the older processor's pods have been long since scrapped,
but some are certain to still exist.

I just ditched some 6502, Z80, and 8085 emulators... They probably are still
available from the recycler if anyone is interested.

I probably would have liked the ones for the 8085 and the 6502, just
because. Every once and while, I need to look at some of those old
ones. Right now it's the 6802 that I need to look at.

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.

Hmmm, got one for the 6800 series? I have core images...

A couple, actually. Sourceforge, and github are littered with them,
particularly the 6809, which is an upfeatured 6802 used in the automotive
industry.

I found a few, they want DOS.

I have one that I wrote that runs under windows and is gui driven.

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

Hmmm, some people want money for those things, not that I begrudge him
the income, but I tend to go to open source.

That's what mine does, although I get tired of writing tools to make
tools....

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

The one in the DM5010 isn't, I think, and actually has internal RAM.
For analysis cases, all it does (of course) is to change the location
of some of the RAM.

Harvey

-Chuck Harris

Harvey White wrote:

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.

There are some situations where the LA can be of use, but mostly for
tracking specific events under specific conditions, IMHO.

Indeed, but I find that the LA disassemblers are problematic. It is difficult
to tell with a piplined processor whether the memory reads you are processing
are reading data, or reading instructions. Without a probe specific to the
processor that can make those determinations, you are just looking at
data translated to assembler mnemonics... not useful. The 8086 was the first
commonly used microprocessor to suffer this problem... and solution. Intel
included extra pads that brought out pipeline tracking information for emulators
and logic analyzers.

Tracking specific events under specific conditions is where a LA shines.

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.

Now for the 6800 and such, you could find the most up-to-date probe,
so that becomes less of a factor for that generation of processors,
I'd think.

Possibly, most of the older processor's pods have been long since scrapped,
but some are certain to still exist.

I just ditched some 6502, Z80, and 8085 emulators... They probably are still
available from the recycler if anyone is interested.

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.

Hmmm, got one for the 6800 series? I have core images...

A couple, actually. Sourceforge, and github are littered with them,
particularly the 6809, which is an upfeatured 6802 used in the automotive
industry.

PHK, Poul-Henning Kamp wrote a nice one that actually analyzes the code
by executing it. He used it to disassemble the code in some HP counters.

...

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well

Tek tended to use the 68B02, which is a 6802 without the internal RAM.

-Chuck Harris

The link is now on Manuals, Catalogs, and Other Publications > Reference Materials.
Dave

On Sat, Oct 13, 2018 at 08:40 AM, <maxim.vlasov@...> wrote:

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.

...

Actually, the 167xx doesn't always need a special adapter. There's a good thread on HP/Agilent disassemblers here:



In post #3 in that thread there's an example of using a 16702B logic analyzer to probe a 6802 processor using flying lead probes directly to the processor pins (no adapter). The thing being probed was a Tek 2465.

On the 2445A/2465A and 2465B/2465B, Tek uses bank-switched memory, making it even more fun to untangle the code. The 2465 does not have bank switching. (Maybe IDA handles bank switching?) If someone wants to head down the disassembly path, here's some info on how the banks are handled, specifically for a 2465A, but I think the B series is the same:



I've done some disassembly of the code along with real-time tracing to figure out how some things work. It's time consuming and some of the code seems a bit hack-y as it was ported from one platform to the next.

-mark

It is supposed to be on the main page Manuals, Catalogs, and Other Publications > Reference Materials but I don't see it listed there. I'll contact Kurt.

Dave

On Sat, Oct 13, 2018 at 09:51 AM, Jeff Urban wrote:

In case you haven't, it is important to check if it is a centering problem or
a triggering problem. Even in auto or free run it is still triggered, so if it
is the problem could be all the way back at the ramp generator.

If the trace itself is moving and not the sweep (I hope you got that...) then
I would more look for hash on a PS line somewhere. Of course that applies to
the ramp generator as well but different PS legs of course.

Thanks Jeff.
There is jitter on the A gate out with no input just a free running trace. I had to put my 465 in 10x to see it but it does match the jitter on the 468. So... This looks like its going to be a fun one to figure out.

On Sat, Oct 13, 2018 at 09:05 AM, walter shawlee wrote:

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

Yes I was wondering about thaat too ! Such a nice resource... that's not even visible/accessible, kinda defeats the purpose of making it public ^^

I guess the link to that RPR page might fit at the bottom of the main page, under the section labelled " Manuals, Catalogs and Other Publications " ?!

Thanks for all the scanned sections so far, and for all those to come :-)


Vincent Trouilliez

In case you haven't, it is important to check if it is a centering problem or a triggering problem. Even in auto or free run it is still triggered, so if it is the problem could be all the way back at the ramp generator.

If the trace itself is moving and not the sweep (I hope you got that...) then I would more look for hash on a PS line somewhere. Of course that applies to the ramp generator as well but different PS legs of course.

On Sat, 13 Oct 2018 01:47:20 -0400, you wrote:

Or, "Square Wave".

To be a bit pedantic, to me, square wave doesn't talk about the
levels, so where's 0 and where's Vmax...?

bet there's lots of opinions on that one.

Harvey

-Chuck Harris

Harvey White wrote:

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

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

Harvey

On Sat, 13 Oct 2018 09:55:50 -0400, you wrote:

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.

There are some situations where the LA can be of use, but mostly for
tracking specific events under specific conditions, IMHO.

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.

Now for the 6800 and such, you could find the most up-to-date probe,
so that becomes less of a factor for that generation of processors,
I'd think.

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.

Hmmm, got one for the 6800 series? I have core images...

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.

IIRC, the 6802 did more integration of the RAM into the processor. I
think that the DM5010 uses one as well.

Harvey

-Chuck Harris

maxim.vlasov@... wrote:

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.

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)