Disc analyser news update

In effect, what the logic analyser did was to display the results of stepping through about 100 instructions showing the data values and address pointers that were required as they were used by the program. This is exactly what a debugging session would be when a used to actually stop the program and then manually and visually inspects the values of interest. While the logic analyser is much more restrictive, its great advantage is that it does NOT change the timing of the operation since it captures any data it collects in real time and stores it in its own buffers outside of and apart from the system being tested without in any manner disturbing the system being tested by that observation. The logic analyser can do this because it is able to collect the data in its own buffer as the data is produced by the test system without regard as to when the trigger location or event in the system being tested will take place. When the event does occur, the logic analyser then takes a simple action. It stops accepting any more data and retains the snapshot of the previous bunch of instructions that preceded the event. It is like asking the breakpoint to take place at a certain location, then asking the system to reverse itself and run backwards to look at what HAD JUST HAPPENED during the previous 100 instructions. Obviously impossible to do with a breakpoint on the normal way, but that is how the logic analyser functions. Please correct my memory of how the logic analyser functions if I did not remember correctly - or if that is just one of the modes of operation. To accomplish to feat, the logic analyser probably has to run at least 10 times faster than the system being tested. (Tony, do you have any estimates?) With the fastest CPUs being used today, that is becoming increasingly MUCH more difficult. Tony, is that what you are concerned about as well, how the logic analysers are able to keep up?