Tek TDS 744A/784A FWs: nvLibrariansDiag, Libs with crcc failures: ,  ExtConst - Page 1
Forum section: electronics / repair

author: mssbid
author_rank: Contributor
timestamp: October 03, 2022, 08:22:30 am
content: After fixing my 744A I decided to play with FW updates. I went from 1.0.1e to 1.1eand all was fine. After going to 4.2.1e I encountered the error:nvLibrariansDiag, Libs with crcc failures: , ExtConst"As we can read elsewhere this is due to a different location of various cal stuff whichsits in the NVRAM. This probably could be fixed by running the entire cal procedure.Is there a list of FWs which exist at all for the 744A (784A) and which are "compatible"regarding the NVRAM layout?

author: TERRA Operative
author_rank: Super Contributor
timestamp: October 03, 2022, 11:23:01 am
content: I have been uploading all firmwares I encounter to the tekwiki.(If anyones finds any versions not there on tekwiki, please copy it out of your scope for me!Instructions here)https://w140.com/tekwiki/wiki/TDS744https://w140.com/tekwiki/wiki/TDS784Ibelieveyou can't go up or down a major revision level (i.e V1.x to V4.x etc) due to physical differences in the hardware.I'm not 100% sure what the actual lines of incompatibility are, but itseemsto be this way. There is definitely incompatibilities with new and old hardware regarding old and new firmware.

author: charlyd
author_rank: Frequent Contributor
timestamp: October 04, 2022, 05:51:12 pm
content: i posted a very big list in an other topic a while ago

author: mssbid
author_rank: Contributor
timestamp: October 04, 2022, 06:36:07 pm
content: Quote from: TERRA Operative on October 03, 2022, 11:23:01 amWell, my understanding is, that you can't use 744A fw on 744B/C/D. And 744C fw on 744A/B/D. And so on.But on 7x4A you _can_ use 1.x as well as 4.x from a hardware point of view (but no .x as these arefor different hardware).However, in order for 4.x to work on a 7x4A which had 1.x before (or vice versa), this ExtConst thing hasto be fixed, e.g. by a complete calibration. When I tried that 4.2.1e on the (former 1.0e) 744A, thiserror was the only one. All other diag tests where passed perfectly. Additionally, the scope seemedto work. I did not verify all combination of settings but all 4 channels with a few att and timebasesettings. I assume that it used some default values which were not to far away.I also found an NVRAM dump where the name suggested that it is for a 744A running 4.2.1e. Knowingthat its cal data won't be the correct ones for my 744A, it tried it and received the same error (and onlythis error) again.If someone has a 744A with a 4.x fw and definitely does not encounter the ExtConst error when runningdiagnostics, I would be interested in his NVRAM dump. Of course this is just for testing as the cal valueswon't be correct as well...

author: mssbid
author_rank: Contributor
timestamp: October 04, 2022, 06:37:44 pm
content: Quote from: charlyd on October 04, 2022, 05:51:12 pmhttps://www.eevblog.com/forum/testgear/tds754d-fail-processor/msg2869574/#msg2869574But it does not mention the compatibility and I can't find 1.0.1e (which was on my 744A)and 1.1e (which is on my 784A).

author: fenugrec
author_rank: Frequent Contributor
timestamp: October 13, 2022, 04:17:35 pm
content: nvLibrarian should be related to the NVRAM, i.e. not the EEPROM on the Acq board which is the one you really don't want to lose. NVRAM should only hold SPC and other easy-to-repeat calibrations ?Have you tried (after a backup) clearing NVRAM entirely then rebooting ?

author: mssbid
author_rank: Contributor
timestamp: October 13, 2022, 05:39:38 pm
content: Quote from: fenugrec on October 13, 2022, 04:17:35 pmFrom what I've learned here, the 744A does not have Acq EEPROMs and indeedhas its factory cal data in the NVRAM.QuoteNope, see above. But I've run SPC with flying colours and the error did not go away.Edit: When time permits :-), I wanted to check where the FW expects to see thatExtConst data in the NVRAM and if 1.x and 4.x use the same layout. Then it mightbe possible to move that block within the NVRAM and after fixing the CRC all couldbe fine. I've been pretty good in 68k assembler 30 years ago (good old Atari times :-))so the only thing I need is time. I also found your interesting posts onhttps://www.eevblog.com/forum/testgear/tds-744a-(-friends)-firmware-reverse-engineering/msg1424907/#msg1424907Do you have some kind of dissassembly which you are able to share (so i do nothave to start from scratch)?

