HBlank Timings

Eke · Post by **Eke** » Fri Feb 27, 2009 9:41 am

mickagame wrote:I'm trying to adjust my DMA Timings with sonic 2 but i have a problem because the display isn't switch off at constant line.
Sometimes it's disabled at line 107 or sometimes at lines 108.
So the blue bar isn't fix ...

this has something to do with your Hint timings or the way you return HBlank flag.

most probably, when Hint occurs and is waiting for HBlank flag to be set (to start the DMA/Display OFF operation), HBlank flag is sometime returned as true immediately and sometime it has to wait until next line HBlank. Try looking at your execution to see when (which 68k cycle count) exactly the game read the VDP status...

DMA timings would only affect the "end" of the blue separation bar, when the display is set back to ON.

mickagame · Post by **mickagame** » Mon Mar 02, 2009 8:37 am

The problem i have with sonic 2 is due to the timings i use :

H-INT : 0
HBlankStart = H-INT + 130 MClks
HBlankEnd = H-INT + 130 MClks + 860 Mclks

So the delay between H-INT and HBlankEnd is 990 MClks
The 68K needs 44 Clks (308 Mclks) to fetch registers before executing first instruction of the interrupt.

So the 68k can execute 682 MClks before the end of HBlank.

The problem is :
Before testing HBlank Flag in status register, there are others instructions at start at interrupt processus.
With my timings, the 68k can execute this instructions and test the hblank flag during this 682 MClks (before end of hblank) so the display is switch Off during this Hblank juste after the H-Int (line 107).

That's not normal because line 107 don't have to be displayed off !!!
I think that in real hardware, when the 68k do the first test of hblank flag, the first hblank period must be ended, so the display will be switched off next line.

So my first conclusion is that this delay of 682 MClks is too much.
The delay of 860 MClks during hblank is confirmed so i think that the delay of 130 MClks between H-INT and HBlankStart is Wrong !!!

If I make HBlankStart = H-INT + 70 MClks (10 Clks 68K) -> The display is OK
IF I make delay between H-INt and HBlankStart longer than 70 MClks, the delay between H-Int and HBlankEnd is too long -> the HBlank flag can be tested -> The display is off -> The display is wrong

Here is interrupt routine (occurs line 107) with each instructions.
You can see the number of cycles the instruction start after H-Int :

Code: Select all

ROM:00000F54 HInt:                                   ; DATA XREF: ROM:00000070o          Start       Length
ROM:00000F54                 tst.w   ($FFFFF644).w                                         309         84
ROM:00000F58                 beq.w   locret_FFE                                            393         84
ROM:00000F5C                 tst.w   ($FFFFFFD8).w                                         477         84
ROM:00000F60                 beq.w   loc_1000                                              561         84
ROM:00000F64                 move.w  #0,($FFFFF644).w                                      645         112
ROM:00000F6A                 move.l  a5,-(sp)                                              757         84
ROM:00000F6C                 move.l  d0,-(sp)                                              841         84
ROM:00000F6E
ROM:00000F6E loc_F6E:                                ; CODE XREF: HInt+24j
ROM:00000F6E                 move.w  (VDP_Control).l,d0                                    925     
ROM:00000F74                 andi.w  #4,d0
ROM:00000F78                 beq.s   loc_F6E
ROM:00000F7A                 move.w  ($FFFFF60C).w,d0
ROM:00000F7E                 andi.b  #$BF,d0
ROM:00000F82                 move.w  d0,(VDP_Control).l
ROM:00000F88                 move.w  #$8228,(VDP_Control).l
ROM:00000F90                 move.l  #$40000010,(VDP_Control).l
ROM:00000F9A                 move.l  ($FFFFEEEC).w,(VDP_Data).l
ROM:00000FA2                 move.w  #$100,(Z80BusReq).l ; D8 ( W)   0: BUSREQ CANCEL
ROM:00000FA2                                         ;           1: BUSREQ REQUEST
ROM:00000FA2                                         ;    ( R)   0: CPU FUNCTION STOP ACCESSIBLE
ROM:00000FA2                                         ;           1: FUNCTIONING
ROM:00000FAA

