R800 DMA...

Even though R800 supposedly has DMA support, the only computer using it doesn't have the pins to drive it connected to any device or bus... So, does it work? Maybe it doesn't and it is one reason it wasn't used... Perhaps it was going to be used with v9978, but as it didn't see the day light... The cartridge port was kept the same and no extension to it was created... So, it doesn't work on TR, it only adds to the "half baked" feeling about TR.

maybe the original plan for TurboR was more ambitious: a v9990+v9958 core plus a DMA CPU support.
It is a pity that had not happened...
the R800 DMA is a sign like the V9990+V9958 => V9978 that they planned something really powerful able to compete with 16 bit machines... The first 16 bit msx

I see the I/O port based VRAM access more as a psychological limit than an effective one. It is relatively rare the need to perform random vram access and sequeltial block access can be faster (sometimes) than a cpu RAM access due to the ability to avoid increment the target ptr (saving cycles)
Just remember that the MSX with a z80 and a VDP I/O port based is able to push in the worst case about 800 bytes of data during vertical retrace period. Some c64 commodore users have a lot of trouble pushing 1000 bytes of color ram. this take a lot more time than on msx to push 800 bytes.

Obviusly an msx should be coded like an msx not like a ZX Spectrum that has the availability of VRAM under cpu control and force a specific way to perform screen updates not working so well on msx.

Apart from this, i do not know if TurboR was a ASCII initiative dropped after a bit of time or if it was a Full Panasonic idea. To me it does appear they worked in the right direction removing the legacy and limiting "features" of the early msx'es

They planned:
1) DMA support (for me targeted to VRAM<->RAM transfers)
2) V9990 (see 1)
3) A more flexible memory management model (24 bit addressing)
4) a more speedy cpu with the compatibility of z80 machine code.

their design is clear to me:
1) Remove limitations
- slow VDP (V9990 was also port based but there is a open door in direct VRAM access AFAIK, thus DMA)
- the plethora of mapper, slot and any other kind of ceremony
2) Go on 16 bit era
- V9990 [meaning as a graphic capabilities more like a 16 bit hw]
- Fast Z80 with a 16 bit alu and 24 bit addressing mode.

unfortunately the project did not have a lot of success, otherwise it could have been a reborn of a 16 bit powerful msx with a lot of early limitations removed.

I've thought this because the only company that done a MSX TR was the panasonic and its name has never been a more logical name like MSX 3 so in my mind it was only a tweak of msx2+ standard made by panasonic.

You are not seeing the real problem: this is not due to I/O port based access. It is mainly because the vdp store sprite color informations linked to plane number instead of a more logical way related to pattern number.
this force you to manipulate 16*32 bytes of VRAM instead of writing only a different pattern no into sat.

Even with random access you will be forced to do the same manipulation and probably you will end up to have a separate RAM buffer in order to perform the same operation without incurring in tearing or any other sort of glitches, so your probably end up using an LDIR instead of OTIR instruction. With VRAM access you pay the initial setup of VRAM ptr but this is negligible power compared to the time you take to do a full 512 bytes block move.
Even if you perform a randomized plane access by plane no (in order to touch only some sprite planes instead of full sat) the overhead is moderate, because to change a msx2 sprite color you need 16 out operations with a overhead of some 2/4 out to set vram ptr. again it does not change too much .

memory copies of vdp register will be necessary even with a memory mapped schema instead of port based I/O.
remember registers are not memory location. they are not required to behave like standard memory locations, it is common that they are write or read only. the c64 is another example of this. there are some VIC-II registers that when written modify some aspect of the display and when you read returns another one. (the scanline interrupt for example)
Nothing related to I/O or memory mapped scheme only to nature of hw registers.
plus disabling interrupts is not required unless you write data in an interrupt handler. the msx int 38h simply read data from a register and the vram ptr is not touched by this operation.
again is not strictly a limit of I/O or memory mapped approach. is instead a limit of the vdp. It does not provide a way to read the VRAM ptr. Basically with memory access schema if you use HL to point to VRAM both in main program and interrupt service routine you MUST SAVE HL and restore on exit otherwise you mess things a lot.
With I/O schema instead of a PUSH HL POP HL you need a way to get the current VRAM Ptr from VDP internal status to restore on exit of the interrupt. Unfortunately there is no way to do this. But it is not due to I/O based access, only to a flaw in VDP design.

I agree. this is the most stupid way to set VRAM ptr address, but again not due to I/O approach, only to the stupid way is was done. There are more smart ways things could have been done. Just remember,to set vram ptr the vdp need basically two operations: 1) out of the address, 2) strobe the read or write

the error was here: using the msb of the address byte to set a write or read operation. this force the cpu to manipulate a bit by merging an address byte with the write or read operation. CPUs are not efficient when it comes to manipulate a single bit. So a waste of time compared to the size of data you manipulate (1 bit).
One solution: different port addresses to perform write or read , when setting the vram ptr and voila the overhead of setting vram ptr was gone. instead of:

ld a, l
out (0x99),a
ld a, h
or 0x40
out (0x99),a

became
ld c, PORT_FOR_WRITE
out (C),l
out (C),h

or
ld c, PORT_FOR_READ
out (C),l
out (C),h

plus the 17 bit issue is a shitty thing that comes from TMS root and to the decision to merge the address bit with a read/write mode bit in the same byte. but there is nothing that at hw level force you to do things in that way. is was a stupid choice.

I think v9938 could had provided a better and clean way (see v9990) to set vram ptr instead of creating the stupid register to select the bank of 16K where to operate and thus requiring two extra out to set the full 17 bit ptr.
But again not a I/O issue only a way they choosed to made things.

Consider that VRAM access tend to be sequential by nature, in those situations the I/O vram ptr access does not make a huge difference.

The only thing when you notice a big bottleneck ( but it is rare ) is when you do a lot of random access to vram and for each access you only modify a single byte. (example a lot of PSET statements in random position, or the drawing of a line) In this situations performance clearly suffer because of the overhead of setting vram ptr.

but when you write some sequential bytes (for example 4-8 bytes) for each vram ptr setup the overhead became acceptable. And the more bigger the block you write the lighter is this overhead.