PC scope point

Bypass the OS, Write directly to the parallel port or some other I/O or memory address where you can attach a scope probe. I normally use a crude R-2R DAC ladder on LPT1 which I write value to. The scope then triggers on the "higest" value, and I can get different timings on one scope trace. Use something like giveio.sys to bypass Win2000.

Regards Anton Erasmus

Or send a char out of an RS-232 port if you have one. It's not too hard to read the actual byte sent if you have a digital scope or a LA hooked up to it.

Vadim

Hi Ted,

I use a logic analyzer for those kinds of jobs. But you can also take a digital scope with long enough pre- and post-trigger storage. Then you can look at events that happened way before the trigger, which might allow you to use the RS232 or a parallel port 'ping' signal. I believe some scopes of the Tektronix TDS Series are equipped with long buffers. But it's been a while that I did that with a Tek scope (and just because the client had no logic analyzer and ours is too heavy for carry-on). Most of my work is HW and high frequency or fast digital stuff, not programming.

If you absolutely need to have your trigger really close to your event maybe you could send something unique to the video chip. That typically gets accessed rapidly. I did that once with an ET4000 (remember these?) by programming in a flip of the color palette, something extreme like from blue to red (no political pun intended...). Or place a hard disk access after a 'quiet period'.

Regards, Joerg

Thanks all.

Perhaps I should have made the query a bit clearer...

I am after a method that will respond immediately after the instruction.

Any method that uses the OS will be too slow. Calling the OS, generating IRPs, calling the kernel routines..all takes far too long...(:-(

I am after some clever idea like placing the scope probe somewhere on the motherboard where such an "immediate" signal would be available.. any ideas??

TIA

There isn't such a thing except to perform a direct write to some IO port; and even those can be delayed from the execution of their instruction. With all the caching, prefetching, speculative branching and multiple execution streams not to mention smart IO controllers it is very, very difficult to tell exactly when an instruction is executed. Even if it is executed, it may have been a speculative execution whose results are not saved.

If I'm not mistaken, a write to an IO port with a read to the same port and some operation performed immediately on the data read would be the only way to be sure.

Noel

And at least some of the methods you were given do exactly that. In particular the "write to printer port" one.

The crux of the matter is what "immediately" means. Direct I/O port writing is "immediate" in the only sense that can possibly apply in a multitasking environment such as Windows NT: the physical change to the port pins will happen *before* your program gets to continue doing anything else. It's quite impossible to tell how long it will take from the point your program gets to the OUTP instruction to the voltage change, and from there to the execution of the next instruction of your program, by the very nature of the environment.

In other words, it's possible you're asking for the impossible.

I would even quibble with the *before* in your description. While somewhat unlikely, it is quite possible that output to the port is queued up for later delivery, much like disk writes in Unix. Thus your program may be continuing while the data is still in the queue, and you cannot count on any timing relationship except that the signal occurs *after* the event.