As you can see, the hblank flag is tested at HInt + 925 Master cycles, so if HBlank End does not occured yet, the display is switched off immediately and the line 107 is not drawn !!!

So the delay between H-Int and the end of HBlank must be smaller than 925 Master cycles in real hardware, so the delay of 130 MClks between H-Int and HBlankStart seems not correct ...

mickagame · Post by **mickagame** » Fri Mar 06, 2009 2:54 pm

I think my Hblank period is too long.
Does the hblank period takes only 644 MClks (92 Clks) instead of 860 Mclks?
The overscan period is not included in hblank area?

Eke · Post by **Eke** » Fri Mar 06, 2009 4:18 pm

double post

Eke · Post by **Eke** » Fri Mar 06, 2009 4:19 pm

Most probably, Hblank flag period < real Hblank period

According to Charles McDonald:

Code: Select all

 Description            32-cell         40-cell
 ----------------------------------------------------------------------------
 Range                  00-93, E9-FF    00-B6, E4-FF
 H-blanking in          93, E9          B6, E4
 H-blanking out         06, 07          06, 07

this makes Hblank flag period being 59 or 60 pixels wide in H32 mode which is approx. 600 MCycles or 86 CPU cycles...

It seems like the HBLANK flag is cleared when the left border ends and active area starts (it has been measured to be 13 pixels in both modes, which coincides to Hcounter = 6,7)

You can still make the calculation according to Jorge Nuno timings measures but it's highely possible that it would be the same amount of cycles in H40 mode.

This is speculation (as always), this would need to be tested better (for example, you could set Hint to read the VDP status in a loop until the flag has swapped twice ...and store all read results in a table so that we could calculate the exact timings.. related to Hint occurence)

mickagame · Post by **mickagame** » Fri Mar 06, 2009 6:15 pm

So according to Charles MCDonald, HBlank period is 10 pixels in H40 mode wider than in H32 mode (E9 - E4 = 5; 5 * 2 = 10 pixels) ?

So 69 or 70 pixels = approx 552 MClks in H40 mode (69 * 8 = 552) ?

Another question :
In Jorge timing post, when you calculate timings, you said that in H40 mode there are 420 pixels with 390 pixels H40 mode and 30 pixels H32 mode.
Wich period correspond this 30 pixels?

Thank you for your informations it's hlep me a lot !!

Eke · Post by **Eke** » Fri Mar 06, 2009 6:45 pm

mickagame wrote:So according to Charles MCDonald, HBlank period is 10 pixels in H40 mode wider than in H32 mode (E9 - E4 = 5; 5 * 2 = 10 pixels) ?

So 69 or 70 pixels = approx 552 MClks in H40 mode (69 * 8 = 552) ?

no, because pixel clock during hblank is not always MCLK/8 but sometimes MCLK/10 (see the other post about VDP timing), so pixels in that area can be 8 or 10 MCycles "wide"...

In Jorge timing post, when you calculate timings, you said that in H40 mode there are 420 pixels with 390 pixels H40 mode and 30 pixels H32 mode.
Wich period correspond this 30 pixels?

This is based on the observations he made on EDCLK:

according to him, Hblank is decomposed like this:

28 (back border) + 18 (back porch) + 7 (start of Hsync) = 53 EDCLK cycles (MCLK/4) = 26 "H40 pixels" and a half

57 (end of Hsync) + 3 (start of front porch) = 60 EDCLK cycles (MCLK/5) = 30 "H32 pixels"

61 (end of front porch) + 26 (front border) = 87 EDCLK cycles (MCLK/4) = 43 "H40 pixels" and a half

so 70 pixels at the end of HBLANK correspond to 140 EDCLK cycles which is (according to the values above) : 87 *4 + (140-87) *5 = 613 MCycles

With all the approximations taken and possible errors that could have occured with measurements, it's quite reasonnable to think Hblank flag period is similar in both modes...

yes , I use to like maths

