To Grauw: Sprite colors linked to sprite pattern no.

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 ), 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.

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.

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 .