Tektronix TDS Scope Field Adjustment Software reverse engineering

[TERRA Operative]

Ok, here we go. Time to try to do away with National Instruments PCII GPIB cards and PC motherboards with ISA slots etc...

This thread is for anyone who is willing and able to help with the reverse engineering and recreation of the Tektronix Field Adjustment Software (FAS) for the TDS line of oscilloscopes.
To start with, this will cover mainly the TDS500/600/700 series scopes, with addition of other lines as testing on those scopes becomes possible.
The TDS200 series scopes do not require any special software as the adjustment procedure is done entirely from the scope controls, but it may be possible to integrate them into our project for automated testing in the future.

Here is my preliminary scope for the project:

- Platform agnostic - The ability to easily compile for the popular operating systems (Windows, Linux, Mac) I have no allegiance to any particular programming language, whatever works best.
- Self contained - No need to rely on other software, browsers, etc, to keep the dependences to a minimum. It's no good if we rely on a 3rd party app that is depreciated or updated to incompatibility a short time later.
- Plug-in type system for scope adjustment procedures - I'm thinking a user editable text file per scope model that defines the test procedures for that scope including switching matrix for automated testing. This will make adding future scopes much easier, maybe even non-Tek scopes too.
- Plug-in type system for GPIB/USB controlled test gear for automated adjustments - As above. This will allow for the use of whatever suitable equipment for adjustment that users have on hand.
- A user friendly UI
- A way to generate a test report at the end for posterity and record keeping.


Now, I have no experience with software development, and I realise that it's simple to make a list of demands. So, I'm hoping there are some others out there that know software enough to get on board and help figure this out.
I have a good lot of TDS600/700 series scopes for testing with, and can work on more of the hardware side of things.

So far I have used 'IDA Pro Free' to somewhat decompile the TDS700D FAS to find the current list of supported test equipment. Not entirely sure what I am doing, but I was able to stumble through to this list:

Code: [Select]

These instruments listed below appear to be compatible with the Tek TDS scope Field Adjustment Software.
The TDS700D .exe file was decompiled to discover this list, and other FAS packages haven't been checked, but the list should be similar.


* Possible allowable categories for entries in 'g-config' file
Dc Dm Osc Sc Cg Pm Sa Sm Atten Cal Fg Ps Sg Rt


* Categories with listed instruments (items without a description are currently unknown)

-Oa
oa5002 : Tek OA5002 1100 to 1600nm singlemode fiber optic attentuator TM5000
oa5012 : Tek OA5012 750 to 1600nm 50um multimode fiber optic attentuator TM5000
oa5022 : Tek OA5022 750 to 1600nm 62.5um multimode fiber optic attentuator TM5000

-Atten (Attenuator)
Tm1095 : Tek 067-1095-99 attenuator TM5000
At5010 : Tek AT5010 50ohm 18GHz programmable attentuator TM5000
At3201t : API/Weinshel 50ohm 3GHz attenuator (With programmable controller)

-Cg (Calibration Generator)
cg5001 : Tek CG5001 Programmable calibration generator TM5000
cg5010 : Tek CG5010 Programmable calibration generator TM5000
cg5011 : Tek CG5011 Programmable calibration generator TM5000

-Dc (Digital Counter)
dc5010 : Tek DC5010 350MHz programmable frequency counter TM5000
dc2465
hp53131a : HP 53131a 225MHz Universal Frequency Counter/Timer

-Pg (Pulse Gen)
wt9500 : WaveTek/Fluke 9500 calibrator

-Ps (Power Supply)
dp8200 : Data Precision 8200 DC volt/current standard
dw4800
fl5100b : Fluke 5100B calibrator
fl5700a : Fluke 5700A multifunction calibrator
ps5004 : Programmable precision DC power supply TM5000
ps5010 : Tek Programmable triple DC power supply TM5000
wt9100f : WaveTek/Fluke 9100 calibrator
wt9100r : WaveTek/Fluke 9100 calibrator
wt9500 : WaveTek/Fluke 9500 calibrator

-Rt
gp700 : Dicon fiber optic switch
hp3488a : HP Switch control unit
rd1200
rd1264
si5020 : Tek DC - 18 GHz microwave switcher TM5000
tsi8150 : Tek Relay driver card mainframe
wt9500 : WaveTek/Fluke 9500 calibrator
vx5020

-Sg (Sinewave Generator)
aps1
aps1b
sp5030
fg5010 : Tek 20MHz signal generator TM5000
fl606 : Fluke 105GHz RF Generator (fluke 6060?)
fl5200a : Fluke programmable AC Calibrator
hp8642a : HP 100kHz to 1050MHz signal generator
hp8656a : HP 100kHz to 990MHz synthesized signal generator
hpesg : HP ESG-series analog RF signal generator
mi2024 : Marconi 2024 9kHz to 2.4GHz synthesized signal generator
sg503 : Tek Leveled sine wave generator TM500 (No GPIB control)
sg504 : Tek Leveled sine wave generator TM500 (No GPIB control)
sg5010 : Tek audio signal generator TM5000
sg5030 : Tek Leveled sine wave generator TM5000
smt03 : Rohde & Schwarz 5kHz to 3GHz RF generator
wt6645b40 : Wiltron 10Mhz to 18GHz 6645 synthesized signal generator
wt6722a20 : Wiltron 10MHz to 12.4GHz 6722 synthesized signal generator
wt6747a20 : Wiltron 10Mhz to 18GHz 6747 synthesized signal generator
wt6759b10 : Wiltron 10Mhz to 26.5GHz 6759 synthesized signal generator
wt6769b2u : Wiltron 10Mhz to 40GHz 6769 synthesized signal generator
wt9100r : WaveTek/Fluke 9100 calibrator
wt9500 : WaveTek/Fluke 9500 calibrator

-Dm (Digital Multimeter)
dm2000
dm2465
dm5010 : Tek 4.5 digit multimeter TM5000
dm5110 : Tek 4.5 digit multimeter TM5000
dm5120 : Tek 6.5 digit multimeter TM5000
fl8840a : Fluke 8840A 5.5 digit multimeter
fl8842a : Fluke 8842A 5.5 digit multimeter
hp3456a : HP 3456a 6.5 digit multimeter
hp3457a : HP 3457a 7.5 digit multimeter
hp3478a : HP 3457a 5.5 digit multimeter

-Fg (Function Generator)
fg5010 : Tek 20MHz signal generator TM5000
hp3325a : HP 20MHz function generator
hp8116a : HP 50MHz 8116A pulse/function generator
wt9100r : WaveTek/Fluke 9100 calibrator
wt9500 : WaveTek/Fluke 9500 calibrator

----------

Additional instruments mentioned in .exe, but maybe only for on-production line diagnostics and troubleshooting or maybe not implemented?

Sa
hp3585a
hp6627a

Sc
scalcf1

Pm
ma6960
hu47770h
hp436a
hp437b
nrvs
hp60500

Sw.Sm.Osc
osc2465
mi5010


From first glance, it would appear that Tek has recycled a lot of code between versions of the FAS for different models of scopes. If we can determine the algorithms used to calculate the calibration offsets, I think they would be similar between scope models.

Basically the adjustment procedure appears to be as follows:

FAS asks user to apply test signal to scope -> User applies signal and hits <return> -> FAS directs scope to take measurements -> FAS acquires data and calculates offsets -> FAS loads offsets into scope EEPROM

The reading and writing process of the EEPROM is known as per this thread also it and other commands and data should be able to be determined from reverse engineering the FAS software and/or sniffing the GPIB comms.



So as it stands now at my end of things is I have a PC and test gear that complies with the original Tek requirements that I am able to successfully adjust a TDS714L scope.
I have just ordered another motherboard with two ISA slots to enable me to run automated cal procedures (Tek specify a second GPIB card for the automated test gear) once I get a second National Instruments ISA PCII/IIA GPIB card.

Any suggestions on a GPIB bus sniffer?




[EDIT] Link to Google Drive folder of all FAS versions I have collected so far:

https://drive.google.com/drive/folders/1nzU_EPE-w0SQ8PnY95D_j9rpL8Mu9YFx?usp=sharing


