Megadrive video timings

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

Moderators: BigEvilCorporation, Mask of Destiny

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

Post by Eke » Mon Mar 16, 2009 3:56 pm

he pixel clock seems to be unrelated to EDclk. In H32 mode Edclk still has the frequency change in the Hsync pulses, but the pixel clock didn't seem to change on Hsync pulses... (Or I set the wrong bit, forcing Hsync to 1 always)
is this confirmed ?

btw, have you measured the different video signals period (YS, HSYNC) and interrupt lines in H32 mode regarding to EDCLK ? or are they exactly the same as in H40 mode ?

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 4:26 pm

Not yet, I think that statement is somwhat wrong... Because if you set bit5 of Mode Set Register #4, Edclk will be always M/4 (hsync signal will be '1' all the time)


In H32: (I'm working with a 2Ch+Ext osc now...)
The pixel clock never changes, its always ~5.319MHz
Image

HSync pulse is 26 pixels wide.
Image

I measured 37 pixels from IPL2 (Hinterrupt) \__ to Hsync \__
Image
Check IPL trigger:
Image

EDclk in H32 changes rate like H40, but the pixel clock is unnafected by it...
Image

[speculation]
...It seems that in H32 mode, the VDP generates the pixel clock form itself, dividing from the 53MHz osc, most likely, while in H40 the pixel clock is disconnected from this divider, and uses the EDclk signal as a reference...
It makes sense though, because the EDclk generator (315-5433 in my case, doesn't know if the VDP is in H32 or in H40 mode, but still the Hsync pulse has to have the same length, or else it would be too short for TV's, that's why it changes rate when Hsync is low.)

Come to think of it, I beleive EDclk is External Dot Clock (how's that? :D )
[/speculation]


Also MRE0 didn't seem to change anything at all, grounding or pulling HI, or leaving it the air...
Last edited by Jorge Nuno on Mon Mar 16, 2009 11:13 pm, edited 4 times in total.

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

Post by Eke » Mon Mar 16, 2009 7:41 pm

interesting... you mean EDCLK is an input for the VDP, not an output ? then it makes sense yes
but what could be 315-5433, never heard of this part before (at least it is not on Model 1 schematics) ?

it would be great if you could redo all your measures (in both modes) relative to the pixel clock this time, it would be easier to make everything eventually fit with Hcounter values ;-)

thanks a lot

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 9:22 pm

Eke wrote:interesting... you mean EDCLK is an input for the VDP, not an output ? then it makes sense yes
but what could be 315-5433, never heard of this part before (at least it is not on Model 1 schematics) ?

It's model1 - TMSS (VA6 board), ext port not present but reserved.

The chip is a squared PQFP like the VDP but it has 160 pins instead of 128.
It includes the TMSS, the ZtoV/VtoZ communication, IOports management, some timing/decoding/refreshing signals...

The Edclk is a square have produced by this chip (or another depending of VAx then it passes through the FB7+capacitor to remove harmonics, that's why it has "rounder" edges than normal) then it goes to the cart port (I'm hooking the probe in here) and the VDP.
Eke wrote: it would be great if you could redo all your measures (in both modes) relative to the pixel clock this time, it would be easier to make everything eventually fit with Hcounter values ;-)

thanks a lot
H40, just do EDclk/2 to obtain measurements in pixel clock units.


Uploaded PICZ to the former post.

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

Post by Eke » Tue Mar 17, 2009 2:34 pm

ok, here's another roll with speculated timings, which takes in account Jorge & Nemesis last measures ;-)

H32 mode:

Image


- according to Nemesis, HBLANK flag is set approx. 8~9 pixels before HSYNC which is indeed back porch width: this *would* mean HBLANK flag is set just after the right border.

- according to Nemesis and Charles Mac Donald, HBLANK flag is set when Hcounter jump from 0x93 to 0xE9, which would also makes the back porch starting here.

- I made the hypothesis that the flag is set anywhere during HBLANK except the two border areas: this would make HBLANK flag being cleared at Hcounter=0x06, which has also been verified Nemesis and Charles Mac Donald. This made the HBLANK flag active period being 580 MClkl which is also close to what Nemesis measured.

- according to Jorge Nuno, HINT occurs 37 pixels before HSYNC: this makes Hint occurs at Hcounter=0x85. This is also probably where Vcounter is incremented (confirmed by Nemesis and Charls McDonald).
It does not seem possible that Hint occurs at the same time as HBLANK flag (as Nemesis measured) since it is in contradcition with all other signal measures.

- according to Nemesis, VINT occurs at Hcounter=0x00. This requires confirmation but is rather close from what Jorge BNuno measured in H40 mode.



H40 mode:

Image

- I made the hypothesis again that the Hcounter "jump" marks the start of the back porch and that HBLANK flag is set at the same moment, when Hcounter jump from 0xB6 to 0xE4 (confirmed by Charlesd MacDonald).

- if we consider that HBLANK flag is again cleared at the end of the front porch, this makes the flag being cleared at Hcounter=0x08

- Hint has been measured by Jorge Nuno and occurs 39 pixels before Hsync: this makes Hint occurs at Hcounter=0xA7, which is also where Vcounter is probably incremented.

-Vint has been measured by Jorge Nuno and occurs 20 pixels after the end of HSYNC: this makes Vint occurs at Hcounter=0x02


On a side note, if you "translate" the given values for H40 mode by 2, you retrieve similar values as in H32 mode: 0x08->0x06, 0x02->0x00, 0xA7->0x85 (256 pixels="0x80", 320 pixels = "0xA0")...


Now, this is (still) speculation only, based on the few tests the above people made on hardware... this still need to be somehow confirmed by additional tests (for example, YS signal transitions and VINT occurence in H32 mode regarding to HSYNC)

But the good thing is that those values are the ones I use in Genesis Plus GX since a few versions and are already confirmed to be working with all games either sensitive to Hcounter (MickeyMania, Striker,...) or HBlank (Sonic 2, Road Roash,...)
Last edited by Eke on Tue Mar 17, 2009 4:59 pm, edited 2 times in total.

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

Post by mickagame » Tue Mar 17, 2009 2:43 pm

Thank you for resuming all informations :-)
I will try this timings tonight but even if they are not exact i think they are very close to real values ...

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

