Small inconsistency with 9938 VDP timings...

The only speed limitations should be related to VRAM access (due to the access slots mechanism), you should need no waits between VDP register access. The nop/nop thing is a bit of a myth that dates back to the time when people didn’t realise waits only applied to VRAM access and recommended adding them just to make sure. I myself do exactly what you do without any issues at all on real hardware.

Edit: But actually you don’t mention what your VDP_STATUS and VDP_DATA defines are, so I actually don’t know what you’re doing :). Using the VDP_STATUS identifier to write seems rather strange (I would expect a read). And if it does refer to 99H, then you should always write in pairs, so you’ve got an incomplete write.

Ok, that trick only works on TMS9918, and not even sure if it works on all variants (Toshiba/Yamaha clones). It does not work on V9938. People should not rely on that implementation detail of TMS9918, it’s not compatible.

And as for openMSX emulation correctness, are you using an openMSX machine that matches your real hardware? If openMSX is an MSX1 and your real hardware an MSX2, that could explain the difference.

Ok, in that case, you probably just set up the VRAM read address and then try to read the value, correct?

There are speed limitations for VRAM access, you need to wait a certain amount after writing and a certain amount before reading. This is documented in the TMS9918 and V9938 application manuals, and in extreme detail in this research by the openMSX team. OpenMSX should be emulating this but perhaps not absolutely perfectly when you’re right on the edge.

The myth I was referring to was related to waits between register access, but that’s not what you are doing (I assumed you were at first but didn’t actually have the context to make that assumption).

Thanks for the tips, I'll check that out as well (didn't realize there was a bios command for loading vram). I am indeed getting the same tile.

As far as using a buffer in RAM, that's partially what I'm doing - the issue comes in from reading the tile number itself.
i.e. set the location of VRAM access (I store these in hl and increment accordingly) then immediately load. I don't quite understand how a RAM buffer can help in this particular circumstance, and I don't see any solution besides NOP.
The (erroneous) block looks like:

        ld a, l 
        out [VDP_STATUS], a 
        ld a, h 
        out [VDP_STATUS], a 
        in a, [VDP_DATA]  ; < reads incorrect byte

followed by various operations (well over 20 t-cycles) and a loop.

Grauw, I am aware of the wait time between commands. Your own website states that this limitation is not present during vblank (I only perform this many operations during vblank, then update the screen once and repeat - the operation as a whole takes about 4 frames), and seems to imply that it only matters for VDP writes - I was using your page as a reference when trying to debug this. I didn't see anywhere that explicitly states that regardless of which VDP register you use you must have a cycle wait, or that there is an issue of timing after setting the VRAM read target in the status registers - unless it just went over my head

I'm clearly not an expert, but this method in particular is not OK on hardware. As I mentioned in the OP, openMSX *sort of* gets the timing right but its off by just enough cycles that hardware provides very visibly different results