Transforming TDS7x4A into TDS7x4C - Example TDS784A into TDS784C - Page 1
Forum section: electronics / testgear

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 11, 2025, 05:50:31 am
content: After purchasing, repairing, using and upgrading different TDSxxx (serie C and D) running with 68040 processor board since 2019, I got interested recently on earlier models (TDS510A and TDS784A) which do run with 68020 processor board.Visually speaking, we can see that the acquisition board of a TDS784A or TDS744A or TDS724A has exactly the same hardware as any TDS500/700C serie model except the U600 chip firmware (acquisition processor MC68HC705B5CFN). Since I have some spare processor boards (68020 or 68040) running with either 1.1e or 4.2.1e or 5.2e then I thought to try my only TDS784A acquisition board with 68040 (firmware 5.2e) which now works partially as a TDS784C.The only issue seems to be the specific format or storage data structure in the EEPROM which seems to be dependent on the processor firmware version. When I boot the modified TDS784A with 68040 processor board under 5.2e then it will state fail++processor then upon checking LOG Error file, I clearly see to be related to the famous EEPROM fault (either EEPROM is dead or has incorrect data, CRC).If I neutralize detailed boot testing by switch DIP #3 then no error at boot plus I'm able to run the SPC with PASS result, the oscillscope works fine including test with real signals, trigger as a new born TDS784C. Now here is the catch, as reportedin this fundamental postyears ago, in the case of failed EEPROM the oscilloscope will use a general purpose approximate values for EEPROM.Since the EEPROM content is super critical and generated at factory level, do you know if there is a way to transform or transcode say the EEPROM depending the firmware version it was designed ?On a side note, the very same issue of EEPROM data structure happens for many users who upgraded their TDS7x4A from 1.x to 4.2.x where the symptom or failure was the same, namely EEPROM integrity violation. When I look at the content of EEPROM from 1.x firmware, 4.x firmware and 5.x firmware there is clearly some tiny difference but my hypothesis is that tektronix engineer would not require to run a full FAS calibration dependent of the main firmware.Another point is to know exactly what is the formulae to compute the CRC of the EEPROM, does anybody knows how it works ?As far as I know, there was a member who provideda java script to compute the CRC of EEPROM and NVRAMbut the algorithm is provided unfortunately.By the way, even if my transformed TDS784A into a TDS784A misses the correct EEPROM factory calibration constant, it runs much faster and quite good so the challenge would be to hack or fool or regenerate by software an EEPROM valid content for 5.x firmware. Unless the issue is about the U600 acquisition processor which need to be revised from 160-7851-03 to 160-7851-04 but unless I'm wrong, I suspect this local processor is really to pass information between the processor board and then acquisition board.

author: TERRA Operative
author_rank: Super Contributor
timestamp: May 11, 2025, 12:51:23 pm
content: I can't help with the EEPROM or software side of things, but AFAIK, the main revision number of the firmware version is tied to the Processor Board version.So a Processor Board that requires firmware v1.x isn't fully compatible with firmware v5.x as that is for a later Processor Board. I.e. the major firmware number is tied to the Processor PCB version.I assume this means there would have been a number of parallel firmware versions in play back when these scopes were in production.As for the calibration/adjustment, using the official Field Adjustment Software you can do a full adjustment sequence, or just certain stages of the cal and not others as required (I got it working on my old PC this week, finally) but I saw no utility for converting cal data or anything like you are asking about in the Field Adjustment Software.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 11, 2025, 01:49:42 pm
content: Quote from: TERRA Operative on May 11, 2025, 12:51:23 pmI think you misunderstood, here I'm able now to run the ACQUISITION board of my TDS784A now with a PROCESSOR board (68040 running under 5.x). This very same ACQUISITION board was initially working with PROCESSOR board (68020 running under 4.2.x) as legit manufactured TDS784A oscilloscope.So the topic or hack or whatever project is to actually re-use the processor board initially working as TDS784A into a TDS784C. For this task, one needs to use a 68040 processor board instead of 68020 processor. As a reminder, 68020 processor board can only run TDSxxx/A/B/no suffix under 1.x 2.x and 4.x whereas 68040 processor board can only run TDSxxx/C/D under 5.x or 6.x or 7.xPlease check again visually the design and component of any TDS7x4A acquisition board, you'll see it is the same as TDS500/700/C/D so the topic is to how to software interface with 68040 processor boards whereas the original design was for 68020 processor boards. It really works fine, maybe not intended by tektronix engineer, no idea but it only requires to update the EEPROM structure.I'm trying to avoid running the Field Adjustment Software so my hope is to decode or learn exactly the data structure of EEPROM depending on what processor board expect to be valid when 4.X then 5.xAs a reminder, other users of TDS744A and TDS784A did have same issue with EEPROM data structure when upgrading from 1.x to 4.x

