What happen on MSX2 VDP if we set hblank interruption register to the last screen line?
In theory, the 2 interruptions should be triggered at the same time since the end of the last line meets the conditions of the 2 interruptions, but what happens in practice?
If only one of the interrupts is triggered, are the 2 flags set (bit 7 of S#0 and bit 0 of S#1)?
I've done such things, but the otherway around. I have vblank set interrupts enabled and a line interrupt at the beginning of the screen. That way interrupt gets nested (or atleast the ISR handler). It's been 30 years, so I can't recall the details. But yeah, just test it man
The case you describe is different. You are talking about an interrupt that is triggered before the ISR of the previous one is completed. In this case, I think that the new interrupt is simply ignored (as long as a reti has not occured).
I was talking about the (hypothetical) case where the vblank and hblank interrupts could occur at the same time.
AFAIK, the interrupt request remains active as long as the CPU has not acknowledged it.
So the Z80 will treat the first interrupt, and then it will proceed to treat the second one.
The line interrupt occurs at the beginning of line scanning. Hblank occurs at the end of the last line scanning.
It seems to solve the problem.
So I can consider that I never have more than one VDP interrupt to handle at a time and that if the vblank is triggered and the F bit of S#0 is set, then the FH bit of S#0 is not. And vice versa. Is this correct?
I will add support for hblank interrupts in my custom ISR and I am looking for the most optimized way to handle only VDP vblank and hblank interrupts.
My current plan (in pseudo-code):
BackupRegisters
Read S#0
if F == 1 then HandleVBlank
else
Read S#1
if FH == 1 then HandleHBlank
RestoreRegisters
From: http://map.grauw.nl/articles/interrupts.php « The RETI instruction can be recognised by a device at the moment it is executed by the CPU, so that it can know that its interrupt has been handled. For this reason it’s better to use a RETI than a RET, although they are identical in function. Note that IFF1 is not set by the RETI instruction. This must be done with an EI instruction in the interrupt routine. »
If the VDP doesn't care that its interrupt has been processed, it's actually useless in my use case.
The point of RETI is that the peripherals in um0081 scans the bus for the RETI instruction fetch and releases their IEO-pin on it.
For that to work all the peripherals able to trigger interrupts needs to be daisy-chained and support this function.
Since the V9938 doesn't monitor Z80 instruction fetches it can't clear the IRQ automatically and it has to be manually cleared.
In a mixed Z80 system where you have both peripherals that supports RETI and peripherals that doesn't, I think the proper way is to only use RETI to return from interrupts triggered by the daisy-chained peripherals and use RET for the others, otherwise they won't be able to count the RETI properly. (Clearly only relevant if you do an EI in the ISR to allow prioritized interrupts.)
AFAIK the Z80 itself doesn't do anything differently between the instructions but RETI take a few more cycles.
Even if RETI could be useful in the case where we create our own interrupt routine, that is not recommended by the standard. So it's not good advice to use RETI in an MSX program.
