- "A Dynamic Debugging System" Steve North "The Best of Creative Computing, Volume 3", pp.303-305 (Retyped by Emmanuel ROCHE.) Are your eyes weary from staring at blinking lights as you attempt to debug a program the hard way? Or, are you fed up with the tedium of using a simple debugging monitor with only breakpoints to help you? If you own an Intel 8080- based microcomputer, then relief is in sight. Relief, in this case, is the Dynamic Debugger, written by David Benevy, and marketed by the Computer Mart of New Jersey. The Dynamic Debugging System (DDS) is a software debugging facility for Intel 8080 assembly language programs. DDS is, actually, a program which helps you to debug your own program. A simple debugging monitor lets you enter breakpoints in your program, runs your program for awhile, and then lets you see the condition of the registers and program when the breakpoint was hit. DDS, on the other hand, monitors the execution of your program as it is going on, displaying pertinent information and identifying possible problem areas. It uses a softcopy device for the display (versions are available for the Processor Technology VDM-1 and popular CRTs, but the VDM version is better, since information may be updated almost instantaneously. DDS can only be used on CRTs with cursor addressing). A keyboard is used to communicate with DDS. The Dynamic Debugger has three types of functions. The first type controls the display of the program being debugged. Actually, most of the display is handled automatically. At the middle of the top of the screen, DDS displays the current program counter and the next five instructions to be executed, in easy-to-read mnemonic format. To the right of this is a display of all the CPU registers, the words that they point to, both as hex and ASCII characters. The individual bits in the flag word are also broken up into mnemonics. In the 64- column version, they are displayed as single characters (C for Carry, for instance). In the 80-column version, the entire name of the flag (such as CARRY) is displayed if the flag is on. To the left side of the top of the screen, DDS displays the current Stack Pointer, the top five words on the stack, and the words that they point to, as hex and ASCII characters. DDS also maintains its own stack of valid return addresses, which is displayed to the far left of the screen. So, at a glance, you can see exactly what is going on in all the registers and the stack, and have a pretty good idea what your program is doing, too. Now for the part of the display which the user controls. There are two types of displays that you may ask for. One of these is a hex/ASCII display of selected portions of memory. There are six lines of display available in the 16-line version, and 11 lines in the 24-line version. These lines may be split up as you wish. For instance, lines 1 and 2 could display memory from 3000 to 301F, while lines 3 through 6 display memory from 2000 to 203F. You may also display memory as instructions, instead of raw data. Two such groups of instructions may be displayed simultaneously. The instructions are displayed in mnemonic format similar to the display of the code currently being executed at the top of the screen. When selected, these displays are located in the lower half of the screen. These displays are requested by DM (Display Memory) and DI (Display Instruction) commands. The two bottom lines on the screen are used for displaying error messages and echoing keyboard input, respectively. CALL STK SP=3FF9 ADDR ---INST----- OP REGS ---- ------------ --------------------- --------------- 2AB5 2AB5=E604 .. 3000 CALL CAB4 CD AF=00FF MZAPC 2388 2388=0418 .. 3003 JMP 0040 C3 BC=03DB=CD18 .. 1234 1234=02B2 .. 3006 SBB E 9B DE=2310=B303 .. FF00=FFFF .. 3007 INR C 0C HL=2320=C00F .. FFFF=C3FF .. 3008 POP H E1 0100 0000 00C3 F000 C900 00C3 CF01 CD1F C0C1 ................ 1000 CA2B 10C6 4032 DA0F 4E79 E61F C640 32DB .+..@2..Ny...@2 3000 CDB4 CAC3 4000 9B0C E122 297D 31A1 2939 ....@....")}1.)9 3010 1A40 CA9E 5B88 D85A 233B A97B 3BEB FFFF .@..X..ZN;.{;... 3020 081A 9D9E 9C1E 5B05 3F39 35AB F1A1 A93A ......[.?95....: 2455 E981 02A7 85B5 AFA5 ED18 A383 5469 80C5 ............Ti.. COPYRIGHT 1977 =>GO,D000. COMPUTER MART NJ Dynamic Debugging System with DM (Display Memory) option in use CALL STK SP=3FF9 ADDR ---INST----- OP REGS ---- ------------ --------------------- --------------- 2AB5 2AB5=E604 .. 3000 CALL CAB4 CD AF=00FF MZAPC 2388 2388=0418 .. 3003 JMP 0040 C3 BC=03DB=CD18 .. 1234 1234=02B2 .. 3006 SBB E 9B DE=2310=B303 .. FF00=FFFF .. 3007 INR C 0C HL=2320=C00F .. FFFF=C3FF .. 3008 POP H E1 2000 MVI A,02 3E 200D SHLD 2330 22 2002 STA 2300 32 2010 SHLD 232F 22 2005 LXI D,2310 11 2013 STA 2400 32 2008 STAX D 12 2016 DCR A 3D 2009 LXI H,2320 21 2017 JNZ 2002 C2 200C MOV M,A 77 201A MVI B,02 06 COPYRIGHT 1977 =>GO,D000. COMPUTER MART NJ DDS display with DI (Display Instructions) command The second group of commands is used for manipulating the user's program or other data. Using the keyboard, you may enter bytes, words (groups of two bytes), or characters into memory; fill portions of memory with a constant; move blocks of memory, or find a combination of up to three bytes. You may also modify any of the registers or register pairs, including the Program Counter and Stack Pointer, the stack itself, or the Dynamic Debugger's separate stack of return addresses. So, you also have complete control over everything going on in your computer. The third and most powerful set of commands is used to control and execute the program to be debugged. When debugging a program with DDS, your program never actually takes control of the system. Instead, DDS executes your program step by step, updating the display as often as you wish. (This is why it is nice to use a VDM-1. The VDM can be updated very quickly but CRTs may take a while longer.) As your program runs, you can see the Program Counter advance, registers change, data get pushed on and popped off the stack, or portions of memory change. Stepping -------- One character on the keyboard (ESCape) is used as the stepping character. Every time that this key is entered, part of the user's program is executed by the DDS. The exact number of instructions executed depends on the value that you enter with the STEP command. By entering a step of one, the program may be single-stepped by hitting the stepping character. Or, you may enter a larger step and run longer sections of code. You may also set the time delay between instructions, which permits you to execute the program slowly while referring to a source listing. Execution of your program stops when DDS executes the specified number of instructions, or when you enter a key (it does not matter which one). Detection --------- The Dynamic Debugger gets even better; it not only tells you what is going on: it stops when it detects something wrong. For instance, if you PUSHed more data on the stack than you POPped in a subroutine, there would normally be an invalid return address on the stack and your program could run off into the woods. By maintaining its own list of valid return addresses, DDS will stop when it thinks that you are trying to use a bad return address. Since some programmers do tricky things with the stack, such as intentionally pushing extra words on the stack to set up return addresses, this feature may be disabled. DDS also halts if you attempt to execute an undefined opcode, a HLT, or a RST. Error Condition --------------- DDS also permits you to enter your own error conditions. For instance, you can tell DDS to stop executing your program if the program references data outside of a certain range, if the program reaches a specified address, if certain opcodes are executed, if the stack goes outside of a given range, if the program attempts to store in a certain location, etc. Note that, for most of these, several conditions may be active at once. For instance, up to five opcodes may be used in the opcode stop option. When DDS finds an error, it displays an error message on the error line, and stops executing your program. Since DDS executes about 300 instructions per second maximum, a standard breakpoint facility is available for running sections of code that are lengthy or critical about timing. Evaluation ---------- This is an extremely powerful software debugging tool. What more do you need for debugging programs? At all times, you know the status of almost everything inside your computer, and if your program has done something foolish. DDS might even be a handy tool for teaching the inner workings of the Intel 8080 CPU (provided that it was not overwhelmed by DDS). Anyway, I could not think of anything critical to say about DDS, so Larry Stein (owner of the Computer Mart of New Jersey) mentioned a few questions that people have asked about the Dynamic Debugger. (1) Can it debug Z-80 programs? Well, sort of. When DDS reaches Z-80 code, it will display an II (Illegal Instruction) message and wait. You can then continue execution, if you want. DDS does not display all the Z- 80 registers, either. So, this version of the Dynamic Debugger really is not designed for Z-80's. It is not for IBM/370's either, says Larry. (2) What happens if you attempt to do an input from the keyboard which DDS is also using? Obviously, that will not work out too well, because DDS is constantly checking the keyboard, since it stops whenever a key is pressed. The solution is to move into the Accumulator what you were going to input. This is only a problem if you have only one keyboard in your system. (3) What happens when your program executes code in ROM (for instance, an I/O routine)? While code in ROM is being executed, the DDS is inactive. It takes over as soon as control returns to code in RAM. If the code in ROM does not return to the instruction following the call, a breakpoint will have to be inserted. This should not be much of a problem, since programs in ROM are usually already debugged. (4) How do you debug programs that use the VDM-1 for output? That might be a little tricky. The DDS does permit you not to refresh the screen after every instruction, and has a clear screen command which completely rewrites the screen. Useful if your program puts some junk on the screen. That's about the best that you could ask for, since you are trying to debug and output with the same device. If you will not like it, you are welcome to your blinking lights! Anyway, I consider most of these to be rather trivial questions. The DDS is available for $30 on CUTS or Tarbell cassette, and $35 on iCOM floppy disk, from the Computer Mart of New Jersey. It will be provided with a relocating loader (another nifty idea) which will let you stuff DDS anywhere in your system's memory. DDS is 4K in size. Complete details on interfacing to your system are provided. Despite my proclivity for finding problems in almost any product, this is one that I can recommend without hesitation. Get one if you do any Intel 8080 assembly language programming, or just like to hack around with fancy software! Dynamic Debugging System commands --------------------------------- AR Address Range stop request AS Address Stop request BK Run at full speed until BreaKpoint is reached CALL Pushes a word on DDS's call stack CLR Completely rewrites the screen DI Display memory as Instructions in mnemonic format DM Display Memory as hex and ASCII characters DY Set time DelaY between instructions EB Enter Bytes into memory EC Enter Characters into memory EP Enter Program counter ER Enter Register ERP Enter Register Pair ES Enter Stack pointer EW Enter Word into memory FILL Fill block of memory with a constant FIND Find a series of bytes in memory GO Same a BK, except that the breakpoint is not retained MOVE Move blocks of memory OS Opcode Stop request POP Pop a word from the stack PUSH Push a word on the stack REF Controls whether the DI or DM display is automatically updated RET Removes a word from the call stack RS Reference Stop request SR Stack Range stop request SS Store Stop request ST Sets number of STeps executed by stepping character TC Controls use of automatic return address validation VSR Value Stop on Register request VSB Value Stop on memory Byte request VSP Value Stop of register Pair request VSW Value Stop of memory Word request Note: Most of these commands require arguments which are entered with the command, separated by commas. A period indicates the end of a command