开云体育

On Friday (04/12/2024 at 11:27AM -0400), Chuck Harris wrote:

Hi Chris,

I knew you would understand.

Only because I have been there and done that too many times.

And, thank you for doing this. I could, but, the first Motorola
processor I wrote for was the 68020, which was a lot different
from the 6808, and fundamentally different from the intel and
zilog stuff I cut my teeth on.. You will undoubtedly do it
better and more quickly than I could.

I first started with the 6800 as a kid and I actually have XC6800 versions
of the silicon in my collection, which were the preproduction versions
of the processor that Motorola sampled along with their MEK6800D1 eval
kit. I had one of these eval kits in 1976, when I was in 8th grade.
I then moved on to SWTPC 6800 and Altair 680 machines-- all using the
6800 processor. I still have all these machines and keep them running.

So, I could (but probably won't) assemble this code on a 6800 itself.

But, I am all too familiar with punching in hex to an EPROM programmer
because in those early days, I never had my own programmer so would have
to do it at work, by typing in my hex dumps on a DataIO or some other
programmer in the lab. It was not fun when I screwed up, only finding out
when I got home and it didn't work, then having to erase the PROM and burn
it again the next day. Long, long development cycle in those days...

Anyway, 6800 stuff is genetic for me now :-)

When you are done, and we have this polished and tested, you
should put it up in the files section with some grand title
like: Restore Calibration Constants from EXER 02 dump...

If you have tekscopes privileges, perhaps put it there too?

Only, be sure to attribute it to our tekscopes2 group.

Sure. We can do that.

I hope to get some time this weekend to get started-- wheel out my
own 2465A and play with the EXER02 dump as well.

Chris

--
Chris Elmquist

I think you should also post a link in the eevblog repair thread
on the 2465 when it's finished.

This will be a really great tool. I have a 2465B sitting in my
queue waiting for me to get around to building something to read
out the NVRAM and program a new one. I would still need to get
my 29B working, but this would provide some incentive.

Paul

--
Paul Amaranth, GCIH | Manchester MI, USA
Aurora Group of Michigan, LLC | Security, Systems & Software
paul@... | Unix/Linux - We don't do windows

Hi Chris,

I started programming a PDP8 back in 1970. I was a junior
member of the local HS computer club as I was in 9th grade
in what was then junior high school. Which today would be
a freshman in HS...

My first computer was an S100 machine I jigged together from
a front panel computer that had a NEC8080 and a octal key
pad for entering data. I built a power supply, wire wrapped
the S100 bus, and added a couple of Seals 8K memory boards.

I got tired of fat fingering in my hand assembled machine code,
so I built an I/O card, which let me connect to a Model 15 tty,
and a homebrew cassette tape interface. I had to either leave
the machine on, or fat finger in the boot strap code for the
cassette every time I cycled the power or crashed the computer.

In college, I learned fortran and apl, and spent one class learning
to program in 8008, and another in COSMAC 1802.

In grad school, there was an interdata 6/16 just sitting around
looking for a project, so I adopted it and built a GPIB interface
and used it to drive an automated network analyzer that I was
building for my thesis project. During that time, I bought an
interdata 8/32C, with a Carousel printer, wrote a word processor
and used it all to write my thesis...

After college, I put my shingle out and wrote z80 code for hire.
When IBM introduced their PC, I became an 8088 man. And then
a 80286 guy, and on it went. Lots of development work with the
8086 and 80186... including some spook stuff...

Then came the real time OS stuff for the PC, and a long gig
doing 68020 driver work.

Along the way, I traded my Interdata 8/32C for a PDP8/E, and my
Interdata ended up in the collection of a computer museum in
Silicon Valley... Santa Clara... or is it Palo Alto?

Later came PAL's, PIC's, Arduino's, Raspberry Pi's, Beagle Bone
Blacks, FPGA's and it is all a blur.

I am in the process of disassembling the 2465B code, using NSA's
Ghidra platform... I have no idea how far I will get with that!

I had to retire, there was no time to get anything done!

