2-cell vertical scrolling + horizontal scrolling

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Aug 19, 2010 7:37 am

Ok, I took some time to test how it works on real hardware. i were right about VSRAM addresses $4E and $4C being used for vertical scrolling of the left-most column when partially scrolled horizontally, but it's not exactly as I thought.

Here are the conclusions of my tests in column vscroll mode:

1) When fine horizontal scrolling value is applied (hscroll % 16 != 0), the left-most column is partially displayed and the vertical scroll value applied is VSRAM[$4C] & VSRAM[$4E]. The same value is applied for both A & B planes.

2) The above statement is only true in 40-cell mode. In 32-cell mode, the left-most column cannot be scrolled vertically, i.e vscroll value is fixed to zero for both planes. I verified that writing vscroll value to other VSRAM addresses had no effects as well.

3) hscroll mode has no effect on the above statements

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Mon Aug 23, 2010 10:11 am

Wow that's pretty random. Why those offsets exactly I wonder?

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Mon Aug 23, 2010 1:57 pm

Those offsets are the two last entries of VSRAM ($4c is the one used for the last column of plane A and $4e the one used for the last column of plane B), one column being 2 cells (16 pixels).

What I imagine is that, when hscroll value is not exactly a multiple of 16 pixels, the left-most column, which is only partially displayed, is rendered earlier and vertical scroll is not parsed correctly because it's not column 0 yet (technically, it would be column -1). Maybe in this case it would use the last value that was read on previous line (in this case, vscroll of last column for the previous line), I'm not sure why it get the same value for both planes though neither why the two last values get anded or why it does not happen in 32-cell mode.

RetroRalph
Interested
Posts: 16
Joined: Wed Feb 24, 2010 6:13 am
Contact:

Post by RetroRalph » Tue Aug 24, 2010 3:09 pm

Not sure if you have seen this EKE, but this video on youtube shows the gynoug scrolling issue. Seems correct with your new findings compared to forcing the partial column to the 0 entry.

http://www.youtube.com/watch?v=8pNGK1lDdIk

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Tue Aug 24, 2010 6:08 pm

I know yes, this is what this thread is all about, I already verified Gynoug on my own MD2, and I've run a dedicated test program on real hardware as well, I'm pretty sure this is correct behavior :wink:

RetroRalph
Interested
Posts: 16
Joined: Wed Feb 24, 2010 6:13 am
Contact:

Post by RetroRalph » Thu Aug 26, 2010 2:42 am

Yeah it's just interesting to see that Gynoug looks better with the "incorrect" emulation. Something that would be hard to notice unless you had played the game on the real system.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Aug 26, 2010 8:42 am

Actually, that made me think I only tested on a Model 2 Mega Drive (the one with the VDP-integrated ASIC, 315-5660). Maybe it behaves differently on the real VDP (315-5313)

Post Reply