💾 Archived View for spam.works › mirrors › textfiles › programming › desdebug.txt captured on 2023-11-14 at 11:49:04.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
==================================================================== DR 6502 AER 201S Engineering Design 6502 Execution Simulator ==================================================================== Supplementary Notes By: M.J.Malone Suggested Programming Style and Debugging Methods Using DR6502 ============================================================== So far in the documentation, you have been introduced to the 6502, its assembly language, the project board and the 6502 simulator. Several times there have been references to 'proper' or 'suggested' programming style. These suggestions are for the purpose of making debugging easier. Learning and writing assembly language is not difficult since the commands are limited to a finite set each performing very simple manipulations. Debugging assembly language is THE hardest problem. Even with a software simulator with extensive program monitoring, finding bugs in a code is very difficult. By following certain programming methods, bugs are more easily located. 'Bottom Up' vs 'Top Down' ------------------------- Much discussion has been spent on the 'Bottom up' and 'Top down' programming styles; each has its merits for different applications. The 'Top down' strategy involves writing the highest logic level of the program first and then the subroutines and then the subroutines of subroutines etc until the task is complete. The 'Bottom up' strategy involves writing basic functions first and then building on them to produce a the code from the bottom of the pyramid. The 'Top down' method has advantages especially if several people are working on the same code. The main logic could be decided and the task divided into modules which could be distributed among the team members. The data structure and the calling parameters for each module would have to be fixed to assure compatibility. Problems can arise if the early definition of the problem and its division into modules leads to some unanticipated difficulties at the level of the elementary subroutines. For example, duplication of tasks can occur when two modules are designed that require (because of their definition) slightly different subroutines that perform essentially the same function. As a result of the duplication, the program is longer and has more parts to debug. This is not a problem since there are more people to debug the program and computer memories are usually not a limiting factor. The entire task, with a team at work, when programming 'Top down' can be completed quickly. The 'Bottom up' method has advantages especially when starting at machine level applications. The basic capabilities required to manipulate data are identified and are written. From there the program develops as ever more complex manipulations until the main program can be written to perform the required task. Problems can occur in 'Bottom up' style if a clear idea of the goal of the program is not kept in mind. For example when advancing to a higher page 2 level manipulation it may be realised that a poorly defined storage method for some critical data element may have to be changed. Reprogramming would have to begin at the lowest level of the occurrence of the problem. 'Reaching the top' may seem impossible when working on the manipulation of basic items. A 'Bottom up' strategy does not duplicate low level functions and will lead to smaller and probably faster code. 'Bottom up' strategy is not easily allocated to a team and is more difficult to develop in parallel. 'Bottom up' strategy allows early debugging of basic functions before they are obscured by higher level manipulations. There is a history of 'Bottom up' programming in computer control applications especially with the FORTH computer language. FORTH is a bottom up language where you MUST enter basic functions first and these are compiled as entered. When higher level functions are entered, their calls to the lower level functions are converted to pointers to the already compiled block of code. As the code is developed the higher level functions are appended to the end of the code until the main program module is entered. The code executes very fast like a compiled language but is entered as an interpreted language. There are in fact even FORTH processors that operate in the FORTH language instead of assembly language and execute computation and control programs very quickly. At the FORTH prompt, the user can type a function call with its arguments and test the operation of that function. Recommended Methods ------------------- It is recommended that students use a 'Top Down' strategy when planning the data structures and general program flow in the form of a block diagram. From this diagram, the range of basic functions required can be listed. The student should then set about programming the software in a bottom up fashion, testing each subroutine as it is coded. Strong use of subroutines should be made to reduce the length of the code. The reason for this is not that it is likely that a student will run out of memory with a maximum of 16K of program space on a project board. The reason is, the shorter a program is, the less there is to debug. The more a subroutine is used, the more is gained by proving it correct. Once the core of basic subroutines are proven, the student can advance to the next tier of nesting with confidence in what has been done thus far. The first routines programmed will likely be the basic multibyte mathematics subroutines. Since values sometimes cannot be expressing in one byte and often these quantities must be added or subtracted, there are few software subsystems that will not require some math routines. Other routines that are likely to be required are a delay loop of a controlled length and basic I/O interface routines. After each routine has been written, the student should use DR6502 in the software mode to test the response of the routine to inputs. For example if the routine adds, then make it add several page 3 numbers and check to see if its answers are correct. Check I/O routines in software mode first and then if the actual interface circuitry is ready and tested, the integration of software and interface should be attempted either with a test EPROM or using the simulator in hardware mode. Often students will give their code to DR6502 without providing any input data. DR6502 executes the instructions, the screen flips and the program reaches its end. The mistaken conclusion is that the routine or program works. The simulator does not check to see if the algorithm of the program conforms to any proper model intended by the student. The simulator does not check to see if data was processed properly. The only error conditions that the simulator will flag and actually stop the execution over fall into the category of dumb mistakes. If a program executes and DR6502 does not complain it just means there are no writes to EPROM, no reads from a location that was never set and no reads or writes from unallocated memory spaces. It is very important therefore to provide input data, check intermediate values and check responses and output values before any conclusions can be reached about a particular piece of code. After and only after the basic routines are tested, should the higher level routines be tested. Because higher level routines may not test as wide a range of input values to the lower level routines under simulated conditions, it is never wise to test several levels of the program at once. This is the most common problem for students. Many students will very often write the entire program and then test it as a whole, hoping it will all work. Often the student will not input as great range of inputs into the program as would be in the actual prototype and the tests will appear to succeed. Since such full tests are difficult and time consuming to stage without the hardware present there will be little motivation to go on and do more. Toward the end of the term, students are sometimes afraid to test their software more extensively in case they do find a terrible bug that would take longer to fix then the time available. Unfortunately, in the final design and testing these undiscovered or ignored bugs will crop up leading to some tough questions from instructors and group members. Make sure that all tests are carefully controlled, testing the performance of one routine. Any routines called in the testing of the routine under investigation are thoroughly tested before hand. Often students will test a routine and go on to test another. When problems are found in the second routine and the reason is not apparent, the student may begin to doubt the performance of the first routine. At this point it becomes important for there to have been notes on the tests performed on each routine. By consulting these notes, the student will be sure whether the routine is functioning or if some aspect of it being used that was in fact never tested. To help in this matter, the DR6502 program outputs a history file providing a record of all work done during a simulator session. The log file is called DR_6502.HST. Though notes in a lab book are still necessary, after a simulator session, the student may wish to rename the history file to a name indicative of the test performed and copy it onto a floppy or into a a different directory page 4 where it can be consulted if necessary. In discussions with instructors or group members, these records are good sources of information on what problems were encountered and solved and how they were solved. In summary, the program should be planned from the highest logic downward and then coded from the lowest level upward. Well designed tests should be performed on each routine as it is completed. Tests should provide a wide range of input values to the routine, monitor intermediate values responses and outputs. It is wise to keep extensive records of the tests performed. Using DR 6502 to Test Software ------------------------------ DR 6502 is a tool that is versatile but has no options like 'test everything and see if it works.' To prepare for the software testing stage of the design, the user of DR 6502 should read the DR6502.DOC file and try hacking up and running the example program. Performing a test on the software will also require a firm idea of what the goals of the test are to be. Once this has been established, the steps in a test should be: 1) Prepare the subroutine or segment of the program to be tested (including the reset vector and a start up routine initializing the stack), assemble with TASM and create a symbol file with DRSYM.EXE. 2) Start the simulator, provide all requested information and proceed to the 'stopped' status screen. 3) Prepare any input data required for the program's execution. 4) Set any output options that are necessary to monitor the progress of the program. 5) Begin execution of the program, monitoring its progress. 6) Upon completion of the test, examine the output data and save it to disk if necessary. 7) Modify the program and repeat or exit the simulator and copy the history file to your records disk. In the case of testing a 2 byte addition subroutine the user may do the following. As above, the program is prepared, assembled, the symbol file is created and the simulator is started. The specification of this routine includes that, as input variables, it takes one 16 bit number passed into the subroutine call by the values of the .X and .Y registers representing the high and low bytes respectively. The other 16 bit number is present in memory locations $00 and $01 as low byte, high byte respectively. The routine is designed for doing a 'running total' type addition where the answer is stored back into the memory location $00 and $01 before the routine executes an RTS. The output variables of this subroutine are a copy of the contents of $00 and $01 in the .Y and page 5 .X registers respectively, the answer. Also returned by this routine is the value of the carry flag: set if there was an overflow, clear otherwise. The overflow flag was not used because the programmer is using it as a quick input port (with the SO pin of the processor) in another routine. The user selects the 'p' option to poke initial values into the $00 and $01 memory locations, and inputs '$00 00' to set both locations to zero. The user then selects the 'r' option to modify the .X and .Y registers and sets each to zero as well. The first test will be to see if the routine can add zero and zero and get zero. This is essentially testing to see if any obvious errors exist in the way the routine handles the carry flag. The user then selects the output options: 'H' to select full history mode, 'm' to monitor the address $00 as a two byte variable and 'b' to set a break point after the addition of the least significant bytes of the arguments. The user then executes the subroutine by pressing the 's' key for each program step or 'g' for continuous execution. The user carefully observes the screen outputs and when the RTS is reached if the code found 0+0=0 then another test would be prepared. When the testing of this routine is complete the user exits the simulator and enters the DOS command: 'copy dr_6502.hst a:\tests\2byteadd.rec' to copy the history file into the test records directory. Testing I/O Routines -------------------- In the above example, the subroutine processes input data and produces output data all internal to the 6502 address space. In such cases DR 6502 is sufficient, in its software form, for complete debugging of routines. In the case of I/O subroutines, there is information that originates outside the 6502 address space involved in the manipulation. The problem can be divided into to classes of subroutines: those that include hardware input and those that do not. If the subroutine is an output subroutine only, with monitoring of the appropriate output port address, a software simulation with DR6502 would be sufficient to check the algorithm. To check to see if the routine would 'work' in the global sense, IE be sufficient to drive the external device in the manner required, then the project hardware must be brought into the loop, either through the hardware simulator or by burning an EPROM and trying it on the target system. If the subroutine contains hardware input then the simulation becomes more difficult. Naturally, working in hardware simulation mode, with the target system present or with an EPROM on the completed target would test input subroutines. If the user would like to test the routine with the simulator in software mode, the task is more complex. The user must use the 'b' break point option to halt the simulation and do inputs manually. The user may halt the execution before the input read and put the data in the input port with the 'p' poke memory location option. The user may wish to use the 'b' break point option and set it to the port location. When the simulator executes and reads the port, the simulation would stop. The user could then put the NEXT value on the port. This method is superior especially when the subroutine next reads the port at several points in the code depending on the last value read in. page 6 Hardware testing is essential to development of the software. For example the control of a stepper motor requires a certain series of bits or combinations to be sent to the output port. The programmer may easily program these combinations and make sure they are sent to the port in the correct order but the system may still not work as a whole. The programmer may have neglected or chosen the time constants, in this case the waiting periods before sending the next bit code, incorrectly. A few tests with a function generator and a few logic circuits may give the programmer an idea of the time delays between sending each impulse. Unfortunately, using a function generator is not always fool-proof either. The maximum frequency, as read on the generator, that the motor will run at and the frequency it will start at are two different values. An acceleration routine would be required that starts the motor with time constants corresponding to the lower frequency and slowly shifts them to the values required for the higher frequency. The motor would then appear to start and them accelerate. Unfortunately, this is often not adequate either. Once the motor has been mounted in its final configuration and attached to the final mechanism with all the masses required to be moving, the torque required from the motor and the momentum changes these constants. Usually the motor must be run more slowly however in the case of a high angular momentum and a small running torque like a flywheel, the maximum frequency of the motor may actually increase. Factors like mass and inertia that lead to time constants. Friction alters those time constants and is found in all practical systems. Such factors must be considered in the design of software and only testing on the physical hardware can prove that the software is adequate. Unfortunately, the hardware simulator does execute instructions as quickly as an actual 6502. As a result, the hardware simulator is not well suited to determining time constants. Testing on the actually hardware with a test EPROM would be required in this case. For additional suggestions on how to determine time constants with a test EPROM see file 'TRICKS65.DOC' Section 3) 'The Reburnable EPROM' particularly the 'Vector Jump Method'. More Advanced Testing --------------------- After the basic subroutines have been tested, the student will then move on to testing the more advanced routines that call the lower level subroutines. After a while the purpose of the routines moves away from the basic manipulation of data and on to the higher level logic of which routines are called in what order to perform a task. There are user selectable modes of operation where the simulator does not produce as much extraneous output. The methods involve the output to the screen and the history file records. The history file can be set in one of three modes of output to limit the quantity of unnecessary output not of interest to the user. The total output mode, outputs instructions, arguments, register values and monitored address values. When the flow of the code is important but the register values are superfluous information, there is a second mode (default) where the history file can be made to contain only the instructions and arguments. In page 7 addition, if only the call structure of the program is important then the history file can be set to more brief output mode where only program steps involving the JSR, RTS, IRQ, NMI, BRK and RTI instructions are recorded. Consider the following call tree typical of a mobile reactive robotics system: Main | ------------------------------------- / | \ Sense Record React | | | | | ---------------------------- / \ Compute Execute | | | | ----------------------------------------------------------- / | | | | \ Add Subtract Multiply Divide Square Root Arctan Let it be assumed that the code has been designed from the top down and is being programmed and tested from the bottom up (though this is not necessary). After the basic math routines have been programmed and tested and the 'Compute' algorithm has been written, the user would like to next test the 'Compute' algorithm. When the simulator executes, it would normally display all the program steps (full output mode), none of the steps (silent mode) or none of the steps up until a break point. If the user is confident of the math routines and is really only interested in the behaviour of the 'Compute' subroutine then a mode that limits the screen output based on the position of the execution in the call tree is required. Just such a mode is available in the simulator as the subroutine trace option. In the above example the user would execute the trace option at any time that execution was in the 'Compute' subroutine. From that point on, none of the steps of the math routines would be displayed nor would any steps of subroutines called by 'Execute' be displayed. If the entire program were present and execution continued to other areas of the calling tree, all subroutines at or above the level of 'Compute' would be displayed. Since limiting screen output also limits history file output, the two methods above can be used in combination. When this option is selected, only program steps at the 'traced' level of nesting or higher are displayed and hence are eligible to be recorded in the history file depending on its output mode. The user may chose at any time to end the trace option. page 8 Recommendations for Testing --------------------------- When testing the subroutines of the code, make sure the purpose of the test is clearly laid out, the progress of the execution well monitored and the results of the test recorded in appropriate detail. If the simulator is used, use all options available to monitor and record the progress of the code. If the code is run on an EPROM, make sure that adequate output is given to whatever output device is available to follow the execution of the program. Use LCD displays whenever possible, connect LEDs to any unused output bits and program the code to give signals to indicate the course of important decisions.