I found it really interesting to read this source code. It's very well commented.
Thanks for the hint.
I see, surprising but I confirmed in the disassembled BIOS source code (“msxsyssrc”) that on MSX2+ and turboR it returns immediately for any mode value above 8. I’ve amended the article.
This part of the MSX2+ BIOS seems to have been rushed. They changed the SCREEN routine (0159h) of the subROM and a lot of the drawing routines, but simply seem to have forgotten to change its S.CHGMOD (00D1h), resulting in malfunction.
I ended up in this thread because I needed other BIOS routines to behave correctly on screen-10. For example, GRPPRT wasn't printing nice text without color bleed as it did on BASIC programs. So I'll describe the problem here in case you want do complement the article, or someone googles for this in the future.
In the end, initializing the MSX2+ screens with the workaround for the CHGMOD bug mentioned earlier in this thread, using SCR8+R#25, has this consequence:
The bit5 of the MODE variable (FAFCh) is not initialized correctly. This results in the BIOS graphic routines will not working as expected for the screen-10.
This means that you also have to set the bit5 of MODE accordingly: 0=scr11/12, 1=scr10.
Another aspect to consider is that, by using the BIOS routines (CHGMOD+WRTVDP), the mode register at I/O port F3h will always be updated correctly. It wasn't used on any of the existing MSX2+ models, but it's very important if someone wants to build new one (like the Omega MSX) that has either a digitizer or an external DAC to support paletted colors on screen8.