TV safe area

LocalH · Post by **LocalH** » Tue Oct 02, 2007 7:22 am

Eke wrote:Thanks a lot
I guess this will help me emulating those borders properly: actually on the Gamecube, any 320(or 256) x 224(or 240) genesis display is scaled by the GC hardware to 640*480, without differencing PAL & NTSC, which is not completely accurate in term or ratio I imagine

For proper aspect, I'd recommend using a 352x240/288 buffer for H40 modes, and letting the GC scale to 640x480 (you'll see the border, but since the GC does overscan by default that is likely to be hidden). Render your Genesis display to the center 320x224/240 of said buffer (most released games used 224 line mode so that's not likely to be a major problem). Unused pixels in the "border" should be set to the color pointed to by VDP register $07, and this should be done on a line-by-line basis (since changing $07 mid-screen does change the border color too).

I'm not 100% sure of what the equivalent buffer should be for H32 modes - 352/320=1.1*256=281.6 which I'd round to 282, so try 282x240/288.

Eke · Post by **Eke** » Tue Oct 02, 2007 1:50 pm

thanks again... how do you know that the active witdh is 352 pixels in H40 mode ?
anyway, that's effectively how I planned to do, I especially wanted to see those vertical borders when the emulated genesis run in PAL mode but accurate ratio is also something important

about H32 mode, the SMS VDP references (TMS9918 datasheet and smsvdp.txt by Charles Mac Donald) state that the border witdh is 13 pixels on the left and 15 pixels on the right, which would give us 256+28=284 pixels of "active" display

the only thing I wonder is if there is a difference between PAL and NTSC line width as I know that scanline duration in both standard are not exactly the same

some interesting links I found about video standards (for newbies like me

)

http://www.kolumbus.fi/pami1/video/pal_ntsc.html
http://lipas.uwasa.fi/~f76998/video/modes/

LocalH · Post by **LocalH** » Tue Oct 02, 2007 6:06 pm

Well, I'm going by the fact that the Genesis pretty much takes up 704 pixels of the industry standard 720x480, and to me the those 704 pixels look damn close to exactly doubled - see the vertical artifacts alternate every other two pixels. Also, here's a screen capture resized down to 352x240 - other than the obvious blurring from RF capture, the pixels don't look uneven across the image (for example, look at the two E's in "THE ECHIDNA", the two 1's and 9's in the SEGA copyright, and the two HEs in "THE HEDGEHOG"):

So, either that measurement is exactly off 1 pixel for every 8 across, or it's close enough for practical use.

tomaitheous · Post by **tomaitheous** » Tue Oct 02, 2007 9:15 pm

Did you miss the formula that I posted?

40 CELL mode uses a 6.7125Mhz dot clock and 32 CELL mode uses a 5.37mhz dot clock. That's what defines the "width" of a pixel for determining correct pixel aspect ratio and overscan area.

6.7125mhz/ 15735hz = 426 dot clock(pixel) length scanline / 1.186 (not displayable part of line, i.e. hblank/sync) = 360 displayable pixels. 360/1.125(for clipping) = 320 non-border pixels.

5.37mhz/ 15735hz = 341 / 1.186 = 288 pixels / 1.125(VDP clipping) = 256pixels.

It doesn't scale or fit the pixels into a 720 (13.425mhz) scanline. 720 is a standard, not a limit. A scanline is infinite in resolution since it's an analog signal. Actually most consumer grade TVs can not even show a true 720pixel line from an input source. The 13.425mhz signal is out of the range of composite,s-video, and RF. Even most SDTV(480i) and EDTV(480i) component output isn't 13.5mhz, and most low-to-mid grade sets won't *translate* all the detail from that frequency anyway.

evildragon · Post by **evildragon** » Tue Oct 02, 2007 9:54 pm

tomaitheous wrote:Did you miss the formula that I posted?

40 CELL mode uses a 6.7125Mhz dot clock and 32 CELL mode uses a 5.37mhz dot clock. That's what defines the "width" of a pixel for determining correct pixel aspect ratio and overscan area.

6.7125mhz/ 15735hz = 426 dot clock(pixel) length scanline / 1.186 (not displayable part of line, i.e. hblank/sync) = 360 displayable pixels. 360/1.125(for clipping) = 320 non-border pixels.

5.37mhz/ 15735hz = 341 / 1.186 = 288 pixels / 1.125(VDP clipping) = 256pixels.