TDS 500/600/700 Programmers Manual links:
TDS 410, 420, 460, 520A, 524A, 540A, 544A, 620A, 640A, 644A, 684A, 744A, & 784A - 070-8709-06
TDS 410A, 420A, 460A, 520A, 524A, 540A, 544A, 620A, 640A, 644A, 684A, 744A & 784A - 070-8709-07
TDS 410A, 420A, 460A, 520B, 540B, 620B, 644B, 680B, 684B, 724A, 744A & 784A - 070-9556-00
TDS 420A, 430A, 460A, 510A, 520C, 540C, 620B, 644B, 680B, 684B, 724C, 754C, & 784C - 070-9876-00

[TERRA Operative]

A few things of note regarding the test equipment required for the adjustment procedure:

The voltage standard only needs to go to +/-9.5V, so something good for a little more than that will be fine, no need for anything that hits hundreds or even 1000 volts at all. It does need 5 digits of resolution though.
A current source good for 20mA at 5 digits resolution is also needed too.
I think even an adjustable linear regulator like an LM317 with a 10 turn pot measured on a 5.5 or more digit multimeter would be fine for this part.
(I was hoping my Advantest R6144 would be suitable, but it lacks the capability in the current ranges, voltage output is ok though)

A multimeter with a corresponding number of digits (5.5 digits or more) is also needed to enter voltage values when applying the test current.

For a 500MHz scope, the sine generator needs to be capable of 505MHz at  +16 to +17 dBm (4V P-P), for a 1GHz scope, the sine generator needs to go to 1050MHz at the same output level.

[DC1MC]

Well, I want to be the first to congratulate  because I was the first to instigate  .
Some say that the 1000miles journey starts with the first step, this is true, but is still the first step, to reach the end of the journey a lot more needs to be done, here are my organizational proposals:

- a (maybe not very public) repository of the initial software and the results of reversing, I think a private GitHub where access is granted on a one by one basis. I think that sooner, or later, some manufacturer/large or even small calibration lab legal vulture or hyena will be sicked against the project to not let their revenue stream diminish.

- a priority based list of what sw does and why it needs to have its functionality reproduced, to know were to start and what to strive for. That may sound obviously clear for the people that uses frequently the sw, but for me is not clear yet what is needed, and don't think I'm alone.

- a (very public) repository where extracted procedures are transformed in general public useful applications or libraries. We could even use Compaq's "clear room" approach and have as little as possible contact between the two groups.

- a Diversity, Equity and Inclusion policy, no, not the woke shite with CoC and other crap, but if some other useful program is found that is not necessarily a Tek FAS thing it should be included as well, without discrimination  .

- a rewards program, passion and interest are OK, but a piece of gear or a bit of cash goes a long way for a beginner in the field that is eager to help but doesn't have many resources.


Now for a technical bit: GPIB sniffer:

The mother of all protocol decoders Sigrok:
http://sigrok.org/wiki/Protocol_decoder:Ieee488

and as HW for the soldering happy people:

GPIB Sniffer board contributed by ARTAG and improved by  Jay_Diddy_B, as well as AND supported by Sigrock !!!
https://github.com/artgodwin/Sigrok-sniffer

Is cheap and ready for JLCPCB I will order some boards and distribute them in DE if anyone around is interested.

That's it for my first post.

[PA0PBZ]

Subscribed! 

I don't have a TDS but experience with reverse engineering so maybe I can help out. I also found a thread here on the forum that contains some interesting information, it looks like some people already started on the same problem: https://www.eevblog.com/forum/testgear/automating-tektronix-field-adjustment-software-for-tds-oscilloscopes/

 

[TERRA Operative]

I agree with all of the above.
I think having a 'modular' framework where the core software can be configured for multiple pieces of equipment other than Tek scopes is a good idea too. It will make it more useful, more used and hence more likely to stay alive. However, we have to start small and get it working first, but design with a view to expansion.

I'm not 100% up with how github works. I do have an account but I basically never use it, so I may not be the best person to take charge of that with versioning and forks and all that stuff.

[nctnico]

For a 500MHz scope, the sine generator needs to be capable of 505MHz at  +16 to +17 dBm (4V P-P), for a 1GHz scope, the sine generator needs to go to 1050MHz at the same output level.

The required output level is where things get hairy. Most RF generators are not capable of such output levels and the ones that do are expensive. So it would be nice if another source can be used. Like a square wave with steep edges or maybe even the calibrator output on the oscilloscope itself. I have owned a couple of these scopes but got rid of them because they can't be adjusted very easely. I got the software and the GPIB card working at some point but the RF generator was a bridge too far.

All things considered, I think the time aligment between the AD converters is the most important test/adjustment because this is required when uphacking these scopes to a higher bandwidth model. Next would be the ability to apply a DC voltage and adjust the gain. These are the  two things I'd concentrate on first and it would really help if these can be done seperately instead of needing to go through all the calibration / adjustment steps.

[TERRA Operative]

It is possible to use an RF amplifier, here is an adventure someone had in using one on youtube:

[DC1MC]

Subscribed! 

I don't have a TDS but experience with reverse engineering so maybe I can help out. I also found a thread here on the forum that contains some interesting information, it looks like some people already started on the same problem: https://www.eevblog.com/forum/testgear/automating-tektronix-field-adjustment-software-for-tds-oscilloscopes/

Well, I do have an limping TDS744 (three channels only, one ceramic section physically broken  :'( ), but no sw for it, so if GitHub is not OK with you TERRA (you don't actually need to concern with versions and commits, you only need to use it as a file storage and eventually just use the web interface) and experience in reversing.
So if GitHub is not OK, then Google Drive, Dropbox or whatever online storage that is not totally ephemeral.

[DC1MC]

It is possible to use an RF amplifier, here is an adventure someone had in using one on youtube:

OK, someone with a lot of scopes should drag fenugrec here

[DC1MC]

User M K das posted some stuff in the TEA thread, I really don't know if the TEK software uses  CEC488/KPC488.2 drivers and libraries, but if yes, here is where you could download your copy of them for dos, as far as I culd find, this is the latest version for DOS and with development software on it, if you new of a similar but newer one, please post it here:

 CEC488/KPC488.2 SDK
https://www.tek.com/en/support/software/driver/cec488-driver-ver-70-gpib-cards-kpci-488-kpc-4882-kpc-4882at-v70-use-isa-bus-interfaces-and

[TERRA Operative]

Subscribed! 

I don't have a TDS but experience with reverse engineering so maybe I can help out. I also found a thread here on the forum that contains some interesting information, it looks like some people already started on the same problem: https://www.eevblog.com/forum/testgear/automating-tektronix-field-adjustment-software-for-tds-oscilloscopes/

Well, I do have an limping TDS744 (three channels only, one ceramic section physically broken  :'( ), but no sw for it, so if GitHub is not OK with you TERRA (you don't actually need to concern with versions and commits, you only need to use it as a file storage and eventually just use the web interface) and experience in reversing.
So if GitHub is not OK, then Google Drive, Dropbox or whatever online storage that is not totally ephemeral.

I don't mind using github, but I'm not proficient enough to be in charge of it. If someone else is good with it, they can take the reigns there.

Also, PM me, I have a sneaky spare hybrid module. We can't have your scope limping if you are going to be involved with this project.

[TERRA Operative]

User M K das posted some stuff in the TEA thread, I really don't know if the TEK software uses  CEC488/KPC488.2 drivers and libraries, but if yes, here is where you could download your copy of them for dos, as far as I culd find, this is the latest version for DOS and with development software on it, if you new of a similar but newer one, please post it here:

 CEC488/KPC488.2 SDK
https://www.tek.com/en/support/software/driver/cec488-driver-ver-70-gpib-cards-kpci-488-kpc-4882-kpc-4882at-v70-use-isa-bus-interfaces-and

On my DOS PC, I just installed the NI drivers for the PCII/IIA card and it just worked. I'm not sure if the Tek FAS is using the drivers or doing some direct access magic though.

[m k]

[rerouted from TEA thread]

Well, besides not having any clue what program is that from

It's CEC488/KPC488.2 8bit ISA card ROM.
The support disk image I found should have had headers but none were present.
Github had something, but icpdas ftp has more.

If Keithley's ISA card has a ROM chip then it's most likely backwards compatible.
But by default newer cards have ROM disabled so default test fails if ROM is needed.
CEC is noting that only oldies from '80s are using the ROM.

It's a very old construction so it should be known by many.
I guess it would be close to easiest 1st level, a controller construction that supports old software.
After that the 2nd level, the new application software, would be much easier.

Emulating TI/NEC chip registers and their addresses is clearly minimum for FAS.