-Chuck Harris




On Fri, 12 Apr 2024 10:49:06 -0500 "Chris Elmquist" <chrise@...>
wrote:

On Friday (04/12/2024 at 11:27AM -0400), Chuck Harris wrote:

Hi Chris,

I knew you would understand.

Only because I have been there and done that too many times.

And, thank you for doing this. I could, but, the first Motorola
processor I wrote for was the 68020, which was a lot different
from the 6808, and fundamentally different from the intel and
zilog stuff I cut my teeth on.. You will undoubtedly do it
better and more quickly than I could.

I first started with the 6800 as a kid and I actually have XC6800
versions of the silicon in my collection, which were the
preproduction versions of the processor that Motorola sampled along
with their MEK6800D1 eval kit. I had one of these eval kits in 1976,
when I was in 8th grade. I then moved on to SWTPC 6800 and Altair 680
machines-- all using the 6800 processor. I still have all these
machines and keep them running.

So, I could (but probably won't) assemble this code on a 6800 itself.

But, I am all too familiar with punching in hex to an EPROM programmer
because in those early days, I never had my own programmer so would
have to do it at work, by typing in my hex dumps on a DataIO or some
other programmer in the lab. It was not fun when I screwed up, only
finding out when I got home and it didn't work, then having to erase
the PROM and burn it again the next day. Long, long development
cycle in those days...

Anyway, 6800 stuff is genetic for me now :-)

When you are done, and we have this polished and tested, you
should put it up in the files section with some grand title
like: Restore Calibration Constants from EXER 02 dump...

If you have tekscopes privileges, perhaps put it there too?

Only, be sure to attribute it to our tekscopes2 group.

Sure. We can do that.

I hope to get some time this weekend to get started-- wheel out my
own 2465A and play with the EXER02 dump as well.

Chris

On Fri, Apr 12, 2024 at 05:27 PM, Chuck Harris wrote:

If you have tekscopes privileges, perhaps put it there too?

Only, be sure to attribute it to our tekscopes2 group.

Don't forget Tekwiki!

Raymond

It appears that I have made a math error!

The memory map of the 2465B, as seen by the 6800, puts the
RAM in two places.

The first 2K block is right at the beginning of the address
space, 0000 to 07FF.

The full 8K of the RAM is located at 8000 to 9FFF.

So, to get to the constants in the RAM chip, the M6800 needs
to add 8000 to the address where the constants are found in
the 8K RAM chip.

That should be 9E00 to 9FFF If I did my math right this time.

Please check my reasoning!

-Chuck Harris

On Wed, 10 Apr 2024 12:31:11 -0400 "Chuck Harris" <cfharris@...>
wrote:

Hi Chris,

256 words, or 512 bytes (0x1e00 to 0x1fff) are always set
aside for the calibration data.

There are only actually something like 170 16 bit words.

The 2465(no suffix letter) used an EAROM chip, and it was
was something like 128 14 bit words. The 2465[A|B] stayed
with the same calibration size, but bumped it up to 16 bit
because it was convenient in a byte oriented world.

The stack pointer was set a polite distance below the
calibration data for safety.

-Chuck Harris


On Wed, 10 Apr 2024 09:42:42 -0500 "Chris Elmquist" <chrise@...>
wrote:

On Tuesday (04/09/2024 at 11:47PM -0400), Chuck Harris wrote:

Hi Chris,

It really doesn't matter where you do your development. I choose
linux. I stopped using MS products in the 1990's, after paying a
ton of money for support on an MS development package. Their
support people repeatedly lied to me, I missed several important
deadlines, and lost a very important customer.

Absolutely agree. I just figured for the OPs goal, it might be a
long slog to get Linux up and running before he ever got to the
task at hand, assembling some 68xx code. I didn't want him to
believe that Linux was required. It's a better choice, but not
required for this exercise.

The memory map for the 2465 is shown in figure 3-2 in the
2465B/2467B Service manual.

Excellent. I have not had to look at said manual in many years so I
have likely forgotten it was there. This info will be needed to
know where to copy to and from and the execution address for where
the little bit of code needs to reside.

