HBlank Timings

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

Moderators: BigEvilCorporation, Mask of Destiny

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Fri Apr 03, 2009 8:47 pm

run a wire from IPL signal from 68K to the TH pin on any controller port... when Hint happens, ExtInt happens, and 68K will read the latched value off the VDP..... this should work out...
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

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

Post by Eke » Sat Apr 04, 2009 9:41 am

neat, I didn't think about that actually but you're right, this is even an easier method 8)

all that you need is to enable TH transition triggering /HL through IO registers and to make sure the IRQ line connected to TH is not cleared before you can read the latched value

now, anyone who want to do the test in different modes (H32/H40, PAL/NTSC) ?

:wink:

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Apr 04, 2009 10:14 am

Can I externally sink TH low on control port 2 (or 3) so it triggers a level 2 int, while TH on port 1 is an output (standart controller)?

I need to set bit #3 of VDP register #$0B and bit #1 of register #00, yes?

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

Post by Eke » Sat Apr 04, 2009 11:21 am

You'll need to:

- mask interrupts on 68k side so IPL2 remains pending

- write the value 0x80 at $A10005 to set TH as an input and allow for /HL to be asserted when TH get low (on Port B)

- connect IPL2 to TH pin on port B so that /HL is asserted when HINT or VINT is triggered by the VDP

- set bit 4 in VDP register #0 (to allow HINT) or bit 5 in VDP register #1 (to allow VINT) depending on the interrupt you want to test

- set bit 1 in VDP register #12 to allow Hcounter to be latched when /HL is asserted

- make your program wait for the Hcounter latch to occur: wait for appropriate Vcounter value then wait for HBLANK flag to be set then cleared and finally read the Hcounter value


I don't think you can not rely on interrupt callback to read the Hcounter since you need to mask interrupts to keep Hcounter latched (it seems to be released as soon as /HL get high again). This however depends on how the I/O chip manages its /HL output on TH transitions


I think that's all ;-)

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Sun Apr 05, 2009 10:15 pm

Here is first results of my tests :

Assuming that :
- HBlank Start with HCounter jump from 0xB6 to 0xE4
- HBlank End with HCounter jump from 0x06 to 0x07
- H-INT occurs 128 MCLKS before start of right border -> start of blanking period.
- The 68K needs 308 MCLKs before executing first instruction of an interrupt routine.

Sonic 2 :

As you can see in this topic, h-int occurs at line 107. Then the game test h-blank flag until flag = 1. Then display is switched off.
Before testing hblank flag, 68k needs 308 MCLKS + 617 MCLKS.
The first time the test if made, if hblank flag = 1, display is switched off so line 107 is blanked, what is wrong.

So this game tell us that value of H-Counter at the moment of H-int can't be under 0xA3, corresponding to h-blank period start at 0xAB

Mickey Mania :

The game test h-counter until it reaches 0x88.
Then display is switched OFF, DMA is switched ON so CPU is freezing during 536 MCLKS.

As EKE said :
as shown by the logs, this games does not use HINT during the 3D level, it only reads Hcounter to wait for HBlank before switching off the display. It probably do not use the HBLANK flag to have a longer available period for DMA.

the writes that disabled the display is supposed to occur 68 cpu cycles after Hcount=0x88, which is 59~60 pixel counts

Now:

0x88 + (59/2) = 0xA5

this would means that HBlank (understand, start of right border) theorically start at this value (at least, we know this is the *maximal* value for HBLANK to start)

HINT is theorically meant to start 16 pixels ahead, which is approx. 0x9E.
If HBlank period begin with 0xA5, H-INT occurs just before 0x9D.

So the game tell us that hblanking period can't begin with h-counter > 0xA5, corresponding to H-INT at 0x9D

The two measures are in conflict ...

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Apr 07, 2009 10:58 am

As i said, this 2 measures are in conflict, but i was thinking a possibility.
In genesis plus, you don't have this conflict because you made a approximation with H-INT and HBLANK period start.
Now imagine that in real hardware, the h-int in entry of VDP is trigger 128 MCLKS before Hblank period start but with lantency h-int is trigger by 68k nearly at the same time as HBlank Start?
It will explain with Nemesis, with his test rom, measure that h-int trigger at the same time at HBlank start ...

I think between the two games mickey mania is more representative because he doesn't use h-int latency.
Now if H-INT and Hblank start with h-counter = 0xA5, the 2 games works perfectly ...

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

