Hi,
> Rainier Maas schreef:
>
>> Hi!
>>
>> I have a little question:
>>
>> - Interrupt occurs
>> -> (DI)
>> -> Interrupt Routine (-> new interrupt occurs)
>> -> EI
>> -> ret
>>
>> What will happen if a NEW interrupt occurs when the MSX is
>> processing obove mentioned "routine-part"?
>>
>> - After switching the interrupts on, will the MSX remember the
>> interrupt and calls again the interrupt-routine?
>>
>> OR:
>>
>> - Is the additional interrupt lost forever?
The interrupts (both maskable & non-maskable) are not 'remembered' by
the Z80, they are only 'sampled' at certain times. If the interrupts
are enabled at that time, the interrupt is 'taken', if they are
disabled at that time, this particular interrupt is lost.
When a (maskable) interrupt is taken, an automatic "DI" is done, so
that (maskable) interrupts are disabled right after that, followed by
a restart-instruction, of which the address depends on the interrupt
mode. With the normal IM 1 used in MSX, this is a "RST 38h" ("CALL
38h"). A databook I have, says that during the acceptance of this
interrupt, 2 extra wait states are added, to give the hardware extra
time to place an interupt vector on the data bus in IM 2, but these
extra wait states are also added for the other interrupt modes.
You SHOULD end a routine for processing maskable interrupts with RETI
(RETurn from Interrupt).
BTW: RETI <-> RET:
As far as I know, RETI and RET work exactly the same in all respects,
and are different only in the exact instruction bytes, and the number
of T cycles they consume. My guess is, that RETI simply serves to
INDICATE that it ends an interrupt-routine, rather than a normal
subroutine. For the rest, it's my belief that these 2 instructions
can fully replace each other (so that you can use a RET wherever a
RETI is used, and vice versa). There IS a difference between RETN
(with NON-maskable interrupts) on the one hand, and RET/RETI on the
other hand, but did anyone ever find a difference between RET and
RETI (other than instruction bytes and T cycles)?
When you want interrupts to keep occuring, than you have to re-enable
interrupts ("EI") SOMEWHERE before the end of the interrupt-routine.
I think in the MSX this is done somewhere after it has been
determined that the interrupt actually came from the VDP (as it
normally is), so that either the VDP can give a next interrupt after
it was determined that this one came from it, or in the rest of the
interrupt routine, interrupts remain disabled until some other source
of the interrupt is determined.
Of course, when calling BIOS routines, or other subroutines in such
an interrupt-processing routine, you have to carefully watch whether
it's okay if interrupts are re-enabled at that time, or avoid using
subroutines that re-enable interrupts.
Such an interrupt-routine might finally end with:
EI
RETI
When the EI instruction is executed, interrupts remain disabled (!)
for 1 more INSTRUCTION, in other words: after the EI, an interrupt at
that time would still not be accepted. First one more instruction is
executed, and THEN another interrupt might be accepted.
In the above example, an interrupt between the EI and RETI would
still be ignored, only after the RETI is executed, a new interrupt
could occur.
This one-instruction delay after EI is provided, so that if you end
an interrupt-routine with a RET(I) directly after the EI-instruction,
the RET's get executed first (getting a return-address from the
stack), so that the stack won't get bigger all the time if interrupts
follow directly after each other.
For the rest, it's perfectly possible to have an interrupt-processing
routine being interrupted, and this next routine being interrupted
itself, etc. etc.
This is only limited by practical issues, like stack space, time
required to process interrupts, and the frequency at which they
occur. If you want things to keep working, you have to provide enough
stack space, make sure that interrupts occur only at such a rate that
the CPU can process them, and make sure an interrupt-processing
routine is built properly.
Well, it's time to interrupt this thing now.... ;-)
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://www.twente.nl/~cce/index.htm (computerclub Enschede)
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
