|
Hello all,
I have posted this on the Tekscopes Forum, but I am posting it here too in the hopes that Chuck Harris sees this because I have seen a post of his on the Tekscopes Forum which might solve my problem.
I had a perfectly functioning 2467B scope (1989 vintage). After reading about possible loss of calibration data due to the NVRAM battery dying, I decided to put in a new battery (mine is the older version, below 50000 serial #) which has the battery separate from the NVRAM. The battery had a date code of 2689, so the battery is 35 years old. I did hook up a backup battery before removing the Lithium battery and confirmed that pin 28 of the RAM chip had at least 3 V on it from the backup battery after removal of the original battery. After putting in the new replacement battery, I also changed out the 4 electrolytic capacitors on the A5 board. When I put the scope back together and fired her up, I got the dreaded " Test 04 Fail 13" message indicating corrupted or lost calibration data. Not sure how this happened since I hooked up a backup battery before removing the original battery. So, the very thing I was hoping to prevent happened by my being proactive!
Before doing all this, I had made a copy of the RAM contents by running through the Exercise 02 option, so I have the original calibration data available. My question is: how to write this data to the RAM? (my scope does not have the GPIB option). Chuck Harris seemed to imply that it would be possible to write the saved calibration data to the RAM manually.
I look forward to your suggestions and hope to get this fine scope functioning again!
|
Hi Don, I'm here, and a few other places too. Typically, losing the calibration data while changing the battery happens when you forget that your soldering/desoldering iron tip is grounded, and you use a backup power supply that is also grounded... Sounds like you didn't do that. I don't know how to get the data back into a pre 50000 2465B. A long time ago, a retired (or former) tektronix person told me that it could be done... and indeed, it makes little sense to allow you to read the data and not actually be allowed to change it... I recall verifying that it works, but I don't recall the method anymore. I didn't concentrate on it mostly because I just recalibrate the things, which eliminates the need. I would say that it is long past time for someone to disassemble the ROM code for this beasty. It is really easy with the 6802 processor. There are a bunch of opensource disassemblers available. -Chuck Harris On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io" <donald_s_58103@...> wrote: Hello all,
I have posted this on the Tekscopes Forum, but I am posting it here
too in the hopes that Chuck Harris sees this because I have seen a
post of his on the Tekscopes Forum which might solve my problem.
I had a perfectly functioning 2467B scope (1989 vintage). After
reading about possible loss of calibration data due to the NVRAM
battery dying, I decided to put in a new battery (mine is the older
version, below 50000 serial #) which has the battery separate from
the NVRAM. The battery had a date code of 2689, so the battery is 35
years old. I did hook up a backup battery before removing the Lithium
battery and confirmed that pin 28 of the RAM chip had at least 3 V on
it from the backup battery after removal of the original battery.
After putting in the new replacement battery, I also changed out the
4 electrolytic capacitors on the A5 board. When I put the scope back
together and fired her up, I got the dreaded " Test 04 Fail 13"
message indicating corrupted or lost calibration data. Not sure how
this happened since I hooked up a backup battery before removing the
original battery. So, the very thing I was hoping to prevent happened
by my being proactive!
Before doing all this, I had made a copy of the RAM contents by
running through the Exercise 02 option, so I have the original
calibration data available. My question is: how to write this data to
the RAM? (my scope does not have the GPIB option). Chuck Harris
seemed to imply that it would be possible to write the saved
calibration data to the RAM manually.
I look forward to your suggestions and hope to get this fine scope
functioning again!
|
Chuck,
Thank you very much for your response.
As you correctly surmised, I took care to use an ungrounded soldering / desoldering iron and the backup battery was soldered to the PCB of the A5 board (I did not use a power supply). The only thing I can think of that might have caused my predicament is that I realized after the damage had been done, that I had forgotten to snip off the excess lead length on the LTC-7P battery terminals after soldering it to the PCB. I wonder if the leads shorted out on the chassis briefly while I was putting the A5 board back. I say briefly because after the board was put back, there was no evidence of a short and I had the correct voltage on pin 28 of the RAM chip (an NEC D4464C-15L)
BTW, my scope is a pre 50000 2467B, not a 2465B, but in this situation that probably does not make any difference.
Thanks again for your input
Don
|
Something you said earlier rang a bell in my feeble memory...? once upon a time I replaced the capacitors on a memory board.? The new, uncharged capacitors looked like a momentary short and dumped the memory.? In my case I was fortunate that a friend had the necessary program and was able to stuff it back in the memory.
Burt, K6OQK
toggle quoted message
Show quoted text
On April 6, 2024 9:51:02 PM GMT+08:00, "Don via groups.io" <donald_s_58103@...> wrote:
Chuck,
Thank you very much for your response.
As you correctly surmised, I took care to use an ungrounded soldering / desoldering iron and the backup battery was soldered to the PCB of the A5 board (I did not use a power supply). The only thing I can think of that might have caused my predicament is that I realized after the damage had been done, that I had forgotten to snip off the excess lead length on the LTC-7P battery terminals after soldering it to the PCB. I wonder if the leads shorted out on the chassis briefly while I was putting the A5 board back. I say briefly because after the board was put back, there was no evidence of a short and I had the correct voltage on pin 28 of the RAM chip (an NEC D4464C-15L)
BTW, my scope is a pre 50000 2467B, not a 2465B, but in this situation that probably does not make any difference.
Thanks again for your input
Don
|
As far as the A5 board goes, there is no difference between the 2467B and the 2465B. They are identical. There is another way that I was just reminded was done by someone on tekscopes. He wrote a simple monitor program that swapped one of the rom chips on his scope, and that program allowed him to key in the codes. The later B models can be fixed using a blank Dallas chip and an EPROM programmer. The only unique data is about 170 values. As I recall Siggy was working on disassembling the ROM for the 2465B. I wonder how far he got? -Chuck Harris On Sat, 06 Apr 2024 06:51:02 -0700 "Don via groups.io" <donald_s_58103@...> wrote: Chuck,
Thank you very much for your response.
As you correctly surmised, I took care to use an ungrounded soldering
/ desoldering iron and the backup battery was soldered to the PCB of
the A5 board (I did not use a power supply). The only thing I can
think of that might have caused my predicament is that I realized
after the damage had been done, that I had forgotten to snip off the
excess lead length on the LTC-7P battery terminals after soldering it
to the PCB. I wonder if the leads shorted out on the chassis briefly
while I was putting the A5 board back. I say briefly because after
the board was put back, there was no evidence of a short and I had
the correct voltage on pin 28 of the RAM chip (an NEC D4464C-15L)
BTW, my scope is a pre 50000 2467B, not a 2465B, but in this
situation that probably does not make any difference.
Thanks again for your input
Don
|
Hi Don, It occurs to me that if you have a linux machine, and a eprom burner, you could fix your problem by simply creating an eprom that has the 6808's jump table, and a two line program that copied a data declaration that contained the calibration constants into the NVRAM space where the constants belonged. There are lots of free assemblers in linux land that can create 6808 hex code that can be burned into eproms. Make one, and swap out the eprom that contains the vector table with your new vector table and copy program. -Chuck Harris On Sat, 6 Apr 2024 08:49:49 -0400 "Chuck Harris" <cfharris@...> wrote: Hi Don,
I'm here, and a few other places too.
Typically, losing the calibration data while changing the
battery happens when you forget that your soldering/desoldering
iron tip is grounded, and you use a backup power supply that is
also grounded... Sounds like you didn't do that.
I don't know how to get the data back into a pre 50000
2465B.
A long time ago, a retired (or former) tektronix person told
me that it could be done... and indeed, it makes little sense
to allow you to read the data and not actually be allowed to
change it... I recall verifying that it works, but I don't
recall the method anymore.
I didn't concentrate on it mostly because I just recalibrate
the things, which eliminates the need.
I would say that it is long past time for someone to disassemble
the ROM code for this beasty. It is really easy with the 6802
processor.
There are a bunch of opensource disassemblers available.
-Chuck Harris
On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io"
<donald_s_58103@...> wrote:
Hello all,
I have posted this on the Tekscopes Forum, but I am posting it here
too in the hopes that Chuck Harris sees this because I have seen a
post of his on the Tekscopes Forum which might solve my problem.
I had a perfectly functioning 2467B scope (1989 vintage). After
reading about possible loss of calibration data due to the NVRAM
battery dying, I decided to put in a new battery (mine is the older
version, below 50000 serial #) which has the battery separate from
the NVRAM. The battery had a date code of 2689, so the battery is 35
years old. I did hook up a backup battery before removing the
Lithium battery and confirmed that pin 28 of the RAM chip had at
least 3 V on it from the backup battery after removal of the
original battery. After putting in the new replacement battery, I
also changed out the 4 electrolytic capacitors on the A5 board.
When I put the scope back together and fired her up, I got the
dreaded " Test 04 Fail 13" message indicating corrupted or lost
calibration data. Not sure how this happened since I hooked up a
backup battery before removing the original battery. So, the very
thing I was hoping to prevent happened by my being proactive!
Before doing all this, I had made a copy of the RAM contents by
running through the Exercise 02 option, so I have the original
calibration data available. My question is: how to write this data
to the RAM? (my scope does not have the GPIB option). Chuck Harris
seemed to imply that it would be possible to write the saved
calibration data to the RAM manually.
I look forward to your suggestions and hope to get this fine scope
functioning again!
|
Hi Chuck,
Thanks for the suggestion. I do have a spare PC that I can install Linux on and I will be acquiring an EPROM burner shortly. However, I have no experience whatsoever with programming so terms like ¡°jump table¡± and ¡° data declaration ¡° go way over my head. I am willing to learn, though. Luckily, Mark (over on Tekscopes) will be collaborating with?me and it sounds like he is planning to do something similar to?what you are proposing. Regardless of the outcome, it will be an interesting and educational experience for me. Don
On Tuesday, April 9, 2024, 12:13 PM, Chuck Harris <cfharris@...> wrote: Hi Don,
It occurs to me that if you have a linux machine, and a eprom
burner, you could fix your problem by simply creating an
eprom that has the 6808's jump table, and a two line program
that copied a data declaration that contained the calibration
constants into the NVRAM space where the constants belonged.
There are lots of free assemblers in linux land that can create
6808 hex code that can be burned into eproms.
Make one, and swap out the eprom that contains the vector table
with your new vector table and copy program.
-Chuck Harris
On Sat, 6 Apr 2024 08:49:49 -0400 "Chuck Harris" < cfharris@...> wrote:
> Hi Don,
>
> I'm here, and a few other places too.
>
> Typically, losing the calibration data while changing the
> battery happens when you forget that your soldering/desoldering
> iron tip is grounded, and you use a backup power supply that is
> also grounded...? Sounds like you didn't do that.
>
> I don't know how to get the data back into a pre 50000
> 2465B.
>
> A long time ago, a retired (or former) tektronix person? told
> me that it could be done... and indeed, it makes little sense
> to allow you to read the data and not actually be allowed to
> change it... I recall verifying that it works, but I don't
> recall the method anymore.
>
> I didn't concentrate on it mostly because I just recalibrate
> the things, which eliminates the need.
>
> I would say that it is long past time for someone to disassemble
> the ROM code for this beasty.? It is really easy with the 6802
> processor.
>
> There are a bunch of opensource disassemblers available.
>
> -Chuck Harris
>
>
> On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io"
> <donald_s_58103@...> wrote:
> > Hello all,
> >
> > I have posted this on the Tekscopes Forum, but I am posting it here
> > too in the hopes that Chuck Harris sees this because I have seen a
> > post of his on the Tekscopes Forum which might solve my problem.
> >
> > I had a perfectly functioning 2467B scope (1989 vintage). After
> > reading about possible loss of calibration data due to the NVRAM
> > battery dying, I decided to put in a new battery (mine is the older
> > version, below 50000 serial #) which has the battery separate from
> > the NVRAM. The battery had a date code of 2689, so the battery is 35
> > years old. I did hook up a backup battery before removing the
> > Lithium battery and confirmed that pin 28 of the RAM chip had at
> > least 3 V on it from the backup battery after removal of the
> > original battery. After putting in the new replacement battery, I
> > also changed out the 4 electrolytic capacitors on the A5 board.
> > When I put the scope back together and fired her up, I got the
> > dreaded " Test 04 Fail 13" message indicating corrupted or lost
> > calibration data. Not sure how this happened since I hooked up a
> > backup battery before removing the original battery. So, the very
> > thing I was hoping to prevent happened by my being proactive!
> >
> > Before doing all this, I had made a copy of the RAM contents by
> > running through the Exercise 02 option, so I have the original
> > calibration data available. My question is: how to write this data
> > to the RAM? (my scope does not have the GPIB option). Chuck Harris
> > seemed to imply that it would be possible to write the saved
> > calibration data to the RAM manually.
> >
> > I look forward to your suggestions and hope to get this fine scope
> > functioning again!
> >
> >
> >
> >
> >?
>
>
>
>
>
>
|
I wish I could offer more direct help but time is short here currently.
However, I can offer that you may not need to get Linux running on a
machine just for this effort. Now, I am a nearly exclusive Linux user
and am always telling people to use Linux whenever they can however not
today :-)
I think that could be a very big side trip if you don't have any prior
experience in that space.
Instead, these very good cross-assemblers,
exist for Windows (and Linux) so you could skip the Linux step and run
the Motorola 8-bit assembler directly on Windows.
I have done Motorola 68xx 8-bit development since the mid-70's so I know
this architecture well. I agree that it should be a very simple, quick
bit of code to do this copy _if_ we know the memory map of the scope,
where the code needs to reside to execute, and where the NVRAM lives so
that we can write to it.
I have not looked but is the memory map documented in the 2465/67 service
manual or maybe somewhere else ??
I am happy to try to support this effort because I may need to do it
myself someday.
Chris N?JCF
toggle quoted message
Show quoted text
On Tuesday (04/09/2024 at 05:57PM +0000), Don via groups.io wrote: Hi Chuck,
Thanks for the suggestion. I do have a spare PC that I can install Linux on and I will be acquiring an EPROM burner shortly. However, I have no experience whatsoever with programming so terms like ¡°jump table¡± and ¡° data declaration ¡° go way over my head. I am willing to learn, though. Luckily, Mark (over on Tekscopes) will be collaborating with?me and it sounds like he is planning to do something similar to?what you are proposing. Regardless of the outcome, it will be an interesting and educational experience for me.
Don
On Tuesday, April 9, 2024, 12:13 PM, Chuck Harris <cfharris@...> wrote:
Hi Don,
It occurs to me that if you have a linux machine, and a eprom
burner, you could fix your problem by simply creating an
eprom that has the 6808's jump table, and a two line program
that copied a data declaration that contained the calibration
constants into the NVRAM space where the constants belonged.
There are lots of free assemblers in linux land that can create
6808 hex code that can be burned into eproms.
Make one, and swap out the eprom that contains the vector table
with your new vector table and copy program.
-Chuck Harris
On Sat, 6 Apr 2024 08:49:49 -0400 "Chuck Harris" <cfharris@...>
wrote:
Hi Don,
I'm here, and a few other places too.
Typically, losing the calibration data while changing the
battery happens when you forget that your soldering/desoldering
iron tip is grounded, and you use a backup power supply that is
also grounded...? Sounds like you didn't do that.
I don't know how to get the data back into a pre 50000
2465B.
A long time ago, a retired (or former) tektronix person? told
me that it could be done... and indeed, it makes little sense
to allow you to read the data and not actually be allowed to
change it... I recall verifying that it works, but I don't
recall the method anymore.
I didn't concentrate on it mostly because I just recalibrate
the things, which eliminates the need.
I would say that it is long past time for someone to disassemble
the ROM code for this beasty.? It is really easy with the 6802
processor.
There are a bunch of opensource disassemblers available.
-Chuck Harris
On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io"
<donald_s_58103@...> wrote:
Hello all,
I have posted this on the Tekscopes Forum, but I am posting it here
too in the hopes that Chuck Harris sees this because I have seen a
post of his on the Tekscopes Forum which might solve my problem.
I had a perfectly functioning 2467B scope (1989 vintage). After
reading about possible loss of calibration data due to the NVRAM
battery dying, I decided to put in a new battery (mine is the older
version, below 50000 serial #) which has the battery separate from
the NVRAM. The battery had a date code of 2689, so the battery is 35
years old. I did hook up a backup battery before removing the
Lithium battery and confirmed that pin 28 of the RAM chip had at
least 3 V on it from the backup battery after removal of the
original battery. After putting in the new replacement battery, I
also changed out the 4 electrolytic capacitors on the A5 board.
When I put the scope back together and fired her up, I got the
dreaded " Test 04 Fail 13" message indicating corrupted or lost
calibration data. Not sure how this happened since I hooked up a
backup battery before removing the original battery. So, the very
thing I was hoping to prevent happened by my being proactive!
Before doing all this, I had made a copy of the RAM contents by
running through the Exercise 02 option, so I have the original
calibration data available. My question is: how to write this data
to the RAM? (my scope does not have the GPIB option). Chuck Harris
seemed to imply that it would be possible to write the saved
calibration data to the RAM manually.
I look forward to your suggestions and hope to get this fine scope
functioning again!
?
--
Chris Elmquist
|
Chris,
Your other alternative is to just go ahead and re-calibrate it. That is what I did with mine, and although it takes some time, it isn't hard, just slog through the maintenance manual steps carefully. You do need the two calibration plug ins from Tek and a 500 series housing, which I bough fairly economically on eBay. Then if you don't have it already, you want Hugo Holden's brilliant document on the 2465B/7B. I've attached it. It includes some memory map info as well.
Reinhard Metz
On Tuesday, April 9, 2024 at 01:17:12 PM CDT, Chris Elmquist <chrise@...> wrote:
I wish I could offer more direct help but time is short here currently.
However, I can offer that you may not need to get Linux running on a
machine just for this effort.? Now, I am a nearly exclusive Linux user
and am always telling people to use Linux whenever they can however not
today :-)
I think that could be a very big side trip if you don't have any prior
experience in that space.
Instead, these very good cross-assemblers,
exist for Windows (and Linux) so you could skip the Linux step and run
the Motorola 8-bit assembler directly on Windows.
I have done Motorola 68xx 8-bit development since the mid-70's so I know
this architecture well.? I agree that it should be a very simple, quick
bit of code to do this copy _if_ we know the memory map of the scope,
where the code needs to reside to execute, and where the NVRAM lives so
that we can write to it.
I have not looked but is the memory map documented in the 2465/67 service
manual or maybe somewhere else ??
I am happy to try to support this effort because I may need to do it
myself someday.
Chris N?JCF
On Tuesday (04/09/2024 at 05:57PM +0000), Don via groups.io wrote: > Hi Chuck, > Thanks for the suggestion. I do have a spare PC that I can install Linux on and I will be acquiring an EPROM burner shortly. However, I have no experience whatsoever with programming so terms like ¡°jump table¡± and ¡° data declaration ¡° go way over my head. I am willing to learn, though. Luckily, Mark (over on Tekscopes) will be collaborating with?me and it sounds like he is planning to do something similar to?what you are proposing. Regardless of the outcome, it will be an interesting and educational experience for me. > > Don > On Tuesday, April 9, 2024, 12:13 PM, Chuck Harris < cfharris@...> wrote: > > Hi Don, > > It occurs to me that if you have a linux machine, and a eprom > burner, you could fix your problem by simply creating an > eprom that has the 6808's jump table, and a two line program > that copied a data declaration that contained the calibration > constants into the NVRAM space where the constants belonged. > > There are lots of free assemblers in linux land that can create > 6808 hex code that can be burned into eproms. > > Make one, and swap out the eprom that contains the vector table > with your new vector table and copy program. > > -Chuck Harris > > > On Sat, 6 Apr 2024 08:49:49 -0400 "Chuck Harris" < cfharris@...> > wrote: > > Hi Don, > > > > I'm here, and a few other places too. > > > > Typically, losing the calibration data while changing the > > battery happens when you forget that your soldering/desoldering > > iron tip is grounded, and you use a backup power supply that is > > also grounded...? Sounds like you didn't do that. > > > > I don't know how to get the data back into a pre 50000 > > 2465B. > > > > A long time ago, a retired (or former) tektronix person? told > > me that it could be done... and indeed, it makes little sense > > to allow you to read the data and not actually be allowed to > > change it... I recall verifying that it works, but I don't > > recall the method anymore. > > > > I didn't concentrate on it mostly because I just recalibrate > > the things, which eliminates the need. > > > > I would say that it is long past time for someone to disassemble > > the ROM code for this beasty.? It is really easy with the 6802 > > processor. > > > > There are a bunch of opensource disassemblers available. > > > > -Chuck Harris > > > > > > On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io" > > <donald_s_58103@...> wrote: > > > Hello all, > > > > > > I have posted this on the Tekscopes Forum, but I am posting it here > > > too in the hopes that Chuck Harris sees this because I have seen a > > > post of his on the Tekscopes Forum which might solve my problem. > > > > > > I had a perfectly functioning 2467B scope (1989 vintage). After > > > reading about possible loss of calibration data due to the NVRAM > > > battery dying, I decided to put in a new battery (mine is the older > > > version, below 50000 serial #) which has the battery separate from > > > the NVRAM. The battery had a date code of 2689, so the battery is 35 > > > years old. I did hook up a backup battery before removing the > > > Lithium battery and confirmed that pin 28 of the RAM chip had at > > > least 3 V on it from the backup battery after removal of the > > > original battery. After putting in the new replacement battery, I > > > also changed out the 4 electrolytic capacitors on the A5 board. > > > When I put the scope back together and fired her up, I got the > > > dreaded " Test 04 Fail 13" message indicating corrupted or lost > > > calibration data. Not sure how this happened since I hooked up a > > > backup battery before removing the original battery. So, the very > > > thing I was hoping to prevent happened by my being proactive! > > > > > > Before doing all this, I had made a copy of the RAM contents by > > > running through the Exercise 02 option, so I have the original > > > calibration data available. My question is: how to write this data > > > to the RAM? (my scope does not have the GPIB option). Chuck Harris > > > seemed to imply that it would be possible to write the saved > > > calibration data to the RAM manually. > > > > > > I look forward to your suggestions and hope to get this fine scope > > > functioning again! > > > > > > > > > > > > > > >? > > > > > > > > > > > > > > > > > > > > > > > > > > -- Chris Elmquist
|
On Tuesday (04/09/2024 at 08:41PM +0000), n49ex via groups.io wrote: Chris,
Your other alternative is to just go ahead and re-calibrate it. That is what I did with mine, and although it takes some time, it isn't hard, just slog through the maintenance manual steps carefully. You do need the two calibration plug ins from Tek and a 500 series housing, which I bough fairly economically on eBay. Then if you don't have it already, you want Hugo Holden's brilliant document on the 2465B/7B. I've attached it. It includes some memory map info as well.
Reinhard Metz Thanks Reinhard but I am not the OP with the issue-- just trying to offer help with the 68xx programming if neccessary. Hopefully Don will also see your response. I do have one of the required TM500 plug-ins I believe, the TG501, but I'm not up to date on what other is required. When my day comes to need such, I will go study up. Thanks again, Chris N?JCF On Tuesday, April 9, 2024 at 01:17:12 PM CDT, Chris Elmquist <chrise@...> wrote:
I wish I could offer more direct help but time is short here currently.
However, I can offer that you may not need to get Linux running on a
machine just for this effort.? Now, I am a nearly exclusive Linux user
and am always telling people to use Linux whenever they can however not
today :-)
I think that could be a very big side trip if you don't have any prior
experience in that space.
Instead, these very good cross-assemblers,
exist for Windows (and Linux) so you could skip the Linux step and run
the Motorola 8-bit assembler directly on Windows.
I have done Motorola 68xx 8-bit development since the mid-70's so I know
this architecture well.? I agree that it should be a very simple, quick
bit of code to do this copy _if_ we know the memory map of the scope,
where the code needs to reside to execute, and where the NVRAM lives so
that we can write to it.
I have not looked but is the memory map documented in the 2465/67 service
manual or maybe somewhere else ??
I am happy to try to support this effort because I may need to do it
myself someday.
Chris N?JCF
On Tuesday (04/09/2024 at 05:57PM +0000), Don via groups.io wrote:
Hi Chuck,
Thanks for the suggestion. I do have a spare PC that I can install Linux on and I will be acquiring an EPROM burner shortly. However, I have no experience whatsoever with programming so terms like ¡°jump table¡± and ¡° data declaration ¡° go way over my head. I am willing to learn, though. Luckily, Mark (over on Tekscopes) will be collaborating with?me and it sounds like he is planning to do something similar to?what you are proposing. Regardless of the outcome, it will be an interesting and educational experience for me.
Don
On Tuesday, April 9, 2024, 12:13 PM, Chuck Harris <cfharris@...> wrote:
Hi Don,
It occurs to me that if you have a linux machine, and a eprom
burner, you could fix your problem by simply creating an
eprom that has the 6808's jump table, and a two line program
that copied a data declaration that contained the calibration
constants into the NVRAM space where the constants belonged.
There are lots of free assemblers in linux land that can create
6808 hex code that can be burned into eproms.
Make one, and swap out the eprom that contains the vector table
with your new vector table and copy program.
-Chuck Harris
On Sat, 6 Apr 2024 08:49:49 -0400 "Chuck Harris" <cfharris@...>
wrote:
Hi Don,
I'm here, and a few other places too.
Typically, losing the calibration data while changing the
battery happens when you forget that your soldering/desoldering
iron tip is grounded, and you use a backup power supply that is
also grounded...? Sounds like you didn't do that.
I don't know how to get the data back into a pre 50000
2465B.
A long time ago, a retired (or former) tektronix person? told
me that it could be done... and indeed, it makes little sense
to allow you to read the data and not actually be allowed to
change it... I recall verifying that it works, but I don't
recall the method anymore.
I didn't concentrate on it mostly because I just recalibrate
the things, which eliminates the need.
I would say that it is long past time for someone to disassemble
the ROM code for this beasty.? It is really easy with the 6802
processor.
There are a bunch of opensource disassemblers available.
-Chuck Harris
On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io"
<donald_s_58103@...> wrote:
Hello all,
I have posted this on the Tekscopes Forum, but I am posting it here
too in the hopes that Chuck Harris sees this because I have seen a
post of his on the Tekscopes Forum which might solve my problem.
I had a perfectly functioning 2467B scope (1989 vintage). After
reading about possible loss of calibration data due to the NVRAM
battery dying, I decided to put in a new battery (mine is the older
version, below 50000 serial #) which has the battery separate from
the NVRAM. The battery had a date code of 2689, so the battery is 35
years old. I did hook up a backup battery before removing the
Lithium battery and confirmed that pin 28 of the RAM chip had at
least 3 V on it from the backup battery after removal of the
original battery. After putting in the new replacement battery, I
also changed out the 4 electrolytic capacitors on the A5 board.
When I put the scope back together and fired her up, I got the
dreaded " Test 04 Fail 13" message indicating corrupted or lost
calibration data. Not sure how this happened since I hooked up a
backup battery before removing the original battery. So, the very
thing I was hoping to prevent happened by my being proactive!
Before doing all this, I had made a copy of the RAM contents by
running through the Exercise 02 option, so I have the original
calibration data available. My question is: how to write this data
to the RAM? (my scope does not have the GPIB option). Chuck Harris
seemed to imply that it would be possible to write the saved
calibration data to the RAM manually.
I look forward to your suggestions and hope to get this fine scope
functioning again!
?
--
Chris Elmquist
-- Chris Elmquist
|
On Tue, Apr 9, 2024 at 11:17 AM, Chris Elmquist wrote:
....
Instead, these very good cross-assemblers,
exist for Windows (and Linux) so you could skip the Linux step and run
the Motorola 8-bit assembler directly on Windows.
I have done Motorola 68xx 8-bit development since the mid-70's so I know
this architecture well. I agree that it should be a very simple, quick
bit of code to do this copy _if_ we know the memory map of the scope,
where the code needs to reside to execute, and where the NVRAM lives so
that we can write to it.
I have not looked but is the memory map documented in the 2465/67 service
manual or maybe somewhere else ??
I am happy to try to support this effort because I may need to do it
myself someday.
Chris N?JCF
Chris, Thanks for the links to the windows versions of the assembler. I will try to find the memory map of the scope and will let you know if I find it. Don
|
On Tue, Apr 9, 2024 at 01:42 PM, n49ex wrote:
?
Chris,
?
Your other alternative is to just go ahead and re-calibrate it. That is what I did with mine, and although it takes some time, it isn't hard, just slog through the maintenance manual steps carefully. You do need the two calibration plug ins from Tek and a 500 series housing, which I bough fairly economically on eBay. Then if you don't have it already, you want Hugo Holden's brilliant document on the 2465B/7B. I've attached it. It includes some memory map info as well.
?
Reinhard Metz
?
Reinhard, I agree that re-calibrating the scope is the best option in this situation. However, I do not have the equipment to perform the calibration correctly, and I cannot justify the expense of sending the scope off to a calibration lab. Plus, it will be a nice learning experience to see if the saved cal data can be reloaded into the scope and will almost certainly be beneficial to others who may find themselves in this situation. Don
|
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.
The memory map for the 2465 is shown in figure 3-2 in the 2465B/2467B
Service manual.
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.
-Chuck Harris
Tue, 9 Apr 2024 13:17:02 -0500 "Chris Elmquist" <chrise@...>
wrote:
toggle quoted message
Show quoted text
I wish I could offer more direct help but time is short here
currently.
However, I can offer that you may not need to get Linux running on a
machine just for this effort. Now, I am a nearly exclusive Linux user
and am always telling people to use Linux whenever they can however
not today :-)
I think that could be a very big side trip if you don't have any prior
experience in that space.
Instead, these very good cross-assemblers,
exist for Windows (and Linux) so you could skip the Linux step and run
the Motorola 8-bit assembler directly on Windows.
I have done Motorola 68xx 8-bit development since the mid-70's so I
know this architecture well. I agree that it should be a very
simple, quick bit of code to do this copy _if_ we know the memory map
of the scope, where the code needs to reside to execute, and where
the NVRAM lives so that we can write to it.
I have not looked but is the memory map documented in the 2465/67
service manual or maybe somewhere else ??
I am happy to try to support this effort because I may need to do it
myself someday.
Chris N?JCF
On Tuesday (04/09/2024 at 05:57PM +0000), Don via groups.io wrote:
Hi Chuck,
Thanks for the suggestion. I do have a spare PC that I can install
Linux on and I will be acquiring an EPROM burner shortly. However,
I have no experience whatsoever with programming so terms like
¡°jump table¡± and ¡° data declaration ¡° go way over my head. I am
willing to learn, though. Luckily, Mark (over on Tekscopes) will be
collaborating with?me and it sounds like he is planning to do
something similar to?what you are proposing. Regardless of the
outcome, it will be an interesting and educational experience for
me.
Don
On Tuesday, April 9, 2024, 12:13 PM, Chuck Harris
<cfharris@...> wrote:
Hi Don,
It occurs to me that if you have a linux machine, and a eprom
burner, you could fix your problem by simply creating an
eprom that has the 6808's jump table, and a two line program
that copied a data declaration that contained the calibration
constants into the NVRAM space where the constants belonged.
There are lots of free assemblers in linux land that can create
6808 hex code that can be burned into eproms.
Make one, and swap out the eprom that contains the vector table
with your new vector table and copy program.
-Chuck Harris
On Sat, 6 Apr 2024 08:49:49 -0400 "Chuck Harris"
<cfharris@...> wrote:
Hi Don,
I'm here, and a few other places too.
Typically, losing the calibration data while changing the
battery happens when you forget that your soldering/desoldering
iron tip is grounded, and you use a backup power supply that is
also grounded...? Sounds like you didn't do that.
I don't know how to get the data back into a pre 50000
2465B.
A long time ago, a retired (or former) tektronix person? told
me that it could be done... and indeed, it makes little sense
to allow you to read the data and not actually be allowed to
change it... I recall verifying that it works, but I don't
recall the method anymore.
I didn't concentrate on it mostly because I just recalibrate
the things, which eliminates the need.
I would say that it is long past time for someone to disassemble
the ROM code for this beasty.? It is really easy with the 6802
processor.
There are a bunch of opensource disassemblers available.
-Chuck Harris
On Fri, 05 Apr 2024 16:08:37 -0700 "Don via groups.io"
<donald_s_58103@...> wrote:
Hello all,
I have posted this on the Tekscopes Forum, but I am posting it
here too in the hopes that Chuck Harris sees this because I
have seen a post of his on the Tekscopes Forum which might
solve my problem.
I had a perfectly functioning 2467B scope (1989 vintage). After
reading about possible loss of calibration data due to the NVRAM
battery dying, I decided to put in a new battery (mine is the
older version, below 50000 serial #) which has the battery
separate from the NVRAM. The battery had a date code of 2689,
so the battery is 35 years old. I did hook up a backup battery
before removing the Lithium battery and confirmed that pin 28
of the RAM chip had at least 3 V on it from the backup battery
after removal of the original battery. After putting in the new
replacement battery, I also changed out the 4 electrolytic
capacitors on the A5 board. When I put the scope back together
and fired her up, I got the dreaded " Test 04 Fail 13" message
indicating corrupted or lost calibration data. Not sure how
this happened since I hooked up a backup battery before
removing the original battery. So, the very thing I was hoping
to prevent happened by my being proactive!
Before doing all this, I had made a copy of the RAM contents by
running through the Exercise 02 option, so I have the original
calibration data available. My question is: how to write this
data to the RAM? (my scope does not have the GPIB option).
Chuck Harris seemed to imply that it would be possible to write
the saved calibration data to the RAM manually.
I look forward to your suggestions and hope to get this fine
scope functioning again!
?
|
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 -- Chris Elmquist
|
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
|
Ok, here's the drill. I think the best/easiest way for Don to get his codes back into his 2467B's pre 50K battery backed RAM would be to burn a little code snippet into a 27128 EPROM, and run it. The 6800 starts up at the last 2 addresses in memory space, as far as I can tell, so 0xfffe and 0xffff should contain a jump into the start of our code snippet... The next 512 bytes should be the calibration constants, as were read using the EXER02 routine, by Don. Then comes the snippet that gets branched to. It should be a simple loop that executes 256 times. It reads a word (16bits) from the calibration constant table, and writes it into the RAM address range 0x7e00 through 0x7fff. To use this little hack, all of this code, and Don's calibration constants should be edited into an EPROM burner's buffer, creating the bootstrap for Don's 2467B. Remember, the 6800 is a big-endian machine. I know Chris indicated he could do this. Fame and goodwill awaits the first person to write and verify this little code snippet to the tekscopes groups... -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
|
Hi Guys,
Give me a few days to research and dig into this-- $DAYJOB in the
way for now but I will do as soon as I can.
The program is very simple. I just need to confirm execution address
and a little more about the vectors that reside at the end of memory.
$FFFE,$FFFF is certainly the reset vector but below that there are NMI
and IRQ vectors too that probably also need to be filled in-- at
the very least, if the system uses NMI for anything, we'll need to
point that at an RTI instruction.
I think the constants can reside anywhere in our PROM, like right at
the end of the copy routine for example, and it is just the destination
address in RAM to which we are copying them that is important.
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.
In any case, thanks for the "bootstrap" Chuck and I'll do my best to get
'er done. I should be able to assemble the code for folks and provide
S-records and listings so you can get them into a device programmer
however you see fit.
If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)
I don't expect to do much for blinking LEDs or anything so I think how
this would work is that you power off the scope, swap out the factory
27128 EPROM with our hack EPROM, power on the scope, count to 10 maybe?,
power it back off, swap the EPROMs again, power back on, and when the
scope comes up, go check if your cal constants are in there correctly
using the EXER02 routine that Chuck mentions below. Does that seem
feasible?
Chris N?JCF
toggle quoted message
Show quoted text
On Thursday (04/11/2024 at 11:21PM -0400), Chuck Harris wrote: Ok, here's the drill.
I think the best/easiest way for Don to get his codes back into his
2467B's pre 50K battery backed RAM would be to burn a little code
snippet into a 27128 EPROM, and run it.
The 6800 starts up at the last 2 addresses in memory space, as far as
I can tell, so 0xfffe and 0xffff should contain a jump into the start
of our code snippet...
The next 512 bytes should be the calibration constants, as were read
using the EXER02 routine, by Don.
Then comes the snippet that gets branched to. It should be a simple
loop that executes 256 times. It reads a word (16bits) from the
calibration constant table, and writes it into the RAM address range
0x7e00 through 0x7fff.
To use this little hack, all of this code, and Don's calibration
constants should be edited into an EPROM burner's buffer, creating the
bootstrap for Don's 2467B.
Remember, the 6800 is a big-endian machine.
I know Chris indicated he could do this.
Fame and goodwill awaits the first person to write and verify
this little code snippet to the tekscopes groups...
-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
--
Chris Elmquist
|
Hi Chris, The EPROMS are fully decoded. U2260 goes from 0xc000 to 0xffff. NMI is generated when the power switch is turned off. It should be perfectly ok to drop into a halt or loop. No status information of any kind, we want this to be as easy as possible to hand load into a prom burner's buffer. I would like this to be purely machine code, with everything in a contiguous blob ending at 0xffff, if possible. We can't assume that everyone using this will have an assembler, or even know what one is. And we don't want you to be on the hook forever creating little custom S-Rec blobs. Ideally, the blob should start with the calibration data, in order of presentation from EXER 02, which is 0 to 0x1ff, high byte, low byte... And then it should go right into the executable all the way to the jump vector at the end. EXER 02 starts at calibration constant 0, and goes through 0xff. The constants are displayed as hex words, in high/low byte order. eg. 0 -> HHLL 1 -> HHLL In other words, I don't want people to have to put a little code at this address, and a little data at that address, and something else else over there... I want you to be able to tell them to: 1) go to address 0x???? 2) enter your EXER 02 data (0, 1, 2, .... FF) 3) enter blah, blah, blah (through to 0xffff). 4) install EPROM in socket U2260. 5) turn on the scope and count to 10. 6) turn off the scope, and put the original EPROM back into U2260. Your scope is now back to its original calibration. I don't mean to sound autocratic, but I come from the days when every computer had a bunch of switches on the front panel, and entering boot loaders, "fat finger" style was how it was done. It has to be simple, or it will get done wrong. -Chuck Harris On Fri, 12 Apr 2024 08:44:30 -0500 "Chris Elmquist" <chrise@...> wrote: Hi Guys,
Give me a few days to research and dig into this-- $DAYJOB in the
way for now but I will do as soon as I can.
The program is very simple. I just need to confirm execution address
and a little more about the vectors that reside at the end of memory.
$FFFE,$FFFF is certainly the reset vector but below that there are NMI
and IRQ vectors too that probably also need to be filled in-- at
the very least, if the system uses NMI for anything, we'll need to
point that at an RTI instruction.
I think the constants can reside anywhere in our PROM, like right at
the end of the copy routine for example, and it is just the
destination address in RAM to which we are copying them that is
important.
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.
In any case, thanks for the "bootstrap" Chuck and I'll do my best to
get 'er done. I should be able to assemble the code for folks and
provide S-records and listings so you can get them into a device
programmer however you see fit.
If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)
I don't expect to do much for blinking LEDs or anything so I think how
this would work is that you power off the scope, swap out the factory
27128 EPROM with our hack EPROM, power on the scope, count to 10
maybe?, power it back off, swap the EPROMs again, power back on, and
when the scope comes up, go check if your cal constants are in there
correctly using the EXER02 routine that Chuck mentions below. Does
that seem feasible?
Chris N?JCF
On Thursday (04/11/2024 at 11:21PM -0400), Chuck Harris wrote:
Ok, here's the drill.
I think the best/easiest way for Don to get his codes back into his
2467B's pre 50K battery backed RAM would be to burn a little code
snippet into a 27128 EPROM, and run it.
The 6800 starts up at the last 2 addresses in memory space, as far
as I can tell, so 0xfffe and 0xffff should contain a jump into the
start of our code snippet...
The next 512 bytes should be the calibration constants, as were read
using the EXER02 routine, by Don.
Then comes the snippet that gets branched to. It should be a simple
loop that executes 256 times. It reads a word (16bits) from the
calibration constant table, and writes it into the RAM address range
0x7e00 through 0x7fff.
To use this little hack, all of this code, and Don's calibration
constants should be edited into an EPROM burner's buffer, creating
the bootstrap for Don's 2467B.
Remember, the 6800 is a big-endian machine.
I know Chris indicated he could do this.
Fame and goodwill awaits the first person to write and verify
this little code snippet to the tekscopes groups...
-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
|
Hi Chuck,
Yup. Totally get it.
I only mentioned S-records because that's what you get out of the
assembler along with the listing in hex. I'll also convert to your
"blob" format, which is just a hex dump from beginning to end.
No problem "packing" the table of constants and the program together
and locating all of it near the end of the PROM region. Will make it so.
Chris
toggle quoted message
Show quoted text
On Friday (04/12/2024 at 10:48AM -0400), Chuck Harris wrote: Hi Chris,
The EPROMS are fully decoded. U2260 goes from 0xc000 to 0xffff.
NMI is generated when the power switch is turned off. It should
be perfectly ok to drop into a halt or loop.
No status information of any kind, we want this to be as easy as
possible to hand load into a prom burner's buffer.
I would like this to be purely machine code, with everything in a
contiguous blob ending at 0xffff, if possible.
We can't assume that everyone using this will have an assembler, or
even know what one is. And we don't want you to be on the hook
forever creating little custom S-Rec blobs.
Ideally, the blob should start with the calibration data, in order
of presentation from EXER 02, which is 0 to 0x1ff, high byte, low
byte... And then it should go right into the executable all the way
to the jump vector at the end.
EXER 02 starts at calibration constant 0, and goes through 0xff.
The constants are displayed as hex words, in high/low byte order.
eg. 0 -> HHLL
1 -> HHLL
In other words, I don't want people to have to put a little code at
this address, and a little data at that address, and something else
else over there...
I want you to be able to tell them to:
1) go to address 0x????
2) enter your EXER 02 data (0, 1, 2, .... FF)
3) enter blah, blah, blah (through to 0xffff).
4) install EPROM in socket U2260.
5) turn on the scope and count to 10.
6) turn off the scope, and put the original EPROM back into U2260.
Your scope is now back to its original calibration.
I don't mean to sound autocratic, but I come from the days when
every computer had a bunch of switches on the front panel, and
entering boot loaders, "fat finger" style was how it was done.
It has to be simple, or it will get done wrong.
-Chuck Harris
On Fri, 12 Apr 2024 08:44:30 -0500 "Chris Elmquist" <chrise@...>
wrote:
Hi Guys,
Give me a few days to research and dig into this-- $DAYJOB in the
way for now but I will do as soon as I can.
The program is very simple. I just need to confirm execution address
and a little more about the vectors that reside at the end of memory.
$FFFE,$FFFF is certainly the reset vector but below that there are NMI
and IRQ vectors too that probably also need to be filled in-- at
the very least, if the system uses NMI for anything, we'll need to
point that at an RTI instruction.
I think the constants can reside anywhere in our PROM, like right at
the end of the copy routine for example, and it is just the
destination address in RAM to which we are copying them that is
important.
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.
In any case, thanks for the "bootstrap" Chuck and I'll do my best to
get 'er done. I should be able to assemble the code for folks and
provide S-records and listings so you can get them into a device
programmer however you see fit.
If Don wants to send me his 256 word cal table, I'll make the first
version of the code just for him! :-)
I don't expect to do much for blinking LEDs or anything so I think how
this would work is that you power off the scope, swap out the factory
27128 EPROM with our hack EPROM, power on the scope, count to 10
maybe?, power it back off, swap the EPROMs again, power back on, and
when the scope comes up, go check if your cal constants are in there
correctly using the EXER02 routine that Chuck mentions below. Does
that seem feasible?
Chris N?JCF
On Thursday (04/11/2024 at 11:21PM -0400), Chuck Harris wrote:
Ok, here's the drill.
I think the best/easiest way for Don to get his codes back into his
2467B's pre 50K battery backed RAM would be to burn a little code
snippet into a 27128 EPROM, and run it.
The 6800 starts up at the last 2 addresses in memory space, as far
as I can tell, so 0xfffe and 0xffff should contain a jump into the
start of our code snippet...
The next 512 bytes should be the calibration constants, as were read
using the EXER02 routine, by Don.
Then comes the snippet that gets branched to. It should be a simple
loop that executes 256 times. It reads a word (16bits) from the
calibration constant table, and writes it into the RAM address range
0x7e00 through 0x7fff.
To use this little hack, all of this code, and Don's calibration
constants should be edited into an EPROM burner's buffer, creating
the bootstrap for Don's 2467B.
Remember, the 6800 is a big-endian machine.
I know Chris indicated he could do this.
Fame and goodwill awaits the first person to write and verify
this little code snippet to the tekscopes groups...
-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
--
Chris Elmquist
|
Hi Chris, I knew you would understand. 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. 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. -Chuck Harris On Fri, 12 Apr 2024 09:59:08 -0500 "Chris Elmquist" <chrise@...> wrote: Hi Chuck,
Yup. Totally get it.
I only mentioned S-records because that's what you get out of the
assembler along with the listing in hex. I'll also convert to your
"blob" format, which is just a hex dump from beginning to end.
No problem "packing" the table of constants and the program together
and locating all of it near the end of the PROM region. Will make it
so.
Chris
On Friday (04/12/2024 at 10:48AM -0400), Chuck Harris wrote:
Hi Chris,
The EPROMS are fully decoded. U2260 goes from 0xc000 to 0xffff.
NMI is generated when the power switch is turned off. It should
be perfectly ok to drop into a halt or loop.
No status information of any kind, we want this to be as easy as
possible to hand load into a prom burner's buffer.
I would like this to be purely machine code, with everything in a
contiguous blob ending at 0xffff, if possible.
We can't assume that everyone using this will have an assembler, or
even know what one is. And we don't want you to be on the hook
forever creating little custom S-Rec blobs.
Ideally, the blob should start with the calibration data, in order
of presentation from EXER 02, which is 0 to 0x1ff, high byte, low
byte... And then it should go right into the executable all the way
to the jump vector at the end.
EXER 02 starts at calibration constant 0, and goes through 0xff.
The constants are displayed as hex words, in high/low byte order.
eg. 0 -> HHLL
1 -> HHLL
In other words, I don't want people to have to put a little code at
this address, and a little data at that address, and something else
else over there...
I want you to be able to tell them to:
1) go to address 0x????
2) enter your EXER 02 data (0, 1, 2, .... FF)
3) enter blah, blah, blah (through to 0xffff).
4) install EPROM in socket U2260.
5) turn on the scope and count to 10.
6) turn off the scope, and put the original EPROM back into U2260.
Your scope is now back to its original calibration.
I don't mean to sound autocratic, but I come from the days when
every computer had a bunch of switches on the front panel, and
entering boot loaders, "fat finger" style was how it was done.
It has to be simple, or it will get done wrong.
-Chuck Harris
On Fri, 12 Apr 2024 08:44:30 -0500 "Chris Elmquist"
<chrise@...> wrote:
Hi Guys,
Give me a few days to research and dig into this-- $DAYJOB in the
way for now but I will do as soon as I can.
The program is very simple. I just need to confirm execution
address and a little more about the vectors that reside at the
end of memory.
$FFFE,$FFFF is certainly the reset vector but below that there
are NMI and IRQ vectors too that probably also need to be filled
in-- at the very least, if the system uses NMI for anything,
we'll need to point that at an RTI instruction.
I think the constants can reside anywhere in our PROM, like right
at the end of the copy routine for example, and it is just the
destination address in RAM to which we are copying them that is
important.
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.
In any case, thanks for the "bootstrap" Chuck and I'll do my best
to get 'er done. I should be able to assemble the code for folks
and provide S-records and listings so you can get them into a
device programmer however you see fit.
If Don wants to send me his 256 word cal table, I'll make the
first version of the code just for him! :-)
I don't expect to do much for blinking LEDs or anything so I
think how this would work is that you power off the scope, swap
out the factory 27128 EPROM with our hack EPROM, power on the
scope, count to 10 maybe?, power it back off, swap the EPROMs
again, power back on, and when the scope comes up, go check if
your cal constants are in there correctly using the EXER02
routine that Chuck mentions below. Does that seem feasible?
Chris N?JCF
On Thursday (04/11/2024 at 11:21PM -0400), Chuck Harris wrote:
Ok, here's the drill.
I think the best/easiest way for Don to get his codes back into
his 2467B's pre 50K battery backed RAM would be to burn a
little code snippet into a 27128 EPROM, and run it.
The 6800 starts up at the last 2 addresses in memory space, as
far as I can tell, so 0xfffe and 0xffff should contain a jump
into the start of our code snippet...
The next 512 bytes should be the calibration constants, as were
read using the EXER02 routine, by Don.
Then comes the snippet that gets branched to. It should be a
simple loop that executes 256 times. It reads a word (16bits)
from the calibration constant table, and writes it into the RAM
address range 0x7e00 through 0x7fff.
To use this little hack, all of this code, and Don's calibration
constants should be edited into an EPROM burner's buffer,
creating the bootstrap for Don's 2467B.
Remember, the 6800 is a big-endian machine.
I know Chris indicated he could do this.
Fame and goodwill awaits the first person to write and verify
this little code snippet to the tekscopes groups...
-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
|
Burt K6OQK