Amiga aspect ratio

[absence]

http://amigadev.elowar.com/read/ADCD.../node00CB.html claims the pixel aspect ratios on Amiga are 44/52 for NTSC lores and 44/44 for PAL lores, and that the "values are more accurate than the values in the original IFF document". Does anyone know where these numbers come from and how accurate they are? They suggests that a regular 320x256 screen is taller than 4:3, and that 320x200 is slightly shorter, which sounds a bit strange, but could be right for all I know.

[Photon]

Never mind any values, just assume your NTSC picture is stretched to fit, say, 320x200 onto a 4:3 screen.

For PAL, 320x256 is squeezed to fit a 4:3 screen.

Square pixel "native resolution" of a 4:3 screen is 320x240.

The latter is close enough to PAL I think. So I prefer not to bother, and think in terms of square pixels at all times. And for artists it's simple ofc, draw something nice and - done.

F.ex., I have my C1081 set to square pixels, and use square pixels in WinUAE on my 1280x1024 (5:4) LCD.

[absence]

Originally Posted by Photon

Never mind any values

Values are exactly what I'm interested in, I don't have a practical problem that needs fixing. According to the document I linked to, 320x256 is not "squeezed to fit a 4:3 screen", which is what makes me curious about where 44 and 52 come from.

[MagerValp]

The 320x256 area doesn't cover the whole screen (if we're talking CRTs), there's a bit of border as well. On PAL Amigas you typically have a little more space on the sides, compensating for the extra pixels on the top and bottom. Of course, no monitor is ever perfectly square - if you really want to know how yours is set up, draw a 200x200 pixel square and measure it with a ruler. It's close enough that it's not worth worrying about though.

[absence]

Originally Posted by MagerValp

The 320x256 area doesn't cover the whole screen (if we're talking CRTs), there's a bit of border as well. On PAL Amigas you typically have a little more space on the sides, compensating for the extra pixels on the top and bottom. Of course, no monitor is ever perfectly square - if you really want to know how yours is set up, draw a 200x200 pixel square and measure it with a ruler. It's close enough that it's not worth worrying about though.

Square is good enough for me, and the bit about the border makes sense (which means the picture aspect ratio of a non-overscan PAL image is actually 5:4 if you wanted to stretch it to fit an LCD monitor or something). But can this information be calculated from the video frequencies somehow? I wonder if that's how the author of the document came up with 44 and 52, or if they're simply measurements of a square on the author's screen. :P

[Photon]

Originally Posted by absence

Values are exactly what I'm interested in, I don't have a practical problem that needs fixing. According to the document I linked to, 320x256 is not "squeezed to fit a 4:3 screen", which is what makes me curious about where 44 and 52 come from.

Ah, I see. Well anyone can write any value in a doc. Can't really figure what it relates to actually!

Originally Posted by absence

Square is good enough for me

OK, I understand why you asked then... Thought you were coding something that required you to know the correct pixel aspect!

I'd agree f.ex. NES and SNES have pixel aspect ratios. But thankfully on the Amiga it's easy. Just go with square pixels, if NTSC, it will be shown on a normal monitor, so it is correctly displayed. And on PAL the picture usually gets left and right margins and is square on both CRTs and 5:4 LCDs. So only if you somehow get a widescreen LCD and force 4:3, in PAL, do you get a stretched picture. Phew!

[MagerValp]

Originally Posted by absence

But can this information be calculated from the video frequencies somehow?

No. The width of a pixel and the height of a line is entirely up to the display device, and typically user controllable. Even if there is some "correct" value, there aren't any display devices that conform to it.

[absence]

Okay, let's try this again. Some data first: The visual part of a scanline lasts 52 μs for PAL and 4739/90 μs for NTSC. The number of visible lines are 576 for PAL and 486 for NTSC. The aspect ratio of the visible part of the signal is 4:3. The Amiga pixel clock frequency in "hires" mode is 28,375,160/2 Hz for PAL and 28,636,360/2 Hz for NTSC (are these figures exact?).

The basic formula for pixel aspect ratio is display aspect ratio divided by data aspect ratio. The display aspect ratio is 4/3. The data aspect ratio is width in pixels divided by height in pixels. The width is the visual scanline duration multiplied by the pixel clock frequency, and the height is the number of visible lines. The result is:

PAL:
4/3 / (28,375,160/2 Hz * 52 μs / 576) = 9,600,000/9,221,927 ≈ 1.041

NTSC:
4/3 / (28,636,360/2 Hz * 4739/90 μs / 486) = 2,916,000,000/3,392,692,751 ≈ 0.8595

(For the curious, substituting the Rec.601 pixel clock frequency of 13.5 Mhz for the "hires" Amiga pixel clock frequency results in correct pixel aspect ratios for digital PAL/NTSC.)

