What if V9938 never existed?

(Slightly off-topic: I always assumed the DIX/DIY flags do matter if you read/write data from CPU to VRAM using commands such as LMMC? That would technically be a 'flip', although not really a useful one ).

Mirroring isn’t that great anyway IMO for high quality artwork. Since the light source would typically be in the top left or top right, if you mirror the shading would be wrong. And mirroring up/down doesn’t apply for obvious reasons.

Also mirroring is a memory optimisation, but I think with 128K of VRAM lack of the memory itself isn’t a huge problem. I mean we can store 256x1024 worth of 4bpp bitmap data, that’s a lot.

Ah, yes, you’re right!

And I do think sourcing tiles from the CPU memory rather than from VRAM page is pretty useful. Especially for ROM based games.

Why not? Look at how fast Aleste 2 scrolls using the V9938’s vertical scroll register. Uridium is that just flipped sideways, which the V9958 has no trouble with scrolling.

It does that too in some very fast sections, but e.g. here @ 16:58 it scrolls at 4 px / frame without repetition. And that’s still relatively slow, the VDP is fast enough to supply 16x212 worth of new pixels for a 16 px per 60 Hz frame scroll.

At max speed Uridium 2 seems to scroll 8 px per 50 Hz frame (pause and use , and . to frame-step in Youtube). That’s no problem for the V9958 to keep up with, even in 8bpp screen modes.

Sonyc scrolls at 4 px / 60 Hz frame bidirectionally, effectively 8 px / frame, as fast as Uridium 2.

Well, that wasn't my point. (oh, wait: Video memory CANNOT be directly accessed on the NES! You have to use PPU ports - which were memory mapped, but this doesn't mean that you can LD anything into VRAM without asking PPU to do it for you)
Also, altough putting most of video memory inside cartridge did reduced the need of a bigger memory bank, it was a one-off feature in the market (as in: no one else -besides SNK on NEOGEO MVS and AES- did anything alike)

You can send data to the HMMC VDP command at pretty much full throttle, no need to poll the TR flag which slows it down by a lot. All real turbo hardware has automatic waits inserted on VDP access (exactly what you wish for), and FPGA emulations don’t have access speed restrictions.

That the waits are not fed by the VDP but through another mechanism (V9958’s /WAIT may seem ideal on paper but there must be a reason they didn’t use it) doesn’t change the fact that you can assume them to be present and rely on it to prevent you from accessing the VDP too fast on a turbo CPU.

Alternatively, you could poll TR if you detect a turbo CPU, and skip it if it’s a regular 3.58 MHz Z80.

(p.s. The OCM / Zemmix Neo turbo mode completely messes up the cartridge bus timing, very nonstandard, causing signal level incompatibilities with a lot of hardware especially > 8 MHz. Would be nice if that was fixed, similar to the turboR.)