The attached program fills the VRAM with a regular pattern while having the mode bits set to specific values. This looks quite different in openMSX compared to real MSX: in real MSX, you see a messy pattern, while on openMSX there are nice vertical bars. See also http://www.msx.org/forumtopicl7331.html
Logged In: YES
user_id=78178
Originator: YES
Oh, this is what Giavotto says about the code:
> Here, there is a lot of code bloat... look at main and fillvram.... (not
> the assembly version, the C one)
Disk with program that demonstrates the bug
Logged In: YES
user_id=78178
Originator: YES
File Added: modetest.dsk.gz
Logged In: YES
user_id=78178
Originator: YES
A correction form the author:
> It's not true that "undocumented mode looks badly"..... should be:
> "Vertical bar looks different in sc5 mode with this test program compared with a real msx2."
> the problem arise BEFORE i set the illegal mode, not after
And this is how it looks on real MSX: http://img180.imagevenue.com/img.php?image=93326_modetest_122_342lo.jpg
On openMSX it looks very close to this, but the stripe-effect is not seen there.
Attached how it looks on real MSX and on openMSX (now):
So, openMSX is ALMOST there!
Last edit: Manuel Bilderbeek 2014-09-18
Lowering priority, because openMSX is really close to the real thing here (except for those vertical stripes).
To be clear: this is a case of accessing the VDP too fast (see http://www.msx.org/forum/development/msx-development/vdp-illegal-modes?page=3)
So, this improved a lot when VDP access timing got implemented.
This is the routine that makes the screen output (after setting up screen 5):
In C it boils down to:
This is SetVRMWR:
Attached a version of the program that has the actual mode test NOPed out (the last 3 vdpsetreg calls in main are removed). This is for easier testing on MSX2 without pause button :)