Does this look right?

Of course, the numbers don't make sense for monitors that let you stretch the standard resolution to the edges. In those cases it is probably better to use the following pixel aspect ratios:

PAL:
(4/3) / (640/512) = 16/15 ≈ 1.067

NTSC:
(4/3) / (640/400) = 5/6 ≈ 0.8333

[absence]

Originally Posted by absence

Does anyone know where these numbers come from and how accurate they are?

Turns out the numbers come from the OS itself (2.0+), as I found out with this, ahem, nice and well-written utility of mine:

    move.l    4,a6
    move.l    #gname,a1
    jsr    -408(a6)    ; oldopenlibrary
    move.l    d0,gbase
    move.l    #iname,a1
    jsr    -408(a6)    ; oldopenlibrary
    move.l    d0,ibase
    move.l    d0,a0
    move.l    60(a0),a0    ; firstscreen
    add.l    #44,a0        ; viewport
    move.l    gbase,a6
    jsr    -792(a6)    ; getvpmodeid
    move.l    d0,d2
    move.l    #$80000000,d1    ; dtag_disp
    move.l    #48,d0        ; size of dinfo
    move.l    #dinfo,a1
    move.l    #0,a0
    jsr    -756(a6)    ; getdisplayinfodata
    move.l    #dinfo,a0
    move.l    22(a0),d0    ; resolution
    rts

gbase:    dc.l    0
ibase:    dc.l    0
gname:    dc.b    'graphics.library',0
    even
iname:    dc.b    'intuition.library',0
    even
dinfo:    dc.l    0,0,0,0, 0,0,0,0, 0,0,0,0

As for their accuracy ... who can tell? Now that there are three possible pixel aspect ratios based on

• tv standards
• stretching the image to 4:3
• the operating system,

the quest to satisfy my curiousity is at an end.

[mark_k]

Resurrecting this old thread since I was thinking about aspect ratios the other day...

Originally Posted by absence

Okay, let's try this again. Some data first: The visual part of a scanline lasts 52 μs for PAL and 4739/90 μs for NTSC. The number of visible lines are 576 for PAL and 486 for NTSC. The aspect ratio of the visible part of the signal is 4:3. The Amiga pixel clock frequency in "hires" mode is 28,375,160/2 Hz for PAL and 28,636,360/2 Hz for NTSC (are these figures exact?).

For NTSC Amigas the high-res pixel clock is 4 times the NTSC subcarrier frequency, i.e. 4×315/88 = 315/22 MHz. Plugging that into your NTSC calculation you end up with an exact NTSC pixel aspect ratio of 28512:33173 = 0.85949...

That's fairly close (within 0.06%) to 0.86:1 = 43:50.

My calculations gave the same 9,600,000:9,221,927 result for the PAL aspect ratio as you. A probable close-enough (within 0.1%) ratio for emulators to use when scaling, or if you're trying to draw a circle on a PAL Amiga would be 1.04:1, i.e. 26:25.

So in summary:
Actual Amiga pixel aspect ratios: NTSC 28512:33173, PAL 9600000:9221927
Good enough for most purposes aspect ratios: NTSC 43:50, PAL 26:25 (= 56:50)


The 44:52 NTSC aspect ratio reported by AmigaOS is further from the correct value than 43:50, but still fairly close. However the aspect ratio reported by AmigaOS for PAL modes is 44:44, i.e. 1:1; about 4% off the correct value!

[absence]

Originally Posted by mark_k

For NTSC Amigas the high-res pixel clock is 4 times the NTSC subcarrier frequency, i.e. 4×315/88 = 315/22 MHz.

Ah, so that's where 28,636,360/2 comes from. Thanks!

Originally Posted by mark_k

The 44:52 NTSC aspect ratio reported by AmigaOS is further from the correct value than 43:50, but still fairly close.

That's the mystery. If 44:52 is an approximation, why choose a poor approximation over a better one? I'd love to know how they derived 44:52. Maybe 44 is some kind of magic number since they also use 44:44 instead of 1:1.

[Mrs Beanbag]

Graphic artists probably draw on the assumption that the pixels are square. If you draw a circle in Deluxe Paint it certainly works on that assumption.

[Leffmann]

Back in the day it probably depended on what region they worked in and what region they primarily targeted their game for. I remember often thinking the graphics looked squashed when playing console games back in the day, and I assume it's because, typically, the Japanese artists drew the graphics to look correct on their NTSC monitors or TV-sets.

In Deluxe Paint there's actually a setting called "Be square" which you use to control this for certain drawing operations.

[mark_k]

Originally Posted by Leffmann

Back in the day it probably depended on what region they worked in and what region they primarily targeted their game for. I remember often thinking the graphics looked squashed when playing console games back in the day, and I assume it's because, typically, the Japanese artists drew the graphics to look correct on their NTSC monitors or TV-sets.

