Products > Test Equipment
Tektronix TDS Scope Field Adjustment Software reverse engineering
m k:
I read somewhere that first run is nagging if driver is missing.
But can't really remember where that was, possibly a Q&A section of something.
Other thing, and maybe a parallel and more hardware route,
somewhere between DOS and W10 is a level where old programs can run without a major hassle.
Maybe that's a suitable middle man/partial level for this.
It can possibly also be easier level for old ISA card to USB adapter porting.
It requires an IA-32 x86 system but can eventually do without ISA with directly ISA controlling software.
With old system old style Virtual Mode Extensions are also available and manipulating them does not need programming, only configuration of the selected VME.
It seems that nowadays DOSBox is sort of a de facto environment but earlier Windows versions may have better solutions.
If this is untested area then with some luck some version can support some needed software.
With FAS the key here is to give running VME full IOPL stuff access, but high speed will probably remain to be a dream.
NI card software seems to be much more complex than KPC stuff, but since both TI and NEC chips are pretty simple I guess replacing ISA card is simpler.
One possible direction is setting one of NI PCI cards to be a PCIIA compatible, maybe the setting is even available already, at least that one ISA card has settings for that direction.
Other possibility is to do a PCIe proto board with uPD7210 support and desired I/O address space, that would also be optimal for current FAS, and no secrets are needed to reveal, but driver is needed and PCIe is possibly going to drop the whole I/O system, no doubt it's old and slow, many architectures are missing it completely and memory mapped way has a bit more space.
Version 2.1.1 of gpib.com of GD-GPIB is doing I/O out things quite similarly with CEC ROM.
I wouldn't be very surprised if some of these cards and drivers were swapable.
fenugrec:
--- Quote ---Metrology-grade coax cables are so affordable
--- End quote ---
Haha exactly. Spending as much on cables as the scope itself just didn't appeal to me ...
Of course I'm aware that the T-adapter was a bit of an RF crime, but I reasoned it should be fairly symmetrical in its ugliness. And I think I still proved that a 500 MHz cal is doable with B-team equipment !
--- Quote ---don't know if the TEK software uses CEC488/KPC488.2 drivers
--- End quote ---
I don't believe so, unless it was statically linked and I didn't recognize object file names / strings when sifting through the disasm a few years ago. I vaguely recall the GPIB IO was quite low-level, writing 7210 regs directly, and sprinkled in a bunch of different funcs. It didn't strike me as a structured API I would expect from a general-purpose library. I mean NI has been providing a DOS SDK since forever, and TEK was specifying NI PCII cards, so if anything, they would've used the NI drivers, not those from CEC. I may also be 100% wrong.
I think also FAS doesn't work if you load the NI drivers that stay resident, they interfere with the FAS ? Didn't test this exhaustively.
To clarify : there's a few ways to talk to a GPIB instrument if it's 1992 and you're coding for DOS :
- use the NI drivers that are loaded and resident in memory. Provides a nice high-level API
- statically link NI drivers into FAS; same API
- go full-on hackerman and write 7210 regs directly, because 1992.
I think TEK went with #3, which I cannot explain. If performance was critical why not enforce DMA ? (IIRC it's optional) Also I like to believe the NI drivers would provide some kind of way to benefit from DMA, so how much performance would be gained from going low-level ? And if it's not about performacne then why even bother ? Beats me.
I think there's some CVS (or RCS ?) $Id lines in the .exe with some developper names, it would be interesting to track them down and see what they remember.
RE : that's cool and all, but I think most people wildly underestimate the amount of work involved in reversing software.
In 2017, ghidra wasn't a thing yet, and IDA couldn't (probably still can't, but I haven't renewed since 7.4) digest the MS C overlays found in tds700. I tried a late-90's disasm ("sourcer" something), with better but still disappointing results.
I then made this https://github.com/fenugrec/overlazy to "unfold" the overlays into something IDA could process. Mostly successful, if a bit janky and with serious limitations. It served its purpose (figuring out which parts to hack to support a different-yet-similar ISA card, AT-GPIB) and I haven't developed it further.
Starting today if I had the energy or the motivation (I have neither) I would 100% look instead at processing overlays natively in ghidra. I think it has almost all the mechanisms to support this, just needs some legwork to make it happen. I know there's been a few people who expressed interest for such a thing in various tickets in the ghidra repo but not sure if anything ever came of it.
But maybe a better goal would be to continue where dxl / Sven left off, with a custom build of qemu where you can hook into the IO layer and emulate the 7210. But maybe not viable, depending on the API you plan on using with modern GPIB hw ? As I said FAS is very low-level. I had started down that QEMU path independently before hearing of Sven's work; hacked at it for a few weeks, then gave up for various reasons.
At some point I was also considering making a thin wrapper around an FPGA-based GPIB adapter based on Frank M. Hess's 7210-compatible core : https://github.com/fmhess/fmh_gpib_core but also didn't pursue that.
DC1MC:
@fenugrec welcome, you're most awaited person ;D, being the most advanced with reversing.
With the NI TSR driver I'm a bit confused as well, the @TERRA autoexec.bat seem to load it, but I can make sense if is used or not :(, this overlay shite really screws IDA, the attached listing is without overlays, it produces credible results, but something doesn't smell right, I have seen this used as an anti-reversing measure and always wondered why the DOS loader is not crashing and how the memory map may look like.
Do you think is there some way to unwrap this executable and make it right ?
I personally don't think that intercepting the I/O port access doing, an emulator for the card and staying with the old DOS shite is the best way to go, so far, AFAIK, nobody tackled this seriously, there were some attempts, look at the overlay issues, have the brain shut down looking at the listing and then abandoning, "naaah, is too complicated" :(
But health permitting is still a better way to keep me entertained than the idiot box or cross-words ;).
I think once the structure of the modules is clarified the progress will speed up exponentially, MSC library is available and I attempt to steal some symbols for the math functions, I don't want to go into math instructions.
Well, I hope this effort will not fizzle out as well, the number of people that even know the insides of MSDOS is dwindling rapidly :'(
I've tracked a number of the original developers, one of them is even active in a senior management position at Tek, but I think he'll be fired immediately if even suggest publishing the 30yrs code with the anti-repair trend nowadays, also not hot on divulging PI and I'm rather sure that none will want to help in any meaningful way, their pension may be in danger :scared:.
Cheers,
DC1MC
Zoli:
--- Quote from: DC1MC on February 21, 2023, 12:09:53 am ---...
I think once the structure of the modules is clarified the progress will speed up exponentially, MSC library is available and I attempt to steal some symbols for the math functions, I don't want to go into math instructions.
...
--- End quote ---
To chime in: typically the calibration procedure is to collect readings; calculate the best fit(that's the heavy math; see LINEST() spreadsheet function in calc, excel etc.), upload calibration constants, verify/validate calibration.
If there's interest, I can throw together a spreadsheet to demonstrate the linear/polynomial principles.
TERRA Operative:
--- Quote from: DC1MC on February 21, 2023, 12:09:53 am ---I've tracked a number of the original developers, one of them is even active in a senior management position at Tek, but I think he'll be fired immediately if even suggest publishing the 30yrs code with the anti-repair trend nowadays, also not hot on divulging PI and I'm rather sure that none will want to help in any meaningful way, their pension may be in danger :scared:.
Cheers,
DC1MC
--- End quote ---
Maybe it can' hurt to ask? These scopes are looonnggg out of Tek's catalogue, and they don't mind people doing the Artek thing with selling copies of their manuals...
At the very least, maybe someone can give us a few sneaky hints if not a full source code dump. :D
In hardware related news, I got a delivery today.. :)
A Tyan Tiger 100 motherboard. It has dual ISA so once I get a working second NI GPIB-PCII/IIA card (And the rest of the PC, need a case etc), I'll be able to start playing with the automation side of tests.
Then I'll take a look at getting some sort of 16 channel logic analyzer, something cheap to work with Sigrock to sniff the GPIB busses.
I'm wondering if trying to port the DOS software across to another platform or modify it to use other GPIB cards is the harder way to do it?
If we can find those algorithms used in the adjustment procedure, we can then use them in an OS and GPIB adapter agnostic application of our own making right?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version