Post by mickagame » Tue Mar 17, 2009 7:07 pm

I made tests with this timings on my emulator.

When i tried mickey mania it didn't work on "3d levels".
As you said that it work on genesis plus I have compared with it and i found the reason :
When display is switched on/off you redraw the line only during Hblank period.
I've made the same thing and it works on my emulator.

What i conclude about this test :
- If we consider that display on/off takes effect only during hblank period this timings are ok.
- If we consider that display on/off takes effect immediately without considering hblank flag period i think there's a problem with this timings.
With my timings it worked without testing the blank flag ...

To confirm my test, can you test mickey mania on genesis plus with test of hblank flag removed when display is switched on/off?

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

Post by Eke » Tue Mar 17, 2009 9:15 pm

mickagame wrote: As you said that it work on genesis plus I have compared with it and i found the reason :
When display is switched on/off you redraw the line only during Hblank period.
I've made the same thing and it works on my emulator. What i conclude about this test :
- If we consider that display on/off takes effect only during hblank period this timings are ok.
- If we consider that display on/off takes effect immediately without considering hblank flag period i think there's a problem with this timings.
With my timings it worked without testing the blank flag ..
it is not that simple... most probably on real hardware, display ON/OFF takes immediate effect and what is sure is that there is nothing like a line being "redraw", it's just that the line would be partially blanked, depending on when the register write occured

and that's the only reason why I limited the "redraw" thing in genesis plus to the blanking area (and not only the blanking flag as you say), which is anywhere outside active display (ie 860MCLK) because I consider that if the register writes occurs during this period, active display has NOT started to be displayed yet so it's "safe" to completely redraw the line according to the new display setting....