Yep that's right. Most other console developers, whether in the USA or Europe, developed with NTSC consoles in mind, meaning that the display of PAL consoles appears to be squashed vertically (hence the black bars at top and bottom). I'm not aware of any console (only talking about 16-bit or earlier here) games in which the graphics were adjusted for the different PAL aspect ratio. Not surprising really, since all artwork was drawn pixel-by-pixel. The main adjustments for PAL releases were music tempo (player routine timed to the vertical blank obviously needs adjusting) and in a minority of cases gameplay speed.

Later on with the advent of 3D consoles it became much easier to adjust for the different PAL pixel aspect ratio, so most later PAL titles on those machines don't look as squashed.

With Amiga games things were a little different; I'm sure many games by European developers had graphics drawn for PAL machines, even if the game only used a 320x200 region of the screen. [I wonder how the Atari ST PAL pixel aspect ratio compares to the Amiga one...]

Originally Posted by absence

That's the mystery. If 44:52 is an approximation, why choose a poor approximation over a better one? I'd love to know how they derived 44:52. Maybe 44 is some kind of magic number since they also use 44:44 instead of 1:1.

Maybe one of the Amiga developers got the 44:52 by measuring on their monitor? Of course 44:52 is equivalent to 11:13. I'm guessing multiplying both sides by 4 made it easier to only work with integers. For example then the aspect of an NTSC high-res non-interlace pixel would be 22:52 rather than 6.5:13. An NTSC super-high res non-lace pixel would be 11:52 aspect.

[mark_k]

Some more mostly-irrelevant ramblings about the PAL Amiga pixel aspect ratio...

The length of the active part of each scanline isn't specified exactly but with some tolerance it seems. Some sources say the active line is 51.95μsec (vs 52μsec above).

For PAL system I, there were (according to some web pages) originally 582 active lines. And if you google pal 582 lines some results suggest CCTV cameras output video with 582 active lines.

PAL Amiga hardware might actually be capable of outputting at least 580 lines, even if the Amiga can only show the background colour there. I wonder if someone could test that? Connect Amiga to a 1081/1084 monitor, reduce picture height so entire image is visible and count scanlines.

Here are calculated Amiga aspect ratios supposing:
576 lines of 51.95μsec: (768/51.95)/14.18758 = 768000000/737044781 = 1.041999 approx (so almost exactly 1.042)
582 lines of 52μsec: (776/52)/14.18758 = 9700000/9221927 = 1.051841 approx.
582 lines of 51.95μsec: (776/51.95)/14.18758 = 776000000/737044781 = 1.052853 approx.

[pandy71]

At first:

http://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en

At second:
Based on AGNUS spec http://eab.abime.net/showpost.php?p=736465&postcount=99 - maximum amount of visible video lines is 573 (625-2*26).

--
btw Amiga HW can display IMHO unlimited amount of lines - limitations is only time (i.e. number of lines will be at a cost of the refresh time and memory).

[Mrs Beanbag]

I wonder if we could get an Amiga to send a teletext page to a TV?

[Toni Wilen]

First visible line is 26*2 (PAL) or 21*2 (NTSC). Note: lines in a field, not in a frame. Start line is always the same in both fields, only end line changes. Previous lines are automatically blanked by Denise/Lisa. (if normal PAL or NTSC mode)

Originally Posted by pandy71

btw Amiga HW can display IMHO unlimited amount of lines - limitations is only time (i.e. number of lines will be at a cost of the refresh time and memory).

ECS Agnus (or AGA) vertical counter is 10 bits, 2047 lines is the max

I wonder if we could get an Amiga to send a teletext page to a TV?

This was already discussed somewhere here. I think the answer was no because Amigas pixel clock is not close enough to teletext "pixel" clock.

[Mrs Beanbag]

Wikipedia tells me the teletext data rate is 144ns, Amiga lores pixel clock is 140ns right?

Could use super-hires and "Bresenham" it.

[mark_k]

Even a low-res display would probably be close enough to the teletext pixel clock. Bear in mind that apparently it's possible to record TV programmes on an S-VHS tape, and on playback the teletext signal can be decoded by the TV set. The clock run-in at the start of each line of teletext data would serve to synchronise the TV's teletext decoder to the Amiga pixel clock (which is ~141ns vs Teletext nominal 144ns). Not much difference, and I'm sure a played-back S-VHS tape has worse video timing.

The bigger problem would be that teletext data is usually transmitted in the vertical blanking interval where (AFAIK) you can't tell the Amiga to output image data. While any scanlines can be used for teletext data, some decoders probably require at least one line be in the VBI. See p145 of the Enhanced Teletext specification.