Copy to VRAM (VDP) programming question

Page 2/3
1 | | 3

Par ro

Scribe (5059)

Portrait de ro

22-06-2022, 08:15

Fastest in interrupt mode?
I am not sure what you mean by that but I couldn't think of a moment this ia true.

Par Bengalack

Paladin (802)

Portrait de Bengalack

22-06-2022, 16:39

If ISR uses VDP, things may be messed up, hence, any out/outi/otir (-sequence) that writes to VDP needs to have interrupts disabled.

Par ro

Scribe (5059)

Portrait de ro

22-06-2022, 21:06

Sure, but what makes isr do faster vdp interaction. Just curious.

Par bore

Master (182)

Portrait de bore

22-06-2022, 22:09

ro wrote:

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?

Par Pencioner

Scribe (1609)

Portrait de Pencioner

22-06-2022, 23:51

ro wrote:

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

Par ro

Scribe (5059)

Portrait de ro

23-06-2022, 09:21

bore wrote:
ro wrote:

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.

Par Metalion

Paragon (1628)

Portrait de Metalion

23-06-2022, 10:29

Everything is explained here (TMS9918A manual):

Par ro

Scribe (5059)

Portrait de ro

23-06-2022, 10:52

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 Smile

Par Micha

Expert (110)

Portrait de Micha

24-06-2022, 11:37

gdx wrote:

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 ?

Par gdx

Enlighted (6429)

Portrait de gdx

24-06-2022, 12:01

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.

Page 2/3
1 | | 3