Fastest in interrupt mode?
I am not sure what you mean by that but I couldn't think of a moment this ia true.
If ISR uses VDP, things may be messed up, hence, any out/outi/otir (-sequence) that writes to VDP needs to have interrupts disabled.
Sure, but what makes isr do faster vdp interaction. Just curious.
Sure, but what makes isr do faster vdp interaction. Just curious.
I haven't seen anyone state that it does, where did you get that from?
Sure, but what makes isr do faster vdp interaction. Just curious.
Not directly related to interrupt itself. Just a side effect that if you didn't change anything (i mean didn't configure it to happen on another scanline) - the interrupt happens when VDP is not drawing things on screen (on V-blank), hence some things will work a little bit faster at that time
Sure, but what makes isr do faster vdp interaction. Just curious.
I haven't seen anyone state that it does, where did you get that from?
Well, it's mentioned a few times on page 1. I'm asking 'cuz I could misinterpret it.
okay, VDP actions are not "faster" in vblank or any other ISR mode. Interrupts are just sub routines that gets called now-and-then. In compute, 1/50 or 1/60 second is a long time.
You can only do one successful and complete VDP action at a time, so any subroutine during VDP actions (like interrupts are) should be aware of that. It's just like registers, keep them save if needs to.
So, when you have no VDP actions going on during any ISR routine, you can savely do VDP actions even with ints on. You see, it's just a matter of knowing, not guessing. If all your vlblank does is play some good old SCC tune or something, just out that vdp with ints on. no worries. (only exception would be status reg)
On the other hand, I tend to do VDP actions on interrupts only. That way you won't see ugly screen refresh misalignment. You know, doing a sprite update somewhere while the scan-line is at that exact moment. you get crooked sprites. Doing such at the bottom of the screen (line interrupt or even vblank interrupt) makes that smooth.
When doing a VDP indirect addressing command, be sure to check the CE status bit to see if the VDP is ready doing what he does.
The most interesting thing should be the difference in VDP access on MSX1 and MSX2/2+/tr machines. I have never coded for MSX1, so I use OTIR or any other fast method always. Works everywhere. But I'm gonna do some tests to see what the MSX1 does with that, I'm triggered by G's comment.
Coding, just love it.
Everything is explained here (TMS9918A manual):
Nice.
I could interpret the "4300 microsecs after vlank" as the non-printed part (or non active) of the screen which, sure, could have a positive effect on VDP performance in that window. This has nothing to do with VDP commands ON interrupt routines, persé.
That's why I was asking
I confirm to make sure your program works on all MSX1s, do not write to VRAM with OTIR, nor with OUTIs one after the other without putting at least two NOPs between them even during vblank.
Wait a minute here... this is a pretty heavy statement ! (I mean the "even during vblank" part). I use unrolled OUTI's in my games to copy the Sprite Attributes Table to vram during vblank, and have never noticed any troubles (tested it on some different real MSX-1 machines).
Are you sure you are right? because it goes against everything I've read so far on this topic.
And why 2 NOP's ? Then it is still only 18 (outi) + 2x5 (nop) = 28 T-states while it should be 29 when not in vblank ?
I can't give more details because I noticed it while fixing games that didn't properly work (graphical glitches) on my MSX1s. I just replaced OTIR and/or successions of OUTI by what I indicated. Sometimes replacements were in the interrupt routine. I have fixed several and I do not know which ones are concerned.