ROM functions,
"short" is a len parameter length of one byte, must be from PC/XT era and for backwards compatibility.

Code: [Select]

00 init
03 transmit "short"
06 receive "short"
09 send "short"
0c spoll
0f ppoll
12 init 2
15 ? "short"
18 in base+4, test 2
1b in base+4, test 4
1e transmit
21 receive
24 send
27 enter
2a DMA?

c8 tarray (cache RAM)
cb rarray (cache RAM)
ce dma2

ROM code has a fixed I/O address.

Code: [Select]

       c800:0000 e9 dd 00        JMP        LAB_c800_00e0
...
       c800:0062 b8 02           dw         2B8h
...
                             LAB_c800_00e0                                   XREF[1]:     c800:0000(j) 
       c800:00e0 55              PUSH       BP
       c800:00e1 8b ec           MOV        BP,SP
       c800:00e3 50              PUSH       AX
       c800:00e4 52              PUSH       DX
       c800:00e5 b0 02           MOV        AL,0x2
       c800:00e7 2e 8b 16        MOV        DX,word ptr CS:[0x62]
                 62 00
       c800:00ec 83 c2 05        ADD        DX,0x5
       c800:00ef ee              OUT        DX,AL

From CEC's ieee-c.h
Push parameters to stack from left to right.

Code: [Select]

#define initialize(addr,level)          ieee488_initialize(addr,level)
...
#define transmit(cmd,status)            ieee488_transmit((char  *) (cmd),0xFFFF,(long int  *) status)
#define receive(s,maxlen,len,status)    ieee488_receive((char  *) (s),maxlen,(unsigned long  *) len,(long int  *) status)
#define send(addr,s,status)             ieee488_send(addr,(char  *) (s),0xFFFF,(long int  *) status)
#define enter(s,maxlen,len,addr,status) ieee488_enter((char  *) (s),maxlen,(unsigned long  *) len,addr,(long int  *) status)
#define spoll(addr,poll,status)         ieee488_spoll(addr,(char  *) poll,(long int  *) status)
#define ppoll(poll)                     ieee488_ppoll((char  *) poll)
#define tarray(d,count,eoi,status)      ieee488_tarray((void  *) d,count,eoi,(long int  *) status)
#define rarray(d,count,len,status)      ieee488_rarray((void  *) d,count,(unsigned long  *) len,(long int  *) status)
...
#define transmit(cmd,status)            ieee488_transmit((char far *) (cmd),0xFFFF,(int far *) status)
#define receive(s,maxlen,len,status)    ieee488_receive((char far *) (s),maxlen,(unsigned int far *) len,(int far *) status)
#define send(addr,s,status)             ieee488_send(addr,(char far *) (s),0xFFFF,(int far *) status)
#define enter(s,maxlen,len,addr,status) ieee488_enter((char far *) (s),maxlen,(unsigned int far *) len,addr,(int far *) status)
#define spoll(addr,poll,status)         ieee488_spoll(addr,(char far *) poll,(int far *) status)
#define ppoll(poll)                     ieee488_ppoll((char far *) poll)
#define tarray(d,count,eoi,status)      ieee488_tarray((void far *) d,count,eoi,(int far *) status)
#define rarray(d,count,len,status)      ieee488_rarray((void far *) d,count,(unsigned int far *) len,(int far *) status)

#define srq                             ieee488_srq
#define setport(bd,io)                  ieee488_setport(bd,io)
#define boardselect(bd)                 ieee488_boardselect(bd)
#define dmachannel(c)                   ieee488_dmachannel(c)
#define settimeout(t)                   ieee488_settimeout(t)
#define setoutputEOS(e1,e2)             ieee488_setoutputEOS(e1,e2)
#define setinputEOS(e)                  ieee488_setinputEOS(e)
#define enable_488ex(e)                 ieee488_enable_488ex(e)
#define enable_488sd(e,t)               ieee488_enable_488sd(e,t)
#define listener_present(a)             ieee488_listener_present(a)
#define gpib_board_present              ieee488_board_present
#define gpib_feature                    ieee488_feature

BTW,
I had a rude awakening once.
My cli/sti test was very slow, then I bought the Unauthorized Win95 by A. Schulman.

Back in the day there were exceptions, can't remember how many.
Maybe virtual DOS can have a filter driver for ins and outs.
That driver could also create logs and so be a sniffer.

[DC1MC]

@M K & all: I keep hearing about "the driver" that does this and that (including sniffing/logging !!), also contradictory stuff about the calibration program needing or not needing some DOS driver.

Could finally enlighten me on the following topics:

 1) What is the infrastructure needed to run a calibration operation:
- what DOS and with what configuration of the upper memory (HIMEM.sys parameters) ?
- is there any device driver that must installed in config.sys and with what parameters or the the program must run on bare DOS ?
- what are the program(s) need to be run, in which configuration and where can they be found ?

Because I have a feeling that I'm a bit unfocused, I have a coupe of hours of time and I wold happily disassemble/reverse something but without a plan is just wasted time.

[DC1MC]

To summarize, the "One True GPIB Card" that TEK crapoholic software supports is one of the CEC488 also sold as KPC488.2, of which datasheet and programmers manual I have attached here and a message above and the SDK link from TEK I've posted above ?
Anybody can 100% confirm this ?

Please have a look on the files and let me know where I can download the actual software, I want to see if CEC library is linked in.

P.S> BLOODY EXPENSIVE POS  I've looked for how much they're offered, in between 300-500USD !!!, it has to be this one, or else nobody will pay this shitload of money !!!

[DC1MC]

This post where even our fearless TERRA    contributed has links that still work for the FAS and some goodies:

https://www.eevblog.com/forum/testgear/tektronix-tds-series-scopes-field-calibration-software-plus-other-utilities/

@TERRA: Maybe you could edit the first post and add the pointers to the SW ?

 Cheers,
 DC1MC

[timeandfrequency]

It is possible to use an RF amplifier, here is an adventure someone had in using one on youtube:

Youtube  video   v=wSqTj4gGCJ

OK, someone with a lot of scopes should drag fenugrec here

Hi all,

Pretty interesting sequence.
Performing the manual calibration sequence takes a huge amont of time, that's why cal benches are as much as possible automated.
But luckily, if the recommended software controlled test gear is not available, using alternate TE is still possible in manual mode.

When @fenugrec started the high frequency calibration, I was surprised that he used clothesline quality coax cable (RG58) between the RF generator and the DUT.
But he figured it out where the mistake was located, and nicely compensated manually for the cable loss.
Metrology-grade coax cables are so affordable...

For the channel sync setup, using a basic T-BNC ruins impedance matching and leads to spurious reflections in the cables. A 50 Ohm power splitter and matched cables would have been a better choice, if available.

[DC1MC]

OK, in MY archives I've discovered this gem (attached), could anyone confirm that is the real deal for TDS7xx series ?

[TERRA Operative]

To run a cal routine (fully successfully) in my case, here is what I used on the PC side:

- PC with ISA slot on the motherboard (I have a Dell Precision MT410)
- National Instruments GPIB-PCII/IIA GPIB card
- DOS v6.22
- NI drivers installed and configured (along with jumpers on the card and BIOS settings) for the default Tek FAS settings (see below).

Attached to this post is my Autoexec.bat and config.sys (I renamed the file extensions to prevent Windows from hiding the files).



The National Instruments 'GPIBInfo' app says this about my setup:

Code: [Select]

Software Information:
The NI-488.2 Software for MS-DOS is loaded.
You are running Version 2.6 for the GPIB-PCIIA board.
It supports both the NI-488 functions and NI-488.2 routines.
It does not support the HS488 high-speed protocol.

Hardware Information:
GPIB0: GPIB-PCIIA board using the NAT4882 chip.
It supports both the NI-488 functions and NI-488.2 protocols.
It does not support the HS488 high-speed protocol.
It uses base I/O address 0x2e1.
It uses interrupt level 7.
It uses DMA channel 1.


The TDS Scope service manual has the following to say:

Adjustment of this oscilloscope requires a computer with hard drive, 3.5 inch 1.44 MByte floppy drive, and the following items:
For DOS software:
- An IBM PC compatible computer running DOS 3.2 or higher. A math coprocessor is strongly recommended.
- 640K resident RAM with 580 K available RAM.
- A GPIB board — National Instruments GPIB-PCII, GPIB-PCIIA or GPIB-PCII/IIA. (A PC-GPIB Package that includes the PCII/IIA is available — Tektronix part number S3FG210)