author: fenugrec
author_rank: Frequent Contributor
timestamp: October 13, 2022, 06:31:04 pm
content: Quote from: mssbid on October 13, 2022, 05:39:38 pmI assure you, my 744A has both U1052 and U1055 EEPs on the acq board. Do some later 744A units not have them anymore ?QuoteYeah, I would still suggest try clearing the NVRAM - the XYZ-librarian functions look up stuff in there according to a certain layout, which they normally won't modify. Based on what I remember from disassembling them a while ago... a blank NV should trigger a reconstruction of the basic structures in there.If you're curious you could try my nvram_tool.c utility (fromhttps://github.com/fenugrec/tdsutils) against a dump of your NVRAM, it should show some of the contents and checksums, but that wouldn't help you much.QuoteI'd have to export the db from IDA, I don't think I ever migrated that project to ghidra... I'll see what I can do. But really, I have my money on clearing NVRAM. Worry about transferring constants later...Anyway, here's part of my shorthand RE notes regarding NVRAM layout corresponding to fw 1.1e :QuoteCan't really help with the finer details, as I haven't looked at this firmware in a few years.

author: mssbid
author_rank: Contributor
timestamp: October 14, 2022, 07:50:37 am
content: Quote from: fenugrec on October 13, 2022, 06:31:04 pmI didn't look exhaustively yet -- I had my eye on replacing the two dallas chips and fixinga cold solder joint on the interconnect board of the 744A. But I've read a lot here and inthe Tek forum and the outcome was that only B/C/D models have them.And I can't look right now as the units are currently approx 5000 km away from me :-).FWIW, I have the product numbers of the boards:744A: 671-3461-03784A: 671-3740-00Do you have your number(s) at hand?QuoteWell I can try that when I am back. But first I'll check if there are reallyany EEPROMs. If yes, I will first remove them and make a copy.QuoteDon't worry -- I still have no idea when I will find the time to dig further into this. Thanksfor the link to your tools.

author: fenugrec
author_rank: Frequent Contributor
timestamp: October 14, 2022, 01:02:32 pm
content: Quote from: mssbid on October 14, 2022, 07:50:37 amWell it's the first time I hear that, anyway. I also remember seeing eeprom read/write funcs in the 1.1e firmware - not sure how it's handled though, is the I2C bus routed all the way to the main board or is it managed via the huge gate arrays....Also haven't compared to other fw versions; seems like a pretty substantial change that would warrant more than just a minor version bump.I only have a photo of my acq board and the sticker is nearly unreadable, tweaking the colors to the max I would say 679-3739-01 .

author: mssbid
author_rank: Contributor
timestamp: October 14, 2022, 06:49:59 pm
content: Quote from: fenugrec on October 14, 2022, 01:02:32 pmHmm, I didn't record the links but it was stated in several places. In the end it doesn'tmatter -- I will have to check the boards when I'm back.

author: mssbid
author_rank: Contributor
timestamp: October 16, 2022, 03:46:56 pm
content: Quote from: fenugrec on October 14, 2022, 01:02:32 pmFWIW, here is one of the posts:https://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/msg2428782/#msg2428782There are more but I am too lazy to search for them :-).

author: mssbid
author_rank: Contributor
timestamp: October 20, 2022, 08:02:03 am
content: Quote from: fenugrec on October 13, 2022, 06:31:04 pmIt seems you are right: I didn't open my 744A for checking but simply ran tdsNvramMinimalFloppyDumperand it spit out a 512 bytes file which perfectly passes all checksum checks:Code:bali:~>java -cp TDSNvrCV_2_1.jar TDSNvramChecksumVerifier ~/x/ACQEEPRM.BINTDSNvramChecksumVerifier v2.1Read 512 bytes of dump data from /people/andre/x/ACQEEPRM.BINDetected small file, considering dump an ACQUISITION EEPROM dumpDump data matching firmware prototype acqEEPROM-TDS784D-v7.4e_TDS784C-v5.2e, all known checksums found VALIDInterpretation of dump data as a firmware acqEEPROM-TDS784D-v7.4e_TDS784C-v5.2e based dump :dump section=ACQEEPROM address=0xa size=0x1ce checksum=OK (actual=0xf146 computed=0xf146)So it really seem to have those two EEPROMs ;-). I will do the same on my 784A later...BTW, in addition to my previous post, here is an excerpt from the info.txt that comeswith tdsNvramFloppyTools_v5:Code:...Dumps the contents of the calibration constants 24C02 EEPROMs locatedon the acquisition boards of the -B, -C and -D series scopes, to a file.-A series scopes have no such EEPROMs on the acquisition board andstore these constants in regular NVRAM, albeit in a hardware-protectedregion....As we have learned now, this might be true but at least for my (and your) 744A it is not.So when time permits, I will follow your suggestion and clear the NVRAM after loadingthe 4.2.1e FW and see what happens.BTW, is there a simple way to clear it? Or should I simply write a 128kB file with zeroesusing tektool?

author: mssbid
author_rank: Contributor
timestamp: October 22, 2022, 02:53:29 pm
content: This to confirm that my 784A also has the two EEPROMs (confirmed visually and by readingtheir content using tdsAcqEEPROMMinimalFloppyDumper).So the statement that these EEPROMs only exist on -B and higher model is not true -- atleast not for the 744A and 784A using the Acq Boards 671-3461-03 and 671-3740-00.

author: mssbid
author_rank: Contributor
timestamp: October 25, 2022, 06:07:56 am
content: Quote from: fenugrec on October 13, 2022, 04:17:35 pmTried that now. I flashed FW 4.2.1e again and uploaded a file containung 131072 zeroes inorder to clear the NVRAM. Settings, SPC and date were reset. I did a SPC which succeeded.However, the errornvLibrariansDiag, Libs with crcc failures: , ExtConst"remains...

author: fenugrec
author_rank: Frequent Contributor
timestamp: October 25, 2022, 02:32:12 pm
content: Quote from: mssbid on October 25, 2022, 06:07:56 amInteresting.To state the obvious... you tried a factory reset from the scope menus ?.... a few minutes later....ah. I got curious, loaded up ghidra and my notes,I'm trying to think how you could get the following function to run, which should reset the extended cal librarian... maybe from the service console, or with a modified version of the the special nvram_dump floppy ?Code:void _loadFactoryValuesIntoExtendedCal(void){_libLoadInitValues(&_extendedCalLibrarian);return;}Incidentally, here's my take on the "librarians".First, a list of the librarian "descriptors" :Code:_libId XREF: _nvLibrariansDiag:011f0c78(R),_calLibrarianDefaultCk:011f0d3e(012b172e(*)050176d4 01 19 a3 cc addr _extendedCalLibrarian = 0119a0f8PTR__calConstantLibrarian_050176d8 XREF: _nvLibrariansDiag:011f0c78(R),_calLibrarianDefaultCk:011f0d3e(050176d8 01 19 9e 10 addr _calConstantLibrarian050176dc 01 19 92 bc addr _scopeStateLibrarian050176e0 01 19 a0 d4 addr _environmentLibrarian050176e4 01 19 a4 ee addr _diagLibrarian050176e8 01 19 a4 9a addr _hwAccountantLibrarian = 0119a3f0Let's see what's in "_extendedCalLibrarian" :Code:_extendedCalLibrarian XREF: _loadFactoryValuesIntoExtendedCa_verifyExtendedCalCheckSum:01196_verifyExtendedCalCheckSum:01196_invokeExtendedCalStartupFunctio_verifyLibExtendedCalCheckSum:01_saveExtendedCalLib:011972b2(*),_saveExtendedCalLib:011972c2(*),012ae8ea(*), 05013f84(*),05013f8c(*), 050176d4(*)0119a3cc 01 19 a0 f8 addr _extendedCalLibrarian_type = 02h0119a3d0 01 19 a1 1e addr _extendedCalLibrarian_size0119a3d4 01 19 a1 6a addr _extendedCalLibrarian_offset0119a3d8 01 19 a2 02 addr _extendedCalLibrarian_factory = 07h0119a3dc 05 03 91 8a addr DAT_0503918a0119a3e0 00 00 01 ca ddw 1CAh0119a3e4 00 00 01 ca ddw 1CAh0119a3e8 00 26 00 04 ddw 260004h0119a3ec 01 19 6b 32 addr _libVerifyExtendedCalOk, nothing very interesting, but digging around more in my notes I found the missing link:Code:_indirectLibHandles XREF: FUN_01196dbe:01196ddc(R),_recallAllLibs:01197208(R),_saveAllLibs:01197242(R),_saveAllButExtAndHWALib:0119727c_libMonitor:01197310(R),012b0912(*)05013f84 01 19 a3 cc addr _extendedCalLibrarian = 0119a0f8PTR_s_EXTCAL_05013f88 XREF: _saveLib:01197018(R),_libMonitor:0119733e(R)05013f88 01 19 73 f2 addr s_EXTCAL_011973f2 = "EXTCAL"05013f8c 01 19 a3 cc addr _extendedCalLibrarian = 0119a0f805013f90 01 19 74 a6 addr _gtlX24c02Bcopy05013f94 01 19 76 62 addr _gtlX24c02Bcmp05013f98 05 03 91 88 addr _extCalRamLibSee those _gtlX24c02* functions : they talk to the serial EEPROMs on the acq board ! So there's a level of indirection when some functions call for e.g. "check librarian checksums", the backend would run these functions to read and write data.So maybe it's not the NVRAM you should be erasing, but instead maybe the EEPs ? Of course making 1000% sure you have a good backup... what I did once was to sniff the I2C bus with an LA to double-check the contents matched what I got via GPIB.Or, write something to those EEPs that is taken from a known-working 4.2.1-based scope ?. Maybe the contents is structured differently. It would make sense that the "factory reset" from the scope UI wouldn't trash that data, since it's quite more critical than e.g. SPC consts.

author: mssbid
author_rank: Contributor
timestamp: October 25, 2022, 04:37:19 pm
content: Quote from: fenugrec on October 25, 2022, 02:32:12 pmSure. Well I did that Secure Erase (or how it's called).QuoteWell, I am pretty sure to have good backups. I read it first with the floppy tools(several times) and then with getcaldata via GPIB. Files were always the sameand survived that checksum test.BTW, on the 784A this worked immediately. On the 744A getcaldata producedonly 2 files containing only zeroes (I remember I've read that other people hadthis as well). I started NI Spy and found the following:getcaldata sends e.g., WORDCONSTANT:ATOFFSET? 262144,0 to the scope.It then reads 6 bytes containing the corresponding word. For some reasonsthe 744A answered something similar to::WORDCONSTANT:ATOFFSET? 262144,0,xyzwith xyz being the desired word value. Since getcaldata couldn't convert ":WORDC"to any meaningful integer, it produces only files containing zeroes. When sendingWORDCONSTANT:ATOFFSET? 262144,0manually with the NI tool, only xyz came back (as expected). So I started to play withthe adapter settings but nothing changed. But after clearing the scope's error logit suddenly worked. No idea why...QuoteAlthough I have probably good EEPROM backups I am still scarey to write them.However, I have ordered some 24LC024 I/SN a few days ago since I wanted tobe prepared if my old EEPROMs fail one day. After having a physical and workingbackup, I might dare to try this ;-).Thanks for your ghidra stuff. Maybe I'll dig into this code one day when time permits...

author: mssbid
author_rank: Contributor
timestamp: October 31, 2022, 01:52:55 pm
content: OK, some more about playing with the EEPROMs on the 744a:1. Removed the two X24C02 EEPROMs. Read them with a programmer and comparedthe results with the data from getcaldata and tdsAcqEEPROMMinimalFloppyDumperAll OK.2. Soldered two self- made DIP/SOIC adapters to the ACQ board (see pic). Now we canswap chips easily.3. Wrote the content to two new 24LC024 chips and inserted them.4. Booted with 4.2.1e:ERRORID: 153 diagnostic test failure extended cal librarian reset5. Removed the chips and booted 4.2.1e again:ERRORID: 346 nv storage too small more bytes requested than availabl-e>0x51ffea8 (tRootTask): libError 346, lib EXTCAL, id=346, msg=more bytes requested than available6. Inserted two empty chips and booted 4.2.1e again:ERRORID: 153 diagnostic test failure extended cal librarian reset(same as in step 4).7. Downgraded the scope to 1.1e (where we came from). Inserted the properlyprogrammed 24LC024 chips. Ran complete diagnostics. No errors.What have we learned so far?a) 24LC024 work as a replacement for the X24C02.b) Empty EEPROMs don't get initialised with whatever defaultsRepeating my request:If anyone has a 744a or a 784a with FW 4.xx (or 2.xx or 3.xx) and has no diagerrors, please send me your EEPROM content. This can easily be obtained withtdsAcqEEPROMMinimalFloppyDumper or getcaldata (getting the dumps is recommendedanyways).

