Confusion with aspect ratios

[+JAC!]

Hi there,

 

assuming I have a PC Image with 640x320 perfectly square pixels. What would be the A8 pixel height/width to make it look identical on a real TV set? I know PAL pixels are not square and I found too many different definitions, so maybe someone here can help.

[+MrFish]

I know PAL pixels are not square...

 

This is an interesting point, and one that I had not considered before in my graphic conversions. NTSC pixels are also not square, so a similar conversion factor could be used here to compensate as well.

 

It looks like the PAL pixel aspect ratio is 12:11. Which means the width of a single PAL pixel is ~1.09090909... times more than the height of the pixel.

 

So, if you multiply the height by the fraction 12/11 or the decimal number ~1.09090909... you can compensate for the difference.

 

This would give you 320 x 175 for an Antic F screen and 160 x 175 for an Antic E screen.

[phaeron]

I think 12:11 is for a 13.5MHz pixel clock, not the rate used by the Atari.

 

Starting from Wikipedia's article on pixel aspect ratio, here's how I derived the aspect ratios used by Altirra:

http://en.wikipedia....el_aspect_ratio

 

For NTSC, we have a square pixel clock rate of 12+3/11MHz. This is for an interlaced image (480i), so for a non-interlaced image the dot clock should be halved to 6.136MHz. GTIA produces high-resolution pixels at a rate of twice the system clock or four times the color subcarrier, 7.15909MHz. 6.136MHz / 7.15909MHz = 0.8571, or pixels that are about 15% narrow.

 

NTSC Amigas use the same dot clock in lores mode, and according to the technical note at http://amigadev.elow...e/node00CB.html, it has a PAR of 44/52 = 0.846, which is in the ballpark.

 

For PAL, the square pixel clock rate is 14.75MHz for 576i, or 7.375MHz for non-interlaced. The system clock is 1.773447MHz, giving a dot clock of 7.093788MHz. Dividing 7.375MHz / 7.093788MHz gives a PAR of 1.039642, which is close enough to square.

 

There seems to be a lot of "close enough" in video engineering, so there's a bit of play in these values even with professional-level equipment and software. 12:11 is supposedly a rounded off version of 59:54.

[roland p]

Double post...

Edited November 7, 2011 by roland p

[roland p]

For PAL, the square pixel clock rate is 14.75MHz for 576i, or 7.375MHz for non-interlaced. The system clock is 1.773447MHz, giving a dot clock of 7.093788MHz. Dividing 7.375MHz / 7.093788MHz gives a PAR of 1.039642, which is close enough to square.

I think it's best to assume the pixels are perfectly square so you won't have weird scaling values.

Edited November 7, 2011 by roland p

[Bryan]

I generally consider a 5x7 or 4x6 grid of 160-mode pixels to be pretty much square in NTSC, but the screen is a bit more squished vertically in PAL.

[+MrFish]

I think 12:11 is for a 13.5MHz pixel clock, not the rate used by the Atari.

 

Starting from Wikipedia's article on pixel aspect ratio, here's how I derived the aspect ratios used by Altirra:

http://en.wikipedia....el_aspect_ratio

 

For NTSC, we have a square pixel clock rate of 12+3/11MHz. This is for an interlaced image (480i), so for a non-interlaced image the dot clock should be halved to 6.136MHz. GTIA produces high-resolution pixels at a rate of twice the system clock or four times the color subcarrier, 7.15909MHz. 6.136MHz / 7.15909MHz = 0.8571, or pixels that are about 15% narrow.

 

For PAL, the square pixel clock rate is 14.75MHz for 576i, or 7.375MHz for non-interlaced. The system clock is 1.773447MHz, giving a dot clock of 7.093788MHz. Dividing 7.375MHz / 7.093788MHz gives a PAR of 1.039642, which is close enough to square.

 

OK, so on NTSC there is still a significant enough difference to warrant using the ratio in conversion. PAL seems close enough. I will try using some of this info for future NTSC graphics conversions.

 

That's one feature that I appreciate about Altirra -- being able to see some difference between PAL and NTSC pixel ratios.

 

I generally consider a 5x7 or 4x6 grid of 160-mode pixels to be pretty much square in NTSC, but the screen is a bit more squished vertically in PAL.

 

Yes, thats the benefit for NTSC systems in Antic E, etc. The pixels are closer to square. It also looks like there is a difference in width between dark and light pixels on NTSC using a CRT. The darker pixels appear to be narrower than the lighter ones.

