Megadrive video timings

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

Moderators: BigEvilCorporation, Mask of Destiny

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Mar 18, 2009 11:17 am

Eke wrote:it also shows that if you add the DMA freezing time (16 bytes in CRAM is approx. 38 cpu cycles), you should still be in Hblank when DMA ends and dispaly is enabled again
It's 16 words -- 32 bytes -- in case that makes a difference.
Eke wrote:No, I didn't say that, I said the contrary: most probably, enabling/disabling the display can have immediate (mid-line) effect
If you want to peform a little test (probably won't get you any hard numbers, though), you can adjust that 0x88 value up or down [word @ 0x1ABE6] and try it on real hardware. Increasing the value makes it late so the blanking shows up on the left. Decreasing it makes it early so it shows up on the right.

Here's a shot from Fusion that should give you an idea. The value I used here was 0xA0. In Fusion (v3.61), you can change it to any value from 0x82 to 0x98 without having it show up on screen.

Image
Last edited by TascoDLX on Thu Dec 30, 2010 2:04 pm, edited 1 time in total.

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

Post by mickagame » Wed Mar 18, 2009 12:52 pm

What happen is that the routine is triggered earlier and display OFF would is sometime triggered at the end of the previous emulated line... if I choose to redraw the entire line in such case, it is indeed incorrect because the active line has eventually already finish its rendering and is already in hblank.
I render the line at time H-INT + 252 MCLKS (36 CPU CLKS), because VDP needs 36 CPU CLKS to fetch all registers.

So i think a good way to have correct redraw with display switched ON/OFF is :

Code: Select all

          -----------------------------------------------------------------------
                     |        HBLANK               |      ACTIVE DISPLAY
          -----------|-----------------------------|-----------------------------
          22222222222|NNNNNNNNNNNNN1111111111111111|22222222222222222222222222222
          -----------|-----------------------------|-----------------------------
          |          |            |                |
        H-INT      HBLANK     RENDERLINE         HBLANK    
        VCOUNTER++ START      (H-INT+252)         END
                   CUR_LINE++
        
        V-COUNTER -> VALUE OF THE V-COUNTER
        CUR_LINE  -> CURRENT LINE (INCREMENT AT HBLANK START)
        
        1 -> REDRAW THE CURRENT LINE (CUR_LINE) FROM PIXEL 0 TO 319
        2 -> REDRAW THE CURRENT LINE (CUR_LINE) FROM CURRENT PIXEL TO PIXEL 319
        N -> REDRAW  IS NOT NECESSARY (CAN BE DONE BUT NO EFFECT)
Last edited by mickagame on Fri Apr 03, 2009 12:36 pm, edited 1 time in total.

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

Post by Eke » Wed Mar 18, 2009 1:40 pm

t's 16 words -- 32 bytes -- in case that makes a difference.
my mistake, I meant 16 words, not 16 bytes
If you want to peform a little test (probably won't get you any hard numbers, though), you can adjust that 0x88 value up or down [word @ 0x1ABE6] and try it on real hardware. Increasing the value makes it late so the blanking shows up on the left. Decreasing it makes it early so it shows up on the right.

Here's a shot from Fusion that should give you an idea. The value I used here was 0xA0. In Fusion (v3.61), you can change it to any value from 0x82 to 0x98 without having it show up on screen.
yes, that a good idea (and can easily be done with a game genie)
comparing the "hcounter window" you are allowed to use on real hardware with the emulated one can give you a good idea of the accuracy of your emulator

this can also be used to measure the CPU access window by measuring the different visible blanking width (according to Nemesis, it should be a factor of 16 pixels)

btw, your test shows that Fusion already support midline display on/off switching ... (which also sometime occurs in sonic 2 vs mode)
;-)

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

Post by Chilly Willy » Wed Mar 18, 2009 8:28 pm

Mail Order Monsters on the Atari 400/800 used mid-line palette changing for more colors on-screen.

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

Post by mickagame » Fri Apr 03, 2009 11:38 am

I made some tests on mickey mania "3d" levels.
Now my emulator is able to take in account mid-line display ON/OFF.
So I don't care anymore about h-blank period to redraw the line.
If I consider H-INT occurs at H-Counter = 0xA5, the display is switched off before the end of the line and i have black pixels at the right of my screen.
the delay between h-counter = 0x88 (tested in the game) and h-blank start period allows 68k to execute all instructions until switched off display.

2 possibility :
- H-Counter value is too late.
- Display ON/OFF doesn't take effect immeditely. If VDP rendering unit is 2 cells (1 column), perhaps this take effect only next column?

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

Post by Eke » Fri Apr 03, 2009 1:10 pm

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.
Display ON/OFF doesn't take effect immeditely. If VDP rendering unit is 2 cells (1 column), perhaps this take effect only next column?
probably, yes.. anywya, you shouldn't count the number of pixels to render with the border color but rather the number of "column"

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

Post by mickagame » Fri Apr 03, 2009 1:33 pm

When i said :
If I consider H-INT occurs at H-Counter = 0xA5
I know that game doesn't use horizontal interrupt but in my emulator a line begin with H-INT so i begin my h_counter table value with the value the h_counter has when H-int occurs ...

I must adjust my timings.
I make the H-INT occur at H-Counter at 0xA5 that's why i have this problem :-)
This is the hblank period which start with 0xA5 ...
My table must begin with 0x9E.

What an error ...

Thank you Eke :-)

Edit : I find why my table began with 0xA5.
It's in relation with the last timings you posted on thistopic :

H40 mode:

Image

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

Post by Eke » Fri Apr 03, 2009 3:47 pm

Until someone figures the *exact* Hcounter value when HINT is triggered, I'd advise not to base your code on any of these tables but rather use the values that works for you.

