At 12:00 -0500 8/27/13, Jerome Fine wrote: Jerome, hopefully you'll get much better-qualified answers than mine; I have little to no experience programming assembly or PDP-11. That said, I can think of a few possible answers: 1) enough instructions that any timing-critical loop will be captured when an external interrupt dropping into the debugger is generated. This might be relatively short - 200 instructions or so? User (not necessarily programmer?) would set up and start a long calculation (mandelbrot set, whatever) and then hit "break", and be able to look back far enough to verify that the correct sequence of instructions is repeating over and over. For actual number, maybe look at the longest loop in RT-11 that repeats many times successively? 2) enough instructions that any timing-critical *subroutine" will be captured when dropping into the debugger. This would be a *lot* more, depending on application. In this case, the programmer would add a break point to the code right after the timing-critical routine (disk access, real-time control interrupt service routine, whatever) and then look back at the buffer to verify that the whole routine took the correct execution path. For disk access, that might be a *lot* of loops, though, so maybe you are only capable of writing a buffer to hold the last few iterations? For actual number, look at the longest single executable code unit in RT-11? 3) Configurable depth, configured at launch time for debugger Programmer gets to make the trade between debugger buffer depth and available memory for his program. Not sure any of this is helpful, and you probably have thought of it anyway. -- - Mark 210-379-4635 ----------------------------------------------------------------------- Large Asteroids headed toward planets inhabited by beings that don't have technology adequate to stop them: Think of it as Evolution in Fast-Forward.