[Kr0tki]

I can confirm phaeron's computations as valid - I have developed the same pixel aspect ratio values completely independently, for use in Atari800.

 

I think it's best to assume the pixels are perfectly square so you won't have weird scaling values.

When stretching the emulated screen over a high enough display resolution (say 1024x768) any scaling artifacts are hardly visible, even less with bilinear filtering enabled.

Edited November 7, 2011 by Kr0tki

[easyrhyme]

Have small question. This doc says 400/800 has 1:1 PAR because of 5:3 SAR/DAR.

https://en.wikipedia.org/wiki/List_of_common_resolutions

 

Is that because it's being drawn on desktop composite monitor and not NTSC TV? Was software designed for 4:3 or 5:3 ago??

 

Thanks

[Rybags]

The problem with that page - it doesn't take borders into consideration.

 

It puts the ST and Amiga in the same row - the Amiga has a dot clock of ~ 7.2 Mhz, the ST is 8 MHz so at the same resolution of 320x200 the ST display is squashed horizontally vs the Amiga which fills almost all of the horizontal visible screen.

 

Generally with all the old computers, and for that matter consoles as well before they went hidef, the scanline size will be exactly the same so effectively the vertical resolution will be identical (or double if interlaced).

 

The horizontal resolution was generally decided by what clock speed the video chip ran at. These were usually based upon direct ratios of the NTSC colour-clocking rates (e.g. Atari 8-bit, Amiga) but in some cases weren't. e.g. the C64 uses a more complex division system to give a CPU and pixel clock rate that aren't integer fractions of the colour-clocking rate (and likewise Atari ST).

 

So, doing the maths gets all complicated and plus we're dealing with systems that targetted analog CRT TVs and monitors and visible area is an area of contention.

But you can compare relationships between 2 unlike computers, you just have to get into doing formulas which are usually based on master clock speed, how many scanlines the machine generates and how many cycles per scanline are used.

[kenjennings]

I think that wikipedia page is pretty much worthless. The aspect is based on the size of a color clock for the Atari 8-bit and the Amiga OCS chipset (Either multiple of the color clock, or fraction of the color clock), and that page is nowhere close.

 

I had a PDF file with pages of graph paper in the correct aspect ratios somewhere around here. Apparently not on this computer. Grrrr... If I recall correctly a high-res pixel (Atari) (which is low res on Amiga) is 11:13 (NTSC). Therefore, a Mode E pixel one color clock x 1 scanline is 22:13, and a GTIA pixel is 44:13.

[fujidude]

I had a PDF file with pages of graph paper in the correct aspect ratios somewhere around here. Apparently not on this computer. Grrrr...

 

I had several PDF documents with various graph paper. I deleted them though, when I got a program that could custom generate whatever I wanted. If I can make a particular size graph paper for you or get you the program, let me know.

[phaeron]

There are so many errors on that wikipedia page it isn't even funny. Atari 400/800 is wrong, Apple II hires is wrong, VGA is wrong (it's switchable and mode dependent), and I'm pretty sure the C64 VIC-II hires and TMS9918 entries are wrong too. The code on the page computes the pixel aspect ratio from the resolution and the display aspect ratio, which is backwards (the dot clock is usually the known quantity, which gives the PAR and then the DAR). This must be from the same people who keep putting back the broken memcpy example on the 6502 page.

[kenjennings]

 

I had several PDF documents with various graph paper. I deleted them though, when I got a program that could custom generate whatever I wanted. If I can make a particular size graph paper for you or get you the program, let me know.

 

 

Thanks, but I know where my graph paper docs are. (not on this particular computer.)

 

Currently killing zombies on my PC games box. I usually do the 800 stuff on a different laptop.

[OxC0FFEE]

On 9/6/2015 at 8:30 PM, easyrhyme said:

Have small question. This doc says 400/800 has 1:1 PAR because of 5:3 SAR/DAR.

https://en.wikipedia.org/wiki/List_of_common_resolutions

I had forgotten about pixel aspect ratio. This seems to be that ineffable difference between emulation and real hardware that I couldn't put my finger on until just now! It certainly makes a difference to realize that, for graphics and ATASCII art purposes, shapes will be 15% narrower than I intend. No wonder my KLF record looked horizontally squished on a real CRT versus LCD in emulation!

 

I just edited that wikipedia page to add a row for ATARI NTSC with the 6:7 PAR computed from @phaeron's response.

Edited November 29, 2021 by OxC0FFEE
I accidentally a ratio