English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 06 January 2010, 13:25   #1
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
Amiga aspect ratio

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.
absence is offline  
Old 06 January 2010, 21:23   #2
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,781
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.
Photon is offline  
Old 07 January 2010, 01:59   #3
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
Quote:
Originally Posted by Photon View Post
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.
absence is offline  
Old 08 January 2010, 11:52   #4
MagerValp
Registered User
 
Join Date: Aug 2008
Location: Göteborg / Sweden
Posts: 236
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.
MagerValp is offline  
Old 09 January 2010, 12:30   #5
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
Quote:
Originally Posted by MagerValp View Post
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
absence is offline  
Old 09 January 2010, 20:47   #6
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,781
Quote:
Originally Posted by absence View Post
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!
Quote:
Originally Posted by absence View Post
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!
Photon is offline  
Old 11 January 2010, 13:35   #7
MagerValp
Registered User
 
Join Date: Aug 2008
Location: Göteborg / Sweden
Posts: 236
Quote:
Originally Posted by absence View Post
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.
MagerValp is offline  
Old 30 May 2010, 03:05   #8
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
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

Last edited by absence; 30 May 2010 at 03:22.
absence is offline  
Old 01 June 2010, 16:36   #9
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
Quote:
Originally Posted by absence View Post
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:

Code:
    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.
absence is offline  
Old 13 October 2013, 15:55   #10
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,113
Resurrecting this old thread since I was thinking about aspect ratios the other day...
Quote:
Originally Posted by absence View Post
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!

Last edited by mark_k; 13 October 2013 at 16:06.
mark_k is offline  
Old 13 October 2013, 16:20   #11
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
Quote:
Originally Posted by mark_k View Post
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!

Quote:
Originally Posted by mark_k View Post
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.
absence is offline  
Old 13 October 2013, 16:24   #12
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 13 October 2013, 17:50   #13
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
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.
Leffmann is offline  
Old 13 October 2013, 18:43   #14
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,113
Quote:
Originally Posted by Leffmann View Post
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...]
Quote:
Originally Posted by absence View Post
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 is offline  
Old 14 October 2013, 14:48   #15
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,113
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.
mark_k is offline  
Old 14 October 2013, 15:20   #16
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,690
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).

Last edited by pandy71; 15 October 2013 at 20:10.
pandy71 is offline  
Old 14 October 2013, 16:24   #17
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
I wonder if we could get an Amiga to send a teletext page to a TV?
Mrs Beanbag is offline  
Old 14 October 2013, 16:47   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,338
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)

Quote:
Originally Posted by pandy71 View Post
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

Quote:
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.
Toni Wilen is online now  
Old 14 October 2013, 19:16   #19
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Wikipedia tells me the teletext data rate is 144ns, Amiga lores pixel clock is 140ns right?

Could use super-hires and "Bresenham" it.
Mrs Beanbag is offline  
Old 14 October 2013, 21:04   #20
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,113
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.
mark_k is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Wrong aspect ratio Leandro Jardim support.WinUAE 5 24 September 2013 05:41
Custom ratio for aspect ratio correction? rsn8887 request.UAE Wishlist 4 16 April 2013 18:49
Keep Aspect Ratio + RTG reenstix support.WinUAE 15 15 February 2011 12:41
iGame screenshot aspect ratio wrong? emuola support.Apps 3 16 September 2010 06:53
aspect ratio and scaling problem hexaae support.WinUAE 42 14 May 2009 20:01

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09017 seconds with 13 queries