VDP Status Register

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

Moderators: BigEvilCorporation, Mask of Destiny

Charles MacDonald
Very interested
Posts: 292
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: 884
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.

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

Re: VDP Status Register

Post by Eke » Fri Mar 05, 2021 9:38 am

Sorry to resurrect this old topic but I was wondering if anyone tested if the HBLANK flag (bit 2) was still set normally during VBLANK ? I could not find any info about this but maybe it was already confirmed somewhere ?

The reason I ask is that an user reported the game "Double Dragon II" having some noticeable slowdowns in Genesis Plus GX and analyzing my trace log, I noticed this game checks the HBLANK bit in its VINT callback and will skip screen update if that bit is set.
I am not sure why they did that (maybe they mixed HBLANK and VBLANK bits ?) but what happens is that sometimes, VINT processing is slightly delayed because the game continuously disables/enables interrupts (trough SR register) during its main processing loop and, as a result, the HBLANK flag sometimes ends up being read as set to 1 so screen update is skipped, thus resulting in some weird action slowdowns / hiccups.

Forcing HBLANK to 0 during VBLANK obviously fixes all these slowdowns (and does not seem to break any other HBLANK sensitive games) but I have no idea if this is correct (and no way to test it on real hardware atm).

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP Status Register

Post by Stef » Sat Mar 06, 2021 10:40 pm

This game suffers from slowdown in Gens too..
Afaik i wonder if developers got documentations about the MD hardware as the game does lot of mistake.
One of it is that it's wrongly testing Z80 BUS REQ bit, i has to add a small delay between BUS request and actually BUS req ack status to avoid the game locking so i wouldn't be surprised it does some other weird things.

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

Re: VDP Status Register

Post by Eke » Sun Mar 07, 2021 11:58 am

It is possible this game suffers from slowdown on real hardware too, I can't really tell without testing it.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP Status Register

Post by Stef » Mon Mar 08, 2021 10:16 am

I never tested it on real hardware but it's likely to have some slowdown issues as well indeed..

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

Re: VDP Status Register

Post by Eke » Fri Mar 19, 2021 1:17 pm

For what it's worth, I finally got access back to my flashcart and verified the game has notable slowddown on real hardware as well.
Also confirmed that HBLANK flag is still set/cleared normally during VBLANK.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP Status Register

Post by Stef » Mon Mar 22, 2021 11:33 am

Not too much surprised.. the game is really badly coded :?

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: VDP Status Register

Post by cero » Thu May 13, 2021 3:46 pm

Is the VBLANK flag valid when display is disabled? I couldn't find anything in google or checking vblank/blank/vcounter keywords here.

Asking because dgen and mednafen differ here, dgen's is valid, mednafen's not.

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

Re: VDP Status Register

Post by Eke » Fri May 14, 2021 12:43 pm

VBLANK flag is forced to 1 whenever the display is disabled/blanked (through VDP register $01 bit 6).

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: VDP Status Register

Post by cero » Fri May 14, 2021 4:56 pm

Does vcounter continue? Thinking about timing frames during a black screen. And if vcounter continues during disabled display, is it affected by also disabling ints (via SYS_disableInts, so vint still fires I believe, it's just ignored).

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

Re: VDP Status Register

Post by Eke » Sat May 15, 2021 11:35 am

HV counters are not affected by display or interrupts being disabled.

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: VDP Status Register

Post by cero » Sat May 15, 2021 5:29 pm

Thanks!

Post Reply