For Windows NT software:
- An Intel compatible computer running Windows NT.
- A GPIB board and software — National Instruments AT–GPIB/TNT, Windows NT (INTEL).


Now that last bit is interesting, I have never seen the Windows NT software........................


And also attached to this post is the TDS700D version of the Field Adjustment Software, as installed on my machine.
This is how it is unpacked and installed ready for use, using the GPIB addresses etc above, so is good for decompilation etc.

[TERRA Operative]

OK, in MY archives I've discovered this gem (attached), could anyone confirm that is the real deal for TDS7xx series ?

Yep, it's a valid version.

I just edited the original post with a link to Google drive with all the FAS versions I have.
These are the install files, so they are copied to floppy disk and installed on the PC used for calibration which unpacks all the actual software and config files.

[DC1MC]

OK, in MY archives I've discovered this gem (attached), could anyone confirm that is the real deal for TDS7xx series ?

Yep, it's a valid version.

I just edited the original post with a link to Google drive with all the FAS versions I have.
These are the install files, so they are copied to floppy disk and installed on the PC used for calibration which unpacks all the actual software and config files.

OK, so far so good, but now comes the question: is there any connection between this NI card and the above mentioned CEC488/KPC488.2 cards for which we have the SDK or they are unrelated to our stuff ?

[TERRA Operative]

AFAIK, the Tek FAS will only see the NI GPIB-PCII/IIA cards. I've never tried anything else to see. I only have an IOtech ISA GPIB card (a Personal488, GP488B version) besides the PCII/IIA one.

If I can get my hands on a CEC488/KPC488.2 card, I can test it, but may be difficult here in Japan.


Also, I added links to some programmers manuals to the first post too, might give us some ideas.

[DC1MC]

AFAIK, the Tek FAS will only see the NI GPIB-PCII/IIA cards. I've never tried anything else to see. I only have an IOtech ISA GPIB card (a Personal488, GP488B version) besides the PCII/IIA one.

If I can get my hands on a CEC488/KPC488.2 card, I can test it, but may be difficult here in Japan.


Also, I added links to some programmers manuals to the first post too, might give us some ideas.

Is there a SDK for these NI cards as well, as for the CEC488/KPC488.2, if so, where ? I'll enjoy having the headers and LIBs.

[TERRA Operative]

AFAIK, the Tek FAS will only see the NI GPIB-PCII/IIA cards. I've never tried anything else to see. I only have an IOtech ISA GPIB card (a Personal488, GP488B version) besides the PCII/IIA one.

If I can get my hands on a CEC488/KPC488.2 card, I can test it, but may be difficult here in Japan.


Also, I added links to some programmers manuals to the first post too, might give us some ideas.

Is there a SDK for these NI cards as well, as for the CEC488/KPC488.2, if so, where ? I'll enjoy having the headers and LIBs.

Hmm, after a few edits to this post, this is as close as I got:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019QOfSAM&l=en-US

https://www.ni.com/docs/en-US/bundle/ni-488.2-feature/page/programming-with-ni-4882-software.html#

I swear I was able to download drivers before, but not sure on an SDK.

Ah ha!

https://download.ni.com/#support/gpib/doswin3/gpib-pcii.iia/488.2/

Also drivers I am using are attached to this post.

[DC1MC]

The DOS drivers and SDK for NI cards are here:

http://download.ni.com/#support/gpib/doswin3/

more specifically here:
http://download.ni.com/#support/gpib/doswin3/gpib-pcii.iia/

the FTP server does not allow anonymous login anymore

Now let's see what goodies are there 

[m k]

From earlier mentioned fork thread I'd say that TI/NEC chip or register level compatible and equally connected is accepted.
Can't be sure though, but the old card is also practically nothing more than a chip and a ROM, and optional RAM.

Needed drivers can be tested.
Newer CEC/KPC card has ROM disabled by default.
Leave it like that and try using it without drivers.
Then enable ROM to CC00 or so and try again.

If polling method is used then drivers are not needed, sill a bad practice.

Personal488 seems to be NI compatible.
It has more components than CEC so maybe CEC was first and then NI shuffled register addresses of the same chip.
Then others followed former or latter model.
This board's IOT7210 doesn't seem to be very far from the original copy either.

[TERRA Operative]

So I found this while sorting through stuff on my PC, it seems to have some programming examples in various languages.

National Instruments GPIB-PCII/IIA Win95-98 drivers:
https://drive.google.com/file/d/1MUKwPHVAb4Bpsc41y0qHyrL66hzbH0Y9/view?usp=sharing

[m k]

uPD7210 and TMS9914 are not equals nor register compatible.

NI 8bit ISA card
PCII uPD7210C chip, no ROM.
PCII/IIA VLSI or NI ASIC chip with ROM and 7210/9914 and PCII/PCIIA dip switches.
PCII/IIA-R a bit different layout.
PCIIA uPD7210C chip, no ROM.
PCIIB TMS9914A chip, no picture.

NI 16bit ISA card
AT-GPIB/TNT (c)'93 a single chip thing, low DMA settings are missing and last address digit is always zero.
AT-GPIB/TNT (c)'95 dual ASIC thing without manual settings.
AT-GPIB dual ASIC thing with manual settings and ROM.
AT-GPIB (c)'90 PLCC sockets, NI TURBO488 chip, no rom.

DMA is not usually required and 8bit card can set last address digit to zero.

[DC1MC]

Well then,
due to some health shite I could not give 100%, but now that I have a (short) break being poked and prodded and used as a needle pillow  :'(, let's put a bit this show on the road, I have given a first pass over the installed software archive posted by @TERRA.
There are two executable files and on other binaries: libraries, overlays and such, just big fat static executable, the memory management is left to Microsoft C for DOS runtime, which is a pain (see later):

Code: [Select]

14921 Feb 19  1999 ASK3C4C.EXE
783572 Jan 20  2000 TDS700CG.EXE

I have no rotating clue what ASK3C4C.EXE is, but I'm eager to find out, please help here.
So the first victim is TDS700CG.EXE, a big fat 750KB executable, that is quite depressingly large , but there is a silver lining, they didn't use any compressors, obfuscators and shit like that and the organization is pretty logical, in nicely separate modules and it seems that the WHOLE library is liked there, including some of their internal modules with tests that say as an error message: "If you see this call Cathy at 1225342!!!"  .

Actually by just looking at referenced functions it seems that the calibration program front-end for the library actually exposes a very small percentage of the available functions !!!, this could be a false result given by the fact that IdaPro has a gadzillion of fails when I analyze the executable with overlays and the fact that it doesn't know about the Microsoft C for DOS compiler from 1988 (most likely 5.x or 6.x, widely available on net and I'll se if we can get some standard library addresses). . So if you look into the attached file you'll see now and then the "SP Analysis Failed" at end of functions

But it is as it is, I have attached, along with the ASM listing, the IdaPro database, I did already the tedious conversion to ASCII of some messages and corrected some auto-parsing stuff, if someone has a better Ida analyze,please share.

Now let's look at the library, there are 179 modules, if you look into the file listing and in the ASM listing you see that the help files (.HLP) have exactly the same name as the .c module linked in, this is nice, you'll also recognize as the name of the module some famous instrument names, so is most certain that that module deals with that instrument. Most of the names are self explanatory as well, for example a2d_off may or may not deal with Analogue to Digital Offset calibration .

