VDP Status Register

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

Moderators: BigEvilCorporation, Mask of Destiny

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Thu Jun 24, 2010 4:53 am

How did you get there was two line buffers ? Wouldn't it be possible to get same effects with only one buffer (the same buffer is filled during HBLANK and pixels cleared as they are being displayed) ?
Yes, it could render during H-Blank but I think the timing would be extremely tight:

40-cell mode, pixel clock is 6.75 MHz (53.693172/8)
428 pixels per line, 320 for display, so 108 for hblank (let's assume every pixel can be used for rendering)
320 / 108 = Draws ~3 linebuffer pixels per pixel clock
Linebuffer write rate is 6.75 * 3 = 20.25 MHz (!)

Given the technology of the time I think it is more realistic that they used two line buffers and rendered at the pixel clock rate. And I know this isn't good evidence but virtually all arcade games of that era use two line buffers and Sega's games were amongst the first to do so (Hang-On, 1986).

At least in my experience using two buffers allows all the sprite behavior I've tested to be reproduced. (not including Mickey Mania :)
Another game to try is Deadly Move (Power Instinct) which disable display before the end of active screen and re-enable it only at line 15. You can make your character (sprite) jump and see that the first line of sprite is not drawn, just like in Sonic 2 when you make your character jump in the bottom screen.
But you lose the line because the buffer was erased when it was displayed before blanking was turned on. For example assume an even number of lines are blanked:

Line 1. Draw to buf #0, show then erase buf #1
Line 2. Draw to buf #1, show then erase buf #0 (CPU turns off screen)
Line 3. Blank line. Would have shown buf #1
Line 4. Blank line. Would have shown buf #0 (CPU turns on screen)
Line 5. Draw to buf #1, show then erase buf #0. #0 is still erased so the line is empty.
Line 6. Draw to buf #0, show then erase buf #1. Normal sprite display from now on.
(1) contrary to Master System VDP, sprite Ypos is directly related to the Vcounter value which seems to indicate that sprite pre-processing starts with Vcounter increment (unlike the SMS VDP where it is done on the previous line, as described in TMS9918 recent docs also)
Hmm, I always thought it worked like the SMS VDP. What games establish that this isn't true?

I understand that I may be completely wrong about all of this. :D

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

Post by Eke » Thu Jun 24, 2010 6:59 am

Well, since Genesis hardware seems to have been inspirated by arcade systems of the same area and especially System 16 (68000, Z80, Yamaha FM synthetizing,..), it would indeed be very possible they used similar design for VDP.

But ok, I think I got it, it depends on the number of line (odd or even) that were blanked. In the case of Deadly Moves, the screen was disabled on previous frame (at the end of line 212) then re-enabled at the end of line 14 of the next frame, I wonder what happen during VBLANK, buffers are probably not switched anymore and maybe even automatically cleared ?
Hmm, I always thought it worked like the SMS VDP. What games establish that this isn't true?

I understand that I may be completely wrong about all of this. :D
Well, this only came up because SMS VDP uses an offset for sprite Y position (as you already know, sprite with Ypos=0 will start to be displayed on line 1), which was related to the fact sprites were pre-processed on the previous line and VDP uses V-counter to look for sprites within the range (it's pretty well explained in a few recent documentsthat were released by the original TMS9918 designer).

The Genesis VDP does not have this offset so that's why I initially thought sprites were fetched as soon as the V counter is incremented (a little before HBLANK), this is also what some Sega patent is describing (see this). But the thing that seems to indicate the most that something special happen during HBLANK for sprites is the "MickeyMania" sprite limit: there are 10 sprites intended to be displayed on a line and only 5 are displayed. It seems quite hard to believe that only 5 sprites have been processed during previous active range and the rest during short HBLANK period.

A possible theory is that sprites (16 or 20) are parsed (Ypos/Size/Link from internal RAM then Xpos/Name/Attr from VRAM if sprite is "on the line") during HBLANK (or more exactly as soon as Vcounter is incremented), but one line before the line they are intended to be displayed (the VDP automatically calculates the offset itself).

In the case of Mickey Mania, since the HBLANK trick is used on every line, less sprite could be parsed on line N and the effect would be seen on line N+1.

Then, during the active period, sprite data is being read from VRAM and the current line buffer is being filled while the other internal buffer is simply being shifted out to the priority controller to be mixed with other planes pixels (still at the dot clock rate).

This would also go with the fact that the VBLANK flag is cleared one line before line 0 of active area, so that sprites parsing+filling is done on line 261.

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

Post by RetroRalph » Fri Aug 20, 2010 4:26 pm

Eke wrote:A possible theory is that sprites (16 or 20) are parsed (Ypos/Size/Link from internal RAM then Xpos/Name/Attr from VRAM if sprite is "on the line") during HBLANK (or more exactly as soon as Vcounter is incremented), but one line before the line they are intended to be displayed (the VDP automatically calculates the offset itself).

In the case of Mickey Mania, since the HBLANK trick is used on every line, less sprite could be parsed on line N and the effect would be seen on line N+1.

Then, during the active period, sprite data is being read from VRAM and the current line buffer is being filled while the other internal buffer is simply being shifted out to the priority controller to be mixed with other planes pixels (still at the dot clock rate).

This would also go with the fact that the VBLANK flag is cleared one line before line 0 of active area, so that sprites parsing+filling is done on line 261.
Wasn't this covered here? viewtopic.php?p=9983
According to the image you linked to it stores nearly the complete sprite table I would think. And you are likely right that it gathers that on the line previous to first displayable. Has anyone verified what information is stored internally?

My opinion is that they would stick with the sprite buffering approach and be pulling the BG planes from VRAM as it draws (with around 32 pixels buffer). It also fits with there being a 256 or 320 pixel "sprite limit" even if it's offscreen. I doubt they would have more than a single 320 pixel buffer.

The only question is WHEN it is doing this. It would be simpler to bundle BG reads together and separate the sprite reads, so I would lean that way, active display=BG, hblank=sprites. This way you can get away with a single buffer (save money). SMSVDP mixes VRAM reads but it doesn't have as much cache as the Genny does. If you look at the SMSVDP it's reading Ypos during the active line (from VRAM), it's likely the Genny does the same Y testing but from its own cache, to provide enough VRAM for BG rendering, then VRAMs all the sprite data at the end (like the SMS) after knowing what sprites are on the line.

Post Reply