> And it works for all cases where the hardware does not need to be reset
> to some "interrupt-handled" state. e.g. some interrupts need to be
> cleared somehow (mostly by reading one or more bytes from pre-defined
> IO registers). If that is _not_ done within the ISR, the interrupt will
> re-fire
hi Al,
>
> Howeer, if you use int! to set a "Forth" interrupt vector, the default isr
> sets the "T" flag when an interrupt trips. It also stores the current vector
> in
> a location where the interpreter can find it.
>
> When the interpreter is about to dispatch it looks to see if the T flag
> Bad unless you have a way to keep a queue of
> interrupts pending, for example
> (which would be another neat project).
yes, a queue e.g. 8 vectors deep, then you must not care on T - when
q. not empty then int. has been fired, and forth will process them
in an order.. mind latency of forth..
P.