So, IMHO, we need to determine the structure of the modules (humble me I'll try with beep.c, but feel free get more complex ones , as well ass the parser for the "Blenoragic LISP (TM)"  configuration files syntax (qconfig.c module maybe  ?!?).

HELP REQUEST: I can't determine for now, could someone (@TERRA) try to start the calibration program WITHOUT the card driver loaded, I want to see if it's used at all for PCII or PCII/II cards for the callibration process, if it is, I have to see what IOCTLS offers, if not, I will ignore it for the moment.

Later I will try a GHIDRA analyze as well, I'll recover from the tiredness and meds, but now is the moment for the reversers to step in.

Code: [Select]

'$Id: a2d_off.c,v 1.1 1994/08/02 22:44:13 claudr Exp $',0
'$Id: accoupl.c,v 1.4 1999/05/27 16:09:26 nucats Exp $',0
'$Id: acqrate.c,v 1.2 1995/04/13 21:36:53 rona Exp $',0
'$Id: at5010.c,v 7.3 1994/09/13 21:49:38 catsos Exp $',0
'$Id: atten.c,v 1.2 1999/02/02 22:21:16 nucats Exp $',0
'$Id: beginend.c,v 1.12 1999/07/04 02:25:47 dougro Exp $',0
'$Id: bitslo.c,v 1.2 1995/04/13 21:37:05 rona Exp $',0
'$Id: btl_pms.c,v 1.11 1999/07/02 16:26:26 michaelp Exp $',0
'$Id: busywait.c,v 1.2 1995/04/13 21:37:12 rona Exp $',0
'$Id: bwlimit.c,v 1.4 1999/05/27 16:10:36 nucats Exp $',0
'$Id: calstat.c,v 1.37 1999/11/24 22:12:00 claudr Exp $',0
'$Id: cg5001.c,v 7.0 1992/10/12 22:26:26 stefanus Exp $',0
'$Id: cg.c,v 7.1 1992/10/12 22:51:59 stefanus Exp $',0
'$Id: chaniso.c,v 1.6 2000/01/11 21:21:20 aaronan Exp $',0
'$Id: chkspec.c,v 1.9 1999/07/01 20:53:27 nucats Exp $',0
'$Id: clkacc.c,v 1.5 1999/07/05 05:47:47 nucats Exp $',0
'$Id: cntl_interface.c,v 7.4 1997/04/04 17:14:06 catsos Exp $',0
'$Id: cntl_lex.c,v 7.2 1994/10/27 19:57:08 catsos Exp $',0
'$Id: cntl_misc.c,v 7.1 1994/10/27 19:57:10 catsos Exp $',0
'$Id: cntl_parse_1.c,v 7.1 1992/10/12 22:54:23 stefanus Exp $',0
'$Id: cntl_parse_2.c,v 7.1 1992/10/12 22:55:19 stefanus Exp $',0
'$Id: cntl_parse_3.c,v 7.1 1992/10/12 22:56:25 stefanus Exp $',0
'$Id: cntl_parse_4.c,v 7.3 1994/09/13 21:50:49 catsos Exp $',0
'$Id: cntl_parse_5.c,v 7.3 1995/02/10 21:16:34 catsos Exp $',0
'$Id: cntl_par_seq.c,v 7.1 1992/10/12 22:53:18 stefanus Exp $',0
'$Id: coldstar.c,v 1.3 1994/10/06 22:44:58 claudr Exp $',0
'$Id: config.c,v 1.3 1999/02/02 22:21:16 nucats Exp $',0
'$Id: constant.c,v 1.2 1995/04/13 21:37:20 rona Exp $',0
'$Id: counter.c,v 1.1 1998/01/19 19:26:25 catsos Exp $',0
'$Id: curvetov.c,v 1.2 1995/04/13 21:37:26 rona Exp $',0
'$Id: cvrcal.c,v 1.9 1999/06/23 21:56:56 michaelp Exp $',0
'$Id: datetime.c,v 1.3 1999/05/27 17:30:17 nucats Exp $',0
'$Id: dc5010.c,v 7.8 1998/01/19 19:37:40 catsos Exp $',0
'$Id: dc.c,v 1.3 1999/02/02 22:21:16 nucats Exp $',0
'$Id: delay.c,v 1.8 1999/05/06 22:17:47 nucats Exp $',0
'$Id: diags.c,v 1.5 1999/06/15 18:06:57 loch Exp $',0
'$Id: diffnonl.c,v 1.7 1999/07/05 02:08:02 nucats Exp $',0
'$Id: dm5110.c,v 1.3 1999/11/10 21:58:51 nucats Exp $',0
'$Id: dm.c,v 1.1 1999/01/07 17:12:14 nucats Exp $',0
'$Id: dp8200.c,v 7.1 1996/07/18 21:10:16 catsos Exp $',0
'$Id: drvr_gio.c,v 1.6 1999/08/31 20:22:52 nucats Exp $',0
'$Id: drvr_misc.c,v 7.4 1994/09/13 22:02:25 catsos Exp $',0
'$Id: drvr_parse.c,v 7.1 1994/10/27 19:57:15 catsos Exp $',0
'$Id: drvr_util.c,v 7.2 1994/10/27 19:57:16 catsos Exp $',0
'$Id: dutgpib.c,v 1.4 1999/10/06 19:07:51 nucats Exp $',0
'$Id: dutintfc.c,v 1.2 1999/11/11 16:05:43 nucats Exp $',0
'$Id: dutio.c,v 1.2 1999/08/31 20:22:52 nucats Exp $',0
'$Id: effbits.c,v 1.2 1999/07/05 05:47:47 nucats Exp $',0
'$Id: eisnum.c,v 7.2 1994/09/13 22:33:03 catsos Exp $',0
'$Id: errlog.c,v 1.5 1995/03/23 00:23:07 claudr Exp $',0
'$Id: fg5010.c,v 7.2 1998/01/19 19:37:40 catsos Exp $',0
'$Id: fg.c,v 7.4 1998/01/19 19:25:16 catsos Exp $',0
'$Id: fl6060a.c,v 7.3 1997/01/16 19:49:02 catsos Exp $',0
'$Id: fl8840a.c,v 7.3 1997/11/10 19:12:27 catsos Exp $',0
'$Id: fltosi.c,v 7.1 1992/10/12 23:03:34 stefanus Exp $',0
'$Id: flushsrq.c,v 1.2 1995/04/13 21:37:45 rona Exp $',0
'$Id: getbits.c,v 1.3 1995/04/13 21:37:51 rona Exp $',0
'$Id: getchan.c,v 1.7 2000/01/18 17:18:59 aaronan Exp $',0
'$Id: getinsid.c,v 1.12 1999/08/06 18:05:30 datt Exp $',0
'$Id: getsn.c,v 1.11 1999/05/27 17:31:52 nucats Exp $',0
'$Id: globals.c,v 7.5 1996/09/11 15:20:50 catsos Exp $',0
'$Id: hfcal.c,v 1.26 1999/12/07 18:09:44 aaronan Exp $',0
'$Id: hyd.c,v 7.1 1993/09/22 16:22:29 catsos Exp $',0
'$Id: initdut.c,v 1.6 1999/05/27 17:32:38 nucats Exp $',0
'$Id: init_instr.c,v 7.22 1998/01/19 19:26:25 catsos Exp $',0
'$Id: inittgl.c,v 1.5 1999/07/01 20:53:27 nucats Exp $',0
'$Id: inputr.c,v 1.10 1999/06/21 23:21:44 datt Exp $',0
'$Id: intglnonl.c,v 1.6 1998/06/19 20:49:16 nucats Exp $',0
'$Id: intradj.c,v 1.12 1999/11/24 21:20:53 claudr Exp $',0
'$Id: intrleav.c,v 1.25 1999/11/24 21:10:05 claudr Exp $',0
'$Id: intrmisc.c,v 1.16 1999/11/24 21:15:36 claudr Exp $',0
'$Id: intrpipe.c,v 1.13 1999/11/24 22:10:08 claudr Exp $',0
'$Id: iosig.c,v 1.7 1999/10/19 18:59:31 claudr Exp $',0
'$Id: iscalqc.c,v 1.4 1999/07/01 20:53:27 nucats Exp $',0
'$Id: Logce.c,v 7.4 1995/11/08 16:41:54 catsos Exp $',0
'$Id: Logd.c,v 1.3 1999/08/12 15:44:55 nucats Exp nucats $',0
'$Id: Logmisc.c,v 1.2 1999/02/02 22:21:16 nucats Exp nucats $',0
'$Id: Logsf.c,v 1.2 1999/08/12 15:45:50 nucats Exp $',0
'$Id: Logsh.c,v 1.2 1999/02/02 22:21:16 nucats Exp nucats $',0
'$Id: Logtf.c,v 1.4 1999/08/31 20:04:59 nucats Exp nucats $',0
'$Id: Logth.c,v 1.3 1999/08/12 15:48:01 nucats Exp nucats $',0
'$Id: manint.c,v 1.7 1999/06/23 22:52:01 michaelp Exp $',0
'$Id: manroute.c,v 1.5 1999/06/23 22:57:20 michaelp Exp $',0
'$Id: menu_bclear.c,v 7.1 1992/10/12 23:18:25 stefanus Exp $',0
'$Id: menu_benter.c,v 7.1 1994/09/14 15:14:22 catsos Exp $',0
'$Id: menu_binst.c,v 7.0 1992/10/12 22:27:57 stefanus Exp $',0
'$Id: menu_binter.c,v 7.1 1992/10/12 23:19:21 stefanus Exp $',0
'$Id: menu_bmsg.c,v 7.1 1992/10/12 23:20:04 stefanus Exp $',0
'$Id: menu_bscroll.c,v 7.2 1994/10/27 19:57:31 catsos Exp $',0
'$Id: menu_bsel.c,v 7.4 1995/08/18 16:39:06 catsos Exp $',0
'$Id: menu_bstr.c,v 7.0 1992/10/12 22:28:08 stefanus Exp $',0
'$Id: menu_bwarn.c,v 7.0 1992/10/12 22:28:09 stefanus Exp $',0
'$Id: menu_foot.c,v 7.2 1994/10/27 19:57:34 catsos Exp $',0
'$Id: menu_head.c,v 7.1 1992/10/12 23:20:56 stefanus Exp $',0
'$Id: menu_init.c,v 7.2 1994/10/27 19:57:34 catsos Exp $',0
'$Id: menu_inp.c,v 7.2 1998/03/02 20:36:46 catsos Exp $',0
'$Id: menu_pwarn.c,v 7.2 1994/10/27 19:57:36 catsos Exp $',0
'$Id: multigpi.c,v 1.7 1999/07/01 20:53:27 nucats Exp $',0
'$Id: multitxt.c,v 1.4 1999/07/01 20:53:27 nucats Exp $',0
'$Id: oa5000.c,v 1.3 1998/08/27 18:04:08 catsos Exp $',0
'$Id: oa.c,v 1.2 1997/03/19 17:39:58 catsos Exp $',0
'$Id: operset.c,v 1.1 1994/06/28 17:18:02 claudr Exp $',0
'$Id: os_active.c,v 7.6 1997/03/18 16:40:53 catsos Exp $',0
'$Id: os_chg_control.c,v 7.3 1998/02/23 20:05:28 catsos Exp $',0
'$Id: os_color.c,v 7.1 1994/10/27 19:57:38 catsos Exp $',0
'$Id: os_endmenu.c,v 7.2 1998/03/20 16:41:43 catsos Exp $',0
'$Id: os_env.c,v 1.2 1999/08/31 20:22:52 nucats Exp $',0
'$Id: os_err.c,v 7.1 1992/10/12 23:22:43 stefanus Exp $',0
'$Id: os_fileio.c,v 7.6 1995/06/22 13:38:36 catsos Exp $',0
'$Id: os_help.c,v 7.1 1993/09/22 16:23:11 catsos Exp $',0
'$Id: os_hlpdisplay.c,v 7.2 1994/10/27 19:57:41 catsos Exp $',0
'$Id: os_hlpmisc.c,v 7.2 1994/09/14 15:58:51 catsos Exp $',0
'$Id: os_interrupt.c,v 7.3 1994/10/27 19:57:43 catsos Exp $',0
'$Id: os_main.c,v 1.5 1999/08/31 20:22:52 nucats Exp $',0
'$Id: os_misc.c,v 7.4 1997/02/14 23:01:03 catsos Exp $',0
'$Id: os_pctime.c,v 7.1 1994/10/27 19:57:48 catsos Exp $',0
'$Id: os_route.c,v 7.1 1994/10/27 19:57:49 catsos Exp $',0
'$Id: os_route_init.c,v 7.1 1994/10/27 19:57:51 catsos Exp $',0
'$Id: os_run_proc.c,v 7.1 1998/03/20 16:40:59 catsos Exp $',0
'$Id: os_sel_dut.c,v 1.2 1999/08/31 20:22:52 nucats Exp $',0
'$Id: os_sel_mode.c,v 7.4 1998/01/19 19:24:35 catsos Exp $',0
'$Id: os_sel_proc.c,v 7.5 1998/05/20 16:49:33 catsos Exp $',0
'$Id: os_sel_test.c,v 7.0 1992/10/12 22:28:44 stefanus Exp $',0
'$Id: overload.c,v 1.6 1999/07/05 02:08:02 nucats Exp $',0
'$Id: pcompcal.c,v 1.7 1999/06/24 16:40:46 michaelp Exp $',0
'$Id: pcompchk.c,v 1.6 1999/06/02 20:11:22 michaelp Exp $',0
'$Id: pfcheck.c,v 1.2 1996/04/24 16:17:50 datt Exp $',0
'$Id: pg.c,v 1.1 1998/01/19 19:25:16 catsos Exp $',0
'$Id: pgsetup.c,v 1.2 1995/04/13 21:38:08 rona Exp $',0
'$Id: pipebal.c,v 1.3 1999/06/02 20:22:33 michaelp Exp $',0
'$Id: pmeasure.c,v 1.5 1999/07/02 14:47:51 nucats Exp $',0
'$Id: pnpltcal.c,v 1.3 1997/06/30 14:41:11 michaelp Exp $',0
'$Id: presult.c,v 1.5 1999/09/21 14:52:45 nucats Exp $',0
'$Id: ps.c,v 7.7 1998/02/04 21:48:06 catsos Exp $',0
'$Id: psDmISet.c,v 1.2 1998/05/19 03:24:30 michaelp Exp $',0
'$Id: ps_man.c,v 1.1 1997/07/10 18:11:36 cats Exp nucats $',0
'$Id: pwr_cycl.c,v 1.3 1994/08/26 22:37:28 claudr Exp $',0
'$Id: qconfig.c,v 1.3 1999/07/04 05:16:59 dougro Exp $',0
'$Id: rdutlib.c,v 1.6 1995/04/13 21:38:28 rona Exp $',0
'$Id: resultsm.c,v 1.6 1999/07/01 20:28:16 nucats Exp $',0
'$Id: ringbell.c,v 1.16 1999/03/03 15:48:04 nucats Exp $',0
'$Id: rndnoise.c,v 1.3 1999/05/27 16:29:09 nucats Exp $',0
'$Id: rrcvrcal.c,v 1.14 1999/06/08 22:09:47 danmc Exp $',0
'$Id: rt.c,v 7.9 1998/01/19 19:24:35 catsos Exp $',0
'$Id: scaleuni.c,v 1.5 1999/07/01 20:53:27 nucats Exp $',0
'$Id: selsec.c,v 1.5 1999/07/14 20:46:26 michaelp Exp $',0
'$Id: seq_pf.c,v 7.1 1992/10/12 23:48:50 stefanus Exp $',0
'$Id: setnvram.c,v 1.2 1995/04/13 21:38:36 rona Exp $',0
'$Id: setupdut.c,v 1.13 1999/05/27 17:35:14 nucats Exp $',0
'$Id: sg5030.c,v 7.3 1998/01/19 19:37:40 catsos Exp $',0
'$Id: sg.c,v 7.16 1998/10/27 22:28:05 catsos Exp $',0
'$Id: shipdoc.c,v 1.14 1999/07/02 00:23:44 dougro Exp $',0
'$Id: si5020.c,v 7.5 1998/10/27 22:28:05 catsos Exp $',0
'$Id: snvalflg.c,v 1.2 1996/05/07 17:14:55 rona Exp $',0
'$Id: spc.c,v 1.3 1996/04/24 16:19:00 datt Exp $',0
'$Id: srchmisc.c,v 1.6 1999/05/26 18:53:13 nucats Exp $',0
'$Id: startend.c,v 1.19 1999/05/27 19:45:00 nucats Exp $',0
'$Id: stenmisc.c,v 1.12 1999/07/01 20:28:16 nucats Exp $',0
'$Id: stubremoveDut.c,v 1.1 1996/04/09 19:40:46 catsos Exp $',0
'$Id: t_acc.c,v 1.3 1998/06/03 17:45:30 jimk Exp $',0
'$Id: t_dsens.c,v 1.2 1999/05/27 16:30:18 nucats Exp $',0
'$Id: t_gacc.c,v 1.1 1994/06/28 17:18:48 claudr Exp $',0
'$Id: th.c,v 7.2 1993/09/22 16:24:20 catsos Exp $',0
'$Id: t_jitter.c,v 1.2 1999/05/27 16:32:01 nucats Exp $',0
'$Id: tmode.c,v 1.5 1999/07/01 20:53:27 nucats Exp $',0
'$Id: t_msens.c,v 1.2 1999/05/27 16:33:36 nucats Exp $',0
'$Id: t_pacc.c,v 1.1 1999/06/09 22:02:47 loch Exp $',0
'$Id: tposcal.c,v 1.15 1999/08/13 20:15:54 sonn Exp $',0
'$Id: tposchk.c,v 1.8 1998/07/30 15:18:26 danmc Exp $',0
'$Id: trigsens.c,v 1.3 1995/11/28 23:55:57 claudr Exp $',0
'$Id: tsterror.c,v 1.4 1999/07/01 20:53:27 nucats Exp $',0
'$Id: tstmaloc.c,v 1.5 1999/07/01 20:53:27 nucats Exp $',0
'$Id: util_sleep.c,v 1.4 1999/11/02 22:20:00 nucats Exp $',0
'$Id: v_bal.c,v 1.3 1999/06/16 23:49:19 datt Exp $',0
'$Id: v_bw.c,v 1.6 1998/04/23 23:42:49 michaelp Exp $',0
'$Id: v_gain.c,v 1.7 1999/05/27 16:37:44 nucats Exp $',0
'$Id: v_hfstep.c,v 1.6 1999/09/14 17:47:26 claudr Exp $',0
'$Id: v_lfstep.c,v 1.6 1998/05/25 22:26:12 danmc Exp $',0
'$Id: v_off.c,v 1.7 1999/07/07 00:09:06 datt Exp $',0


[TERRA Operative]

Good work!

I'm off to Canada for a week or so to stare at the aurora borealis and buy some western clothes and shoes that fit me.... But when I'm back in Japan, I'll have time to poke at things and play around.

[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]

Metrology-grade coax cables are so affordable

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 !

don't know if the TEK software uses  CEC488/KPC488.2 drivers

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  , 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  .

Cheers,
DC1MC

[Zoli]

...
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.
...

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]

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  .