author: charlyd
author_rank: Frequent Contributor
timestamp: October 31, 2022, 09:13:36 pm
content: hi i can asure you that installing good empty eeprom 24C02 will work on a TDS754D solving the [250 nvstorage too small more bytes requested than available] but the unit needs to be recalibrated to get back triple PASS .

author: mssbid
author_rank: Contributor
timestamp: November 01, 2022, 12:13:43 pm
content: Quote from: charlyd on October 31, 2022, 09:13:36 pmNo need to assure me as I didn't say anything different. I wrote:Code:5. Removed the chips and booted 4.2.1e again:ERRORID: 346 nv storage too small more bytes requested than availabl-e>0x51ffea8 (tRootTask): libError 346, lib EXTCAL, id=346, msg=more bytes requested than availableandCode:6. Inserted two empty chips and booted 4.2.1e again:ERRORID: 153 diagnostic test failure extended cal librarian reset(same as in step 4).so the "too small" message appeared WITHOUT any EEPROMs and changedinto "cal librarian reset" after installing two blank ones.The whole thread is about switching from FW 1.1e to 4.2.1e. Regarding my 744A and 784AI have learned now, that1. In contrary to what has been stated in a lot of places, there are A-type devices whichhave these EEPROMs on the ACQ board.2. The "precious" cal data is in these EEPROMs and not in the Dallas chip(s).3. Therefore one can erase the Dallas content and will only lose options and SPC andthe date.4. The X24C02 can be replaced by 24LC024 (and probably others).5. The data in the EEPROMs is compatible when going from 1.0.1e to 1.1e but not from1.1e to 4.2.1e.6. One probably can get rid of this when doing a full recal. I can't do this so I will stay with1.1e for the time being.Two confirm this, I am interested in trying any(!) EEPROM content from any 744A with aFW 4.2.1e.

