This was tested on a Canon V-20, I can't be sure if part of this also applies to an MSX2. This regards undocumented details of the MSX1 VDP.

The MSX can send a request to this register, to prevent its lower bits from updating, by setting bit 6. This request is only honored if bit 6 and 7 are clear. Afterwards, these bits will be "stuck", until the status register is read. These rules apply to all screen modes.

Screen 1,2,3:
Reading this register returns the current value of the internal sprite counter. It's possible to use this as a per-scanline horizontal counter, though some reads will return erroneous values (possibly due to reading it exactly the same time it's being updated). Of course, if the VDP sets the overflow bit, bits 0-4 will stay stuck. The sprite counter keeps continuing though, and if you reread it (twice) inside vblank, it will point to the last handled sprite number. Some simple examples (overflow or no overflow doesn't matter):
sprite 16 Y value of 208 --> 16
sprites 0,1,2,3,4 on scanline 191 --> 4
no sprites on scanline 191 --> 31

So, those bits don't just get reset to 00 or 31 after the status register is read.

Screen 0:
The collision bit is never set. Bits 6,4,3,2,1,0 represent an undocumented VDP register somehow related to the pattern name table, or maybe just open-bus, I haven't figured out the pattern. The on-screen test numbers (contents of the nametable) influencing themselves didn't help much .. values were not random though.

Blank (reg 1 bit 6 clear):
If the blank bit is cleared in mid-screen, the result will be the same (or similar, don't know) to those of screen 0. If it's cleared before vblank ends, it gives an interesting result (reads separated by a few cycles):
scanline -1: (VDP activates: sprite evaluation starts here) garbage like screen 0
scanline 0: $11, $11, $11, $11, $11, $51
scanline 1: $01, $01, $01, $01, $01, $41
scanline 2: $11, $11, $11, $11, $11, $51
etc.
Reading from this seems stable, unlike reading from the active sprite counter. Also, it seems that bit 6 doesn't get reset by reading this register (maybe it gets updated very fast).

*edit* all these internal registers/counters/whatevers are inactive during vblank.


Something else I noticed, semi-related: the 1st write to the VDP address register ($99) immediately updates the lower byte. There's no such thing as a temporary latch.

Note that the sprite collision and 5th sprite bits aren't always set at the scanline where the actual collision occurs. It varies +/- two scanlines or so.

Another interesting thing is that sprite collisions and/or 5th early clocked sprites (left of display area) are not handled the same on MSX1 and MSX2. On one, the collision is detected and on the other its not (can't remember which one does what).

It would be most logical if those were set during sprite evaluation, eg. sprite 0 collides with sprite 1 at (240,100), the collision bit would be set during the start of sprite evaluation somewhere on scanline 99.

Other MSX1 VDP info: I don't think any mainstream emulator supports reg 1 bit 7 (the 4k/16k option), it's documented in Sean Young's tms9918a.txt .. I've confirmed it on my MSX1, it's exactly as described. VRAM degrading (lack of refresh) happens in 4k mode, that's been mentioned before on this forum.
XL2S's The Cure sets this bit to 0, then to 1, causing the title screen and sprites to be messed up on MSX1 (The Cure's diseased? )

Quote:

It would be most logical if those were set during sprite evaluation, eg. sprite 0 collides with sprite 1 at (240,100), the collision bit would be set during the start of sprite evaluation somewhere on scanline 99.

Yeah, that would be most logical but its not the case. Try setting up a sprite collision, then poll the status bit. When set, you change background color. You'll see that this won't happen at the same scanline. I guess a better test would be to use an external timer but this example shows that its not as simple and predictable as one think.

Quote:

Other MSX1 VDP info: I don't think any mainstream emulator supports reg 1 bit 7 (the 4k/16k option),

blueMSX did, but I removed the feature because I wasn't exactly sure when refresh didn't happen. blueMSX refreshed too often. If you have exact info I can put it back.

Did you check with big sprites? Or sprites the size of 1 dot? This is an assumption.. it might be possible that if you read the status register the same time it updates, it returns 0 and resets the collision bit, then sets it again on the next line.

Sorry, I don't have any exact timing info. You can probably just emulate the addresslines swapping (that's what makes The Cure look glitched, it's not due to VRAM degrading).

Quote:

It would be most logical if those were set during sprite evaluation, eg. sprite 0 collides with sprite 1 at (240,100), the collision bit would be set during the start of sprite evaluation somewhere on scanline 99. Other MSX1 VDP info: I don't think any mainstream emulator supports reg 1 bit 7 (the 4k/16k option), it's documented in Sean Young's tms9918a.txt .. I've confirmed it on my MSX1, it's exactly as described. VRAM degrading (lack of refresh) happens in 4k mode, that's been mentioned before on this forum. XL2S's The Cure sets this bit to 0, then to 1, causing the title screen and sprites to be messed up on MSX1 (The Cure's diseased? )

Oh, yes, that bit I spoke as a switch ON/OFF of the refresh cycle.... in BASIC prompt to change that, means a FREEZE of the BASIC... I realy don't know way..... I wondered always why if the VRAM degrades the BASIC just crashs....

Its much more than one line we're talking about. Of course it could be that I'm unlucky and 'cancel' the data several times in a row.

Hmm, I'll try to (de)confirm it tomorrow.

flyguille: If you reset that bit on MSX1, the graphics become garbled (you can't see what you type), Basic continues to run though, try this:
10 SCREEN2:CREATEREALLYNICESELFPORTRAIT
20 A$=INPUT$(1):VDP(1)=VDP(1)XOR128:GOTO20

Quote:

Hmm, I'll try to (de)confirm it tomorrow. flyguille: If you reset that bit on MSX1, the graphics become garbled (you can't see what you type), Basic continues to run though, try this: 10 SCREEN2:CREATEREALLYNICESELFPORTRAIT 20 A$=INPUT$(1):VDP(1)=VDP(1)XOR128:GOTO20

No, I mean in DIRECT BASIC mode, NO PROGRAMMING....

If you reset that bit... the basic freezes.... you can ear that the keyboard's sound clic do not happens.... and (SCREEN 0) offcourse.

Doing VDP(1)=VDP(1)XOR128 directly doesn't make Basic freeze on my MSX1.

Quote:

Doing VDP(1)=VDP(1)XOR128 directly doesn't make Basic freeze on my MSX1.

I will re-test that tomorrow.... the last time I do that, was like in 1996. But I remember that perfecly.... mmmmmmm

¿Or maybe was just that can't be to write because all written is erased and none command can be entered....? Now, you settles that doubt...

Anyway... I remember doing some things in direct basic that really crashs bASIC

lilke destroying in a bucle all VRAM

I will retest tomorow and come in with the results....

Now that this is kind of a general undocumented MSX1 VDP thread, a while ago GhostwriterP found out a quirk causing sprites to clone: http://www.msx.org/forumtopic5579.html

I've looked at it a bit, and the details are not as he described. This effect only happens when reg 3 bit 6 and reg 4 bit 1 are 0 (other bits: don't care), in Screen 2. The internal sprite comparator seems to mess up. It will compare spriteline Y positions with the current line, and additionally with the current line OR 128, causing sprites in the 0-127 area to be cloned 128 pixels down (or on line 0 if Y=127) [[*edit* of course, clonesprites with a result Y of 191-254 are not handled]]. Any normal sprite below this area will not be cloned. A normal sprite with Y=80 will not be interpreted as the end of the table (80+128=208). Other sprite functions remain normal: collision and overflow can happen between cloned and normal sprites. One thing to note is that the first 8 sprites are unaffected: they will not be cloned, the maximum number of sprites that can be shown with this is 56.

Now for something very strange: with time (maybe due to temperature) this cloning effect gradually deteriorates (cloned sprites start to flicker, and it sometimes fetches a wrong X coordinate). It takes a few minutes for it to completely go away, and will only come back if I turn off my MSX1 for a while.

(dvik: I didn't get to do the sprite collision/overflow thing yet, I'll reply here when I do)

It would be nice if there would be small demo programs that show these effects. Then it's easy to test on different machines and VDP's and also emulators.

I agree, but I don't have the motivation to create user-friendly test programs. The ones I make for myself are temporary and require a lot of on-the-fly reprogramming to try out every parameter/detail.

Check the thread I linked to for a small demo of the sprite cloning effect.

Very nice! This means that the s.c. hybrid mode could work without sprite coloning provided that one choices correctly the register values. Or not