The calibration constants are the last 256 words in RAM... (eg.
0x1e00 to 0x1fff)

All of the rest of the RAM gets initialized every time the scope
is power cycled... So it just doesn't matter.

So, does that mean there are always 256 bytes of calibration data?
No fewer? The entire 256 byte block is what would be copied?

Chris

Since I only have access to 2465A here, do we know, and can we safely
assume that 2465, 2465A, 2465B, and 2467 and 2467B are going to have
the same address decoding and run the same code? Or are there differences
between these instruments that would drive different versions of code?

Also, all are 6808 processors correct?

Chris

--
Chris Elmquist

Hi Chris,

The 2465 plain model and 2467 plain model are different. They have
only 2K of RAM starting at 0, and use an EAROM, which is an early
serial ROM, that was obsolete by the time the 2465 reached production.
The EAROM is 14 bit x 100 words in size.

It is written in a very special way they clock in the serial address,
and the serial data, tell it to write.

The 2445A and B, 2465A and B, and the 2467A and B are all the same.
Their major difference is whether they use a DALLAS NVRAM, or did the
job discretely.

As a mater of fact, I often replaced the battery and the RAM chip in
a 2465A, or early 2465B with a FRAM chip... after doing a slight
modification to the power connections.

All of the 2465 family use 6808's. They may all be Mostek parts, but
I am not sure.


-Chuck Harris


On Fri, 12 Apr 2024 15:30:08 -0500 "Chris Elmquist" <chrise@...>
wrote:

Since I only have access to 2465A here, do we know, and can we safely
assume that 2465, 2465A, 2465B, and 2467 and 2467B are going to have
the same address decoding and run the same code? Or are there
differences between these instruments that would drive different
versions of code?

Also, all are 6808 processors correct?

Chris


On Friday (04/12/2024 at 02:46PM -0400), Chuck Harris wrote:

It appears that I have made a math error!

The memory map of the 2465B, as seen by the 6800, puts the
RAM in two places.

The first 2K block is right at the beginning of the address
space, 0000 to 07FF.

The full 8K of the RAM is located at 8000 to 9FFF.

So, to get to the constants in the RAM chip, the M6800 needs
to add 8000 to the address where the constants are found in
the 8K RAM chip.

That should be 9E00 to 9FFF If I did my math right this time.

Please check my reasoning!

-Chuck Harris

On Wed, 10 Apr 2024 12:31:11 -0400 "Chuck Harris"
<cfharris@...> wrote:

Hi Chris,

256 words, or 512 bytes (0x1e00 to 0x1fff) are always set
aside for the calibration data.

There are only actually something like 170 16 bit words.

The 2465(no suffix letter) used an EAROM chip, and it was
was something like 128 14 bit words. The 2465[A|B] stayed
with the same calibration size, but bumped it up to 16 bit
because it was convenient in a byte oriented world.

The stack pointer was set a polite distance below the
calibration data for safety.

-Chuck Harris


On Wed, 10 Apr 2024 09:42:42 -0500 "Chris Elmquist"
<chrise@...> wrote:

On Tuesday (04/09/2024 at 11:47PM -0400), Chuck Harris wrote:

Hi Chris,

It really doesn't matter where you do your development. I
choose linux. I stopped using MS products in the 1990's,
after paying a ton of money for support on an MS development
package. Their support people repeatedly lied to me, I
missed several important deadlines, and lost a very important
customer.

Absolutely agree. I just figured for the OPs goal, it might be
a long slog to get Linux up and running before he ever got to
the task at hand, assembling some 68xx code. I didn't want him
to believe that Linux was required. It's a better choice, but
not required for this exercise.

The memory map for the 2465 is shown in figure 3-2 in the
2465B/2467B Service manual.

Excellent. I have not had to look at said manual in many years
so I have likely forgotten it was there. This info will be
needed to know where to copy to and from and the execution
address for where the little bit of code needs to reside.