It doesn't scale or fit the pixels into a 720 (13.425mhz) scanline. 720 is a standard, not a limit. A scanline is infinite in resolution since it's an analog signal. Actually most consumer grade TVs can not even show a true 720pixel line from an input source. The 13.425mhz signal is out of the range of composite,s-video, and RF. Even most SDTV(480i) and EDTV(480i) component output isn't 13.5mhz, and most low-to-mid grade sets won't *translate* all the detail from that frequency anyway.

Finally, someone who truly understands a CRT.

My SDTV's show about 500px width, that's it.. My HDTV (CRT) shows only 850 (which totally bombs, but atleast my vertical res is full)

LocalH · Post by **LocalH** » Wed Oct 03, 2007 5:59 am

tomaitheous wrote:It doesn't scale or fit the pixels into a 720 (13.425mhz) scanline. 720 is a standard, not a limit.

Right, but it's a useful standard, since 704 of those 720 columns, at standard NTSC PAR, are directly equivalent to 640 columns at 1:1 PAR. Thus, since the discussion was on the Gamecube which stretches the buffer to 640x480, it's a useful metric, albeit not as accurate as the calculations. I already knew that NTSC is inherently analog, and that resolution is theoretically infinite given enough bandwidth and a display device that can handle the transitions.

So by your calculations, H40 is 360x240 or 360x288 with the center 320x224 or (for PAL V32) 320x240 being the addressable screen, while H32 is 288x240 or 288x288 with the center 256x224 or (for PAL V32) 256x240 being the addressable screen. Of course, when converting those horizontal values into other PARs, you'll need to know the PAR of the Genesis video in both H modes. I seem to remember that I had calculated them at some point, and I think in H40 pixels are 10:11 (0.9090~, which as far as I know is the exact same PAR as NTSC DV at 720x480, hence the nice correlation between my DV capture and the artifacting, since noninterlaced Genesis pixels would be twice as big in both directions as interlaced DV), and in H32 they're similar to NES pixels, which are 40:33 (1.2121~). Of course, pixels in interlace 2 are half-height and thus twice as wide as the corresponding noninterlace/interlace 1 pixels (which would be 20:11 for H40 and 80:33 for H32).

