Suggestions Appreciated for a Program Counter History Log

I know of only one example of a debugger which supports a Program Counter History Log. I am in the process of adding a Program Counter History Log to the System Debugger in RT-11 on a PDP-11. I would appreciate a few suggestions from anyone who has any experience with a debugger program which supports Program Counter History Logging. For users who are not familiar with PDP-11 hardware, the primary interface is a serial terminal, usually with 9600 baud these days (don't laugh - I first started on a PDP-11 around 1975 over a 300 baud modem), with a screen of 24 lines by 80 columns. There are a probably a VERY, VERY few systems which use VT420 terminals which can support 48 lines, but which are probably rarely, if ever used with other than 24 lines by 80 columns. From my point of view, the primary considerations are the lack of both speed (9600 baud takes seconds to fill a full screen) and available screen space to display more than about 200 addresses from the History Log Buffer (at 10 addresses per line). While I normally use the Ersatz-11 Emulator for the PDP-11 which provides me the possibility of using screens of 50 lines, I suspect that I am presently the ONLY person to interact with RT-11 using a screen of this many lines, let alone the speed of the screen which is so fast that the time between SCROLL and NOSCROLL is usually a dozen lines of output to the screen. At 9600 baud, the SCROLL vs NOSCROLL time delay is only a few dozen characters at most, certainly less than one line of output to the screen in almost all cases. The only experience I have with a debugger which has a History Log is with a 64 word buffer of addresses for the 64 immediately previous instructions. While this is often sufficient to at least pinpoint the general location of where the program stopped, it was often insufficient to locate where the problem started. For those who have direct PDP-11 experience, the following information might also be useful. At present, there are two buffers which can be displayed: (a) A buffer with 40 of the last interrupt entries to SD: which are composed of 5 words each: - Program Counter Address from the Stack - Program Status Word from the Stack - Word (instruction?) at that Address - Word (instruction?) at the Previous Address - Control Word which is used by SD: (PROSNG) (b) A buffer with the last 1000 Addresses of the last 1000 instructions that have been executed The current logic in the code to save each instruction address in the 1000 word buffer ONCE and ONLY once uses all five of the above values. There seems no point in displaying all 1000 addresses since only about 200 can stay on the screen and it takes too long in any case. However, just how useful are the past 1000 addresses as an aid in debugging? Since it takes no additional time for a larger circular buffer over a smaller circular buffer (in fact maybe a larger buffer is insignificantly faster) and there is memory available, I opted for the largest buffer that was reasonable The other buffer with the 5 word entries entries for the last 40 interrupts will be used when there are any questions about the exact details of any interrupt with respect to a user having set a Breakpoint or any other logic errors in the debugger in general and specifically when adding addresses to the 1000 word history log. NOW finally, here are my questions. Are there any suggestions as to how many previous instructions are needed to usually be helpful to have a log for when a program has a problem? Also, would it be useful to have the first word (two bytes) of the instruction as well as the address in order to identify the actual instruction or is the address almost always sufficient? On the PDP-11 with instructions being 1, 2 or 3 words, it is totally unlikely that having the addresses of the previous instructions would ever allow a user to confuse which code was previously executed unless two variants of almost identical code had been purposely constructed so as to confuse the user. This could occur when two overlays use the same addresses to execute that code, but it is almost impossible to happen by chance and even it it did, an extra NOP could simply shift the code for one of the variants so as to avoid the confusion. Jerome Fine