Mail Archives: djgpp/2003/07/12/07:30:18
Thanks for your reply!
In fact, I really did the experiment again and again. I changed the
interrupt source to a function generator, which can provide more
stable square wave. And I tried PMODE, too. But similiar result was
got.
I am not clear with NMI or bus reset. In what cases NMI or bus reset
will be triggered? In my mind, only power off can trigger NMI. But how
about bus reset?
Actually, I find that some dos programs have strange behaviors in new
CPUs, such as P3 or P4, but work well in some old Pentium systems.
Maybe it is due to the bad design of bios? But programms running in
pure protected mode will not call any BIOS funcitons, right?
Is it possible to get an interrupt response time within small range in
protected mode? so tough...
Sincerely,
Wang Yong
Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote in message news:<3f0f4fdc DOT sandmann AT clio DOT rice DOT edu>...
> > Both programs are compiled by DJGPP v2.03, gcc 3.23. DPMI host is
> > CWSDPMI v5. I use CWSPARAM to disable virtual memory, so no paging
> > will occur. And in program (2), ALL hareware interrupt are disabled
> > expect IRQ7, main() is an infinite loop: for (;;) {}. Therefore,
> > technically, no mode switching will occur in program (2) during test.
>
> > I use logical analyzer to capture the interrupt latency (time between
> > the low-to-high edge of interrupt source signal from program (1) to
> > low-to-high edge of signal from program (2)). Normally, the latency is
> > less than 6 microseconds, which is really reasonable. However,
> > sometimes (in 1 or 2 hours), a very large latency, 30 to 60
> > microseconds, can be observed.
>
> There is nothing in the software which should caus this to happen.
> I suspect that something in the hardware triggers this - maybe a
> NMI - or a bus reset.
>
> You might try PMODE (which has an even lower latency) to see how it
> works for you. Since it doesn't enable paging, maybe the hardware
> will respond differently, I don't know.
- Raw text -