The calibration constants are the last 256 words in RAM...
(eg. 0x1e00 to 0x1fff)

All of the rest of the RAM gets initialized every time the
scope is power cycled... So it just doesn't matter.

So, does that mean there are always 256 bytes of calibration
data? No fewer? The entire 256 byte block is what would be
copied?

Chris

On Friday (04/12/2024 at 05:45PM -0400), Chuck Harris wrote:

Hi Chris,

The 2465 plain model and 2467 plain model are different. They have
only 2K of RAM starting at 0, and use an EAROM, which is an early
serial ROM, that was obsolete by the time the 2465 reached production.
The EAROM is 14 bit x 100 words in size.

OK. So I guess we won't support those for this effort.

It is written in a very special way they clock in the serial address,
and the serial data, tell it to write.

Right. Like a SPI interface except a lot older.
These are also used in DEC VT100 terminals that I try to keep running
here.

The 2445A and B, 2465A and B, and the 2467A and B are all the same.
Their major difference is whether they use a DALLAS NVRAM, or did the
job discretely.

So, we can work on 2445AB, 2465AB and 2467B. Was there ever a
2467A? TekWiki does not show one to me.

As a mater of fact, I often replaced the battery and the RAM chip in
a 2465A, or early 2465B with a FRAM chip... after doing a slight
modification to the power connections.

Yes. Familiar with that mod although once had trouble getting a device
programmer to properly program some FRAM parts so ultimately just put
another Dallas BBRAM part in there. Nod to Andy ;-)

All of the 2465 family use 6808's. They may all be Mostek parts, but
I am not sure.

The Moto ones were basically "bad" 6802 where the on-chip RAM was
defective. So they packaged them with the RAM enable grounded (disabled)
and called it another ground pin.

Chris
--
Chris Elmquist

Hi Chris,

I misinformed. The 2465A and the 2467 share the same manual, and
the same parts for the most part.

The 2467 came late to the game so it got a better CPU board than
the 2465.

There are 3 of these beasts that won't succumb to this easy fix:
2445, 2455, and 2465.

All the rest of the family will work.

-Chuck Harris


On Fri, 12 Apr 2024 17:01:10 -0500 "Chris Elmquist" <chrise@...>
wrote:

On Friday (04/12/2024 at 05:45PM -0400), Chuck Harris wrote:

Hi Chris,

The 2465 plain model and 2467 plain model are different. They have
only 2K of RAM starting at 0, and use an EAROM, which is an early
serial ROM, that was obsolete by the time the 2465 reached
production. The EAROM is 14 bit x 100 words in size.

OK. So I guess we won't support those for this effort.

It is written in a very special way they clock in the serial
address, and the serial data, tell it to write.

Right. Like a SPI interface except a lot older.
These are also used in DEC VT100 terminals that I try to keep running
here.

The 2445A and B, 2465A and B, and the 2467A and B are all the same.
Their major difference is whether they use a DALLAS NVRAM, or did
the job discretely.

So, we can work on 2445AB, 2465AB and 2467B. Was there ever a
2467A? TekWiki does not show one to me.

As a mater of fact, I often replaced the battery and the RAM chip in
a 2465A, or early 2465B with a FRAM chip... after doing a slight
modification to the power connections.

Yes. Familiar with that mod although once had trouble getting a device
programmer to properly program some FRAM parts so ultimately just put
another Dallas BBRAM part in there. Nod to Andy ;-)

All of the 2465 family use 6808's. They may all be Mostek parts,
but I am not sure.

The Moto ones were basically "bad" 6802 where the on-chip RAM was
defective. So they packaged them with the RAM enable grounded
(disabled) and called it another ground pin.

Chris

The 27128 EPROM is 16K bytes and so does that mean it is fully decoded
from $C000 to $FFFF or ?? If so, then our program could start at
$C000 but this is another detail I need to confirm.....


If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)



Chris N?JCF

Thank you, Chuck for the detailed information and Chris for trying to get my cal data back on to my scope.

Not sure if this matters, but the EPROM in my scope is a 27512 (not 27128).

