Date : Thu, 01 Apr 2004 02:04:08 +0100 (BST)
From : Pete Turnbull <pete@...>
Subject: Re: Aspect ratio question
On Mar 31, 12:29, Thomas Harte wrote:
> What I actually did was calculate what proportion of the entire
defined PAL visible area that the Acorns use,
> then scale that so that the 1024x768 screen covered only the used
region, but without distorting the image
> during scaling. So I allowed for overscan and then some. I'm not
interested in making your monitor display
> exactly the same image as an equivalently sized TV, just in making
sure that the image it does display is the
> same proportion of width to height.
OK, so you want the image on some screen to have the same aspect ratio
as the image on a real monitor, which we assume is reasonably correctly
adjusted, connected to a real BBC Micro. That ratio is 5:4. Not just
in theory, but when I measure the image on the screen beside me, which
is a 12" Zenith monitor, correctly adjusted, made in 1984, connected to
a BBC B in Mode 0, it is 213mm wide x 171mm high (measured across line
16 and down column 40). That's 1.246, or as close to 5:4 as matters.
Hmm, where have I seen that before, oh yes, your Mode 7 display :-)
Are we talking about the same image? I'm talking about the exact area
you can plot pixels in, ie not including the borders.
> I now
> believe that the display should be 45/38ths as wide as tall (as a
natural result of the calculations already
> posted). Which is somewhere a little over 1.18.
This is the calculation where you said "each scanline is 52 µs of
visible time, of which the Acorn machines use 40 µs"?
Firstly: that's not strictly true. That 52µs is the non-blanked
interval, not the visible part, because of overscan. Or to put it
another way, the other 12µs is only the horizontal blanking interval,
without any consideration of non-visibility because of overscan. The
visible part is less than 50µs. That makes the Beeb usage
significantly more than 80% of the total, not 77% (10/13).
Secondly: there's no overscan in a 1024 x 768 (or any comparable
monitor mode). In fact, it's underscanned: the raster does not extend
to the edge of the physical screen.
The PAL picture is designed to be overscanned. Monitor modes like
1024x768 are not. In fact in order to make best use of the bandwidth,
they're normally underscanned, and this has more effect on the
horizontal than the vertical. I can demonstrate this very easily on a
couple of my testbench monitors, which are Taxans with
overscan/underscan switches. Professional-quality studio video
monitors have switches to change from very precise "normal" (overscan)
to "underscan", and you might be surprised how much the picture
shrinks.
The reason is that they're designed to overfill the CRT so there can be
no margins on a normal picture (normal is 1% over available CRT area),
but reduce it enough to see all the corners and beyond all the edges in
underscan mode, to check for skew and tracking errors, and to check
that test charts touch all four corners of the raster.
That's probably why your ratios come out wrong. On a typical 17"
monitor or TV the diagonal of the tube is 17" (by definition) or about
43cm, but the bezel obscures part of that, leaving a diagonal of about
40cm. The visible width across the centre is just over 32.5cm, and the
height is about 24cm. If you fit a 1024 x 768 pixel image into that
there's normally a margin of over 1cm at each side, but only about
0.5cm top and bottom (30.5 x 23, aspect ratio 4:3). Of course the
raster, the part of the image that doesn't have the horizontal blanking
applied will be slightly larger, over 1cm bigger, like 32cm. It's
bigger because you need to allow some phase shifting of the luminance
signals relative to the horizontal drive in order to be able to adjust
the centering, without pushing the luminance into the horizontal
blanking region.
Scaling that width from 32cm to about 37cm, as you would if you turned
an underscanned image to overscanned, you're applying a factor of 1.15.
Alternatively, if you scale the viewable image from 30.5 to near the
edge of the phosphor, it will be about 35cm (about 1cm beyond the bezel
at each side), giving the same ratio (it doesn't matter much, it
cancels out when scaling the vertical size).
You'd have to scale the vertical size by the same amount to preserve
the aspect ratio, so 23cm would become 26.4cm. But that's equivalent
to 288 lines, you said. 256 lines (from a Beeb or anything else
matching the PAL standard) would only be 23.5cm high. Very close to
the image we started with, not entirely coincidentally, with a small
margin top and bottom. But the Beeb image is only 40/52 of its raster
width, that is 40/52 of 37cm, or 28.46cm. 28.46/23 is 1.24.
> > You're measuring the wrong things, I think. I'm just saying that
the
> > size is a function of the displayed pixels, which are square
>
> I'm just saying: I don't see how they can be square from the clock
rates, and they never looked square to me.
Why can't they be square?
They are *designed* to be square, so that if you draw a circle with a
diameter of, say, 1000 OS units, it comes out visibly as wide as it is
high, or if you draw a "square" which is 1000 OS units high and 1000 OS
units wide, it actually is square. This is the same reason that pixels
in 1024 x 768 or 1280 x 1024 screen modes on modern machines are
designed to be square.
Acornsoft's "Graphics on the BBC Microcomputer", page 3, "In Mode 1 the
resolution is quite good[1] and the pixels are square". It also
explains that the OS units are squares, but the pixels may not be,
depending on the screen mode. You'll also find, in Archimedes
documentation, many references to "square pixel" modes and "rectangular
pixel" modes.
[1] Well, it was written in 1982 :-)
--
Pete Peter Turnbull
Network Manager
University of York