Y coordinate 217 for sprite mode 2

Page 2/2
1 |

By Grauw

Ascended (10565)

Grauw's picture

30-01-2019, 20:59

hit9918 wrote:

are you saying that msx1 is identic to msx2

Identical, certainly not, similar in parts, yes. Both have the concept of access slots. Both use a large amount of them fetching sprite table data every line.

See the “results” graphic at the top, and the further info at the bottom of Wouter Vermaelen’s VDP research pt. 2, and of course also the TMS9918 application manual.

The 29 CPU cycle (8 µs) write interval in screen 2 is based on a fixed set-up overhead (2 µs) + the maximum distance between available access slots, which is 16 slots (5.96 µs / 64 VDP cycles) as seen in the graphic. If we disregard bitmap data access slots, the maximum distance is still 13 slots (4.84 µs / 52 VDP cycles). This is not enough to permit 18-cycle OUTI access (5 µs) during blanking.

Therefore we can conclude that sprite data is not fetched (also there would be no point in doing so).

By hit9918

Prophet (2921)

hit9918's picture

30-01-2019, 20:47

I heard that the MSX2 is different in sprite collisions in the border
that is why I am poking around
but cant I remember which paper

By PingPong

Prophet (3885)

PingPong's picture

01-02-2019, 13:43

so to summarize:
a) on tms9918 if i place 5 sprites with y = 198 (for example) partially overlapping on x value when i read r#0 i should found both collision bit and sprite overflow bit both to 0?
b) on v99x8 if i place 9 sprites as in (a) with y = 220 (taking into account r#24 value when it's not 0) i should read r#0 with both collision and sprite overflow bit = 0, right?

someone can confirm (a) and (b) on real hw?

Page 2/2
1 |