| Products > Test Equipment |
| Just got a Tek 2465A, couple questions (how I screwed the calibration data)!! |
| << < (9/17) > >> |
| MarkL:
--- Quote from: alpher on March 28, 2018, 03:57:56 pm ---Reacalibration easier? :o Gues if I had necessary gear, maybe. Anyway here's the z01z's calibration data in a differnt format, (guess you cannot color within code brackets). I marked the firts AA contants, according to the service manual there shoul be AA 14bit constants in the 2465A ram CMOS memory. What worries me is that starting from 6F there are some bigger that that ? :-// Should I worry or the manual is wrong here? --- End quote --- It wouldn't be the first time the service manual was wrong, and in that paragraph in particular. At least all the data from 0x01 to 0x6E is within range, which is where the manual says parity is computed. I would say try z01z's data and see what happens. It might be good to check the parity on 0x01 to 0x6E for a little bit of a verification on the data. |
| MarkL:
--- Quote from: alpher on March 28, 2018, 04:19:55 pm ---I don't think these are settings of the scope as read the memory many times after I changed the settings, powered it up and down and the last 512 bytes never change. There's a lot of changes in the lower memory locations though. I've included a few of the reads in the attached zip file. --- End quote --- Ok, so it's storing the settings elsewhere. It doesn't surprise me that other parts of memory are changing. Other than the 128 bytes in the 6808, this is the THE memory for the system, so the processor is doing whatever the processor usually does in the SRAM. I agree with your suspicion that the last 512 bytes have been reserved for NVRAM functions, but since the whole memory is battery-backed, the firmware could stick non-volatile values anywhere it wants. In these dumps, location 0x1e00 is always 0xef. I thought you said it was changing? Or is there some specific action that makes it change? Also note that it's an 8-bit value, which is consistent with Tek's checksum algorithm. Let me rephrase that... Of course it's 8-bit because that's all I'm looking at. Duh. But it's still a consistent 0xef 0x22 in all of the dumps. |
| MarkL:
--- Quote from: MarkL on March 28, 2018, 04:32:50 pm ---... I would say try z01z's data and see what happens. It might be good to check the parity on 0x01 to 0x6E for a little bit of a verification on the data. --- End quote --- Just wrote a quick check. The parity is good on 0x01 to 0x6E. FYI. I can't seem to derive the checksum, though. It may take disassembling the code for the 2465A. |
| alpher:
0x1e00 is where the calibration constants start, from there on to the very end 512 bytes or 256 words (14bit words if to believe the manual ;D ). I'm going to try z01z data mybe even today, anxious to see the outcome . |
| MarkL:
I did a little disassembly of a 2465A EPROM (160-3303-06) and found checksum code similar to the 2465. It appears to be checksumming the calibration values from 0x11 to 0xAA, with special processing for locations up to and including 0x6E. The special processing would be the parity checking. Unfortunately, I still can't get the computed checksum to match. Without an actual 2465A to watch with a logic analyzer, it's getting too much in the weeds to figure out. It could be something I'm doing wrong (very likely), or there's an error in the data (possible). If anyone else has a second set of Exerciser 02 data from a 2465A I could look at, please post. Good luck with z01z's data. Let us know what happens... |
| Navigation |
| Message Index |
| Next page |
| Previous page |