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) » Mon Mar 16, 2009 1:48 pm

On semi related note, emulators should fill all RAMs with grabage (as RAM state is undefined on powerup). One thing I have noticed when I tested a friend's ROM on real HW is that Vscroll RAM first 2 entries is random on powerup, but the rest seem to be fixed to 0...
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

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

Post by Jorge Nuno » Mon Mar 16, 2009 1:53 pm

Remember that there is the pixel clock at ~6MHz... Every video signal is synchronous with it's rising edges, but for some reason everyone forget it. In H40 it's nothing more than Edclk/2, which means that during H pulses it changes rate.

Nemesis wrote:Unfortunately, my current oscilloscope doesn't have the bandwidth to sample MCLK, so I can't get a precise reading. I estimate that on a PAL system running in H32/V28, the HBLANK flag is asserted around 85 MCLK cycles before HSYNC enters the blanking phase, and that the HBLANK flag remains asserted for around 590-600 MCLK cycles.

Here's the ROM I used to perform this test:
http://nemesis.hacking-cult.org/MegaDri ... gister.bin

And here's the source:
http://nemesis.hacking-cult.org/MegaDri ... gister.asm

Jorge, you might have better luck sampling the output. You seem to have access to a pretty good CRO.

EDIT: I should mention, all the bits of the VDP status register can be sampled with this ROM, except bit 9 (FIFO Empty flag) and bit 4 (Odd interlace field flag). Just hook the corresponding data line from the 68K bus matching the bit you want to sample.

EDIT2: It just occurred to me, I should be able to get an accurate sampling if I compare the data to EDCLK, then convert the EDCLK values back to MCLK. I think I'll try that tomorrow.
My MD has TMSS, and I'm not sure if bypassing it, the VDP is still acessible.
Last edited by Jorge Nuno on Mon Mar 16, 2009 7:17 pm, edited 1 time in total.

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) » Mon Mar 16, 2009 4:40 pm

you will still have to write "SEGA" but you won't be having the TMSS ROM ran.
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

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

Post by mickagame » Mon Mar 16, 2009 5:34 pm

Nemesis wrote:Unfortunately, my current oscilloscope doesn't have the bandwidth to sample MCLK, so I can't get a precise reading. I estimate that on a PAL system running in H32/V28, the HBLANK flag is asserted around 85 MCLK cycles before HSYNC enters the blanking phase, and that the HBLANK flag remains asserted for around 590-600 MCLK cycles.

Here's the ROM I used to perform this test:
http://nemesis.hacking-cult.org/MegaDri ... gister.bin

And here's the source:
http://nemesis.hacking-cult.org/MegaDri ... gister.asm

Jorge, you might have better luck sampling the output. You seem to have access to a pretty good CRO.

EDIT: I should mention, all the bits of the VDP status register can be sampled with this ROM, except bit 9 (FIFO Empty flag) and bit 4 (Odd interlace field flag). Just hook the corresponding data line from the 68K bus matching the bit you want to sample.

EDIT2: It just occurred to me, I should be able to get an accurate sampling if I compare the data to EDCLK, then convert the EDCLK values back to MCLK. I think I'll try that tomorrow.
Have you possibility to do the same test in H40 to know approximatively how many MCLK paste between HBlank flag set to 1 and HSync period?

It will help to complete eke schema ...

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

Post by mickagame » Wed Mar 25, 2009 5:46 pm

Nemesis wrote:Well, the logic analyser thing didn't go so well. I'll have another go at it later.

What I did instead was create a test ROM which is actively polling the status register and HV counter in tandem as fast as possible, and writing that sampled data to RAM. I ran the ROM multiple times over, under a variety of conditions, both with an without interrupt handler routines, dumping the contents of RAM out to my PC to generate around 1MB of sampled data.

The only tests I've done so far have been in V28/H32 mode on a PAL system, but the data I've compiled suggest the following:
-The HBLANK flag in the status register is set when the HCOUNTER value "jumps" from what appears to be 93 to E9. I assume in other display modes, the HBLANK flag will also be set when the HCOUNTER value jumps ahead, regardless of what the actual values are under that mode.
-The HBLANK flag is cleared at what appears to be a HCOUNTER value of 06.
-HINT is triggered at the exact same time as the HBLANK flag in the status register is set, and the HCOUNTER value jumps. In other words, the HCOUNTER jump, HINT, and HBLANK flag being set, all occur at the same time.
-The VCOUNTER is incremented slightly before HBLANK is set, at an apparent HCOUNTER value of 85. IE, if the VCOUNTER was 14 when HCOUNTER was 84, when HCOUNTER is 85, VCOUNTER will now be 15.
-On the last line, the VBLANK flag is set when the VCOUNTER value is incremented to E0.
-The VBLANK flag is cleared when the VCOUNTER value is incremented from FE to FF the second time. As per the info from Charles MacDonald, and my own tests, the VCOUNTER in this PAL mode counts in the following sequence: 00-FF, 00-02, CA-FF. VBLANK is set when VCOUNTER hits E0, during the 00-FF block. When VCOUNTER hits FF in the CA-FF block, VBLANK is cleared.
-VINT is triggered when the HCOUNTER resets from FF to 00, well after the VCOUNTER has been incremented to E0 and the VBLANK flag has been set.
-The VINT occurrance flag is set as soon as VINT is asserted. It only reads as set when the interrupt has not yet been taken. Reading the status register immediately after entering the VINT routine for example registers this bit as unset.