Cheers,
DC1MC

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.


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?

[PA0PBZ]

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?

I think that is the way to go. It looks like the .CON files are a description of how the tests are done, so once there is a full understanding of the descriptive language in there nothing stops you from doing the communication with the TDS any way you like, it even tells you the commands (I think?):

Code: [Select]

TEXT = MF_SET_GLO (
":SELECT:CH1 OFF;CH2 OFF;CH3 OFF;CH4 OFF"
":SELECT:CH2 ON"
":CH2:BANDWIDTH TWENTY"
":TRIGGER:MAIN:EDGE:SOURCE LINE"
":HORIZONTAL:SCALE 1E-3"
":HORIZONTAL:RECORDLENGTH 5000"
":ACQUIRE:MODE HIRES"
":PASSWORD PITBULL"
)
I also tried to load the code in IDA but it pukes out most of the code because of the overlayed nature and Ghidra was not much better.

[fenugrec]

but something doesn't smell right, I have seen this used as an anti-reversing measure

In this case overlays are simply a way to use less memory at runtime. With a horrible penalty everytime an overlay is swapped but hey, those were the days of "RAMdisks" too... The MS 5.1 compiler docs have a good chapter on overlays, how & why to use them.

always wondered why the DOS loader is not crashing and how the memory map may look like.