Post by Eke » Tue Apr 07, 2009 12:36 pm

Yes, there are some delays to take in account which are:

- delay between two consecutive Hcounter read (instruction execution takes at least 18 CPU cycle in our case): the best case is when the CPU read a value that is exacly the expected value, the worst case being when the CPU read a value that is just before the expected value.

- delay for the VDP to take a register update in account: this is unknown but you could theorically think that the worst case is the VDP rendering window, i.e 16 pixels.


Anyway, it's very likely that programmers did not have exact values to deal with and had to made various tests before finding the correct H-counter value.
Unless you are going to emulate bus/cpu latencies perfectly, you are quite forced to do approximations in an emulato, 128 MCLK or 16 pixels isn't really that much

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Apr 07, 2009 12:51 pm

There is instruction latency too.
the value of h-counter between the start of instruction and the end can change :-) ...

It would be interesting to test on real hardware when IPL1 IPL2 are triggered regarding of HSYNC ...

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

Post by Eke » Tue Apr 07, 2009 1:16 pm

It would be interesting to test on real hardware when IPL1 IPL2 are triggered regarding of HSYNC ...
this has been measured: we already know that there are 16 dot clocks between HINT and /YS going low, then 23 dot clocks before /HSYNC goes low, making 39 dot clocks (78 EDCLK) in total

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Apr 07, 2009 1:21 pm

What would be interesting for me is the delay between IPL1 IPL2 are triggered and start of blanking period ...
I don't know exactly what is /YS signal :oops:

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

Post by Eke » Tue Apr 07, 2009 1:32 pm

well, this IS the start of blanking period (= start of the right border): /YS goes low when background pixels are drawn, i.e when the borders are rendered, read the VDP timing thread again :wink:

Actually, everything has been measured regarding video & interrupt signals, we know how long active period is (always 2560 MCLK), how long blanking period is (always 860 MCLK), when left/right borders occurs in the blanking period (still need to confirm measure in H32 mode though) and when HINT/VINT occurs regarding the blanking period.

/HSYNC signal is not really relevant to any VDP event, it can be used as a reference signal though.


what is still unsure:

- the HBLANK flag occurence : it can obviosuly not be measured as precisely as above signals since it needs to be read from CPU

- Hcounter values for those events: that's why I proposed a small hardware modification which use the Hcounter latch feature to get exact Hcounter value when interrupt occurs.

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Apr 07, 2009 1:41 pm

So delay between H-INt and /YS is 16 dots but delay between IPL1 IPL2 are set and /YS is shorter?

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

Post by Eke » Tue Apr 07, 2009 1:57 pm

it's the same

IPL1/IPL2 are 68k interrupt signals, controlled by the VDP: they can be used to measure when HINT is triggered from the VDP

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Apr 07, 2009 2:47 pm

OK so the delay between IPL1 and IPL2 are set and hblanking start is 128 MCLKS.

So perhaps the différence between the 2 measures can be explained by the fact the vdp internal renderer unit is 2 cells.

Assuming that :
- HBlank Start with HCounter jump from 0xB6 to 0xE4
- HBlank End with HCounter jump from 0x06 to 0x07
- H-INT occurs 128 MCLKS before start of right border -> start of blanking period.
- The 68K needs 308 MCLKs before executing first instruction of an interrupt routine.
- The vdp internal renderer unit is 2 Cells, so when register changed this take effect only next column.

According to Sonic2 : value of H-counter at the moment H-INT occurs can't be under 0xA3, elsewhere line 107 is blanked (incorrect).

Now take the hypothese H-INT occurs at 0xA3
So Hblank start is 0xAB.
-> ie Blanking period can't start under 0xAB

Code: Select all


            Cell 38                      Cell 39                    Blanking
|------------------------|------------------------|-----------------------------]
 0xA3                                         0xAA 0xAB
|
|
 H-INT

Now if you take mickey mania, the game switch display off at H-Counter = 0xA5.

As you can see in the schema, the last column has already started the rendering, so the display ON/OFF will take effect only at start of blanking period.

So the last column (ie H-INT) can't begin with h-counter value > 0xA5
-> HBlanking period can't start with h-counter > 0xAD

So correct h-counter value when hblank start is [0xAB - 0xAD]

This is only an hypothese ...

Post Reply