VDP VRAM access timing

[Eke]

Again, the problem is your math:

25 slots = 25 x 4 EDCLK not MCLK !

Also, I count only 23 slots from the left of the page to HSYNC so this makes 368 Mcycles.

However, you need to understand that timings in hvc.h refer to the video timings observed in the previous thread, they are NOT related to the slot access (as most likely, in the VDP, "events" are not related to access slots but the internal clock) .

Similarly, there are no references to HINT, H Counter or display borders in Nemesis diagrams, just slots positions related to EDCLK and therefore "2 cells" groups are NOT necessarily aligned to rendered pixels as you seem to assume (and they probably aren't if you compare HSYNC timings from both thread).

The "only" thing you need to do is gather informations from both threads, using the only common reference in both ones which is HSYNC timing, to get what you want, quite all the information needed is in there (though I think it still misses HINT & video timings in H32 mode)

Now, from the previous thread :

There are 78 EDclk cycles (All Mclk/4) from H-int falling edge to sync pulse falling edge

78 EDCLK = 312 MCLK, this is were hvc.h timings come from.

So, apparently, this *would* mean that HINT is triggered after SC=706, i.e between access slot 176~177.

[mickagame]

My maths wasn't correct
I was assumed that 2 cells buffer were filled just after corresponding slot access and that was my error.

What i'm trying to do is to emulate each slot access during the line.

So if i understand correctly the main activity of the vdp during Hblanking is to read sprite pattern according to sprite mapping parsed during previous line.

I think that for the first line sprite line buffer is filled during last line of the previous line, in relation with the vblank flag cleared on the last line.

The game interesting to observe in sonic 2 too. During the two screen of each players the display is disabled until the dma end.
So if the first line of the second screen is able to show sprite the display must be enable at the beginning of the hblanking period but the sprite parsing hasn't been made because display was disable during the previous line ... That would be interesting to test

[Eke]

The first line of the bottom screen in Sonic 2 VS mode does not show sprites, you can easily see it when making the character jump.

And yes, VBLANK flag is cleared at the start of the last line, not line 0, so sprites attribute + pattern data are processed on that line to be displayed on next line (line 0).
This is only true for games with display enabled off course: in some games that reduce the active screen height by "expanding" vertical borders using the display OFF feature, you can see that the first line of "active" display does not display sprites as well. Again, this is only noticeable if you can make the sprite character jumps or moves to the top border, a good example for that is Power Instinct / Deadly Moves.

All these stuff are emulated in Genesis Plus btw and were verified on real hardware. The only thing I am not sure is what happen if you disable display just AFTER the sprite line buffer has been filled (end of HBLANK) then re-enabled at the exact same spot a few lines later. I think that the previously parsed line of sprites got displayed since the buffer was not emptied but I can't find any games to verify that.

[mickagame]

Thanks Eke all is clear for me now
I just begin my test and my emulator is 4 times slower and i don't finish emulate all the slot ...

[mickagame]

If i take your notes Nemesis.
From Access Slot 6 to 13 (2 cells Border) datas from 2 first displayed cells are latched and renderer in a 2 cells buffer.
During Access Clots 14 to 21 (2 first displayed cells) pixels are generated from the buffer and during this time datas from displayed cells 3 and 4 are latched ...
What correspond sprite pattern from access slot 7 and 11?

Thanks

[Eke]

If i take your notes Nemesis.

What correspond sprite pattern from access slot 7 and 11?

Those are the last 16 sprite pixels cached to upcoming line buffer.

I think it has already been discussed before in that thread and elsewhere too:
- sprite entries for line N are preselected during active line N-1 (using only vsize, ypos and link from internal SAT cache)
- sprite pixels are fetched and sprite line buffer is filled during HBLANK for line N
- sprite pixels are shifted out of the buffer and sent to priority controller during active line N

[mickagame]

If i undst good the shema from Nemesis :
Slot 12 :
When Hsync go high the line start to be drawn on tv
Slot 6 to 13 :
The first left scrolled 2 cells are fetched and output to internal line buffer
=> During this period 2 cells fulling with background color are output to tv (left border)
Slot 14 to 21 :
The 2 cells fetched just before are output to TV
=>etc ...

Is correct?

[mickagame]

Can someone correct me if i understand the timings in the wrong way?



I wonder if xscroll = 0 what pattern are read during the two first left scrolled cells?

[Eke]

According to Nemesis intial post

If the cells in layer A and B are perfectly aligned to the screen, so that every cell is entirely visible, these additional reads are still performed, but the results are not used.

so the column -1 is always being fetched, even when xcroll & 15 = 0 and the pixel out for a plane is probably just delayed according to 4 lower bits of xscroll value.

If you look at this other thread, you can see that active display apparently starts 74 (48+26) SC cycles after /HSYNC rising, which would corresponds to the middle of access slot #24 in above figure, so, the pixel out is not exactly aligned with column fetches as in above figure and I guess that, at hardware level, for each plane :
- there is a 4-bit counter that get loaded at the start of the line with the lower 4 bits of xcroll fetched value
- at some point (most likely 16 pixels before active display starts, which would be middle of access slot #16 in above figure), pixel value is shifted out from fetched column buffer(s) if the counter has reached 0, otherwise the counter is decremented at each pixel clock

When xscroll lower 4 bits are equal to 0, this would result in all 16 pixels from column - 1 being shifted out during the left border, thus not being visible at all.

[mickagame]

Thanks eke step by step all is more clear for me. When you speak about active display you speak about visible display area, not the left border?

[Eke]

Yes, as described in linked topic, active display corresponds to the 256 or 320 active pixels wide area.