There are three types of files which are used with ictester program. All files are textual and you can edit it with text editor. In all files # character at beginning of line is used to comment entire line.

First type is link file and have identical suffix like one of other two file types. Main purpose is to redirect reading to another file.
For example, there's test file for 7400 ICs, but you can with that file test 7403, 7437, etc., why? Because IC logic and pinouts are the same, only difference is on some upgrades which this IC Tester device can't test anyway.
So that test file don't have to be copied in several copies and took additional space on disk, instead of that there's this link file which is small and it can redirected program to another file.
Structure of link file:

1. line: Information to program which type of file is it that it knows how to read it.
2. line: Starts with keyword Information: after what comes text which will be wrote when program reads file.
3. line: Contain location of redirected file, so that program knows where is it.

Second type is dump file and have .ddf suffix.
This is dump file which is generated from program, but you can edit it like others, just make sure that next lines are in place:

1. line: Information to program which is file type, so that it knows how to read it.
2. line: Description of dumped ICs, like part number and comments.
3. line: Number of pins, location of +5 V pin and GND pin at dumped IC.
4. line: First and last name who is author of this dump file.
5. line: E-mail address of author.
   Next lines: Contains data which will be set and read from device. This data lines must be in form that first 16 characters are for setting and next 16 characters what should be read from test socket at device.

You can with -d option generate dump file and take a look in it to see how it looks.
You can use -c option to check if data from this file match with data from tested IC, but this doesn't work with complex ICs like counters, bistables, shifting registers, etc.
Check for details in Program - ictester section under -c option.

Third type is analyze file and have .adf suffix.
This is real test file, with it you can test if IC is correct and if it's not where's the problem and how to use this IC.
For standard testing you can use -r option to read status and -w option to set data on test socket. But if you want test more ICs on the same principle, you don't have to do it manually with r and w options, you can write those testing steps in script, which is this analyze file.
Make it easy to you, there are few rules which you may find very interesting.

First line must be information to program which type of file is, so that it knows how to read it.
Next lines you can wrote with listed actions:

Each action have first letter and ':' character, after that you write parameters for that action.
NOTE: when you use action make sure that all parameters for it is write in one line and that line can't be longer that 255 characters (including action letter).

• A: - Entry for author name and (or) e-mail address, you can multiply this action and write unlimited lines with it.
  Only limitation is that total characters wrote under all entries mustn't be larger than 65025.
• M: - Last modify date. Here you place last date when you modify this file, so that other if using it, know which ones is newer. It should be only one action of this type in file. The date must be formatted as: YYYY/MM/DD-HH:MM-ZONE, e.q.: 2001/03/29-16:58-UTC. Please use this format because program checks this date to determine which file is newer.
• D: - Description of tested IC, in here writes what is type of tested IC on which you use this file. E.q.: 4 x NAND gates with 2 inputs. It should be only one action of this type in file and you can write maximum 255 characters.
• T: - Title of ICs which this test works and it's tested. In here you write prefix and root number of tested ICs, so that others may know on which manufacturers this works. I know that must work on all, but there are some exceptions.
  You can write unlimited lines of that action, only be careful that total number of all characters from all lines of that action not exceeds 65025.
• N: - Real name of tested IC, here you put actual name of IC for which this test file works. Eq.:SN 7400 or CD 4011. It should be only one action with maximum of 255 characters in line.

• W: - Set power on test socket, input entry identical like in '-w' option for program. So you write this action letter and after that 16 characters which are used to set data at exact pin. E.q.:
  W: ======0========1
  for powering up with +5V on pin 16 and GND at pin 7 and you can using this action unlimited times, like
  W: =100===0=======1
  W: =010===0=======1
  W: =110===0=======1
  W: =001===0=======1
  W: =101===0=======1
  W: =011===0=======1
  W: =111===0=======1
  three bit binary count at pins 2, 3 and 4, with power on of +5 V on pin 16 and GND at pin 8.
  All rules for characters are the same like in -w program option.
  1 - sets +5 volts on pin.
  0 - sets 0 volts (GND) on pin.
  = - sets NC (not connected) on pin.
  
  When using this option, always on output pins set '=' character (not connected (NC)), on that way you will secure tested IC from short circuit and that's the only way how you can get right information.