These readings I took mostly line up with this timing info Eke posted:
http://img10.imageshack.us/img10/8066/vdptimingsh32.gif
With the exception of the VCOUNTER increment, which I read as happening when HCOUNTER reaches 85, not when it reaches 86. The additional info I've provided, such as interrupt timing and vblank flag timing, fit into this diagram as I've described above.

This is preliminary info. I need to do a lot more analysis and sampling, and in particular test under different screen modes such as H40, V30, and on NTSC systems, but I can be pretty confident about what I've posted. Regarding the interrupt timing, note that I sampled those times by determining the last sample I was able to capture before the interrupt was taken, so interrupt execution times haven't affected my readings. Due to the volume of sample data I've captured, I'm reasonably confident the info I've given is accurate, but I do need to carry out more tests.
Do you have same results for H40 mode?

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Thu Mar 26, 2009 1:21 am

I haven't done anything more with this in the last week or so. I'll try and get back to it this weekend.

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

Post by mickagame » Thu Mar 26, 2009 7:41 am

Great !!!

Snake
Very interested
Posts: 206
Joined: Sat Sep 13, 2008 1:01 am

Post by Snake » Fri Mar 27, 2009 8:31 pm

Eke wrote:
mickagame wrote:I thought to read hvcounter in a loop and write to ram only in interrupt routine, not each time you read it :)
oh well, something like this ?

Code: Select all

Main:
LEA       $C00004,A6

Loop:
MOVE.w   (a6),         D0     ;Get HVcounter 
BRA Loop;


Hint:
MOVE.w   D0   $E01000
// DISPLAY STORED VALUE ON SCREEN
RTE;
I don't know if this is possible with the 68k but it would be damn precise yes ;-)
Old post, I haven't been around much lately...

But, no, this won't be very precise. The move and bra in the main loop are fairly long instructions and they will affect when the interrupt comes in. What you really need to do is read it in the interrupt, and have the main loop doing as little as possible.

Logically it seems that doing STOP #$2300 in main is the best way to achieve this - but it appears not to be either, it seems to take quite a while to wake up.

Best way is to fill a block of ROM with about 80000 NOP instructions, no loops - and execute that. That should take over 2 frames to execute, which will be enough time for any interrupts to happen. This way, the most the interrupt will get delayed is 3 cycles.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Mar 27, 2009 11:12 pm

The manual says STOP is always 4 clock cycles, but maybe it always executes the following instruction on waking before the interrupt is processed. The manual isn't clear on that. The only thing they say occurs before the next instruction is a trace exception if tracing was enabled. So maybe

STOP #$2300
NOP

is the way to handle it.

Snake
Very interested
Posts: 206
Joined: Sat Sep 13, 2008 1:01 am

Post by Snake » Sat Mar 28, 2009 4:10 am

Yes, you may be right there. Even so, that would make the timing at least one cycle longer than a bunch of NOPs. Hell, what else are you going to fill that rom space with? ;)

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Mar 28, 2009 7:52 am

Good point. 4 MB of NOPs should be good. :D

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

Post by Eke » Fri Apr 03, 2009 7:58 am

I was thinking of another method recently: what if we used the /HL input ability to freeze the Horizontal Counter ?

This would involve minor hardware modifications (but nothing more complicated than a 50/60Hz switch) and the ability to access required pins (maybe only possible on earlier model 1 revisions ?

By connecting /HL input to /IPL2 output and masking interrupts on 68k side, horizontal counter would be latched (and remain latched as long as interrupt remains pending) at the exact moment when interrupt level 4 or level 6 is triggered.

As long as you wait enough time for this to occur (wait for VCounter specific value, wait for Hblank flag to be set then cleared in teh case of HINT, wait for VINT flag in the case of VINT), you could then read the Hcounter and retrieve the latched value

This could be used for both interrupts... and even used with other signals such as /YS, /HSYNC or /VSYNC to measure other events but it might not be so easy to read HCounter before it is unlatched :wink:
Last edited by Eke on Fri Apr 03, 2009 10:02 am, edited 2 times in total.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Apr 03, 2009 9:41 am

Sounds like your best bet for truly accurate measuring on the values in question.

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 9:46 am

you can nicely do that on MD2, all of them have a discrete 68K... no, VA4 does not... so you can nicely do the level2 int trick :)
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 » Fri Apr 03, 2009 12:43 pm

well, you essentially need access to the /HL input ... and since this is usually managed by the I/O chip, you would need a revision where VDP and I/O are not integrated in the same glue chip

Post Reply