What do you mean by DOS loader crashing ?

As for the memory map, in the 'overlazy' docs I have some ASCII graphs attempting to show the memory map.

MSC library is available and I attempt to steal some symbols for the math functions

I think I managed to generate signatures for MSC libs but I had trouble with PDCurses. I'm fairly certain they're using PDCurses 1.4, but I wasn't able to figure out the correct compiler switches to generate binary-identical functions. PDC has some .asm modules, and those eventually produced signatures that IDA was able to identify in the .exe. Less luck with the C functions. Here's an excerpt from my notes trying different compiler flags :

Code: [Select]

comparing update.c::Putchar() , tests :

0 "CFLAGS=-M$(MODEL) -c -Ox -W2" ; missing _chkstack, doesn't use opcode "cwb"
1 "CFLAGS=-M$(MODEL) -c -Oails -W2" : chkstack ok; uses sar ? wtf. Also missing pushpop si+di
2 "CFLAGS=-M$(MODEL) -c -Oail -W2" : sar, but cwb ! Almost. No si+di
3 CFLAGS=-M$(MODEL) -c -W2 : same
4 CFLAGS=-M$(MODEL) -c -G2 -W2 : same
5 CFLAGS=-M$(MODEL) -c -Od -W2 : lol : again sar, but SI+DI !
That said, as I recall the pdc functions are all next to each other and should be fairly recognizable; it's a beginner-friendly task to manually map them by hand. Signatures would definitely have been nice though...
If you want to port the software, I think it would save work to keep the same UI for now, since there are still plenty of curses implementations (including pdcurses) with probably all the same/similar API. This means TEK's in-house "CATS-OS" layer can be re-compiled mostly as-is, without needing to re-design it from scratch.

Do you think is there some way to unwrap this executable and make it right ?

Yes, the 'overlazy' tool I linked previously does exactly that. It will create an unwrapped, but non-executable, .exe file.

sniff the GPIB busses.

Remember you could also sniff the register accesses to the 7210 IC directly - IIRC it's 3 address lines, a few R/W and misc control lines, and one 8-bit data port. This may give more information than just a bus capture.

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

It's a good question. Doing a full port of the software is a massive undertaking. Judging by the amount of soft-float functions in there, it's possibly also doing some DSP stuff to process acquisitions, it's not just reading a script.

But please, people, use a decompiler, don't just stare at 700kB of x86 asm trying to understand everything. You will never finish.

PS - I have found forum threads to be a mediocre medium for collaborating on substantial RE efforts, where sub-discussions branch out a lot, sometimes go dormant for a while, etc... For general discussions and progress reports, sure, but for in-depth technical stuff, not great.
For documenting findings and technical details, a wiki can be an alternative. Else, some kind of git-versioned, categorized text files might also work.

One thing I'd be curious to try someday is using ghidra with a shared server (e.g. https://www.ghidra-server.org/ ) to collaborate on a single db. Though I would probably want to run ghidra in a sandbox / VM before doing that.

[m k]

TDS700CG.EXE from TERRA's ZIP

0xac1c jbe +6

How that area should be disassembled?


Same file and I found only one I/O out that is not floating point something.