Those are timings that worked for me because I make HBLANK and HINT start at the same time, that's all

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

Post by mickagame » Fri Apr 03, 2009 9:54 pm

Do you have a list of game which are using h-counter? hblank fkag?
In my emulator the delay between h-int and hblank start is 128 MCLKS as mesured by Jorge.
So the way i emulate them are similar to real hardware (not perfect i am sure but ...)
I've made many tests on mickey mania (test h-counter value) and sonic2 (test hblank flag in h-int process) and i would be interested to complete this tests in order to define an h-counter interval of value in wich h-int occurs. This will help to make the relation between h-counter and h-int.
I will post my tests with explanations at end :-)

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

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

mickagame wrote:Do you have a list of game which are using h-counter? hblank fkag?
In my emulator the delay between h-int and hblank start is 128 MCLKS as mesured by Jorge.
So the way i emulate them are similar to real hardware (not perfect i am sure but ...)
I've made many tests on mickey mania (test h-counter value) and sonic2 (test hblank flag in h-int process) and i would be interested to complete this tests in order to define an h-counter interval of value in wich h-int occurs. This will help to make the relation between h-counter and h-int.
I will post my tests with explanations at end :-)
I know that Striker & Road Rash (1,2,3) read Hcounter to do mid-frame VDP changes
Skitchin, Zero the Kamikaze (sky rendering) & Sonic 3D (bonus level) too I believe (unsure)

Sonic 3 read the HBLANK flag in its 2-player mode

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

Post by mickagame » Sun Apr 05, 2009 7:45 pm

Does Mickey Mania does :
- Display Off
- DMA ON
- Display ON

with 1 move instruction?

The problem in my emulator's that as display ON/OFF is in the same instruction the cpu is freeze after the instruction so display is switched ON immediately and the 16 words needs 6080 MCLS (because we are in active display) instead of 536 MCLKS (no more in blanking) in order to do the transfer ...

I must correct this before continuing my tests.

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

Post by Eke » Mon Apr 06, 2009 7:54 am

Does Mickey Mania does :
- Display Off
- DMA ON
- Display ON
with 1 move instruction?
no, it does Display OFF/DMA ON in the first MOVE
then Display ON/DMA OFF in the next MOVE
CPU is kept out of the bus during DMA so it can't execute the 2nd MOVE until DMA has finished

and I don't even think you should care about disabling then enabling the display using a single MOVE.L (do two consecutive writes in the SAME register), this would not even be noticable on screen

no game should do that anyway (why would they do ?)

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

Post by mickagame » Mon Apr 06, 2009 11:15 am

So i must correct my cpu freezing ...
thank you Eke :-)

A test which can be interesting to do on real hardware is to change h-counter value tested by mickey mania.
By incrementing the value the blanking period will be visible on the left on the screen.
By decrementing the value the blanking period will be visible on the right.
It could be interesting to know min/max value h-counter can be used without visible blanking period be shown on the screen.

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

Post by mickagame » Mon Apr 06, 2009 9:27 pm

Code: Select all

ROM:0001AC2A loc_1AC2A:                              ; CODE XREF: sub_1AB92+9Aj
ROM:0001AC2A                                         ; sub_1AB92+D4j
ROM:0001AC2A                 cmp.b   (a0),d0
ROM:0001AC2C                 bhi.s   loc_1AC2A
ROM:0001AC2E                 move.w  (a2)+,(a6)
ROM:0001AC30                 move.l  (a2)+,(a6)
ROM:0001AC32                 move.l  (a2)+,(a6)
ROM:0001AC34                 move.l  d2,(a6)
ROM:0001AC36                 move.l  d3,(a6)
ROM:0001AC38                 movea.l a1,a4
ROM:0001AC3A                 move.l  (a3)+,(a4)+
ROM:0001AC3C                 move.l  (a3)+,(a4)+
ROM:0001AC3E                 move.l  (a3)+,(a4)+
ROM:0001AC40                 move.l  (a3)+,(a4)+
ROM:0001AC42                 move.l  (a3)+,(a4)+
ROM:0001AC44                 move.l  (a3)+,(a4)+
ROM:0001AC46                 move.l  (a3)+,(a4)+
ROM:0001AC48                 move.l  (a3)+,(a4)+
ROM:0001AC4A                 lea     -$20(a3),a3
ROM:0001AC4E                 adda.w  (a5)+,a3
ROM:0001AC50                 cmpa.l  #$FFFF9A40,a3
ROM:0001AC56                 blt.s   loc_1AC5E
ROM:0001AC58                 suba.l  #$2800,a3
ROM:0001AC5E
ROM:0001AC36 move.l d3,(a6)
First 0x0080 is written, which enable dma transfer and freeze 68k.
Then, in the same move.l, 0x8164 is written, which enable display.

So in real hardware, cpu is frozen between the 2 words move.

As I update DMA transfer each time display is switched ON/OFF (to calcul remaining cycles before end of DMA) after the move DMA needs 6080 MCLKS instead of 536, which blanking the line ...
I wanted to be precise emulating display ON/OFF during DMA transfer but it will be more complicated to emulate dma transfert so precisely :-)

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Tue Apr 07, 2009 7:56 am

mickagame wrote: ...
ROM:0001AC36 move.l d3,(a6)
First 0x0080 is written, which enable dma transfer and freeze 68k.
Then, in the same move.l, 0x8164 is written, which enable display.

So in real hardware, cpu is frozen between the 2 words move.
I really doubt you can freeze the CPU in the middle of instruction. At least you can't interrupt it like this for sure. There is some delay between writing the command and actual DMA start/CPU freeze anyway.

Post Reply