I am evaluating a possible support to MA-20 in my next msx1 games. At boot time I could read the port at 6h and print a message in case it is not 99h. The message could be something like "This is an msx1 game, please unplug that MA-20 extension and reboot." 
Maybe a nice example of the reverse; the CX5M-II is an MSX1 with the V9938 VDP, in Synthesix I went out of my way to support its 80-column text mode. Similarly e.g. screen 4 games could do so as well. You do have to bypass the BIOS for this 
.
Official way for me 
(patching the code in RAM with the ports value read from BIOS for speed sake)!
Interesting, just like patching the PSG.
is that topic so unsolved?
one cant line interrupt with the bios... but can do it with port retargeting.
OK then we do magic or voodoo.
yeah bios you can forget in a game. except in a little game.
Sure, you tried and cofirmed?
there is also another thing that stop the use of the BIOS when doing time critical operations: the fact that the bios implements functions that are 'trusted' to do a task (I/O, set graphic mode, set a point, draw a line, set psg etc) does not mean that the BIOS IS THE SAME on every machine, implementation could vary.
plus the interrupt handler of the BIOS is 'sensitive' to hw configuration (floppy drive or hw that do interrupts).
the BIOS is fundamentally not only slow, but also timing-unreliable.
say we need to write a charater on screen at a specific time: the BIOS guarantees that the charater will be printed but say nothing about the time it spend to achieve the result. If you talk to bare metal directly you can have a control even on this aspect, (or more precisely you can have better control on timing).
Again, it is NOT slow. Sometimes I think BIOS is confused with BASIC. At the end they are machine code small functions with an extra JP, there is no much difference.
I tested with how many function calls could be made in a full interrupt time (a complete screen scan), so get the overhead. The results was the bios achieved 177 and direct code 199. There is little difference, and unless your code only calls to it, much less difference.
And about the HW configuration dependant, you also have it for direct code. Unless you only target ROMs, you can't override the 38H routine, or the system will crash or freeze. And we can't limit ourselves to only making ROMs for 64KB RAM machines (to override the 38h in RAM at page 0).
Think also that if trying to fit so exactly in a hw, what about if it has a 6MHz CPU? or any other change? Is that predicted?
I repeat, MSX is not a videogame console, a closed system where the manufacturer specifies everything because it is its own system, and can.
Then, instead that exact fit dependency, in computers with variable hardware configurations is the flexible way the one adpoted.
Why you need to write the character at exact time? Maybe because writing on-the-fly to VRAM SAT and expect to be at time? Well, that could be fine on videogame console, but for computer a better solution is to work on double buffer and swap when characters are ready. There is also a better solution, but I think is off-topic.
I've noticed that the real speed is on the other code, the logic itself and how do you access to machine (in the side of way, not microcode itself), not getting some few cycles in an operation that you will probably do 20-30 times in a loop as much.
Most of the worries here about it I start to think that is because a wrong idea of BIOS. And moreover, the topic here is to put a RAM read and using the IN/OUT (C) operation, that is even much lighter. Surprised about it seems the idea of if you write a 99h instead it will run at double speed or something.
A topic not touched on here, but you should also update VDP register mirror values in RAM, and update the palette mirror in VRAM as well. But ouf, now things are getting quite expensive if we want to do things fully according to the book .
Another thing, consider DOS applications, accessing the BIOS must be done using a very expensive interslot call (iirc, 300+ cycles overhead?). For things which would access the BIOS often, like VDP or PSG, it seems better to skip that or your graphics and music routines will take away a significant portion of your frame time.
A topic not touched on here, but you should also update VDP register mirror values in RAM, and update the palette mirror in VRAM as well. But ouf, now things are getting quite expensive if we want to do things fully according to the book .
Another thing, consider DOS applications, accessing the BIOS must be done using a very expensive interslot call (iirc, 300+ cycles overhead?). For things which would access the BIOS often, like VDP or PSG, it seems better to skip that or your graphics and music routines will take away a significant portion of your frame time.
Notice that. Good point I forgot to mention, updating the system variables. I put it (the LD (RGMIRROR), A) between the 2 OUTs so it is used too as WAIT. I read no remember where it is good to give time to the VDP. Probably not needed on MSX2 or greater, but if it must be done well I see no problem doing it there.
@Graw the operation was precisely LDIRVM, using the BIOS one and using the steps (but the setting expanded VRAM, I skip that one, supposing the VRAM will be always in non-expansion VRAM, bad for me ) indicated in the V9938 manual.
For writing the registers using OUT(99h) or OUT(C) I truly think there is no practical difference.
About inter-slot, that's true, here is the way:
X BAD:
loop {
inter-slot call
}
V FINE:
set bios at page 0
loop {
direct calls
}
set RAM at page 0
Single calls are not problem, inside loops must be more careful. I also measured the inter-slot call overhead and is about double, I mean, you can do half calls in the same time than with direct calls for mid-complex functions (the call itself, not the work done inside that has no extra cost).
Then, for PSG are really not much, only settings the registers for 3 channels for the current playing sounds (are not so much). The VDP is not that so much as explained before. And remember that during ISR we already have the BIOS at page 0, no need to set it.
@Louthrax I read the input from RAM directly, they are in the system area, the BIOS updates it, so no need to call again the input functions but the joystick one (STICK, the TRIG are also in RAM), that only needs to be called once per loop iteration.