author: charlyd
author_rank: Frequent Contributor
timestamp: November 03, 2022, 07:53:54 pm
content: what i can tell about FW and exchange them between same unit models. this can be tricky for example there is a TDS784D but this scope has a least two different models ACQ board and those FW versions are not interchangable. and i can image that there are more models with the same situation.somewhere on this forum i posted a very big list of all FW version of the TDSxxx and there belonging models.

author: mssbid
author_rank: Contributor
timestamp: November 04, 2022, 06:09:49 am
content: Quote from: charlyd on November 03, 2022, 07:53:54 pmMight be, of course. This is why I'd like to have an EEPROM dump of anybody with a 744A/784Awho runs 4.x and has no diag errors.QuoteYep, I found this list (may I ask: where did you get it from?).

author: hvontres
author_rank: Contributor
timestamp: January 03, 2023, 04:22:44 am
content: Quote from: mssbid on November 04, 2022, 06:09:49 amI don't have the setup for dumping my EEPROMS yet, but I can confirm that even a partial calibration of a 744a with 4.2.1e removes the nvLibrariansDiag Errors from the Error log. I am asuming that if there are no errors, the self test simply re-boots the scope without showing the results? Sorry, this is my first TDS 7xx and it came with 4.2.1e already on it, so I have no idea what correct operation is supposed to be like.Once I can get the rest of the cals to pass (my DIY reference setup struggles with the 20ma step during the 50 Ohm gain step and my cheap RF amplifer appears to be dead, so I can't do the HF cals yet either) I will try to dump the EEPROMS for you.