author: fenugrec
author_rank: Frequent Contributor
timestamp: May 11, 2025, 02:58:56 pm
content: I could open my firmware RE notes on 1.1e, I don't recall how much of the eeprom structure I explored. NVRAM I remember doing a fair amount of work on the Librarian* functions.In the meantime, I can offer a few incremental EEPROM dumps taken at multiple stages when I ran the FAS process a few years ago, on a 744A with fw 1.1e. May or may not be useful, but it's only a few kB so here it is.

author: TERRA Operative
author_rank: Super Contributor
timestamp: May 11, 2025, 02:59:42 pm
content: Aaahhh, okok. I get you now. I should read more carefully....I still can't help much with firmware/software/etc hacking (software is my weakness) but it would make sense that the later scopes had different cal data due to 'reasons'.I can dump out EEPROM data from various scopes I have on hand if it would help?

author: fenugrec
author_rank: Frequent Contributor
timestamp: May 11, 2025, 03:43:47 pm
content: Quote from: fenugrec on May 11, 2025, 02:58:56 pmHmm well I didn't delve much, but the built-in symbol tables (thanks vxworks) make things soooo much easier :Code:Outgoing References - _gtlX24c02BcopyFUN_01191152_readSerialNVRamByte_readSerialNVRamBook_writeSerialNVRamBook_logMsg*********Outgoing References - _indirectLibVerifyExtendedCal_libVerifyExtendedCal_libVerifyOrSave_verifyCheckSum_libCheckSum_libCheckSumMem_libLoadInitValues_scopeErrorLogAdd_indirectStorageStartup_libMonitor_sysClkRateGet_taskDelay_verifyLibCheckSum_logFirstByteWhichDiffers_libErrorAdd_taskSpawn**********short _libCheckSumMem(short *src,uint num_bytes) {uint cnt;short i16_sum;i16_sum = 0;cnt = 0;if (num_bytes >> 1 != 0) {do {i16_sum = *src + i16_sum;cnt = cnt + 1;src = src + 1;} while (cnt < num_bytes >> 1);}return i16_sum;}The 'ExtendedCal' functions refer to the data saved in the two 24c02 eeproms. Checksum looks like a trivial 16-bit sum; not sure on what blocks it applies.As I recall now while looking again,there are "Librarian" descriptors such as 'hwAccountantLibrarian', 'calConstantLibrarian', 'extendedCalLibrarian' etc, with their associated read/write functions, data size and structure, etc.This is a great beginner-intermediate RE project; it disassembles fairly cleanly, tons of symbols that identify funcs and data; now it just needs time - something I cannot provide unfortunately. If someone's really interested I can help get started, maybe make a video or writeup, but that's about it. I did start a 'firmware RE' thread a few years ago but there was little interest.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 11, 2025, 05:11:43 pm
content: Many thanks@fenugrecfor sharing info and guidance.Would you have by any chance some EEPROM (U1052/U1055) copies of TDS7x4 running under 4.x so we could compare the data structure ?Many thanks also to@TERRA, same question about copies of EEPROM ?The first idea and comparison if you check the attached picture I've just made, we can clearly see that EEPROM structure is related to 1.x or 4.x or 5.x or 6.xIn all cases, we always have first 8 bytes set to ZERO then what seems to be a signature, look at the end of each file for the last 4 bytes. Of course then in between the million dollar question or reverse engineering topic to find out what field is for what (i.e. chain of 4 specific parameters for each channel, gains, offset...).With 1.x firmware, the EEPROM always ends with00 00 01 BAWith 4.x firmware, the EEPROM always ends with00 00 01 CAplus 16 more bytesWith 5.x or 6.x firmware, the EEPROM always ends with00 00 01 CEplus 24 more bytesI need to check some more stored EEPROM in my computer after acquiring and repairing some TDS since 2019 but what I miss is more EEPROM examples when 4.x so we could eventually guess the data structure (the only EEPROM content is mine TDS784A). What is crystal clear after reading and interviewing some TDSxxx owners, the 1.x structure is different than 4.x structure then again different from 5.x structure which explains log file errors.I'm pretty convinced that my real test of running the TDS784A acquisition board with a 68040 processor board under 5.x proves the HW/SW of the board is cross compatible between 4.x and 5.x because I try different signals, different frequencies and the mutated TDS784C from TDS784A works fine. Only problem is the EEPROM integrity fail but this does not block use of the oscilloscope. When the 5.x firmware sees a problem with EEPROM, it will still upload a default EEPROM content which is found in the firmware. This will degrade a bit the precision or the performance but works. So my assumption is thte actual EEPROM data set at factory under 4.x must be valid for 5.x except the integrity check (i.e. additional bytes plus another signature with CRC) which requires reverse engineering.

