开云体育

Chris, That is exactly what I did long before the idea of writing back the cal data to the RAM originated. Based on some posts that suggested that instead of doing a full calibration, I should just do

Hi Don, The battery backed ram chip, or nvram in the case of the Dallas part, is used for two things: 1) calibration constants 2) ordinary read/write memory for microprocessor. They did the first

I think this could be an issue if they were computing a checksum over the cal constants and storing that som

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

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

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

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

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

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

Hi John, Any hex editor will do. Most eprom programmers come with one in some form. -Chuck Harris <john@...> wrote:

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

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 :-) Hmm. Interesting. I will take a look at the

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

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

OK. So I guess we won't support those for this effort. Right. Like a SPI interface except a lot older. These are also used in DEC VT100 terminals that I try to keep running here. So, we can work on

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

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

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.

Don't forget Tekwiki! Raymond

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