author: mssbid
author_rank: Contributor
timestamp: January 03, 2023, 06:19:37 am
content: Quote from: hvontres on January 03, 2023, 04:22:44 amCool, thanks a lot in advance!

author: hvontres
author_rank: Contributor
timestamp: January 03, 2023, 09:56:26 am
content: Quote from: mssbid on January 03, 2023, 06:19:37 amQuick update: I managed to get my Gpib setup working enough to clear the error logs, and indeed, the nvLibrarians errors are gone.

author: mssbid
author_rank: Contributor
timestamp: February 10, 2023, 11:17:32 am
content: Quote from: hvontres on January 03, 2023, 09:56:26 amCool. Any chance to drop me a dump of the two EEPROMs? Thanks!

author: hvontres
author_rank: Contributor
timestamp: February 10, 2023, 11:52:23 am
content: Quote from: mssbid on February 10, 2023, 11:17:32 amSorry, the tek is currently stuck behind some other projects. I am currently fixing up my old HP 8542B which should allow me to finish up the HF cal. Had a bit of an oops with the power supply caps. Took them out to test them and then mixed up the -5V and 50V caps.... 35V cap + 65V DC == lots of smoke and black goo. Also finally did the full set of adjustments on an HP 3314a. I'll post the dumps as soon as I get my GPIB setup sorted.

