Megadrive video timings

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

Moderators: BigEvilCorporation, Mask of Destiny

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

Post by Eke » Fri Jan 08, 2010 2:52 pm

HardWareMan wrote:
tomaitheous wrote:Also, what are the steps in voltage in those charts? And in reference, how does the brightest white compare to say other RGB outputs (like vga, or amiga, etc)? I would like to get a reference as to how close 0xEEE is relative to 24bit 0xFFFFFF.
You have Ultrascope. When you open waveform, you can turn on cursors. They will show you voltage. Then, you must make measurements and get delta from black level. If we assume black level as 0% and white level as 100%, you can calculate percentage of every color level and lay it on byte of computer's truecolor depth. Understand?
I measured this (in V):

Code: Select all

 Shadow   Highli    Normal 
-------- -------- ---------   
(0) 0.0             0.0 (0)
(1) 0.5            
(2) 0.9             0.9 (1)
(3) 1.3 
(4) 1.6             1.6 (2)
(5) 1.9 
(6) 2.2             2.2 (3)
(7) 2.4   (0) 2.4
          (1) 2.7   2.7 (4)
          (2) 2.9
          (3) 3.2   3.2 (5)
          (4) 3.5
          (5) 3.8   3.8 (6)
          (6) 4.2
          (7) 4.7   4.7 (7)
It seems quite symetrical steps to me, considering signal noise..

I'm also wondering, could we assume that pure white would be at +5V (considering AGC and AVC are some kind of reference signals) ?

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Fri Jan 08, 2010 11:51 pm

Eke: thanks, that's what I was looking for. So max white is 4.7v.

If we did assume max white for RGB was 5v, then that would put max white as ~239 if scaled to 24bit values. That seems to fit the steps by 34 setup for scaling.

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

Post by TmEE co.(TM) » Sat Jan 09, 2010 12:18 pm

Here's small example of the slight differences in the highlight :
RGB:
http://www.fileden.com/files/2008/4/21/ ... arsRGB.jpg
S-video (using TV's sharpness setting to enhance the effect a bit) :
http://www.fileden.com/files/2008/4/21/ ... erence.jpg

And a photo of the newer SHL test results :
http://www.fileden.com/files/2008/4/21/ ... result.jpg

and from a PC LCD :
http://www.fileden.com/files/2008/4/21/ ... romLCD.jpg
with one of these :
http://www.fileden.com/files/2008/4/21/ ... Dsetup.jpg
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

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

Post by notaz » Sat Jan 09, 2010 1:13 pm

It's not really visible after it passes through compo(site/shite) conversion:

Image

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

Post by Eke » Sat Jan 09, 2010 2:51 pm


Here's small example of the slight differences in the highlight :
RGB:
http://www.fileden.com/files/2008/4/21/ ... arsRGB.jpg
S-video (using TV's sharpness setting to enhance the effect a bit) :
http://www.fileden.com/files/2008/4/21/ ... erence.jpg
The thing is that on the signal recording (directly from VDP output, right ?), there isn't any noticeable differences in the voltage level. There is indeed some voltage drop or jump which result in a tiny separation between bars (some time darker, some time lighter) that gives the impression color changes but they are the same. The tiny voltage variation is probably due to the VDP internally switching between highlight & normal.
HardWareMan wrote:Now I have an oscilloscope too. I'd made some records of EDCLK singnal. Take a look:
Image
Image
Image
You can take full record here (use UltraScope for viewing).
Now, it's look like EDCLK more complex, than we think. So, what do you think?
I looked into this and it indeed seems that there are 60 EDCLK at MCLK/5 during a line, like Jorge Nuno measured but that these clocks are "interrupted" by MCLK/4 clocks, like this:

15 cycles @MCLK/5
2 cycles @MCLK/4
15 cycles @MCLK/5
2 cycles @MCLK/4
15 cycles @MCLK/5
2 cycles @MCLK/4
15 cycles @MCLK/5


It seems that HSYNC signal is what triggers the changes in EDCLK frequency, with some latency though.

The total is still 840 EDCLKS (420 pixels) with 780 @MCLK/4 and 60@MCLK/5 (total is 3420 MCLCKS).

HardWareMan
Very interested
Posts: 727
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sat Jan 09, 2010 4:10 pm

I think this dots are caused by EDCLK. Just thoughs...
Image

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

Post by TmEE co.(TM) » Sat Jan 09, 2010 4:29 pm

2 missing ones in every 64 pixel "zone".....

the dots are VDP CRAM writes there, each pixel being in color the color getting into written CRAM... in that case, things are transferred via DMA, each dot represents one "access slot".
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

HardWareMan
Very interested
Posts: 727
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Mon Jan 11, 2010 4:49 am

I made record of control bus signals of VRAM (SE0, SC, RAS1, CAS1, WE0, OE1) in last scanline interval of gradient ladder of TmEE SHLTEST. But, Ultrascope allows show only 2 signals, and we need to show 7. Maybe, I can load it as RAW sound data in multitrack sound editor? Any thoughs?

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

Post by Snake » Thu Jan 14, 2010 12:07 am

TmEE pointed me at this thread, and I read this:
tomaitheous wrote:To clear up S/H, normal once and for all? I've heard that S/H fits nicely into a 12 bit palette and that S/H just adjust the step increments. But I've also read that idea/method this doesn't display right for all games.
... and thought 'ah, this old argument again...' - but now I've read the rest of it.

Clearly, S/H mode does indeed basically (almost) double the number of colours, and the 'doesnt display right for all games' thing is just wrong. I tested this way back in the KGen days.

But, on my crappy old TV, through RF no less :P - it looked like the crossover point from normal to highlight was at 0x888 - and since that made perfect sense, that's what I did. From Hardwaremans posts its clear the crossover point is actually at 0x777. No big deal, but nice to know :)

TmEE - fix your program so it displays this properly on real hardware please :)

While I'm here:
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
well, according to the 68k user manual, Bus Access is granted between memory cycles so theorically, this could happen.

but you are right, VDP reaction is not immediate
Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.

Graz
Very interested
Posts: 81
Joined: Thu Aug 23, 2007 12:36 am
Location: Orlando, FL

Post by Graz » Thu Jan 14, 2010 12:40 am

Another thing I documented a long time ago.
Any chance that documentation is available for us to read?

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

Post by Snake » Thu Jan 14, 2010 12:44 am

It was all posted on a devchannel set up by (I believe) Charles Macdonald, and I don't know if it's still around. I did keep notes of a lot of this stuff but then lost it :evil: However, pretty much every emulator out there since then handles all the stuff I found.

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

Post by mickagame » Thu Jan 14, 2010 6:51 am

Snake wrote:TmEE pointed me at this thread, and I read this:
tomaitheous wrote:To clear up S/H, normal once and for all? I've heard that S/H fits nicely into a 12 bit palette and that S/H just adjust the step increments. But I've also read that idea/method this doesn't display right for all games.
... and thought 'ah, this old argument again...' - but now I've read the rest of it.

Clearly, S/H mode does indeed basically (almost) double the number of colours, and the 'doesnt display right for all games' thing is just wrong. I tested this way back in the KGen days.

But, on my crappy old TV, through RF no less :P - it looked like the crossover point from normal to highlight was at 0x888 - and since that made perfect sense, that's what I did. From Hardwaremans posts its clear the crossover point is actually at 0x777. No big deal, but nice to know :)

TmEE - fix your program so it displays this properly on real hardware please :)

