wait 15 T-States between reading and writing to Vram

According to OpenMsx the vram pointer is not incremented, unfortunately.
I have a splitline in my code, where I want to update ONLY the y variable of several (bordermasking) sprites.
So my code looks like this:
ld hl,BorderMaskingSpat
ld c,$98 ;port to write to and deal with the nop required wait time
outi | nop | in a,($98) | in a,($98) | in a,($98) ;write new y value, then increase vram pointer 3x
outi | nop | in a,($98) | in a,($98) | in a,($98) ;write new y value, then increase vram pointer 3x
.... repeat
The first OUTI is to write the new Y value to the Spat, then I use 3x in a,($98) just to increment Vram pointer.
Unfortunately it doesn't work. I don't have a real msx to test, so it could be working on a real msx.

Instead I have to transform this into:
ld hl,BorderMaskingSpat
ld c,$98 ;port to write to and deal with the nop required wait time
outi | nop | in a,($98) | nop | in a,($98) | nop | in a,($98)
outi | nop | in a,($98) | nop | in a,($98) | nop | in a,($98)
.... repeat

The extra wait in between the in command's are required (even if you ONLY want to increase Vram pointer).

At least in Openmsx....
If someone wants to test this on a real msx, it's worth testing it imo...

Ok, let’s take a look…

If I read the V9938 VRAM timings (part 1) article, in section “position of access slots” it says the maximum gap between slots is 70 VDP cycles, and in section “allocation of access slots” it says the setup time for a write is 16 VDP cycles. In the section “too fast CPU access” it concludes that the minimum wait time is the sum of these, iow 86 VDP cycles or 14.33 CPU cycles.

• Sprites enabled: 70 + 16 = 86 VDP cycles (14.33 CPU cycles)
• Sprites disabled: 54 + 16 = 70 VDP cycles (11.67 CPU cycles)
• Screen disabled: 44 + 16 = 60 VDP cycles (10 CPU cycles)
• TEXT1 & TEXT2: 100 + 16 = 116 VDP cycles (19.33 CPU cycles)

The 14.33 cycles rounded up to 15 matches the title of this topic. I don’t know what the source is of that 13 cycles number on the wiki page, but it matches none of the above. The 20 cycles it mentions for TEXT2 does match, but this actually also applies to TEXT1 mode (width 40), as V9938 VRAM timings (part 2) mentions explicitly.

Edit: Oh look, the MAP already had this info in a nice table, including references to sources :).

I’m not sure indirect I/O instructions (out (c),r) are “typical”, direct addressing (out (n),a) is used a lot, it seems the text should mention the both of them and also (or only) consider the faster one.

Since the wait line of the V9958 is not hooked up in any machine, this is not really the case. I suggest to either remove this line, or elaborate that it is not hooked up, otherwise it will mislead the reader.

I thought this wait is only needed for reading? To allow the VDP to fetch the value? Since it is already mentioned in the bullet points earlier, where it says the read setup time is 10 cycles (source?), I don’t think it needs repeating in more vague statements like “wait a little”. Though maybe it is different for TMS9918, but that’s not very clearly stated then.

Pretty sure this should be jp nz.

just got confirmation. Tested on a real msx
in a,($98) | nop | in a,($98)
If you leave out the nop, the Vram pointer is not incremented

I rely on the MRC wiki for a lot of things, I respect the work put in by everybody, and I contribute to it too. But for programming articles I like to see a clear author and maintainer, source references, experimental confirmation. Not to say the MAP is perfect, but I think it’s harder to achieve on a wiki.

Yes I have! Thanks for informing me. I will update it after I confirm, I sent a reply in the meanwhile.

Great, good to know!

You should test this also by displaying an image. If the pointer was not incremented in just one of the written pixels, you get a 45 degree angle (leftside) in the displayed gfx. I never saw this happen in any of my projects but only some pixels being corrupted.

CORRECTION: It does happen :-)