   
                     IC Tester HELP - Database section
                              Test data files
                                      
   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.
       
   You can look in database directory /usr/local/share/ictester/data
   (default on Linux and Minix) or C:\ICTESTER\DATA (default on dos) for
   7403.adf or 4016.ddf file to see how it looks.
   
   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 check this date to
       determine which file is newer.
     * D: - Description of tested IC, in here write 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
       exceed 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.
       
   All actions which are write above must be written before any actions
   which will be described next. Also try to write it in order which are
   listed above, because program display information from actions as it
   reads it.
   When you want import this file into database, all comments what you
   type before any W:, R:, E: or ?: actions will be erased. If you do not
   write comment before this actions as:######### Test part from here
   #############, all comments will be ignored and not included in
   database.
     * 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 it's 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 follow.
       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 is 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.
       
   You can look in database directory /usr/local/share/ictester/data
   (default on Linux and Minix) or C:\ICTESTER\DATA (default on dos) for
   7400.adf file to see how it looks.
   When you write test file take this advice for writing test part:
    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.
   
                               Database files
                                      
   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 analyse 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