author: fenugrec
author_rank: Frequent Contributor
timestamp: May 11, 2025, 07:41:02 pm
content: Quote from: Tantratron on May 11, 2025, 05:11:43 pmNot me, but there is one herehttps://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/msg4152352/#msg4152352And I may be able to do better - I still have a half-started analysis of 4.2.1e from a while back, and can expand on your observationQuoteHere's a comparison of the Librarian descriptors for both : you can see the 1BA and 1CA values there.Code:******************** 1.1e ****************_extendedCalLibrarian01193f22 uint8_t * _extendedCalLibrarian_type pType points to 0-terminated array of bytes ?01193f26 uint16_t *_extendedCalLibrarian_size pSize point to array of sizes01193f2a uint32_t *_extendedCalLibrarian_offset pOffset point to array of offsets01193f2e void * _extendedCalLibrarian_factory pFactory default data ?01193f32 void * DAT_050391a2 pAlt point in RAM or NVRAM space; live/editable copy ?01193f36 uint32_t 1BAh sign1 end-of-library signature ? or version / type ?01193f3a uint32_t 1BAh sign2 same as sign1 ?01193f3e uint32_t 250004h unk_flags looks like flags of some sort.01193f42 void * _libVerifyExtendedCal pVerifyFunc******************** 4.2.1e ****************_extendedCalLibrarian0119a3cc uint8_t * _extendedCalLibrarian_type pType points to 0-terminated array of bytes ?0119a3d0 uint16_t *_extendedCalLibrarian_size pSize point to array of sizes0119a3d4 uint32_t *_extendedCalLibrarian_offset pOffset point to array of offsets0119a3d8 void * _extendedCalLibrarian_factory pFactory default data ?0119a3dc void * DAT_0503918a pAlt point in RAM or NVRAM space; live/editable copy ?0119a3e0 uint32_t 1CAh sign1 end-of-library signature ? or version / type ?0119a3e4 uint32_t 1CAh sign2 same as sign1 ?0119a3e8 uint32_t 260004h unk_flags looks like flags of some sort.0119a3ec void * _libVerifyExtendedCal pVerifyFuncBut, I have not-so-good news; the contents of each looks vastly different. Unclear what Type refers too, could be 'basic type' like u8/u16/float etc, but some entries may be arrays. Anyway, notice how v1.1e has 38 'entries' of different types, whereas 4.2.1ehas 53 :Code:******************** 1.1e types and sizes ********************_environmentLibrarian_type011939a0 03 03 03 db03 02 0303 02 02011939a0  3h, 3h, 3h, 3h,011939a4  2h, 3h, 3h, 2h,011939a8  2h, 2h, 2h, 2h,011939ac  2h, 2h, 2h, 2h,011939b0  2h, 2h, 2h, 2h,011939b4  2h, 3h, 3h, 3h,011939b8  3h, 2h, 2h, 2h,011939bc  3h, 3h, 3h, 2h,011939c0  2h, 2h, 4h, 4h,011939c4  2h, 2h, 2h, 2h,011939c8  2h, 2h, 2h, 3h,011939cc  1h, 1h, 1h, 1h,011939d0  1h, 1h, 1h, 2h,011939d4  2h_environmentLibrarian_size011939d6 00 04 00 dw04 00 0400 04 00011939d6  4h, 4h, 4h, 4h,011939de  8h, 10h, 10h, 2h,011939e6  2h, 2h, 2h, 2h,011939ee  2h, 2h, 2h, 2h,011939f6  2h, 2h, 2h, 2h,011939fe  2h, 4h, 4h, 4h,01193a06  4h, 14h, 2h, 2h,01193a0e  4h, 4h, 4h, 2h,01193a16  2h, 2h, 4h, 4h,01193a1e  2h, 2h, 2h, 2h,01193a26  2h, 2h, 2h, 4h,01193a2e  1h, 1h, 1h, 1h,01193a36  1h, Bh, 65h, 2h,01193a3e  2h******************** 4.2.1e types and sizes ********************_extendedCalLibrarian_type XREF: 0119a3cc(*), 012ae922(*)0119a0f8 02 00 03 db03 03 0303 04 040119a0f8  2h, 0h, 3h, 3h,0119a0fc  3h, 3h, 3h, 4h,0119a100  4h, 3h, 4h, 4h,0119a104  4h, 3h, 4h, 4h,0119a108  3h, 4h, 4h, 4h,0119a10c  3h, 1h, 3h, 3h,0119a110  4h, 2h, 2h, 2h,0119a114  2h, 4h, 4h, 3h,0119a118  4h, 4h, 4h, 3h,0119a11c  3h, 4h_extendedCalLibrarian_size XREF: 0119a3d0(*), 012ae914(*)0119a11e 00 c8 00 dw00 00 0400 04 000119a11e  C8h, 0h, 4h, 4h,0119a126  4h, 4h, 4h, 4h,0119a12e  4h, 4h, 4h, 4h,0119a136  4h, 4h, 4h, 4h,0119a13e  4h, 4h, 4h, 4h,0119a146  4h, 1h, 4h, 4h,0119a14e  Ch, 1Ah, 1Ah, 1Ah,0119a156  1Ah, 8h, 4h, 4h,0119a15e  4h, 4h, 4h, 4h,0119a166  4h, 10hI doubt very much there will be an 'easy' data conversion from 1.1e to anything. Or anyway, nothing that will be easily figured out by comparing a handful of eeprom dumps... maybe some insight could be gained by looking at the FAS 'scripts', do they differ according to fw version ? actually that 01BA / 01CA value is probably the size of the Librarian data

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 12, 2025, 04:50:10 am
content: Quote from: fenugrec on May 11, 2025, 07:41:02 pmMany thanks@fenugrecbut would it be possible to rather consider only conversion of EEPROM from 4.x to 5.x instead of 1.x to 4.x since the project or transformation or hack is to really run under 5.x (68040 processor board) any TDS7x4a initially under 4.xIn the meantime, I've added some cases tobe compared (1.x 4.x and 5.x) in a specific Excel format then PDF view where the idea or hypothesis would be serie of 4 bytes arrays (4 channel), please see attached my file which can help reverse engineer. The first page shows in comparative manner the bytes of U1052 and the second page the bytes from U1055. Notice again systematic 8+2 bytes at the beginning of U1052 then some kind of signature (4 bytes) at the end of U1055.From a quick visual analysis, I think you are right that it will be difficult to transform a 1.x EEPROM into a 4.x or 5.x because there seems to be specific added bytes at the end. However I think its is easy from 4.x to 5.x where we just need to figure out hat is the added 4xrow calibration data at the end of U1055.If more EEPROM dumps would be available, statically we could intuit or guess exactly the 4 channel data structure plus CRC and how to manipulate then write again valid EEPROM under 5.xQuote from: fenugrec on May 11, 2025, 07:41:02 pmThis is fantastic guess valid for 1.x 4.x and 5.x data structure. Indeed the last 4 bytes in U1055 indicate (0x1BA or 0x1CA or 0x1CE) the total useful size of U1052/U1055 minus 8 zero bytes and 2 additional bytes (maybe CRC) at the beginning of U1052.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 12, 2025, 10:57:20 am
content: P.S. I've just found a decompilation of java which normally contains the checksum algorithm for NVRAM and EEPROM check (please see attachment). Unfortunately i'm not a java programmer whereas I can do C programming, maybe do you guess exactly what CRC or checksum method has been implemented in the java ?Thank you, Albert