• R: - Read data from test socket, if read data don't match with one you write then test fails.
  This action is usually used after W: action, and its check what status is on test socket. You have some rules, which can help you to analyze output from device:
  1 - on that pin is +5 volts or is NC (not connected).
  0 - on that pin is 0 volts (GND).
  = - use this character to ignore reading from that pin.
  
  You can using this action unlimited times, usually it's used with E: action.
  Writing parameter is equal to one from W: action, only difference is in differ character meaning. E.q:
  W: ================ - you set to all pins NC
  R: 1111111111111111 - read status at test socket. All pins must be set to +5V or NC or there's error.
  NOTE: IC Tester device can't tell difference between +5V and Not Connected state.
  
  W: =======0=======1 - set +5V on pin 16 and 0V (GND) at pin 8
  R: 1======0=======1 - now check if there is +5V on pin 16 and GND at pin 8, also test only if on pin 1 is +5V or NC.
  R: =0=====0======== - now check if there is GND only at pin 8 and pin 2, if one of last two reading don't match with data there's error.
• E: - Error report, write what's wrong with tested IC.
  Use this action after one or more R: actions to display error. If message is longer that one line or more than 255 letters, you can write rest of it in new E: action which follows.
  Here is example how you can use it:
  W: ================
  R: 1111111111111111
  E: Detecting power on some pins and there shouldn't be any!
  E: Use -t option and do test IC Tester device to make sure that's working ok.
  In this example, first is set NC to all pins, next we read status and checking that output is all with +5V or NC (in this case NC).
  If output wasn't what we expected then there's some error, now program will read information under E: action and wrote it.
  Program will wrote all E: actions until it read first other action.
  Of course you do not have to put this action after every R: action, see next example:
  W: 00====0========1
  R: 001===011======1
  W: 01====0========1
  R: 011===011======1
  W: 10====0========1
  R: 101===011======1
  W: 11====0========1
  R: 110===011======1
  E: There is problem with gate 1 at output pin 3, GATE 1 DON'T WORK!
  In this example we set +5V on pin 16, GND at pins 1, 2 and 7. After that we test if on pins 1, 2 and 7 are GND and on pin 16 +5V, in this case we test only first gate of IC SN7400 which have 14 pins.
  All other gates we will ignore from testing, setting and reading.
  So pins 8 and 9 are not occupied and there should be NC, on pin 3 is output from first gate and IC logic NOT AND tell us that on output must be +5V.
  In that pattern we do 2 bit binary count on inputs of first gate (pins 1 and 2) and check if output data match to one what we expected.
  If in all of this tests are one or more failure then program will wrote message under E: action.
  This action will be used if there is error (not match under R action) and it will be reset after use, so if on next test is another failure then it will be used again. All E: actions in between if there's no error will not be used.
  
• ?: - If there was error, write message, and ask for continue.
  This action works as E: action but with one difference, it asks if you want to continue testing after any error.
  Look this example:
  W: ================
  R: 1111111111111111
  E: Detecting power on some pins and there shouldn't be any!
  E: Use -t option and do test IC Tester device to make sure that's working ok.
  ?: I advise you to check if device working properly, continue testing?
  Here is testing if after we set NC to all pins, status is identical on all of it. If that's not the case then it's possible that device not working properly. That is serious problem, because if you continue test, you could do damage to tested IC and to IC Tester device itself.
  So we used here ?: action to make possible break from testing.
  Also you can use this action if there are a lot of errors to abort testing, because there will be errors and when you continue.
• P: - Pause for number of milliseconds (1000 msec = 1 sec).
  This action is used when you need to delay execution of test file for some time.
  E.q.: P: 5000 - delay execution for half of second.
  Action is included here because it's used with test files for addons. When you tests standard logic ICs it's not needed, because IC Tester device isn't that fast that you have to use it.

