To Grauw: Sprite colors linked to sprite pattern no.

By PingPong

Prophet (3281)

PingPong's picture

27-05-2019, 13:49

A common critic about msx2 vdp sprites is that sprite colors are linked to sprite plane no instead of sprite pattern no.
Before VRAM access timing was reengineered i always thought that is was not possible because of the need to calculate the SCT address from pattern no. I thought it was for fast to get the color byte from planeno during SAT fetch because it is implicitly already available, just start SCT at base address and while you increment SAT PTR you can easily do SCT=SCT+16.

But looking at the fetch pattern used by the vdp, i see that color informations are fetched later after reading two sprite SAT entries. So i think there is time to calculate from the already fetched patternno a SCT address.

It could have been done! Only the SCT would resulted to be 1024 bytes instead of 512......
(that is extremely sad.)

Or I am wrong?

Login or register to post comments

By hit9918

Prophet (2853)

hit9918's picture

27-05-2019, 16:36

the reasons for the sprite colorquirk are not timing reasons but about the ability to change the sprite color in BASIC Big smile

and you are getting something for it! to let the enemies flash white when they are hit like in amiga games. the sega needs extra pattern for that.

and the colorquirk was talked like it makes games impossible. this was exaggerated.

By Grauw

Enlighted (8015)

Grauw's picture

27-05-2019, 20:44

I think it works the way it does because it had to work within a legacy architecture; sprite mode 2 had to be built on top of the same sprite unit that also has to support sprite mode 1. So making a structural change to the way the data is processed is difficult.

Currently the sprite data is processed in exactly the same way in both sprite modes, with mode 2 having only a small alteration to the address calculation when it retrieves the colour attribute. There is no separate SCT counter; there’s just an existing sprite line counter which is ANDed into the SAT address lines at the moment the colour is retrieved. This is easily switched on/off with only a few transistors.

If the colour data were linked to the pattern number (but not early clock!), it introduces a completely new code path with a different (indirect) fetch pattern, requiring an extra access slot as well, and it would probably have been a lot more difficult to route and make it fit, possibly even might have required a separate sprite unit.

I can’t look at Yamaha’s silicon designs (I probably wouldn’t understand them anyway Smile), but I imagine these kind of considerations were in play. I think the current system is the result of very smart and creative engineers who managed to get us the additional sprite mode 2 capabilities through very clever tricks (like the OR colours). They could’ve only increased the number of sprites per line, but instead they squeezed much more out of the legacy constraints imposed by TMS9918 compatibility.

By PingPong

Prophet (3281)

PingPong's picture

27-05-2019, 21:01

Grauw wrote:

.... requiring an extra access slot as well, and it would probably have been a lot more difficult to route and make it fit, possibly even might have required a separate sprite unit.

Sorry but can you explain me why this extra access slot is required?
from the timings, i see that the vdp does sprite fetches in groups of two sprites reading:
6 bytes (fast mode) of SAT. (3 bytes x sprite)
then after it does have read two sprites units it does:
2 bytes read (non fast mode) of SCT (one color byte x sprite)
So it does have already an extra access slot, or i'm wrong?

By Grauw

Enlighted (8015)

Grauw's picture

27-05-2019, 22:02

The fourth sprite attribute byte contains not just colour but also the early clock bit. To have EC in the pattern table would be another kind of inconvenience similar to that we have now. Though arguably a lesser one, but we would certainly still be complaining about it because it is not perfect.

To remedy this issue somewhat more properly, the fourth attribute byte would still need to be fetched along with the colour data, but in this case it would require an extra access.

By PingPong

Prophet (3281)

PingPong's picture

28-05-2019, 00:24

thxs i forgot that the stupid early clock bit was there, now it is clear.
there is nothing to do: when a design is bad there is little one can do to remedy with small effort.

By Grauw

Enlighted (8015)

Grauw's picture

28-05-2019, 00:58

Yeah, and as I looked at it more closely this evening, I think the solutions are actually pretty creative. That rerouting of the colour attribute read to a per-line fake-SCT, pretty clever. The OR colour as well, probably triggers some clever composition in the internal sprite buffers with minimal logic changes.

Of course we can all see what a better sprite system would be, SCT decoupled from SAT, a 9th X bit rather than EC, no line 216, and a simpler alternative to OR colours. But given the mandatory starting point of the TMS9918, I think Yamaha’s engineers achieved a lot. I mean you get eight 16x16 full-colour sprites, two per line, or twice that if you use 2 OR-sprites… Way way better than TMS9918, with relatively minor changes. Look at Ashguine 2, that’s pretty cool. Let’s not forget that Smile.

By PingPong

Prophet (3281)

PingPong's picture

28-05-2019, 08:57

the problem with SCT linked to plane no is that this force you to manage additional 512 bytes when doing sprite rotation.

Quote:

...no line 216...

in this case they needed to change the logic to work from 208 to 212 based on the vertical resolution bit.
This already involved some logic.
In this case they would have done a better job by entirely suppressing this stupid magic value, most probably the logic would be more simpler.