author: fenugrec
author_rank: Frequent Contributor
timestamp: May 12, 2025, 04:46:31 pm
content: Quote from: Tantratron on May 12, 2025, 04:50:10 amI don't have a 5.x firmware dump, but if I did I could extract the Size and Type fields as I did for the others, that only takes about 5 minutesQuoteIMO that is the wrong way to look at it; you will need to parse into 'size' chunks as I posted previously, because that is how the data is accessed via the libManager* functions. You are right that many sub-structures should be "one per channel", but definitely not all.QuoteYes, I don't know why they skip those 8 bytes. But it's hardcoded that way in the firmware. Next 2 bytes are checksum, a 16-bit sum I am fairly certain : here you can see how _libManagerWordAtPut() updates the sum at the end by writing the u16 that lies 2 bytes before the start of the RAM copy at "pAlt" :Code:void _libManagerWordAtPut(uint param_1,short newval) {librarian *plVar1;short *p_targetvalue;short oldvalue;plVar1 = (&_libraryCollection)[(param_1 << 8) >> 0x18];p_targetvalue = (short *)((int)plVar1->pAlt + plVar1->pOffset[param_1 & 0xffff]);oldvalue = *p_targetvalue;*p_targetvalue = newval;p_targetvalue = (short *)((int)plVar1->pAlt + -2);*p_targetvalue = (newval - oldvalue) + *p_targetvalue;return;}I'm fairly certain the signature 01BA at the end is the size to be checksummed ("sign2" field here contains 1BA, 1CA etc):Code:undefined2 _libCheckSum(librarian *param_1) {undefined2 uVar1;uVar1 = _libCheckSumMem(param_1->pAlt,param_1->sign1);return uVar1;}QuoteNote, both firmware 1.1e and 4.2.1e contain 'factory' eeprom data which I understand is the default contents of the eeproms; worth adding to your comparison as a baseline maybe.I might just post this ghidra project somewhere as-is, so people can have a look. It's not rocket science, I don't know why so few people even try reverse engineering.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 12, 2025, 06:20:34 pm
content: Quote from: fenugrec on May 12, 2025, 04:46:31 pmPlease find attached firmware 5.2eN.B. You'll notice using a HEX editor then search for hex string 00 00 01 CE (end marker of default EEPROM) inside 5.2e firmware to find the complete EEPROM default values.