While I'm here:
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
well, according to the 68k user manual, Bus Access is granted between memory cycles so theorically, this could happen.

but you are right, VDP reaction is not immediate
Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.
Very interesting !!!
It could explain the special effect from mickey mania?

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

Post by Eke » Thu Jan 14, 2010 10:05 am

Very interesting !!!
It could explain the special effect from mickey mania?
Not really, this issue is probably more related to the way VDP is processing sprites during HBLANK: when display is disabled, sprite processing is very likely also disabled and the result is that only some of the sprites will be processed for the upcoming line (in Mickeymania, the first 5 sprites with xpos=0 are processed, you could eventually relates this to the number of clocks during which display is disabled).

The only way to know exact timings would be to spy those VRAM bus signals and see how, when and what stuff are fetched from VRAM :wink:

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sun Jan 17, 2010 6:30 am

Snake wrote:TmEE pointed me at this thread, and I read this:
tomaitheous wrote:To clear up S/H, normal once and for all? I've heard that S/H fits nicely into a 12 bit palette and that S/H just adjust the step increments. But I've also read that idea/method this doesn't display right for all games.
... and thought 'ah, this old argument again...' - but now I've read the rest of it.

Clearly, S/H mode does indeed basically (almost) double the number of colours, and the 'doesnt display right for all games' thing is just wrong. I tested this way back in the KGen days.

But, on my crappy old TV, through RF no less :P - it looked like the crossover point from normal to highlight was at 0x888 - and since that made perfect sense, that's what I did. From Hardwaremans posts its clear the crossover point is actually at 0x777. No big deal, but nice to know :)

TmEE - fix your program so it displays this properly on real hardware please :)

While I'm here:
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
well, according to the 68k user manual, Bus Access is granted between memory cycles so theorically, this could happen.

but you are right, VDP reaction is not immediate
Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.
I don't remember the argument details, but something about brighter than white (which is now known doesn't exist). Not a big deal, but it's nice to know. Matters to me so I can get my colors correct for my apps though :) I'd still like to know what 0xEEE is really is in comparison to 0xffffff (or just 252/252/252). It would be nice to know if steps by 36 are pretty damn close, so I can keep using those :D

Also, on the interrupt/halt in between cycles of an instruction; are they in segments of 4 cycles or as low as 2 cycles?

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

Post by Snake » Sun Jan 17, 2010 6:16 pm

tomaitheous wrote:Not a big deal, but it's nice to know.
Oh, sure, very nice :) But a bit different to what people have been implying to me for a long time, i.e. that the whole thing was way off.
tomaitheous wrote:It would be nice to know if steps by 36 are pretty damn close, so I can keep using those :D
From what I can tell the steps are around 34, so you're pretty close. This was done by outputting from PC to TV and adjusting till it looked right.

However be aware that if you're trying to match the colours on a TV, the NTSC or PAL encoding does, in some cases, make a HUGE difference, and certain colours can look completely different.
tomaitheous wrote:Also, on the interrupt/halt in between cycles of an instruction; are they in segments of 4 cycles or as low as 2 cycles?
I believe it's immediate, I.E. if you write a long in which the high word triggers a DMA, and the low word does something that'd completely break that DMA, the DMA always works as expected, and the final word is written after. Figuring out at exactly which cycle the write is performed isn't easy, but probably doesn't make any difference. At least for every possible instruction I tested it made no difference.

It's a bit naughty anyway and probably shouldn't be used ;)

Post Reply