Suggestions Appreciated for a Program Counter History Log

Actually, the SD: debugger for RT-11 already does that. The user can request that 126 instructions execute in a single step mode and the debugger will display each instruction and all the registers as those instructions are executed. If a particular portion looks interesting, the user can <CTRL/S> to stop the process and <CTRL/Q> to restart. On a VT100, the key called {NO]SCROLL can be used to toggle that. However, the overhead is quite high (probably a few thousand instructions for each instruction displayed) and I found that less than 100 instructions is sufficient to capture just the address of each instruction. It is actually quite complicated since interrupts to the SD: debugger can table place for many reasons and the pre-analysis when history logging is active is not at all simple. The word pointed to by the PC at the time the instruction would have been executing. By the time the SD: debugger in RT-11 is in control as a result of the interrupt, the stack holds the address of the instruction, so both answers are actually correct. Usually, I think of the instruction as being at the address pointed to by the PC, but after the interrupt, that address is pointed to by the stack - although for a PDP-11 running a Mapped Operating system with the user program executing in User Mode and the SD: debugger executing in Kernel Mode, it takes a special PDP-11 instruction, MFPI or Move From Previous Instruction, to access the User Mode Instruction Space from Kernel Space. Fortunately, the instruction: MFPI @(SP) will use the word on the stack as the pointer address and add the word at that address in User Mode to the stack in Kernel Mode. So it usually takes only a single instruction to retrieve the instruction that was just about to be executed when the interrupt took place. Someone put a lot of thought into how programs could be debugged under RT-11. As it happens, the operating system also requires MFPI since a call to the operating system also results in an interrupt directly into operating system code which also places the address (in this case of the next word) on the stack. The simple solution to capture that word is: Mov (SP),-(SP) ;Copy the address on the stack Sub #2,(SP) ;Get address of instruction causing the interrupt MFPI @(SP)+ ;Place instruction causing interrupt on the stack That is the specific answer I was looking for. With a 64 word buffer, only a very general are is possible. At that point, it often takes MANY more attempts to isolate the bug, but at least even a very small buffer provides a hint and a start. By nature, I am a VERY conservative programmer. In almost all cases, I attempt to add as little code as possible when I make a change. That helps to pinpoint the area to look at when any changes cause a problem. Notice the HELP - it does not work all the time. That is what I thought. Even when overlays are used and many possible different subroutines can be read into the same memory, with the PDP-11, the mix of different instruction lengths will also provide confirmation as to which group of instructions was executing. THANK YOU for your suggestions. I feel that I am on the right track. At the moment, I also want to add the ability to choose between 10 addresses per line in the history log (when the screen is 80 columns wide) and 18 addresses per line in the history log (when the screen is 132 columns wide). I can use <CTRL/N> to set the screen to 80 columns and remember the screen size. Alternatively, <CTRL/W> can be used to set the screen to 132 columns. <CTRL/R> seems a good choice to just refresh the screen as needed. Many other RT-11 programs also use <CTRL/R> and <CTRL/W> as equivalent to refresh the screen, so they seem to be a good fit along with adding <CTRL/N> for the NARROW screen. Jerome Fine