author: tv84
author_rank: Super Contributor
timestamp: May 12, 2025, 07:58:12 pm
content: The whole structure seems to be 16 bits, so no reason to think of 32 bits data.The 01CA should be the size of the previous structure excluding the initial 8 bytes 0x00.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 12, 2025, 08:19:35 pm
content: Hello@tv84, from your posted hex image map showing your eeprom content, do you know exactly the formulae to compute and verify the CRC ?

author: tv84
author_rank: Super Contributor
timestamp: May 12, 2025, 09:35:12 pm
content: Quote from: Tantratron on May 12, 2025, 08:19:35 pmIt's very simple!This is how the checksum is calculated (in C#):ushort checksum = 0;for (int i = 10; i < buffer.Length; i += 2)checksum += UInt16_BigEndian(buffer, i);In the attached picture there is my suggestion to convert between U1052 different versions. And, of course, recalculating the checksum at the beginning.

author: fenugrec
author_rank: Frequent Contributor
timestamp: May 13, 2025, 03:37:36 am
content: _extendedCalLibrarian descriptors for 5.2eInterestingly, firmware structured a bit differently (copies itself to, and executes from RAM), so it took me a bitmore than 5 minutes (YT)This one also globs the first 0xc8 bytes into an 'item', like 4.2.1e, but unlike 1.1eCode:************************************* 5.2e ************************_extendedCalLibrarian_type0506f350 02 00 03 db03 03 0303 04 040506f350  2h, 0h, 3h, 3h,0506f354  3h, 3h, 3h, 4h,0506f358  4h, 3h, 4h, 4h,0506f35c  4h, 3h, 4h, 4h,0506f360  3h, 4h, 4h, 4h,0506f364  3h, 1h, 3h, 3h,0506f368  4h, 2h, 2h, 2h,0506f36c  2h, 4h, 4h, 3h,0506f370  4h, 4h, 4h, 3h,0506f374  3h, 4h, 3h0506f377 00 ?? 00h_extendedCalLibrarian_size0506f378 00 c8 00 dw00 00 0400 04 000506f378  C8h, 0h, 4h, 4h,0506f380  4h, 4h, 4h, 4h,0506f388  4h, 4h, 4h, 4h,0506f390  4h, 4h, 4h, 4h,0506f398  4h, 4h, 4h, 4h,0506f3a0  4h, 1h, 4h, 4h,0506f3a8  Ch, 1Ah, 1Ah, 1Ah,0506f3b0  1Ah, 8h, 4h, 4h,0506f3b8  4h, 4h, 4h, 4h,0506f3c0  4h, 10h, 4h_extendedCalLibrarian_offset0506f3c6 00 00 00 ddw00 00 0000 c8 000506f3c6  0h, C8h, C8h, CCh,0506f3d6  D0h, D4h, D8h, DCh,0506f3e6  E0h, E4h, E8h, ECh,0506f3f6  F0h, F4h, F8h, FCh,0506f406  100h, 104h, 108h, 10Ch,0506f416  110h, 114h, 116h, 11Ah,0506f426  11Eh, 12Ah, 144h, 15Eh,0506f436  178h, 192h, 19Ah, 19Eh,0506f446  1A2h, 1A6h, 1AAh, 1AEh,0506f456  1B2h, 1B6h, 1C6h

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 13, 2025, 07:13:13 am
content: Quote from: tv84 on May 12, 2025, 09:35:12 pmMuito obrigado so now I've made simple C program (see after) which then run fine on 6 different U1052.bin/U1055.bin appended into ACQEEPRM.bin files (1.x case, 4.x case and 5.x case wether C serie or D serie).Code:int main(void){#define EEPROM_LEN 512FILE *eepromfile;uint8_t buf;uint16_t bufBigEndian[EEPROM_LEN/2];int i, j, readlen;uint16_t checksum, temp;eepromfile = fopen ("ACQEEPRM.bin", "rb");if (!eepromfile){printf("Failed to open EEPROM file\n");return 1;}readlen = fread(buf, 1, EEPROM_LEN, eepromfile);if(readlen != EEPROM_LEN){printf("Failed to read EEPROM file\n");return -1;}j=0;for(i=0;i<EEPROM_LEN;i+=2){bufBigEndian = (buf << 8) + buf[i+1];j++;}temp=0;for(i=5;i<EEPROM_LEN/2;i++) temp += bufBigEndian;printf("EEPROM CRC %04x / Check CRC %04x\n",bufBigEndian, temp);fclose(eepromfile);}Later I'll modify my actual TDS784A eeprom content with additional line then re-compute (reverse engineer) its CRC so it will be floppy disk util BAT written in U1052/U1055 chips to check integrity run of acquisition board under 5.x instead of 4.x

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 13, 2025, 07:32:24 am
content: Quote from: fenugrec on May 13, 2025, 03:37:36 amThanks for doing this where by the way, one explanation of the firmware difference between 68020 versus 68040 processor boards is foundin this thread, in particular this post where I've finally repaired while ago one TDS784D with specific kernel boot fail.There is much more info about this on the old tektronix forum but to make short a long story: the C and D version still use exactly the same Kernel and hardware programmed as 68020 (A and B versions) but special chip U1 doing the translation between 68020 space and 68040. This is why you found the copy like an indirect pointer paradigm when manipulatin and reverse engineering the 5.2e firmware.This is also why I think the TDS7x4A acquisition board can be hacked via the eeprom local manipulation (add 00 00 02 23 bytes, increase length of library marker from 0x01CA to 0x01CE then recompute CRC) so it becomes a TDS7x4C => much faster and enhanced features.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 14, 2025, 07:13:44 am
content: Earlier this morning, I've decided to test the hack method so modification of EEPROM under 5.x format then floppy boot write direct U1052 and U1055. All worked fantastic and now confirmation that any TDS7x4A acquisition board under 4.x (old 68020 processor board) can be used under 5.x (new 68040 processor board).In my specific test with TDS784A, now it is now transformed as TDS580C (monocolor CRT) or TDS784C (color CRT).There is one line of 4 bytes at the end of the EEPROM file which i'm not sure of its meaning and importance, maybe@fenugreccan analyze and reverse its foundation with his analyzer tool. Statiscally I've checked many calibrated EEPROM from C serie and D serie all running under 5.x or 6.x, the line happens to be always 00 00 02 23 bytes except one case which was 00 00 02 24 bytes. I decided to choose adding 00 00 02 23 in my hacking attempt because it is found as default in the firmware and again, most of the time I saw this line with 23 instead of 24 in most EEPROMs.Maybe someone can guess its definition (factory cal or other), no idea but the CRC will need to be adjusted if you choose 0x23 or 0x24.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 15, 2025, 04:21:33 am
content: P.S. On a side note, I've no TDS520B or TDS540B in stock but normally these models running under 68020 processor board do use the same acquisition board as in the TDS724A TDS744A or TDS784A. So technically the same hack could be used once installing a 68040 processor board interfaced with TDS5x0B acquisition board. If one of you could share the EEPROM content of either TDS520B or TDS540B then we would verify the signature at the end coding the size of the calibration constant library.