author: Tantratron
author_rank: Frequent Contributor
timestamp: February 10, 2023, 12:15:59 pm
content: Quote from: mssbid on February 10, 2023, 11:17:32 amIt might not be a good idea at all for you to write another TDSxxxA oscilloscope EEPROM's content. The content of both these two EEPROM contains the very fine calibration value of your Acquisition board.There are some techniques to eventually recover the content of your old EEPROMs content which would be then written in the new sets of EEPROM. Otherwise you have no choice to run a complete calibration of your Oscope in order have dedicated and valid content, again highly related to your specific A10 acquisition board.If there is something you do not want to have wrong with precise TDS Oscope is the integrity of these two EEPROMs

author: mssbid
author_rank: Contributor
timestamp: February 10, 2023, 12:27:02 pm
content: Quote from: Tantratron on February 10, 2023, 12:15:59 pmYep, but this thread is about something different...

author: mssbid
author_rank: Contributor
timestamp: February 10, 2023, 12:29:07 pm
content: Quote from: hvontres on February 10, 2023, 11:52:23 amOK, take your time (and good luck with your caps ;-))

author: Tantratron
author_rank: Frequent Contributor
timestamp: June 14, 2023, 03:54:17 am
content: I do not have any TDS7x4A so cannot extract any image or do any test. However I've asked a friend of mine in Spain to try on his TDS744A running with version 1.1e to upgrade 4.2.1e version.He got the same problem, the reported errorERRORID: 153 diagnostic test failure extended cal librarian resetwhich can only be solved by re-calibration or understanding the data structure inside both U1052/U1055 chips.This poses the fundamental question of how is structured acquisition EEPROM (total of 512 bytes). We know for sure the first 8 bytes are always 0x00 and there are always at least 4 bytes to indicate end of file or end of calibration constants storage.

author: Tantratron
author_rank: Frequent Contributor
timestamp: March 23, 2025, 10:40:13 am
content: Quote from: mssbid on October 04, 2022, 06:36:07 pmI've been offered a TDS744A earlier this week, the company wanted to throw it away to the junkyard because was unused for long.After some dust cleaning and different check prior powering up, it does boot under firmware FV:4.2.1e but will takehugetime to complete the normal run.So I've forced S1001 8-pin switch to 0b00000100 to skip diagnostics, this time the boot is muchquicker.However it runs fine without anynvLibrariansDiag, Libs with crcc failures: , ExtConstalert.My concern is about the speed of starting, does any owner of TDS784A could tell if it is normal to boot super slow under FV:4.2.1e versus prior firmwares, is it due to the slow 68020 processor ?So far since 2019, I've owned or repaired many TDSxxxC/D which run with 68040 so booting was always fast.

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 23, 2025, 11:22:21 am
content: The slow boot was a thing, and apparently Tek then set the DIP switch to skip extended tests to speed up boot time.Switch 3 is the one that determines the extended test or short test (open = quick test, closed = long test). In all of my scopes it's been set to a short test.

author: Tantratron
author_rank: Frequent Contributor
timestamp: March 24, 2025, 07:42:32 am
content: Quote from: TERRA Operative on March 23, 2025, 11:22:21 amUnless I'm wrong, it seems the TDS784A (maybe same for TDS744A or TDS724A) acquisition board has same design as acquisition board from TDSxxx/C serie, in particular hybrid chip ADG299G.Has anyone ever being able to hack the TDS784A acquisition using a A11 processor board with 68040 (only C or D serie) then run under firmware 5.x to get speed and maybe new functions ?In other words, to keep all boards of TDS784A except upgrading processor board to obtain TDS784C oscilloscope...

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 24, 2025, 09:04:10 am
content: I've never tried... I might have enough scopes to give it a go, but I don't currently have the bench space.... I will in a while once I continue selling off unused gear.

author: Tantratron
author_rank: Frequent Contributor
timestamp: March 26, 2025, 06:47:35 am
content: Quote from: TERRA Operative on March 24, 2025, 09:04:10 amFinally to catch 2 birds with one stone, I've tried running 5.2e with 68040 processor board with TDS784A acquisition board, it works partially as reportedhere.

author: Tantratron
author_rank: Frequent Contributor
timestamp: May 11, 2025, 07:18:34 am
content: Quote from: TERRA Operative on March 23, 2025, 11:22:21 amAs for using switch 3 on DIP, in fact this cheating trick does the job to actually to transform a TDS784A into a TDS784C.See thisnew threadwhich i've started focussed on the EEPROM content structure and manipulation versus the firmware (1.x 4.x or 5.x) which did the factory calibration