Sprite collisions in the border?

By TomH

Champion (327)

TomH's picture

23-10-2018, 21:56

Hi;

I've recently been reading a lot about the Master System and its TMS-based VDP. It's almost exactly a TMS with one extra mode. It takes a completely different approach from the V9938 to increase video bandwidth over the TMS though, by switching to a 16-bit data bus but otherwise retaining essentially the same line timing as the TMS. Not identical but clearly a minor adaptation of the same thing.

One of the other interesting things it does is to generate sprite collision and overflow flags even in the border. Not just the horizontal border, but also the vertical and while the screen is blanked. That's despite also offering improved memory access availability while blanked or in the vertical border.

So it seems that Sega's designers implemented some light-touch sprites-only fetch pattern for blank and vertical border periods. But that's while generally hewing as closely as possible to the TMS' scheduling and functionality.

If you think about it, this would actually be a useful feature for the TMS — it means that if you unblank the display partway down, sprites are correct from the very first output line. Which was possibly Sega's motivation but there's no evidence either way.

So I was just curious:

  • is it known whether the TMS generates sprite collisions in the horizontal and/or vertical border?
  • supposing it does, is it possible that it isn't refreshing RAM "multiple times" as Mattias postulates, but spending some of those 'refresh' accesses on sprite activity?

Apologies for the probably-stupid question; I've been unable to answer it for myself.

Login or register to post comments

By PingPong

Prophet (3499)

PingPong's picture

23-10-2018, 23:55

TomH wrote:
  • is it known whether the TMS generates sprite collisions in the horizontal and/or vertical border?
  • supposing it does, is it possible that it isn't refreshing RAM "multiple times" as Mattias postulates, but spending some of those 'refresh' accesses on sprite activity?

AFAIK neither the TMS nor the Yamaha followers do generate sprite collision outside vertical Y position greater than the active area. (border)
For sure the sprite overflow bits are not affected by sprites on border i think the vdp just ignores them completely

By TomH

Champion (327)

TomH's picture

24-10-2018, 00:27

That would definitely seem to imply no sprite processing whatsoever.

I was curious because of both (i) the massive amount of spare refresh cycles the TMS is believed to have; and (ii) the almost direct mapping of TMS functionality to Sega's added mode.

E.g. for each column of the background the TMS collects three bytes: name, colour, pattern. The Sega VDP has double the bandwidth thanks to a 16-bit bus. So at the same times it collects: name+flags, first two bytes of tile image, next two bytes of tile image. For full 4bpp tiles. And pretty similar, but not exactly the same for sprites; all output horizontal and vertical timings are also identical, with the same delay between fetching graphics and their output.

So it would have been fairly natural if Sega's sprite collisions in the border had been a result of TMS functionality.

By hit9918

Prophet (2883)

hit9918's picture

24-10-2018, 00:29

but I heard that 9938 vs 9918 are different in these issues

By TomH

Champion (327)

TomH's picture

26-10-2018, 20:36

Actually, minor update on this: further reading suggests that the analysis over in Master System land supports the idea that collisions occur when you'd expect in the left and right borders, and definitely can happen in the top and bottom borders but it's also seemingly observed that the overflow flag doesn't get set in top and bottom borders.

So to my mind that doesn't necessarily establish that any sprite data is being fetched, rather than merely that the latched sprite data from the final pixel line might be replayed ad infinitum. So you'd see the collisions the sprites actually imply as if they were displayed during line 193, then the collision flag being set afresh on every line from there until frame size at the same location(s).

I'm just reading up on this stuff, my first impression may have been correct. But also it may not have been.