Demonseed:
ASM to me seems dizzying.
At first yes. But once you get going isn't that dificult. The most dificult part is using it in the correct (fastest) way. Which is very important when addressing the VDP.
I have to re-code my VDP updates in my interrupt routine because they are way to slow.
With you LEDA coding skills I am confident that you can master it (There is help all around).
Can I prove my noobness on msx2?
I would like to set an interrupt at line -1 (in the border, just before the screen starts), while the Vblank ISR is still beeing executed.
It would be a new interrupt able to interrupt also the standard interrupt code....
Is it doable? How could it be done?
Thanks
PS
I have bios in page 0 but I use a custom ISR using the hook at fd9a and by popping th ereturn address
PPS
It would be ok even to set the interrupt at line 32
PPPS
this should allow to have the borders and the scorebar in screen 5 and the game area in screen 4
Sure it can be done, but make sure that every interrupt in interrupt is controlled. You can for instance set a new address and then EI again within the ISR. At the end of ISR2 you set the original ISR again. In order to get everything working correctly, you will have to know the extents of what can happen. For instance, is it possible for ISR1 to be finished before ISR2 is triggered. This means you'd have to EI at the end of ISR2. But this would be disastrous if ISR1 could last long enough to trigger another vblank.
You may want to take a few extra lines if you use FD9A though. The full register push bios does gives quite a bit of delay. Which you actually *have* to do since you can't do a line interrupt on line -1 (you'll have to look up the last line that is possible (which is different for 50/60Hz))
Line 32 would be much better. Although I can't imagine why you'd want the scorebar in sc5. Takes much more time to update.
The idea is to use VDP commands to mange msx2 sprites.
As the game is in screen 4, I need to move to screen 5 at the very beginning of the standard ISR (start of the vertical border), send the VDP commands, do a lot of z80 stuff, return to screen 4 before the screen starts but after the commands are ended, continue the z80 stuff, end the ISR.
Polling the CE but while doing the z80 work is very inefficent.
The sole effective faw to return to screen 4 is a line interrupt able to interrupt the Vblank ISR when any vdp command is for sure ended.
@ARTRAG
In your case the VDP is not your friend... If you really want to do this with interrupt I suggest you to leave the first 8 lines unused and set the interrupt to line 0. This way you have 8 lines time to change the screen mode.
Hmm... I'm really not expert on this, but I also started to wonder that if you use 256x192 screen in SCREEN 4 and 256x212 in screen 5 then doesn't the line 0 come earlyer in SCREEN 5? I mean that if you alter REG#9 bit 7 then maybe you can get interrupt in SCREEN 4 line -8 (or something like that) if you ask for interrupt on line 0.
If these ideas don't work then I suggest just to adjust your routines so, that fixed time routines are executed first and if you still have too little time spent then try to add CE check to some outer loop on your variable time routines.
Hmm... Thinking again, you propably end up just adjusting the screen 8 pixels up... but maybe if you then use adjust register #18... I think you need to do some tests
Atm i have insertred the polling of the CE bit in the code that updates the PNT....
if command ends I set screen 4
It is not very efficient (as it adds overhead in the I/O) but works
If the CE bit changes always in middle of PNT copy, you can just spit the copy: ie.
<copy 2/3 of PNT>
<change screen mode>
<copy 1/3 of PNT>
... no need for overhead in I/O
(I assume you always copy same amount of data with VDP copy)
actually not: I copy 128 or 64 bytes....
what I could do instead is to split the code that updates the PNT in two:
<copy the PNT untill CE >
<change screen mode>
<copy the rest of the PNT without polling CE>