Y coordinate 217 for sprite mode 2

Paragon (1215)

28-01-2019, 19:26

The MSX2 Technical handbook by ASCII states (in 3 different places) that :

"In screen modes 1 through 3, Y-coordinate was 209 for erasing the display of the specified sprite and was 208 for erasing the displays of the specified sprite and all sprites following it, but in screen modes 4 through 8, where the limit of Y-coordinate has been increased to 212 dots, the values to be specified are now 217 and 216, respectively."

I never heard before of that 217 Y-value for sprites ... I know of the 216 Y-value and the effect it has on sprites of higher plane number, but not that one. What bothers me is that the Yamaha manual for the V9938 VDP does not talk about it either.

Of course I understand that with a Y-value of 217 the sprite will not be on screen, but not generated and not on screen are two different things ...

By Grauw

Ascended (9394)

29-01-2019, 08:59

I avoid line 216, but use line 217, and see no flickering.

That line 217 they talk about may just be used as a convention to hide the sprite.

By Metalion

Paragon (1215)

29-01-2019, 13:28

It should not cause flicker, as it is used to erase an individual sprite.
It is used in the BIOS too :

CLRSPR (0069H)		*3
  Function:	initialises all sprites. The sprite pattern is cleared to
		null, the sprite number to the sprite plane number, the
		sprite colour to the foreground colour. The vertical location
		of the sprite is set to 209 (mode 0 to 3) or 217
		(mode 4 to 8).
  Input:	SCRMOD (FCAFH) for the screen mode
  Output:	none
  Registers:	all

By hit9918

Prophet (2897)

29-01-2019, 23:07

there must be a parking place where the sprites dont make collision and 5th sprite!
and. the MSX2 does turn the sprites off in the border. then it does not need this collision prevention feature.

I dont know 100% but these 2 things fit the symptoms.

using a color of 0 or parking the sprite at x = -32 is not possible because that would need DMA for X and C byte.
a real turn-off feature can only be in the Y byte. because the Y bytes of all 32 sprites get always read.

By Grauw

Ascended (9394)

29-01-2019, 23:10

Metalion, I’m talking about when using the vertical scroll. Then I need to avoid line 216 but not line 217.

So I think it’s indeed just a de facto parking space used by the BIOS (as you quoted) rather than a VDP function.

By hit9918

Prophet (2897)

30-01-2019, 01:52

chipstms9918.pdf, on page 2-11. says something about "lines 0 to 192".
maybe 5th sprite is not set outside those lines.
now it is imaginable to have the whole thing without a line 209 feature.
but the collision is said "regardless of where it is located".
collision could be avoided in various ways in X, color, pattern bytes. again no line 209 feature needed.

By PingPong

Prophet (3556)

30-01-2019, 11:30

@hit9918: Am I wrong or the vdp ( at least on yamaha v99x8 ) disable sprite processing for y values greater than the y value of the last y value of active area?

If i'm not wrong, for the Y value outside the active area the vdp stops sprite management, that means that:
1) collision flag is not updated
2) collision coordinates are not significative
3) the sprite scanline/overflow is not set even if there are a lot of sprites on the same Y position but with Y value outside of active area.

this behaviour is the same regardless of R#24 value, that only shift the absolute value of Y marking the start of border line.

If all of this are true the y magic value of 217 simply make no nense, or on other words there are a bunch of Y values that behave like y = 217.

By Grauw

Ascended (9394)

30-01-2019, 11:48

Sprites are not processed outside of active display. This frees up the VRAM access slots. Additionally, sprites are processed one line in advance. This is why when you make a screensplit which disables the screen for a few lines, then enable it again, the sprites enable one line later than the bitmap does.

By hit9918

Prophet (2897)

30-01-2019, 18:31

my wondering was all about the MSX 1.
this whole question was created by the MSX 1.
on the MSX2 there is no question.

By Grauw

Ascended (9394)

30-01-2019, 20:30

Since during blanking (also on MSX1) there is no speed restriction to the VRAM access, due to access slots not being occupied, this implies that sprites (one of the major access slot consumers) are also not evaluated.

By hit9918

Prophet (2897)

30-01-2019, 20:10

are you saying that msx1 is identic to msx2