Sprite Table Address Wierdness

[tomaitheous]

So I'm probably wrong. Sorry for muddying the waters.

Well, it's nothing but speculation on my part. Hehe If we could slow down the clock to the VDP by quite a bit and spy on vram, we could probably figure out what's being read from start to finish on a scanline for vram and at what points. This is a popular method from what I understand.

But one thing seems a bit strange. If in fact all sprite pixel fetching is done during hblank, and there are no sprites on that scanline, shouldn't hblank then be free to read/write vram? (Again, this is true on the PCE - so maybe trying to draw parallels is a bad idea) Maybe it's something else that's prefetched during Hblank from vram. Something fixed and always "on" so to speak - like tilemap entries or such.

[Mask of Destiny]

If we could slow down the clock to the VDP by quite a bit and spy on vram, we could probably figure out what's being read from start to finish on a scanline for vram and at what points. This is a popular method from what I understand.

Master clock is around 50MHz right? Plenty of logic analyzers on ebay that can handle that speed without issue.

But one thing seems a bit strange. If in fact all sprite pixel fetching is done during hblank, and there are no sprites on that scanline, shouldn't hblank then be free to read/write vram?

The logic would probably be simpler to just block off access during the portion of the scanline that the sprite engine would be active rather than doing so conditionally. The sprite engine probably doesn't have a way of knowing in advance whether it will need VRAM access. It probably does a single traversal through it's cache of the SAT and if it hits one that's on the current line it then fetches the necessary info from VRAM. It might be problematic for a 68K/DMA request to be in progress when it gets to that point so it wouldn't be inconceivable for all access to be blocked regardless of sprite usage.

This is not to say it is of course.