author: TERRA Operative
author_rank: Super Contributor
timestamp: May 15, 2025, 05:24:08 am
content: I think I might have a TDS520 and/or 540 of some variant.I'll check in the next few days.I have taken a few various EEPROM dumps of some of my scopes as they pass my bench over the last few days on their way to Yahoo Auctions, so I'll upload those soon too.

author: TERRA Operative
author_rank: Super Contributor
timestamp: May 16, 2025, 01:52:44 am
content: Here's a few EEPROM dumps from various scopes. TDS620B, TDS714L, TDS754D and TDS784DI'll post more as I dig scopes out of storage.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 16, 2025, 04:36:23 am
content: Many thanks@TERRAwhere we have confirmation for C serie and D serie the last 4 bytes always end with 00 00 01 1C so the size of EEPROM library. Then we also have confirmation the previous 4 bytes can be either 00 00 02 23 or 00 00 02 24 where I do not know what is the purpose or definition when 23 or 24. In my hack, I choose 23 scenario but maybe worth try 24 scenario, I'm totally blind on this one.Now for your specific case of TDS620B running under 4.4.1e the EEPROM data structure is totally different from what I've seen so far. However I'm not sure TDS620B could be actually have an upgraded version under C or D serie, its acquisition board HW/SW might be different than any TDS500/700, I've never had any TDS600 in hands.

