These are the register writes after pressing SPACE in the title screen, according to openMSX logging I added:
Wrote 162 to reg 1
Wrote 159 to reg 3
Wrote 0 to reg 4
Wrote 1 to reg 0
Wrote 2 to reg 0
Wrote 3 to reg 0
Wrote 4 to reg 0
Wrote 5 to reg 0
Wrote 6 to reg 0
Wrote 7 to reg 0
Wrote 8 to reg 0
Wrote 9 to reg 0
Wrote 10 to reg 0
Wrote 11 to reg 0
Wrote 12 to reg 0
Wrote 13 to reg 0
Wrote 14 to reg 0
Wrote 15 to reg 0
Wrote 1 to reg 7
Wrote 226 to reg 1
So, 15 is written to reg 0, which means that the EXT_VIDEO bit is indeed 1. As hap put it:
It's the EXTVID bit(VDP register 0, bit 0), meant for overlaying the VDP output on another image.
If it's unconnected, the result glitchy effect probably differs per MSX model (maybe even differs per tv?). IIRC on my MSX I got a fuzzy monochrome image when I set it.
See https://www.msx.org/forum/msx-talk/hardware/alternative-svi-...
My best guess is that this is what causes the weird palette. On which other machines was this tested?
Anyway, this EV bit isn't emulated by openMSX, because the result isn't very well defined and depends on many factors.
That makes a lot of sense! Gerardo tested it in three different MSXs, but they were all the same model: Philips VG8020
Aha, so that explains the consistency. Can someone try it on another MSX model? That may give different results, if it's the EV bit playing here.
I think the reason the palette change code is not harmless on MSX1 has nothing to do with the palette port, but with the fact that the palette index register is register 16 and since MSX1 VDPs only have 8 control registers, writes to register 16 end up in register 0 instead. That's why the values 1..15 end up being written to register 0 in Manuel's log, those are the index of the color in the palette that the code tries to set in register 16.
By the way, it is not necessary to set the palette index for every color like this, since register 16 auto-increments each time a color (2 bytes) has been written to the palette port.