Also, the additional pixels aren't "clipped", they're filled with the backdrop register, and is changeable at any point in the frame, even mid-line (if you're in the top or bottom border when you change it).

evildragon · Post by **evildragon** » Wed Oct 03, 2007 6:46 am

But, doesn't an analog CRT TV technically NOT have pixels?

That's what keeps getting said, only "lines".

Shiru · Post by **Shiru** » Wed Oct 03, 2007 8:02 am

CRT, TFT, etc.. does not matter. Only TV standart (timings etc) matter. Pixels defined by pixelclock in width and by timing for lines in height.

Eke · Post by **Eke** » Wed Oct 03, 2007 8:31 am

tomaitheous wrote:Did you miss the formula that I posted?

40 CELL mode uses a 6.7125Mhz dot clock and 32 CELL mode uses a 5.37mhz dot clock. That's what defines the "width" of a pixel for determining correct pixel aspect ratio and overscan area.

6.7125mhz/ 15735hz = 426 dot clock(pixel) length scanline / 1.186 (not displayable part of line, i.e. hblank/sync) = 360 displayable pixels. 360/1.125(for clipping) = 320 non-border pixels.

5.37mhz/ 15735hz = 341 / 1.186 = 288 pixels / 1.125(VDP clipping) = 256pixels.

It doesn't scale or fit the pixels into a 720 (13.425mhz) scanline. 720 is a standard, not a limit. A scanline is infinite in resolution since it's an analog signal. Actually most consumer grade TVs can not even show a true 720pixel line from an input source. The 13.425mhz signal is out of the range of composite,s-video, and RF. Even most SDTV(480i) and EDTV(480i) component output isn't 13.5mhz, and most low-to-mid grade sets won't *translate* all the detail from that frequency anyway.

I didn't miss it but have some questions about your pixel calculations:

1/ how do you get that the pixel clock is the main clock (5.3693175 Mhz) divided by 8 in H40 ? The x10 factor in H32 mode seems fine as it is compatible with Charles Mc Donald's tests on the SMS.

2/ how do you know for sure that the VDP line frequency is 15735hz (which is, from what I read, the specific NTSC line frequency). For example, in the original TMS9918 doc (working in H32 mode), the line period is specified to be 63.69 us (ie 15700Hz): this is compatible with the fact that both this doc and McDonald's tests say that the maximum number of pixel per line is 342 in this mode (not 341), i.e the line frequency is 53693175/10/342 = 15700Hz. I doubt that the VDP line frequency would change between h40 and h32, only the pixel clock change.

3/ next, about htotal/hsync ratio: again, in the TMS9918 docs, the timings are described to be as following:
63.695 us for the line (342 pixels)
43.67 us for active display (256 pixels)
2.42 us for right border (13 pixels)
2.8 us for left border (15 pixels)
the rest is for hsync/hblank/color burst

this give us 284pixels out of 342 and a 1.21 ratio, which is more like the specified NTSC timings (nominal line period = 63.5555 us , Line-blanking interval = 10.9 us)

with this in mine and supposing the H40/H32 ratio is 5/4, I calculated:
NTSC resolutions:
284x240 pixels in H32 mode
356x240 pixels in H40 mode

4/ finally, what about PAL mode ? Should the max number of pixels per line remain constant ? this would mean, if the clock dividers do not change, that the VDP line frequency in PAL mode is slower, in order to compensate a slower pixel clock (pal main clock is 5.3203424 Mhz)
Secondly, aren't the hdisplay/hsync ratio different between NTSC and PAL formats ?

sorry to bother you with all those question, I'm in a complete learning stage about this subject so maybe I misunderstood some video concepts

PS: I made some test with a megadrive model 2 (PAL) that I modded to 60Hz: it appears my TV set (a 28" sony CRT) does not show any top/bottom borders but show the right side border quite completely (it's like the image is shifted to the left, not centered)

tomaitheous · Post by **tomaitheous** » Thu Oct 04, 2007 2:02 am

1/ how do you get that the pixel clock is the main clock (5.3693175 Mhz) divided by 8 in H40 ? The x10 factor in H32 mode seems fine as it is compatible with Charles Mc Donald's tests on the SMS.

The main crystal is 53.69mhz. Divide by 10 to get 5.37mhz and divide by 8 to get 6.7125mhz.

2/ how do you know for sure that the VDP line frequency is 15735hz (which is, from what I read, the specific NTSC line frequency). For example, in the original TMS9918 doc (working in H32 mode), the line period is specified to be 63.69 us (ie 15700Hz): this is compatible with the fact that both this doc and McDonald's tests say that the maximum number of pixel per line is 342 in this mode (not 341), i.e the line frequency is 53693175/10/342 = 15700Hz. I doubt that the VDP line frequency would change between h40 and h32, only the pixel clock change.

I don't know for sure. I've seen a line vary in length, but not that much. I'll ask Charles if he tested/measured the line with an oscope. Patents and docs are known to be wrong. I can test it myself if it's that important. As for 342 isn't too far off from 341 considering all the rounding involved

3/ next, about htotal/hsync ratio: again, in the TMS9918 docs, the timings are described to be as following:
63.695 us for the line (342 pixels)
43.67 us for active display (256 pixels)
2.42 us for right border (13 pixels)
2.8 us for left border (15 pixels)
the rest is for hsync/hblank/color burst

this give us 284pixels out of 342 and a 1.21 ratio, which is more like the specified NTSC timings (nominal line period = 63.5555 us , Line-blanking interval = 10.9 us)

with this in mine and supposing the H40/H32 ratio is 5/4, I calculated:
NTSC resolutions:
284x240 pixels in H32 mode
356x240 pixels in H40 mode

It's possible the front or back porch is slight longer on the TMS chips verses other chips with a 5.37mhz dot clock. But still, I think the maximum allowable/displayable pixels for a 15735hz scanline @ 5.37mhz dot clock is 288(287.x). Though either way, the dot clock "width" is still the same and you can base pixel aspect ratio from that with centering/clipping, which neither effects the ratio.

Btw, what's the dot clock width for the GC? Stated 640x480 doesn't give enough info.

4/ finally, what about PAL mode ? Should the max number of pixels per line remain constant ? this would mean, if the clock dividers do not change, that the VDP line frequency in PAL mode is slower, in order to compensate a slower pixel clock (pal main clock is 5.3203424 Mhz)
Secondly, aren't the hdisplay/hsync ratio different between NTSC and PAL formats ?

sorry to bother you with all those question, I'm in a complete learning stage about this subject so maybe I misunderstood some video concepts

PS: I made some test with a megadrive model 2 (PAL) that I modded to 60Hz: it appears my TV set (a 28" sony CRT) does not show any top/bottom borders but show the right side border quite completely (it's like the image is shifted to the left, not centered)

I do remember there being slight difference in horizontal line length between NTSC and PAL, but I don't remember off hand what it is. Sorry, but I'm not much help on the PAL format. Though the formula is the same, I just don't know PAL in detail.

So by your calculations, H40 is 360x240 or 360x288 with the center 320x224 or (for PAL V32) 320x240 being the addressable screen, while H32 is 288x240 or 288x288 with the center 256x224 or (for PAL V32) 256x240 being the addressable screen. Of course, when converting those horizontal values into other PARs, you'll need to know the PAR of the Genesis video in both H modes. I seem to remember that I had calculated them at some point, and I think in H40 pixels are 10:11 (0.9090~, which as far as I know is the exact same PAR as NTSC DV at 720x480, hence the nice correlation between my DV capture and the artifacting, since noninterlaced Genesis pixels would be twice as big in both directions as interlaced DV), and in H32 they're similar to NES pixels, which are 40:33 (1.2121~). Of course, pixels in interlace 2 are half-height and thus twice as wide as the corresponding noninterlace/interlace 1 pixels (which would be 20:11 for H40 and 80:33 for H32).

Yup - 720x480 is a 13.42MHZ dot clock - exactly twice the dot clock of 40 cell mode. The NES, SMS, SNES, and PCE(TG16) all use the 5.37mhz pixel clock. Well- PCE low res is 5.37mhz, the two others are 7.16mhz and 10.74mhz.

Also, the additional pixels aren't "clipped", they're filled with the backdrop register, and is changeable at any point in the frame, even mid-line (if you're in the top or bottom border when you change it).

Same difference. It's still clipping sprite/BG layers regardless of the width setting

Eke · Post by **Eke** » Thu Oct 04, 2007 9:51 am

I don't know for sure. I've seen a line vary in length, but not that much. I'll ask Charles if he tested/measured the line with an oscope. Patents and docs are known to be wrong. I can test it myself if it's that important. As for 342 isn't too far off from 341 considering all the rounding involved

If you have such equipment, this would be really useful to have the genesis display timings (even if it is only for NTSC). As far as I know, Charles McDonald only did it for the NTSC SMS Model 1. He measured the scanline, between two rising edges of /HSYNC to be 684 MCLK (MCLK = 10.738580 Mhz for SMS 1) which is approx. 15700Hz
It would be great to know if the same timings apply to Genesis H32 mode (probably) and even more interesting to determine the timings in H40 mode.

evildragon · Post by **evildragon** » Thu Oct 04, 2007 3:14 pm

This was an excuse to use my oscilloscope.

I don't know how to use the stupid thing.

(I measured the H-Sync pin on the cartridge connector)

NTSC 320
http://blackevilweredragon.spymac.com/S ... tsc320.PNG

NTSC 256
http://blackevilweredragon.spymac.com/S ... tsc256.PNG

PAL 320
http://blackevilweredragon.spymac.com/S ... pal320.PNG

PAL 256
http://blackevilweredragon.spymac.com/S ... pal256.PNG

TmEE co.(TM) · Post by **TmEE co.(TM)** » Thu Oct 04, 2007 4:34 pm

These don't show to be very useful... zoom into the wave...

evildragon · Post by **evildragon** » Thu Oct 04, 2007 4:52 pm

This is as far as it will go, and it doesn't look very reliable at this level.

NTSC 320
http://blackevilweredragon.spymac.com/320n.png

NTSC 256
http://blackevilweredragon.spymac.com/256n.PNG

PAL 320
http://blackevilweredragon.spymac.com/320p.PNG

PAL 256
http://blackevilweredragon.spymac.com/256p.PNG

I have no idea what this was, it was supposed to be NTSC 256.
http://blackevilweredragon.spymac.com/256n2.PNG

(EDIT: I have no freakin clue why each picture moved down my video cards framebuffer like that in the screenshot.. wasn't like that on the screen)

Fonzie · Post by **Fonzie** » Thu Oct 04, 2007 5:01 pm

It is a utility that read the microphone values of your soundcart?
Nice idea

Strange that you don't get so so precises values... maybe 44000hz don't do it for Hsync?.