author: TERRA Operative
author_rank: Super Contributor
timestamp: May 16, 2025, 10:38:04 am
content: The 600 series often (always?) uses a CCD for acquisition to enable the higher sample rates, which would be incompatible with the non CCD 500 and 700 series.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 16, 2025, 11:54:16 am
content: Quote from: TERRA Operative on May 16, 2025, 10:38:04 amThanks again, I did not know neither heard of CCD technology then just foundthis very recent article discussing the CCD on TDS600. Clearly the acquisition board is quite different from TDS50/700.

author: madao
author_rank: Frequent Contributor
timestamp: May 16, 2025, 01:50:18 pm
content: I wanna tell about TDS600-familyThere is also difference between 600B and 600C same as 500B/C and 700A/C: 68020 vs 68040 CPU Board and same chipset on acqusistion board.we need example from TDS600C family (i have here a TDS684B/C acqusistion baord, but i don't know B or C )

author: tverbeure
author_rank: Regular Contributor
timestamp: May 16, 2025, 02:19:20 pm
content: I have a 684B and 684C. (I wrote that CCD blog post.)What information do you want me to dump?

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 17, 2025, 05:08:25 am
content: Quote from: tverbeure on May 16, 2025, 02:19:20 pmGreat blog post you wrote about CCD, I did not know of this sampling technology before TERRA mentioned regarding the specific case of TDS600.I've never possessed any TDS600 neither TDS800 so will not be able to test or experiment any hack but to check if it works, ideally we would need from you or others dump of EEPROM.To do the EEPROM dump, you can first run GPIB getcaldata from tektools suite however the best would be to use floppy disk dump. If for some reason the EEPROM is corrupted or failed, I assume TDS600 would do as TDS500/700/C/D namely, create a log file error then use default eeprom found in the firmware.Please indicate the EEPROM file against the TDS680 C or D plus the respective core firmware.Depending the result, you might try to convert yoru B into a C but I must warn that all these hackings are challenge that if false move then you brick your oscilloscope.

author: TERRA Operative
author_rank: Super Contributor
timestamp: May 17, 2025, 09:30:53 am
content: Some more EEPROM dumps from today. Still got more I can provide as I dig out more scopes if needed?

author: tverbeure
author_rank: Regular Contributor
timestamp: May 19, 2025, 04:28:03 am
content: getcaldata EEPROM contents for TDS 684B and TDS 754D.The error log is clean, so I don't think a floppy dump is necessary.My 684C was already flaky in booting up last week and now it just refuses, with all the front panel LEDs green.I assume the DS1486 died, so I know what to do next...

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 19, 2025, 05:46:24 am
content: Quote from: tverbeure on May 19, 2025, 04:28:03 amAs for your TDS684C which would really help investigate the EEPROM content signature between 68020 and 68040, you might use the floppy disk method to dump directly the EEPROM. It should normally work wether DS1486 is failed or partially corrupted due to battery issue. Another temporary option for you is to replace actually the DS1486 by either DS1250Y or DS1650Y with enough battery, you just flash its content and it will boot fine. Only problem is no RTC time clock will work but the oscilloscope will run fine including the fact no need to have both NVRAMs, only DS1486 needs to host valid NVRAM.

author: tverbeure
author_rank: Regular Contributor
timestamp: May 19, 2025, 02:46:04 pm
content: I’ll give both methods a try. I don’t have a desoldering pump on hand right now. Maybe a solder sucker will be sufficient.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 19, 2025, 03:48:44 pm
content: Quote from: tverbeure on May 19, 2025, 02:46:04 pmI've removed many DS1486/DS1250Y/1650Y from many TDSxxx so best you use a good desoldering gun (i.e. Hakko) because otherwise you could ruin the multi-layer PCB in that zoning with classic solder sucker or pump.

author: tverbeure
author_rank: Regular Contributor
timestamp: May 25, 2025, 12:58:41 am
content: getcaldata EEPROM contents for TDS 794D.Update: attachment removed since it was all zeros. New dump attached a few messages down...

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 25, 2025, 04:31:23 am
content: Quote from: tverbeure on May 25, 2025, 12:58:41 amThanks but is full of zeros so not valid.What dumping method did you use ?

author: tverbeure
author_rank: Regular Contributor
timestamp: May 25, 2025, 07:25:40 am
content: Weird. I used getcaldata as before.I also checked the error log, no issues.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 25, 2025, 08:10:04 am
content: Quote from: tverbeure on May 25, 2025, 07:25:40 amGetcaldata always works but you might have a problem with your eeprom or the bus linking to processor board.As for error log with no issues, if eeprom is full of zero then the CRC will be always zero => valid even though it isinvalid.Try eventually floppy dumping of eeprom to know exactly the full story.

author: tverbeure
author_rank: Regular Contributor
timestamp: May 25, 2025, 05:52:10 pm
content: Ok. I managed to run the floppy tool (I hate those things.) The EEPROM dump now isn't all zeros. When I use getcaldata it's still all zeros.Since the floppy tool and getcaldata both go through the CPU board, the connection between the CPU and the ACQ should be ok. So who knows what's going on here...I'll update the firmware of the scope from v6.0e to something later and see if that changes anything.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 25, 2025, 05:59:02 pm
content: Ok great about your floppy dumping eeprom, now is fine and confirms the specific signature of C/D serie under 5.x and 6.x firmware.Just a question about your use of getcaldata via GPIB, do you confirm running the app when NVSRAM are locked so normal run of your TDS794D ?Any chance you can solve the eeprom dump of both your TDS684B/C to help member@madaohack his own piece ?