In screen 2, It does appear that there is a sprite overflow situation on sprite n. 17
In screen 0 there is a sprite overflow on sprite 8. A mode without sprites?
In screen 1 of Toshiba there is a sprite overflow on sprite 15
Weird that screen 0 there is a sprite overflow status
There is another bug which is not insignificant. The VDP type test on the wiki works fine on OpenMSX and other emulators but not on real MSX1. It works fine too on real MSX2 and Turbo R. On real MSX1 the returned value changes sometime randomly. (Tested many times on two real Japanese MSX1)
Status register 1 does not exist on TMS9918. Thus, you read the 5th sprite bits of status register 0, it seems the routine relies on this. I think the 5th sprite bits give the internal sprite counter of the VDP until it is latched when a 5th sprite is found, or something like that (your findings seem to suggest this is only the case on TMS9918 and not V99x8). Therefore, if you use this value you may get various values. I think this is not implemented on openMSX, which could explain the difference.
p.s. Register 15 does not exist on TMS9918, so due to the mirroring you are writing the value 8 and then 0 to register 7, rather than restoring it to its original value. This can mess up the text and background colour (leave the screen blank).
@Grauw can you also say such sensible things about the status register 0 findings at the top of this page?
Quote:
I think the 5th sprite bits give the internal sprite counter of the VDP until it is latched when a 5th sprite is found, or something like that (your findings seem to suggest this is only the case on TMS9918 and not V99x8). Therefore, if you use this value you may get various values. I think this is not implemented on openMSX, which could explain the difference.
If someone designs tests to find out how it works in enough detail, we'd be happy to implement it.
I don’t know (haven’t tested) the exact behaviour. It is more a suspicion than a known fact. I think I recall Tom Harte implemented something in his CLK emulator. Or maybe it was someone else and something similar related to s#3-s#6.
Knowing the exact behaviour can potentially be very useful, it might allow to detect the current position of the raster beam with some sprites placed across the screen vertically. But exact details on how this behaves on each VDP are needed.
