to better understand the many benefits of the present invention it is important to understand the process involved in developing software for testing target equipment . fig1 and 1 illustrate a prior art process used to develop target software for a computer . target software is code that is assembled and linked on the host computer 50 ( e . g ., a personal computer ) and downloaded into the target processor program memory via an isa interface and a controller 55 , using the jtag scan chain . the controller 55 includes a boundary scan master ( bsm ) chip to control the flow of data between the host computer 50 and the target device 60 . on execution in the target processor 60 , the target software tests or operates on the target board hardware . to develop target software , a series of source codes files 2 - 2 n are created in a conventional manner . these source code files may include , for example , diagnostic information , identification of tests to be performed , data monitoring / logging , or applications programs to be run by the target device , and they are used to input the information needed to create the executable target file . the target source files are input to an assembler 4 to assemble and produce corresponding object files 6 . the object files 6 are fed to a linker 8 which creates the executable target program 10 ( tfile . e ). the executable target file 10 is stored for use by the host computer . a graphic user interface ( gui ) 12 receives a configuration file 14 which configures the gui 12 and directs it to the location of various programs used by the gui to test and exercise the target hardware . for example , the configuration file 14 might identify which diagnostic programs will be implemented in a particular test . based on the input from the configuration file 14 , the gui 12 selects batch files 16 needed to run the desired diagnostic program and default commands 18 initialize the selected batch files in accordance with the user requirements . once the appropriate batch files 16 have been selected to identify the diagnostic program ( s ) that will be carried out , a software tools program 20 runs specific software tools designated by the configuration file 16 utilizing the target information input from the executable target program 10 . the software tools program 20 , configured to perform the desired test , runs the diagnostics on the target device and displays the results 24 at the host computer . because of the complexity of the testing performed by conventional testing programs , the batch files 16 and default commands 18 must be run and loaded properly , and the software tools program 20 must read the batch files 16 to control the test execution and result handling . this process requires the preparation of at least 4 separate files ( configuration files 14 , batch files 16 , default commands 18 , and tool instructions 22 ) by the user for each test in addition to the source files 2 - 2 n needed for generating the executable target program 10 . referring now to fig2 the process for developing the target program of the present invention is described . the target program is a set of one or more programs which are downloaded to the target device . creation of the target source files is identical to that of the prior art . however , the execution files for the host computer are simplified and do not require the completion of a tool program or the creation of batch files and default files to control the test - execution and result - handling . referring to fig2 a dos executable program 30 , e . g ., a single microsoft c / c ++ 3 program ( called view in this example ), is used to develop code to test the jtag channel , check the link of the target device , setup the target device on the scan chain , load the program into the device , run the program , and display the results of the program . these are the only functions needed to perform the diagnostics of the present invention . the host program 30 receives the port address , target program name , output file name , and any parameters needed by the target program from the executable target program 10 . the need for a separate software tool program is not required . all that is required is a gui and the host program 30 that runs under the gui . the host program 30 is a “ console application ” and not a windows application . this means that it will comprise a simple executable (. exe ) output . the host side interface ( where all user interaction takes place and where all results are sent ) accommodates embedded breakpoints which allow the host to be told when the target has reached a certain location in the program . these embedded breakpoints can be unlimited in number . the host program 30 performs the following : 1 ) tests the bsm and link before each download of target code ; 3 ) sends any data to a running target program interactively to be loaded into registers or memory ; and 4 ) time - stamps all test data and records all data into and out of the target . the host program 30 is always in a monitoring mode waiting for any data from the target program . all data must be sent using the jtag register in the host . the host user must be able to interrupt the program at any time ( e . g ., with a key stroke ) to allow the user to terminate infinite loops running on the target device . the present invention can be embodied in a host program 30 that operates as follows . the initialization and startup phase of host program 30 is illustrated with reference to fig3 . at block 100 , command line parameters are decoded and verified to confirm that the nature of command line parameters are valid and that the correct number of command line parameters exists . the command line parameters may be input from the configuration file 14 shown in fig2 or can be directly input from the keyboard of the host computer using the host control panel gui , if the host user wishes to modify the diagnostics specified by the configuration file 14 . at block 110 , it is determined if a hardware test has been requested . if a hardware test has been requested , a thorough hardware testing program is run to conduct the desired hardware test ( s ) ( block 115 ). the details of an embodiment of one such hardware test will be described more fully below with respect to fig5 . if a hardware test has not been requested , the bsm is tested ( block 120 ). if the bsm fails the test , this information is output to block 180 , an error message is printed ( block 190 ), all opened files are closed ( block 200 ) and the program is terminated ( block 210 ). by closing all open files at block 200 , a “ clean ” exit of the program is ensured , because nothing is left open that might interfere with other programs . if it is determined that the bsm is functioning properly , the bsm link to the target is then tested ( block 130 ). if the bsm link fails the test , this result is output to blocks 180 - 210 and the program terminates as described above . if it is determined that the bsm link is functioning properly , the jtag chain is tested at block 140 . next , at block 150 all dsps are reset , all dsps are stopped , and then the dsps that are desired to be monitored are selected ( block 160 ). assuming the desired dsps are selected , the code in the executable target files specified on the command line is loaded into the selected dsps ( block 170 ) and at block 220 , the memory map is set so that the device will start up ( when reset is released ) in the correct memory configuration . once the memory map is set , all the selected dsps are started and the system moves to control loop 240 . referring to fig4 control loop 240 begins by determining if the jtag register was written by the target device ( block 250 ). the control loop continuously monitors the jtag register for a data word ( code ) from the target device . since the host program of the present invention is only a monitoring program , the target device must initiate all conversation with the host . all communications with the host are carried out via the jtag register in the target . this is used to send and receive data to and from the host . the data words are defined and interpreted by the host program . at block 260 , the data words written to the jtag register are decoded . if the first word returning from the target is not one of the defined data words , the host program sends and / or prints an error message identifying the existence of the unknown code and the host program terminates . in the preferred embodiment , five general categories of codes are used , as shown in fig4 . obviously , fewer or more codes could be used , depending on the needs of the system . the general categories of codes shown in fig4 are end codes , continue codes , format codes , send data codes and receive data codes . if the first word back from the target is not one of these codes , the program will print an error message identifying the unknown code , and stop . end codes have done equal to “ yes ” or “ true ” and cause the corresponding message to be printed ( pass , fail , complete , stopped ) along with any data requested and cause the host program 30 to stop processing . continue codes are those that have done equal to “ no ” or “ false ” and also send back state information ( pass , fail , complete , or stopped ). these are used in several cases . a typical example is a memory test where a location fails . the continue codes displays an error message along with pertinent register information , but the test is not halted . another example is where there are several passes or individual tests involved in the target program . the continue codes cause the display of the state of each pass or test but continues with all the remaining tests . the format for the continue codes is identical to that of the end codes . the only difference is that the host program 30 does not stop . it remains in the control loop ( 240 ) monitoring the target program . data can be sent back any time from the target for display . the data can be sent a word or block at a time . there are two separate codes that handle these conditions . the send data code is used to indicate whether the host is to receive one word or n words and the format code determines what format to display the data ( e . g ., hexidecimal , decimal , etc .). the format flag is hexadecimal by default and will remain set until changed by another format code . examples of send data codes include the send_one_word code and the send_n_words code . when the send_one_word code is seen , the next word loaded into the jtag register is the data word to be sent to the host . this is displayed on the host computer with an indication which target it is from . this is useful in cases where a single word needs to be sent back during the running of the program ( e . g ., a loop counter at the end of each loop ). the protocol for the send_n_words code is the next word set to the jtag register is n ( word count ) followed by the n words . the running program must insure that it sends n words because the host program 30 will expect to read in the number of words specified by this command . this is very useful for sending blocks of memory back to the host ( e . g ., a memory dump at the end of a program ). receive data codes allow the host program 30 to interact with ( send data to ) any program executing in the target . to send data to a target program , the target program must be in a wait loop for the jtag register to be written by the host . once written by the host and read by the target the jtag register may be used by the target program in any way desired . the target program initiates the transfer of data from the host by sending either the code receive_one_word or receive_n_words . if the latter is used the target program must also send n ( word count ) as in the send_n_words example above . once one of these codes is sent , the target program waits until the host sends the requested word or block of data . if the data word entered on the host ends in a “.” the number is assumed to be in decimal format , otherwise it is assumed to be in hexadecimal . as with the send_n_words code , the target must read n words from the host in order for the protocol to operate correctly . in the control loop of fig4 if the host computer , in monitoring the jtag register , receives a receive data code from the target , the fact that the code is a receive data code is printed ( block 280 ), on screen and the data being received from the target is read into the host computer ( block 285 ). the data is then displayed on the host machine ( block 290 ) and , since an “ end ” code has not yet been received , an indication is output that the program is not yet completed at block 295 ( e . g ., set done = false ). next , at block 370 , a determination is made if there are any registers ( as specified on the command line ) to read in . these registers are sent back by the target as in the case of the send_n_words command . the difference is that the number of registers is specified on the command line , not by a special code . if there are registers to read in , the data is read from the target ( block 375 ) and is displayed in the format as described earlier with respect to the format command ( block 380 ). if there are not registers to read in , the system bypasses steps 375 and 380 . next a determination is made as to whether or not the control loop has completed its monitoring task ( block 385 ) ( done =“ true ” ). if it has , the test results are displayed at step 390 , all open files are closed at step 395 , and the program is terminated at step 400 . if the monitoring program has not completed its diagnostic task , the process loops around to block 240 and checks the jtag registers for additional information written by the target at block 250 . if the word coming back from the target is a “ send data ” code , this message is displayed at the host ( block 300 ), the requested data is read in from the host to the target ( blocks 305 and 310 ) and , since an “ end ” code has not yet been received , the loop continues at block 315 ( set done = false ). if the code read from the jtag register is a “ format ” code , this message is printed at the host ( block 320 ), the format flag is set ( block 325 ) to the requested type . all future data sent from the target will be displayed in the current format and the loop continues ( set done = false , block 330 ). if the data word from the target indicates a “ continue ” code , then this message is printed at the host ( block 335 ) and the register flag is set ( block 340 ) to indicate any registers or values to send back from the target . this must match that specified on the command line . once again , since an “ end ” message has yet to be received , the loop continues ( set done = false , block 345 ). finally , if the data word received from the target is an “ end ” code , this message is displayed at the host computer ( block 350 ). the results of the diagnostic testing are saved to the appropriate file ( block 355 ), the register flag is set ( block 360 ) as described earlier to match the registers specified on the command line and done is set to be equal to “ true ” ( block 365 ). at block 385 , when done is equal to true , the test results are printed ( block 390 ), all open files are closed ( block 395 ) and the program terminates ( block 400 ). fig5 illustrates an example of a hardware test ( block 115 of fig3 ). hardware tests are standard tests to determine and assure that the hardware is functioning properly . as shown in fig5 the hardware test first clears the fail flag ( block 410 ) and then the bsm is tested by running its built - in - self - test ( bist ) a predetermined number of times ( block 415 ). if all of the bsm tests indicate a failure , a print message is sent to the host indicating these failures ( block 450 ), the fail flag is set ( block 455 ), the fail flag is then tested to display the results of the tests ( block 430 ), the test results are displayed ( block 435 ), the results of the test are saved to the appropriate file ( block 440 ), all open files are closed ( block 445 ) and the program is terminated ( block 460 ). if any of the bsm tests indicate a “ pass ”, the link is then tested a predetermined number of times ( block 420 ) and if any of the link tests fail , the program is directed into the “ set fail flag ” loop ( blocks 450 and 455 discussed previously ). if all of the link tests indicate a “ pass ”, the jtag connection is tested ( block 425 ). if the jtag connection fails , the program is directed into the “ set fail flag ” loop ( block 450 and 455 ). if the jtag connection passes , the fail flag is tested at block 430 , the test results are displayed at block 435 , the results are saved at block 440 , all opened files are closed at block 445 and the program is terminated at block 460 . the present invention requires a bsm chip in a controller 55 , an isa interface and a jtag link to a target board 60 , and a host device 50 such as a pc with an isa interface , as shown in fig1 a . it should be understood that the method depicted in fig2 - 5 are only illustrative of the method of the present invention and that other embodiments would be apparent to someone skilled in the art of programming . the user communicates with the monitoring program of the present invention via a command line . there are several required parameters and some optional parameters that are input on the command line . these parameters control the target executable program to be loaded and the starting memory map for the program , the number and format of “ registers ” or data to be displayed at certain times in the target program , the address of the bsm device , and the output file name . the command line can be incorporated into the configuration file 14 , run from a window &# 39 ; s application control panel , or it can be typed in any dos window for standalone operation . in a preferred embodiment , the format of the command line is as follows , assuming the name of the host program 30 is “ view ”: as can be seen there are a minimum of 4 arguments on the command line ( counting the command view itself ). the optional parameters specify how many ( if any ) registers are to be returned and displayed by the running program and in what format and what memory map to start program execution for each program and device specified . a special case involves a test of the bsm and the jtag link itself without a test of the target processor . in this case the target executable file “ exfile ” has the name “ hwtest ”. the target executable file “ hwtest ” is a built in function of the host program 30 as discussed earlier . this can be implemented with the following command line : “ loopcnt ” is optional and indicates the number of passes for the link tests . the preferred default is 100 . this runs the target program “ led ” in map 4 with bsm address 0 × 310 , and sends the results to the file “ diag . out ”. view fft — 1t5a frequency . d “ absolute power . d ” 0 × 310 diag . out this runs the target program “ fft - ltsa ” in map 4 with bsm address 0 × 310 and sends the results to the output file “ diag . out ”. when a code is returned that indicates register values are to be displayed , two values are read in and displayed in decimal format with the titles “ frequency ” and “ absolute power ” indicated . this runs the target programs “ led1 ” in map 4 in device 1 and “ led2 ” in map 4 in device 2 , with bsm address 0 × 310 , and sends the results to the output file “ diag . out ”. the string ( strx ) argument may include spaces and multiple words if they are enclosed in quotation marks ( e . g . “ absolute power . d ” above ). the format codes all start with a period followed by the code . the period is required but the code can be in upper or lower case . the register strings or titles shown above end at the character before the period whenever it occurs in the line . the format information is not part of the displayed string . obviously , there can be many variations on the command line parameters . an example of valid codes for format information are shown below : all communication with the host is through the jtag register in the target . this can be used to send and receive data to and from the host . the simplest way to invoke this feature is by embedding two lines of code ( an embedded breakpoint ) at any location when it is desired to send a code or to send data back to the host . following is a simple example of code which invokes the send / receive feature : where special_code is replaced by any of the codes discussed earlier , e . g ., end , continue , etc . the first test should normally be the built - in hardware test . for the purpose of this example , the file name to run the hardware test is “ hwtest . exe ”. by inputting “ hwtest 200 ” to the command line , the built - in test is run with a loop count of 200 . the remaining parameters of the bsm address and output file are added by the gui , as input from the configuration file 14 . thus , this information does not have to be input on the command line when the system is running from a configuration file with gui 12 . the results of each test and detailed information about the target device appear in the results . these results are echoed on the console and written to the designated output file . while there has been described herein the principles of the invention , it is to be understood by those skilled in the art that this description is made only by way of example and not as a limitation to the scope of the invention . accordingly , it is intended by the appending claims , to cover all modifications of the invention which fall within the true spirit and scope of the invention .