Code: [Select]

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             undefined FUN_379e_1b08(undefined2 param_1, undefined1 p
                               assume CS = 0x379e
             undefined         AL:1           <RETURN>
             undefined2        Stack[0x4]:2   param_1                                 XREF[1]:     379e:1b0b(*) 
             undefined1        Stack[0x6]:1   param_2                                 XREF[1]:     379e:1b0e(*) 
                             FUN_379e_1b08                                   XREF[70]:    FUN_239c_01fc:239c:0223(c),
                                                                                          FUN_239c_01fc:239c:0232(c),
                                                                                          FUN_239c_01fc:239c:0241(c),
                                                                                          FUN_239c_01fc:239c:0263(c),
                                                                                          FUN_239c_01fc:239c:02c9(c),
                                                                                          FUN_359a_0008:359a:0068(c),
                                                                                          FUN_35ad_0000:35ad:0063(c),
                                                                                          FUN_35ad_0000:35ad:00b3(c),
                                                                                          FUN_35e3_0002:35e3:0130(c),
                                                                                          FUN_35e3_0002:35e3:014a(c),
                                                                                          FUN_35e3_0002:35e3:017f(c),
                                                                                          FUN_35e3_0002:35e3:0198(c),
                                                                                          FUN_3601_0008:3601:02cf(c),
                                                                                          FUN_3601_0008:3601:0366(c),
                                                                                          FUN_3601_0008:3601:037f(c),
                                                                                          FUN_3601_0008:3601:0398(c),
                                                                                          FUN_3601_0008:3601:03bb(c),
                                                                                          FUN_3601_0008:3601:03d5(c),
                                                                                          FUN_3601_0008:3601:03ef(c),
                                                                                          FUN_3601_0008:3601:0409(c), [more]
       379e:1b08 55              PUSH       BP
       379e:1b09 8b ec           MOV        BP,SP
       379e:1b0b 8b 56 06        MOV        DX,word ptr [BP + param_1]
       379e:1b0e 8a 46 08        MOV        AL,byte ptr [BP + param_2]
       379e:1b11 ee              OUT        DX,AL
       379e:1b12 b4 00           MOV        AH,0x0
       379e:1b14 5d              POP        BP
       379e:1b15 cb              RET


This one NI GPIB.COM I checked used mainly double indirect I/O port addressing.
That is many bytes compared to fixed address or memory mapped I/O.

Maybe creating a memory mapped filter driver between forked and fixed address GPIB.COM and what ever GPIB hardware is also a possibility.
(if that GPIB.COM is actually used)
*.COM file can be extended easily and remapping double indirect I/O ports to memory locations should be also pretty easy.

Filter driver can also export stuff to where ever.

Code: [Select]

       2000:1f1f b8 02 00        MOV        AX,0x2
       2000:1f22 8b 57 06        MOV        DX,word ptr [BX + 0x6]
       2000:1f25 83 c2 05        ADD        DX,0x5
       2000:1f28 ee              OUT        DX,AL
...
       2000:2a3a 25 1f 00        AND        AX,0x1f
       2000:2a3d 8b 1e 00 bc     MOV        BX,word ptr [0xbc00]
       2000:2a41 8b 57 0c        MOV        DX,word ptr [BX + 0xc]
       2000:2a44 03 16 e6 ae     ADD        DX,word ptr [0xaee6]
       2000:2a48 ee              OUT        DX,AL
...
       2000:2a83 b8 e0 00        MOV        AX,0xe0
       2000:2a86 8b 1e 00 bc     MOV        BX,word ptr [0xbc00]
       2000:2a8a 8b 57 0c        MOV        DX,word ptr [BX + 0xc]
       2000:2a8d 03 16 e6 ae     ADD        DX,word ptr [0xaee6]
       2000:2a91 ee              OUT        DX,AL


[m k]

Some possible IRQ specials, 2F0-2F7.

[vaualbus]

Amazing thread! I too original decomp the software just to get the list of instruments that there were mentioned.
Anyway in respect to the user told us that he add a contact inside Tek what would be amazing to get is the repair software that allows to run board specific test to the scope.
(Basically the one that allow to execute all the tests that the repair manuals told).
To my knowledge it has never been released. The software apparently download some kind of FW to the scope that than execute the tests )via the debug/console port that the CPU has)
Any way I really hope we will eventually be able to make a software that work with any GPIB adapter and not just 16bit ISA one one for which we do not have drivers for NT system as NI never made the 32bit driver. 

[TERRA Operative]

Alrighty, I have got almost all the parts for my PC (enough to have it running DOS and the FAS), including two NI ISA GPIB cards to allow for auto or semi auto calibration.
I have to wrestle with the thing to get the two cards working in the FAS. So far I have one card recognised in the NI diagnostic software, but not in the FAS. I'll have to keep poking away to find the magic combination of settings.

I plan to hook up my SG5030 so the FAS can automatically set the levels and frequencies while I watch to see what's going on. I have a few questions about some instructions (like do I set the signal level to be a specified number of vertical divisions at the sine wave generator amplitude settings, or as displayed on the screen of the scope? etc)

I also got an ebay module that works with Sigrok to use as a 16 channel logic analyzer. I'll make up an adapter so I can sniff the GPIB bus and hopefully see what commands are flying back and forth.

[fenugrec]

So far I have one card recognised in the NI diagnostic software, but not in the FAS

As I mentioned somewhere, my understanding is that the resident NI drivers ( that you're loading from autoexec.bat or manually), will interfere with the FAS' low-level access. I could be wrong, but suggest eliminating this possibility.Once basic tests with NI ibdiag etc. succesfully prove that your ISA cards are good, DIP switch or jumpers properly configured etc., you should probably reboot and not load NI's drivers at all.

(like do I set the signal level to be a specified number of vertical divisions

I assume you've seen my video ? For a manual cal, you adjust the amplitude to obtain visually 6 divisions peak-to-peak. Don't forget my comments re RG58 losses at high frequencies too.

I would also suggest running a simple setup first with no automation, maybe just 1 ISA card, to make sure the FAS runs fine and can control the scope.

[TERRA Operative]

It's weird as on my previous setup (Dell Precision 410, but only one ISA slot) I had the NI drivers loaded and it all worked fine. This PC is set up identically besides the motherboard and a few other PCI cards and it doesn't work.
I have two ISA slots for the two GPIB cards, but I'm only running one for the tests.
I'll prevent the drivers from loading at boot and see what happens. I bet it's something simple like you say, there can't be too much going on to mess things up.


With the test signal level, if setting the amplitude to a number of on-screen divisions, then how does the automated test do it? And why the call for leveled sinewave generators? I read the instruction the same way (set the sinewave level to 6 on-screen divisions) but then the automated test would need a way to view the screen right? Unless it's doing something with waveform capture and checking that?

[fenugrec]

It's weird as on my previous setup (Dell Precision 410, but only one ISA slot) I had the NI drivers loaded and it all worked fine.

Ah, good to know. Still a pretty easy thing to eliminate from the equation. I had freeDOS configured to give me an extra bootmenu entry to load with/without NI drivers so I never really bothered to test the interaction between both, I would just reboot.

how does the automated test do it? And why the call for leveled sinewave generators?

The leveling head of course compensates for cable loss. But I agree it's a silly requirement to be setting the amplitude visually, because if you mess it up, the FAS tells you immediately e.g. "measured 505 MHz, amplitude 6.4 divisions". I would guess the automated test just sets the expected amplitude, measure (either via the scope with a :MEAS command, or it dumps the waveform and does an FFT + amplitude calc), then apply a correction.

[pivous]

FAS asks user to apply test signal to scope -> User applies signal and hits <return> -> FAS directs scope to take measurements -> FAS acquires data and calculates offsets -> FAS loads offsets into scope EEPROM

As TERRA operative, mentioned in the first post, could you please confirm if the process of recording the measured correction values into the TDS occurs after every measurement or if it occurs only after the completion of a certain measurement sequence? If it occurs after the sequence, do you happen to know where these sequences start and end? I am wondering if I need to repeat the entire measurement from the beginning in case of an error, or if it is enough to repeat only a part of it. Thank you.

[charlyd]

Hello great topic this one.. i was curious if we could relate or join forces when it comes to FAS and that also for future units like  TDS7000 series.
i will add the link to the topic. i my self did many Field cals with different TDSXXX series and have a setup ready to test  ( dos-pc PCII card and more.)

https://www.eevblog.com/forum/testgear/does-anyone-have-a-fluke-(wavetek)-9500-and-5-9530-heads-adjustiment-tds7104/msg4868576/#msg4868576

extra intresting link maybe?  http://www.hakanh.com/dl/TDS_pv.htm

[TERRA Operative]

I am stepping closer to having my adjustment gear all set up...

I have confirmed that my HP 437B with 8481A Power Sensor pretty much agrees with my Tek SG5030 and SG503 Levelled Sinewave Generators, so that's nice.
I'll have to keep an eye out for an 8482A power sensor so I can measure down to 100KHz (the 8481A ranges from 10MHz to 18GHz, the 8482A ranges from 100kHz to 4.2GHz)

I also recently got another SG504 Levelled Sinewave Generator which I'll need to poke at a bit (my other one is playing silly games and not levelling..) so far it seems pretty ok throughout its range besides a slight unlevelling issue above 1035MHz, but I'll do a bit of an overhaul and spit-polish before I put it to use.

Still have to get the ISA cards working on the Tyan Tiger 100 motherboard, but will keep chipping away at that too.

[fenugrec]

could you please confirm if the process of recording the measured correction values into the TDS occurs after every measurement or if it occurs only after the completion of a certain measurement sequence?

I'm pretty sure it's only updated after a successful sequence. I was dumping the EEPROM after each sequence for comparison purposes, and after a partly failed CH1 HF CAL (some steps were OK), the contents had not changed.

[oh2erk]

Ghidra does not seem to handle dos interrupts really good at the moment so disassembly is quite a mess. I need to do similar calibration software for the 2782 spectrum analyzer once I get it fixed. It uses same era software where most of the test information is already plain text. Probably the easiest thing to do is just to re-implement the test sequences with modern programming/scripting language. Then you don't have to worry about old ISA GPIB cards etc and can utilize more modern hardware.

[vaualbus]

Hey all, have you made any progress since than?
I still hope that someday we can have a newer software to calib this instrument!

[TERRA Operative]

I haven't made any progress, I'm not a software guy, so reverse engineering is beyond me... But once we have the test sequences figured out, I'll be able to slap it into a Python script or similar.