I did not take a video of the cal data, but I wrote them down. I double-checked to make sure that I wrote them down correctly. I will make a text document or spreadsheet of the cal table and send it to you. Should I put the file in the files section here or send it to you by email?

Don

On Friday (04/12/2024 at 04:08PM -0700), Don via groups.io wrote:

The 27128 EPROM is 16K bytes and so does that mean it is fully decoded
from $C000 to $FFFF or ?? If so, then our program could start at
$C000 but this is another detail I need to confirm.....


If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)



Chris N?JCF

Thank you, Chuck for the detailed information and Chris for trying to get my cal data back on to my scope.

You are welcome. It's an interesting exercise and should be handy for
a lot of folks, including myself, if I never get around to replacing
the battery :-)

Not sure if this matters, but the EPROM in my scope is a 27512 (not 27128).

Hmm. Interesting. I will take a look at the schematics but they are
most likely using only part of it since that's a 64K byte device which
would consume all of the 6800 address space if fully decoded. They do
use a bank switching scheme for the RAM but not for the executable PROM
code as far as I can tell.

I did not take a video of the cal data, but I wrote them down. I double-checked to make sure that I wrote them down correctly. I will make a text document or spreadsheet of the cal table and send it to you. Should I put the file in the files section here or send it to you by email?

You can send them by email and I will build them into the first attempt
of the program, simply for reference. Other folks will put their own
constants into the same place in the program, keeping only the copy
routine ahead of them but we can then show the constants in spreadsheet
form and also in hex form in the program so folks can see where they
go.

For my direct email, just use that callsign earlier in this message
@arrl.net, in case it's not revealed in the groups.io header for you.
But use the actual zero key on your keyboard rather than the Danish Oh
as shown.

Chris
--
Chris Elmquist

On 4/12/24 17:52, Chris Elmquist wrote:

Other folks will put their own
constants into the same place in the program, keeping only the copy
routine ahead of them but we can then show the constants in spreadsheet
form and also in hex form in the program so folks can see where they
go.

What tools will we need to edit the EPROM data on linux? Vim? An assembler?
Straight machine language only with vim, nano, gedit, etc.?
Maybe more than a couple will use linux to do this...
--
John Griessen
68HC11 assembly programmer for a little while, back in the 70's, early 80's.

Hi John,

Any hex editor will do. Most eprom programmers come
with one in some form.

-Chuck Harris


On Fri, 12 Apr 2024 18:33:44 -0600 "John Griessen via groups.io"
<john@...> wrote:

On 4/12/24 17:52, Chris Elmquist wrote:

Other folks will put their own
constants into the same place in the program, keeping only the copy
routine ahead of them but we can then show the constants in
spreadsheet form and also in hex form in the program so folks can
see where they go.

What tools will we need to edit the EPROM data on linux? Vim? An
assembler? Straight machine language only with vim, nano, gedit, etc.?
Maybe more than a couple will use linux to do this...

Looking at some Tektronix code, it occurs to me that some of that data in the EPROM is a checksum, and changing data without changing the checksum will be a problem.

That's what the disassembly is going to be for, amongst other things.

Not sure where they did it, but this code dates from the paranoid era of microprocessors where you have jump tests, load and store tests, subroutine tests, etc built into the startup code.? I know that on the DC5010 there's a bit of it.

So changing things may be a bit more complex than let on (if they did that on the cal data).

Harvey

Hi Don,

The oldest of the 2465's used multiple 8K parts. We can't
support the 2465, as the EAROM is too hard to program for this
little hack.

The pre 50K serial number CPU's must have run out of space on
the board, as they used the expensive 27512's. The after 50K
serial number boards had a spot for a through hole 27128 and
surface mount 2764... that wasn't used.

I don't foresee a problem using the 27512, I just forgot about
that variation.

-Chuck Harris

On Fri, 12 Apr 2024 16:08:40 -0700 "Don via groups.io"
<donald_s_58103@...> wrote:

The 27128 EPROM is 16K bytes and so does that mean it is fully
decoded from $C000 to $FFFF or ?? If so, then our program could
start at $C000 but this is another detail I need to confirm.....


If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)



Chris N?JCF

Thank you, Chuck for the detailed information and Chris for trying to
get my cal data back on to my scope.

Not sure if this matters, but the EPROM in my scope is a 27512 (not
27128).

I did not take a video of the cal data, but I wrote them down. I
double-checked to make sure that I wrote them down correctly. I will
make a text document or spreadsheet of the cal table and send it to
you. Should I put the file in the files section here or send it to
you by email?

Don

Hi Harvey,

The checksums are read by the normal tektronix EPROM code.

We are making the rules here, not tektronix ;-)

Well, tektronix made the sand box we are playing in, but we
will be running only our code, and our code doesn't calculate
checksums.

-Chuck Harris


On Sat, 13 Apr 2024 00:32:36 -0400 "Harvey White"
<madyn@...> wrote:

Looking at some Tektronix code, it occurs to me that some of that
data in the EPROM is a checksum, and changing data without changing
the checksum will be a problem.

That's what the disassembly is going to be for, amongst other things.

Not sure where they did it, but this code dates from the paranoid era
of microprocessors where you have jump tests, load and store tests,
subroutine tests, etc built into the startup code.? I know that on
the DC5010 there's a bit of it.

So changing things may be a bit more complex than let on (if they did
that on the cal data).

Harvey


On 4/13/2024 12:24 AM, Chuck Harris wrote:

Hi John,

Any hex editor will do. Most eprom programmers come
with one in some form.

-Chuck Harris


On Fri, 12 Apr 2024 18:33:44 -0600 "John Griessen via groups.io"
<john@...> wrote:

On 4/12/24 17:52, Chris Elmquist wrote:

Other folks will put their own
constants into the same place in the program, keeping only the
copy routine ahead of them but we can then show the constants in
spreadsheet form and also in hex form in the program so folks can
see where they go.

What tools will we need to edit the EPROM data on linux? Vim? An
assembler? Straight machine language only with vim, nano, gedit,
etc.? Maybe more than a couple will use linux to do this...

Right, forgot for a moment that this is not tektronix executable code and it couldn't care less about checksums.

Many years ago, I worked on a mil-spec processor system that had a lot of that in the startup code.? Considering it was made of discrete chips, it made sense.

Harvey

Hi Chris,

There is one variation that I see with the "A" model, and I
presume the early "B".

Because they ran out of room for two EPROMS, and a battery, they
decided to use a single 27512 EPROM, which uses up the entire
address space of the M6808.

Well, don't despair! Yet...

Their description says:
The programable array logic device also generates the /OE and /WE
signals to the random-access memory (RAM). This RAM can be accessed
with addresses 8000 to 9FFF if either ROM SELECT or PAGE SELECT
signals are HI. In this mode the ROMS, U2160 and U2260 are not
accessible in this address range.

I'm not sure what this means. It could mean that we need to write
to a port that sets ROM SELECT, or PAGE SELECT HI, only they don't
identify any such port in the address map, or it could mean that the
signals get created when you try write or read 8000 to 9FFF.

Siggi warned me about this, but I wasn't on the same page as he was
at the time.

The signals ROM SELECT and PAGE SELECT come from U2310, a 74LS174.

U2310 is sampling the data bus, and gets clocked by "PORT1 CLK",
which comes from U2550, pin 12.

So, it looks likely that we have to set data bit 3 or 4 high and
write it to PORT1 CLK, which is identified on the address map as
being addresses 08C0-08FF.

As I understand the description, we should be able to run with
ROM SELECT and/or PAGE SELECT high all the time because we don't
need the bottom of the 27512 for our project... We gladly sacrifice
the 8K of code space.

Can anyone confirm my thinking?

-Chuck Harris

On Fri, 12 Apr 2024 18:52:12 -0500 "Chris Elmquist" <chrise@...>
wrote:

On Friday (04/12/2024 at 04:08PM -0700), Don via groups.io wrote:

The 27128 EPROM is 16K bytes and so does that mean it is fully
decoded from $C000 to $FFFF or ?? If so, then our program could
start at $C000 but this is another detail I need to confirm.....


If Don wants to send me his 256 word cal table, I'll make the
first version of the code just for him! :-)



Chris N?JCF

Thank you, Chuck for the detailed information and Chris for trying
to get my cal data back on to my scope.

You are welcome. It's an interesting exercise and should be handy
for a lot of folks, including myself, if I never get around to
replacing the battery :-)

Not sure if this matters, but the EPROM in my scope is a 27512 (not
27128).

Hmm. Interesting. I will take a look at the schematics but they are
most likely using only part of it since that's a 64K byte device which
would consume all of the 6800 address space if fully decoded. They do
use a bank switching scheme for the RAM but not for the executable
PROM code as far as I can tell.

I did not take a video of the cal data, but I wrote them down. I
double-checked to make sure that I wrote them down correctly. I
will make a text document or spreadsheet of the cal table and send
it to you. Should I put the file in the files section here or send
it to you by email?

You can send them by email and I will build them into the first
attempt of the program, simply for reference. Other folks will put
their own constants into the same place in the program, keeping only
the copy routine ahead of them but we can then show the constants in
spreadsheet form and also in hex form in the program so folks can see
where they go.

For my direct email, just use that callsign earlier in this message
@arrl.net, in case it's not revealed in the groups.io header for you.
But use the actual zero key on your keyboard rather than the Danish Oh
as shown.

Chris

On Fri, Apr 12, 2024 at 10:04 PM, Chuck Harris wrote:

Hi Harvey,

The checksums are read by the normal tektronix EPROM code.

We are making the rules here, not tektronix ;-)

Hi Chuck,

All this is way over my head, so please excuse me if this is a dumb question....
I know that the custom EPROM code to load the cal data doesn't care about a checksum,
but what happens when the original EPROM (with the checksum in it) is put back
in the scope? Am I correct in assuming that once the original cal data is written back to the NVRAM
the checksum will be correct? Is the checksum only for the cal data or is it for ALL the data in the NVRAM?
If the latter, the checksum would change every time any changes are made to the front panel settings, wouldn't it?

Don

On Saturday (04/13/2024 at 05:42AM -0700), Don via groups.io wrote:

On Fri, Apr 12, 2024 at 10:04 PM, Chuck Harris wrote:

Hi Harvey,

The checksums are read by the normal tektronix EPROM code.

We are making the rules here, not tektronix ;-)

Hi Chuck,

All this is way over my head, so please excuse me if this is a dumb question....
I know that the custom EPROM code to load the cal data doesn't care about a checksum,
but what happens when the original EPROM (with the checksum in it) is put back
in the scope? Am I correct in assuming that once the original cal data is written back to the NVRAM
the checksum will be correct? Is the checksum only for the cal data or is it for ALL the data in the NVRAM?
If the latter, the checksum would change every time any changes are made to the front panel settings, wouldn't it?

I think this could be an issue if they were computing a checksum over
the cal constants and storing that somewhere else in the NVRAM that is
not displayed by the EXER02 routine.

We have only the data displayed by EXER02 to work with so if they
calculated and salted away a checksum that they did not display, then
we will have a problem.

We'd need to figure out what algorithm was used and where they put the
calculated checksum in the NVRAM so that we could reconstruct it.

Probably looking at disassembled Tek code is going to be the shortest
path there, if we believe they did such a thing.

What happens on the scope if you enter the calibration process but then
exit it without changing any values? Maybe if the cal constants checksum
fails you cannot even enter the cal process? Hope that's not the case.

Completely a guess but they might recalculate and store the checksum on
the way out of this cal routine and they would use any values already
in NVRAM that haven't been changed for that recalculation. If we
put the values there with our hack code, enter cal, exit cal, maybe it
would recalculate the checksum using the values we parked there? Dunno.
Again, looking at their code might reveal this.

Chris
--
Chris Elmquist