I didn't found any game enabling/disabling the display during active display that's why I had no need to handle VDP rendering in a more accurate but slower way (two-cells based for example)

and MickeyMania is no exception, ALL register writes that enable/disable the display occurs during Hblanking, removing the hblank period test did not change anything to me, still works perfectly with those timings (to be fair, line & Hint actually starts at Hcounter=0xA5, not 0xA7 but I don't think it is really important)

Image

Image

maybe you could post a picture of what's wrong with your emulator, this is not necesseraly due to what you're thinking

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

Post by mickagame » Tue Mar 17, 2009 9:41 pm

With line & Hint starts at Hcounter=0xA5 and no hblank flag test it works, not with 0xA7 !!!

With 0xA7 i have this :
Image

With 0xA5 i have this :
Image

Have you the possibility to test with 0xA7 and no hblank flag test?
Last edited by mickagame on Tue Mar 17, 2009 9:56 pm, edited 1 time in total.

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

Post by Eke » Tue Mar 17, 2009 9:53 pm

EDIT: you're right, with 0xa7 i got the same result as you

but taht does not mean necesseraly that Hcounter values are right or wrong, could be something else :wink:

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

Post by mickagame » Tue Mar 17, 2009 10:03 pm

I don't disassemble mickey mania yet but do you know how the game use the h-counter value?

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

Post by TascoDLX » Wed Mar 18, 2009 6:23 am

Mickey Mania @ 0x1AC2A:

Code: Select all

; a0 = 0xC00009, a4 = 0xFF0584, a6 = 0xC00004
; d0 = 0x88, d2 = 0x8134C000, d3 = 0x00808164, d7 = 0x006D
@A: CMP.B  (a0),d0
    BHI    @A              ; wait until h-counter exceeds 0x88
    MOVE.W (a2)+,(a6)
    MOVE   (a2)+,(a6)
    MOVE   (a2)+,(a6)      ; (dma length 16 words) (dma source FF0584)
    MOVE   d2,(a6)
    MOVE   d3,(a6)         ; (display off, dma on) (dma copy to cram 0000) (display on, dma off)
    MOVE   a1,a4
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+
    MOVE   (a3)+,(a4)+     ; copy 16 words from buffer to FF0584
    LEA    -32(a3),a3
    ADDA.W (a5)+,a3        ; add to buffer ptr
    CMPA   #0xFFFF9A40,a3
    BLT    @B
    SUBA   #0x2800,a3      ; wrap ptr if neccesary
@B: LEA    -10(a2),a2
    NOP
    NOP
    DBF    d7,@A           ; loop executes 110 times (once per line in the affected area)
    ...

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

Post by mickagame » Wed Mar 18, 2009 8:25 am

So i think this come from the delay between h-counter = 0x88 and h-int (corresponding to v-counter increment).
The delay is too long so display is switched off during the current line (so my emulator is blanking the entire line).
But I think Eke you're right if display is switched on/off outside the display area this will take effect on the next line.
So i consider this timings are ok.

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

Post by Eke » Wed Mar 18, 2009 9:02 am

So i think this come from the delay between h-counter = 0x88 and h-int (corresponding to v-counter increment).
The delay is too long so display is switched off during the current line (so my emulator is blanking the entire line).
not exactly
from the disassembling, DMA occurs once Hcounter has reached 0x88. Hint event has nothing to deal with it, it could have happen at any moment before, display OFF & DMA starts is synchronized with hcount=0x88 in all cases.

what it shows is that at the time display is disabled (which is Hcount=0x88 + DMA register writes length) display should be in Hblank

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

so it only tells you that the relation between Hblank period and Hcounter is not correct in the emulator

here's the debugging ouput I got:

Code: Select all

176(86319): VDP HVC read --> 0xb08c (0001ac2c)
176(86335): VDP register 19 write --> 0x10 (0001ac30)
*** LINE 36(86347 / 86340 cycles) ***
177(86347): HINT (OFF) pending (0001ac30)
177(86347): VDP register 20 write --> 0x0 (0001ac32)
177(86347): VDP register 21 write --> 0xc2 (0001ac32)
177(86367): VDP register 22 write --> 0x82 (0001ac34)
177(86367): VDP register 23 write --> 0x7f (0001ac34)
177(86387): VDP register 1 write --> 0x34 (0001ac36)
177(86387): VINT enabled, DISPLAY OFF (0001ac36)
177(86387): redraw line  (0001ac36)
177(86399): DMA type 1 --> 180 bytes (16 bytes left) (0001ac38)
177(86437): DMA freeze 38 cycles (0001ac38)
177(86437): VDP register 1 write --> 0x64 (0001ac38)
177(86437): VINT enabled, DISPLAY ON (0001ac38)
177(86437): redraw line  (0001ac38)
177(86683): VDP HVC read --> 0xb156 (0001ac2c)
177(86701): VDP HVC read --> 0xb15e (0001ac2c)
177(86719): VDP HVC read --> 0xb166 (0001ac2c)
177(86737): VDP HVC read --> 0xb16d (0001ac2c)
177(86755): VDP HVC read --> 0xb175 (0001ac2c)
177(86773): VDP HVC read --> 0xb17d (0001ac2c)
177(86791): VDP HVC read --> 0xb185 (0001ac2c)
177(86809): VDP HVC read --> 0xb18d (0001ac2c)
177(86825): VDP register 19 write --> 0x10 (0001ac30)
177(86837): VDP register 20 write --> 0x0 (0001ac32)
177(86837): VDP register 21 write --> 0xc2 (0001ac32)
177(86857): VDP register 22 write --> 0x82 (0001ac34)
177(86857): VDP register 23 write --> 0x7f (0001ac34)
*** LINE 36 (86877 / 86864 cycles) ***
178(86877): VDP register 1 write --> 0x34 (0001ac36)
178(86877): VINT enabled, DISPLAY OFF (0001ac36)
178(86877): redraw line  (0001ac36)
178(86889): DMA type 1 --> 194 bytes (16 bytes left) (0001ac38)
178(86927): DMA freeze 38 cycles (0001ac38)
178(86927): VDP register 1 write --> 0x64 (0001ac38)
178(86927): VINT enabled, DISPLAY ON (0001ac38)
the game does not use Hint, only Hcounter to know when Hblank has started so it can trigger a short display OFF/DMA operation between 2 lines

here's the debugging output with line starting at 0xA7

Code: Select all

*** LINE 39 (79068 / 79056 cycles) ***
162(79068): VDP register 1 write --> 0x34 (0001ac36)
162(79068): VINT enabled, DISPLAY OFF (0001ac36)
162(79068): redraw line  (0001ac36)
162(79080): DMA type 1 --> 194 bytes (16 bytes left) (0001ac38)
162(79118): DMA freeze 38 cycles (0001ac38)
162(79118): VDP register 1 write --> 0x64 (0001ac38)
162(79118): VINT enabled, DISPLAY ON (0001ac38)
162(79118): redraw line  (0001ac38)
162(79364): VDP HVC read --> 0xa259 (0001ac2c)
162(79382): VDP HVC read --> 0xa260 (0001ac2c)
162(79400): VDP HVC read --> 0xa268 (0001ac2c)
162(79418): VDP HVC read --> 0xa270 (0001ac2c)
162(79436): VDP HVC read --> 0xa278 (0001ac2c)
162(79454): VDP HVC read --> 0xa280 (0001ac2c)
162(79472): VDP HVC read --> 0xa287 (0001ac2c)
162(79490): VDP HVC read --> 0xa28f (0001ac2c)
162(79506): VDP register 19 write --> 0x10 (0001ac30)
*** LINE 39:(79518 / 79508 cycles) ***
163(79518): HINT (OFF) pending (0001ac30)
163(79518): VDP register 20 write --> 0x0 (0001ac32)
163(79518): VDP register 21 write --> 0xc2 (0001ac32)
163(79538): VDP register 22 write --> 0x82 (0001ac34)
163(79538): VDP register 23 write --> 0x7f (0001ac34)
163(79558): VDP register 1 write --> 0x34 (0001ac36)
163(79558): VINT enabled, DISPLAY OFF (0001ac36)
163(79558): redraw line  (0001ac36)
163(79570): DMA type 1 --> 178 bytes (16 bytes left) (0001ac38)
163(79608): DMA freeze 38 cycles (0001ac38)
163(79608): VDP register 1 write --> 0x64 (0001ac38)
163(79608): VINT enabled, DISPLAY ON (0001ac38)
163(79608): redraw line  (0001ac38)
163(79854): VDP HVC read --> 0xa35a (0001ac2c)
163(79872): VDP HVC read --> 0xa361 (0001ac2c)
163(79890): VDP HVC read --> 0xa369 (0001ac2c)
163(79908): VDP HVC read --> 0xa371 (0001ac2c)
163(79926): VDP HVC read --> 0xa379 (0001ac2c)
163(79944): VDP HVC read --> 0xa380 (0001ac2c)
163(79962): VDP HVC read --> 0xa388 (0001ac2c)
163(79978): VDP register 19 write --> 0x10 (0001ac30)
163(79990): VDP register 20 write --> 0x0 (0001ac32)
163(79990): VDP register 21 write --> 0xc2 (0001ac32)
163(80010): VDP register 22 write --> 0x82 (0001ac34)
163(80010): VDP register 23 write --> 0x7f (0001ac34)
163(80030): VDP register 1 write --> 0x34 (0001ac36)
163(80030): VINT enabled, DISPLAY OFF (0001ac36)
163(80030): NOT redraw line (0001ac36)
*** LINE 39 (80042 / 80032 cycles) ***
164(80042): DMA type 1 --> 200 bytes (16 bytes left) (0001ac38)
164(80080): DMA freeze 38 cycles (0001ac38)
164(80080): VDP register 1 write --> 0x64 (0001ac38)
164(80080): VINT enabled, DISPLAY ON (0001ac38)
164(80080): redraw line  (0001ac38)
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.

As you can see, if the last values being read would have been 0x87 instead of 0x88, there would have been an additional read and the display would have been switched OFF on the next line like before.

The conclusion is that it is not only a matter of correct Hcounter, it is also a matter on HOW and WHEN you are rendering the line. 0xA7 might be a correct value on the real thing but on a line-based emulator, the timings probably need to be more optimistic and leave some room for approximations like that...
mickagame wrote: But I think Eke you're right if display is switched on/off outside the display area this will take effect on the next line.
So i consider this timings are ok.
No, I didn't say that, I said the contrary: most probably, enabling/disabling the display can have immediate (mid-line) effect

And as I showed above, you can NOT tell timings are right or wrong just because they don't work in emulators... it can be a lot of other things that would impact timings and that are not emulated or only partially emulated.

What you CAN say is that in your emulator which starts the line with hint event, Hcounter apparently should began at 0xA5... but this does not mean that on the real thing, Hint occurs necessarely at Hcount=0xa5... see the difference ?

An alternate way to do would be to have the exact same piece of code (for example, a loop reading Hcounter in Hint routine like Jorge Nuno did) running on both emulator / real hardware and then adjusting your Hcounter table offset to match real hardware... because at the end, what matters in our case is to match real hardware output, even if the emulation is not exactly accurate

The purpose of the topic however is to know the VDP exact timings which can unfortunately only be speculated by tests with emulators...
Last edited by Eke on Wed Mar 18, 2009 10:09 am, edited 1 time in total.

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

Post by notaz » Wed Mar 18, 2009 10:08 am

Eke wrote: No, I didn't say that, I said the contrary: most probably, enabling/disabling the display can have immediate (mid-line) effect
Yeah, and this is where most (all?) emulators could fail, as they have line-based rendering. Fortunately no games seem to be messing with stuff in the middle of line, but I know other systems have games that do. Some NES game switches VRAM banks during the line and causes tiles to be fetched from different ROM in the middle of the screen then on the left part.

Post Reply