edit: btw, it's possible Hcount restarts at 0xE5 in H40 mode, not 0xE4... this is more compatible to the fact that there is 420 pixels per line (not 422) and I found direct references to 0xB6 and 0xE5 Hcount values when disassembling the lightgun X positionning routine in Menacer 6-in-1 game...

mickagame · Post by **mickagame** » Fri Mar 06, 2009 8:51 pm

isn't it 147 EDCLK acoording to your values?

And :

87*4 + (147 - 87) * 5 = 648 MCLKS?

So in theroy for H32 mode :

8 (back border) + 18 (back porch) + 7 (start of Hsync) = 53 EDCLK = 26 "H40 pixels" = 212 MCLKS = 42,4 "H32 pixels"
(Corrected after Eke post : 212/10 = 21,2"H32 pixels")

57 (end of Hsync) + 3 (start of front porch) = 60 EDCLK cycles (MCLK/5) = 30 "H32 pixels" (not changing)

61 (end of front porch) + 26 (front border) = 87 EDCLK cycles (MCLK/4) = 43 "H40 pixels" and a half = 348 MCLKS = 69,6 "H32 pixels"
(Corrected after Eke post : 348/10 = 34,8 "H32 pixels")

42,4 + 30 + 69,6 + 256 pixels (active display)= 398 pixels per line in H32 mode
(Corrected after Eke post : 21,2 + 30 + 34,8 + 256 = 342 pixels)

IN H 40 : 26,5 + 30 + 43,5 + 320 = 420 pixels per line

Is it correct?

Eke · Post by **Eke** » Fri Mar 06, 2009 10:56 pm

mickagame wrote:isn't it 147 EDCLK acoording to your values?

no, 140 EDCLK cycles correspond to 70 pixel counts, which was the "estimated width" of the hblank flag active period. I was just calculating the number of "H32-like" pixels in those 70 ones.

And :

87*4 + (147 - 87) * 5 = 648 MCLKS?

So in theroy for H32 mode :

8 (back border) + 18 (back porch) + 7 (start of Hsync) = 53 EDCLK = 26 "H40 pixels" = 212 MCLKS = 42,4 "H32 pixels"

57 (end of Hsync) + 3 (start of front porch) = 60 EDCLK cycles (MCLK/5) = 30 "H32 pixels" (not changing)

61 (end of front porch) + 26 (front border) = 87 EDCLK cycles (MCLK/4) = 43 "H40 pixels" and a half = 348 MCLKS = 69,6 "H32 pixels"

42,4 + 30 + 69,6 + 256 pixels (active display)= 398 pixels per line in H32 mode

no, that's wrong:

1) your math is not correct: 212 and 348 MCycles would make respectively 21,2 and 34.8 "H32" pixels, not the double

2) there are no such things as 0,2 pixel counts and you can not just reuse the same formulas: the previous values ONLY apply to H40 mode, the VDP in H32 mode works differently (pixel clock is constant).
Active area is 256 pixels (2560 MCycles), Blanking area is 15+8+26+24+13=86 pixels (860 MCycles) and full line area is 342 pixels (3420 MCycles). This has been verified on a SMS and it's confirmed by the official TMS9918 manual... it's very likely that the Genesis VDP is similar when in H32 mode.

IN H 40 : 26,5 + 30 + 43,5 + 320 = 420 pixels per line

Is it correct?

yes
also note that Active display area is still 2560 MClk ( 320*8 ), Blank area still 860 MClk ( 26,5*8 + 30*10 + 53,5*8 )...

mickagame · Post by **mickagame** » Fri Mar 06, 2009 11:28 pm

Yes i made error with my calculs.
I calculated Number of Master Cycles correctly but not converted in good number of H32 pixels, so i correct them in my post.

Hblank period is composed by end of HSync + start of front porch + end of front porch + front border, wich correspond to 147 MCLks?
So the 7 MClks of difference between your 140 MClks comes from the register latency? Where do you get this 140 Mclks value for Hblank flag active period?

Now about PAL timings :

PAL Crystal Clock is 53203424

I presume that in PAL mode clock pixel is always MCLK/8 or MCLK/10 as in NTSC mode ?