1. Set to all pins NC and test if NC is at all pins. If aren't there may be error with IC Tester device itself, write error message and ask to continue.
2. Set power up and check if power up is really working, if not tested IC maybe in short circuit, write error and ask to abort testing.
3. Test if there are on all inputs of tested IC +5V or NC, if not, IC is probably damaged and in most cases you can't use that input.
4. If there's more parts in tested IC like gates, set +5V to inputs of one gate and check if there's respond from it.
   Then check others inputs on others gates to see if there may be break from this gate. Repeat this test for each gate.
5. Now perform the same tests described in last entry, only this time set GND to input pins of one gate. In this way you can cover all possibilities of breaking from one gate to other.
6. If you have IC with more gates, perform binary count on all inputs of each gate to test if gate logic works.
7. By this point all entries was standard testing, if there was error you can safely ask to abort testing, because tested IC is probably damaged.
8. Perform full test at all inputs with binary count to make sure that all logic on tested IC working properly.

If you wrote test file and you want to share it, take a look in Feedback section for more details.

From program version 0.0.6 there is available database which contains all data as analyze data files, but in smaller format and more compact.
All test data what you write in analyze data file you can import to database and export from it back to analyze data file of course. Database file are in binary form and it's modified or generated by ictdataedit program. It's graphical program and requires X-windows environment and gtk+ graphic library.
Here I'll describe only construction of database, if someone want to make own program for manipulating with database file. Note: you can download source code of program and see how ictdataedit program work with database.

Legend:
Green color : Size of entry in database
Red color : Entry of variable size in database
Black color : Standard text for explanations or naming some part
Normal color : for additional information.

Here is structure from first byte to last:
[2 bytes database identification (0xFF and 0x00)]
[1 byte version of current database (from 0x00 to 0xFF)]
Beginning of single test entry.
Next part is data part from single analyze test file and that structure can repeating until reach end of file (Eq. if you have more analyze test files in database).
[1 byte size of string for link or test file name (7400), mixed with first bit of this byte is type of data (link or data file): 1xxxxxxx - link, 0xxxxxxx - test file] [string of test file name, max 128 chars]
If this is link entry then only in this case there will be this entry:
<1 byte size of string for link location><string of link location, max 128 chars>
otherwise it will continue with:
[4 bytes size of the rest test file entry]
[1 byte size of string ][string of true name (SN 7400), max 255 chars ]
[1 byte size of string ][description of IC test name (4xNAND), max 255 chars]
[2 bytes size of string ][ list of tested ICs, max 65025 chars]
[2 bytes size of string ][list of author names and/or e-mail, max 65025 chars]
[20 bytes for date - YYYY/MM/DD-HH:MM-ZONE]
[4 bytes size of additional data]
In ictester program this 4 bytes is using as skip value. In that area is place pictures for IC pinout, tables of truth, additional information, etc...
That part of database is using graphical test program xictester who will be available for Linux and Windows when gtk+ library will be completely ported on windows. When xictester program comes out then here will be described in details this part of database.
From this point is data for testing IC to end of this test entry. It means that you must from total size of entire test entry (you got this value at beginning) subtract total size of all read entries so far and after that you know how large is next test data part. O.k. here is what you can find in this:
[1 byte action: 0 - write data, 1 - read data, 2 - error report, 3 - ask report, 4 - pause]
After that action byte goes data in next forms:
[4 bytes for read (R:) and write (W:) actions, where standard 16 characters data are converted with next form: original entry - 1==10==1000==1=1; converted into 4 binary entries: 10010001(rw) 01100110(ign) 00000101(rw) 00011010(ign); and finally converted from binary to decimal or hexadecimal: 145 102 5 26]
[1 byte size of string for error (E:) and ask (?:) actions] [ask or error string report]
[1 byte size of string for pause][max 10 characters for string of long number]
With this ends test data entry block, if there is more imported analyze test files it will be wrote continuously after, in exact form as described entry in database.

You can also see currently supported ICs for full testing in supported file.

(C) Copyright Silvio Klaic, you can write to me at sklaic@student.math.hr