Correct usage of VDP ports following the standard

2 cycles but the problem is that you have to do first ld a,(...) ld c,a or ld hl, xxxx ld c,(hl) for each vdp access. if accesses are scattered there is a huge penalty

And you loose one register. You need also to swap in the rom and store the value in ram if you use dos or roms without bios

Get the base ports from BIOS is standard only for MSX2 (for MSX1 + MSX2 cartridge upgrade). In fact, many games for MSX2 do not respect this rule.

Hi, I think the best way is to make a copy into RAM. Even can create the all ports table, precomputing all them. Are only 8 bytes.
Takes some more cycles (39 vs 17 for the first access), but what about using?

LD IX, (nn)
LD C, (IX+d) ; d = port number if we had defined the ports table

Very organized and clear. As noted, for the first access, because later if you don't modify the IX it takes only 19 as the 1st instruction is not needed and with no need to make a copy of A if want to preserve its value.
You can also use anyway INC/DEC C to travel through ports.

About the topic of hardcoding or not, this is what the MSX manual says, think that is intended for making software for MSX platform. We usually confuse machine with platform. It is true that most MSX use fix ports to the values of the V9938 manual, but that is merely by circunstances. We can say that because the system was discontinued, and we are based on already immovable existing data.

The only thing we can suppose for and open architecture like MSX is that we have to suppose nothing.

In fact, take a look at the MSX-Video specification (specification, not implementation like particulary is the V9938). It allows bidirectional transfers, it defines one port for write and another for read. The V9938 implementation joint both into one as it has only one bus.
But that does not prevent for any other to create its own implementation MSX-Video compliant, with dual bus, and DMA for parallel read/write from DMA/CPU at the same time.
This would be the same that what we have today with video cards manufacturers, each one with its own implementation. That is the power of an open architecture, but the software must be care of it.

So, fine the real case was that almost everyone mounted the same MSX-Engines and that is in that way for most MSX machines, but as I say, "machines", not MSX platform.

Then, at the end that is a personal preference, I only expose the way the platform designer says it should be used. Because all this is in a "looking at the past" environment, that greatly determine it. But as said at begin, this is for those who like to "follow the standard" AKA "follow the manual". Simply that.

I agree that at the very beginning of the msx life the ports were intended to be in a variable position and there was more room for better video HW, but during the commercial life of the standard, all the hardware producers have selected ports 98h and 99h and use one bidirectional bus. It's an historical fact that none can change. For me, coding on msx is archeology on machines that have been already produced more than 30 years ago, trying to exploit any HW feature and undocumented glitch of the chips squeezing the most of any single cycle.
About the module MA-20, it is just an expansion module for msx1 machines, you can unplug it and use your machine as it is.
If you want to run msx2 games today, pretending to use an msx1 with an expansion module instead of a full msx2 machine, is just a geek oddness. Find on ebay a cheap msx 2 if you have the urge.

Ah, there is the issue of the new modern machines that to be eventually produced nowadays by fans and homebrewers. Well, IMHO it has to be their care to preserve compatibility with 30 years of existing software. I would not produce a new stand alone machine with ports in e.g. 28h and 29h knowing that a large part of the games wouldn't work, but you can put your ports wherever you like, just do not pretend to run any game.