H40 mode :
26,5 "H40 pixels" = 26,5 * 8 = 212 MClks
30 "H30 pixels" = 30 * 10 = 300 MClks
43,5 "H40 pixels" = 43,5 * 8 = 348 Mclks
320 "H40 pixels" = 320 * 8 = 2560 Mclks

So as in NTSC full line is 3420 Mclks (But one Pal MClks is a bit longer than a NTSC Mclks)

25 frames with 312 lines and 25 frames with 313 lines.

3420 * 312 * 25 + 3420 * 313 * 25 = 53437500

So i have a difference with crystal clock :

53437500 - 53203424 = 234076

Eke · Post by **Eke** » Sat Mar 07, 2009 12:19 pm

Yes i made error with my calculs.
I calculated Number of Master Cycles correctly but not converted in good number of H32 pixels, so i correct them in my post.

Hblank period is composed by end of HSync + start of front porch + end of front porch + front border, wich correspond to 147 MCLks?
So the 7 MClks of difference between your 140 MClks comes from the register latency? Where do you get this 140 Mclks value for Hblank flag active period?

I think you are messing two things:

- the HBLANK flag active period has been deducted from the Hcounter values in Charles McDonald document: this is approximately 69-70 pixel counts and this is where the 140 EDCLK value comes from. I thought you figured that as well...

- the Horizontal Blanking period is anything outside Active Display area: this is 860 MCycles or 53+60+87 EDCLK cycles... I don't understand why you want the Hblank flag period being *exactly* 60+87, those are different things...

Now about PAL timings :

PAL Crystal Clock is 53203424

I presume that in PAL mode clock pixel is always MCLK/8 or MCLK/10 as in NTSC mode ?

H40 mode :
26,5 "H40 pixels" = 26,5 * 8 = 212 MClks
30 "H30 pixels" = 30 * 10 = 300 MClks
43,5 "H40 pixels" = 43,5 * 8 = 348 Mclks
320 "H40 pixels" = 320 * 8 = 2560 Mclks

So as in NTSC full line is 3420 Mclks (But one Pal MClks is a bit longer than a NTSC Mclks)

25 frames with 312 lines and 25 frames with 313 lines.

3420 * 312 * 25 + 3420 * 313 * 25 = 53437500

So i have a difference with crystal clock :

53437500 - 53203424 = 234076

where did you get it was 25 frames with 312 lines and 25 with 313 lines ?
there are no proof of that and most documents indicates the VDP output 313 lines per frame in PAL mode

Also, you can NOT just add values like that at the end, this makes no sense: there isn't exactly 50 frames per second (or 60 for NTSC)

what determines the frame rate is the MCLK value and the number of Mcycles per frame (number of Mcycles per line * number of lines per frames)

also, there is no point in making the calculations in PAL mode back again, you have to wait first that someone measures EDCLK on a PAL Mega Drive as well[/quote]

mickagame · Post by **mickagame** » Sat Mar 07, 2009 12:25 pm

Thank you Eke for all this information.
I understant now more precisely how the vdp work

I expect Jorge will make same measure for PAL Timings

If you overclock the vdp, the pixel clock is overclocked too, so the pixels are generated more quickly, so the frame displayed on the screen is wrong?

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Mar 07, 2009 5:27 pm

Time it takes to achieve something will decrease for absolutely everything, you'd get shorter lines, higher refresh rate etc... things get messed up for regular monitors

mickagame · Post by **mickagame** » Sat Mar 07, 2009 5:50 pm

But frequency of H-Interrupt and V-Interrupt are more important too?
I always thought these interrupts depended of the position of the TV electron beam?

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Mar 07, 2009 6:22 pm

TVs are generally pretty fixed to certain timings, and if they go too out of spec, you'll not see anything or see a mess...
H and V will all get faster if you increase clock and thus out of specs, and TV will not not see them when it expects to see them and what happens next is entirely TV dependant... my TV will show nothing but a blank screen if timings are wrong... however if I supply correct sync from some other system and have RGB lines from test subject hooked up, you can see rolling and scrolling unintelligable image