Date : Fri, 02 Apr 2004 20:40:23 +0100 (BST)
From : Pete Turnbull <pete@...>
Subject: Re: Aspect ratio question
On Apr 2, 13:14, Thomas Harte wrote:
> > notably the paragraph headed "Square Pixels" (but ignore the
obvious
> > typo of 56µs where 52µs is clearly intended, in the first diagram
:-))
>
> "I found the BBC micro in 320x240 pixel mode (8 MHz pixel rate) gave
almost square pixels"
And "The few percent error I can attribute to the TV's own
width-adjustment settings being slightly off." :-)
> Looking at it another way - "a small error in either setup or
> measurement will account for much of [any]
> difference". Therefore, could it not possibly be that the 'true'
> output is not quite square
Sure, but I think the true value is closer than is implied by the
aspect ratio of 1.18 or thereabouts that you say it should be.
> Horizontal:
> Total number of characters on a line minus one = 63
> The number of displayed character cells per line = 40
> Position of horizontal sync = 49
> Sync width = 4 chars
>
> implies:
>
> Total time over which pixels are output = 59 chars
> left border: 10 characters (output chars - position of sync)
> pixels: 40 chars
> right border: 9 characters (position of sync - number of chars)
Not quite. The right border is indeed the interval after the displayed
character cells (position of sync - number of chars). The left border
is however (output chars - position of sync - sync width) -- which I
think is what you meant, because 63 - 49 - 4 = 10.
You've got an off-by-one error, though, because there are 64 character
cells, not 63. The content of the register is one less than the actual
number of cells used -- it's stored as that because it's the character
cell counter for the line. The left margin is 11 characters by that
reckoning.
But that's not the whole story either. The PAL standard defines a
front and back porch, which is non-displayable, black level. There's
no way to program this into the 6845, so it's not reflected in the
register contents, although it is shown in the diagram above the table.
There's no point in telling something like a 6845 about it, really,
since it's a pretty simple CRTC and it can be assumed that the display
will be at black level some time (maybe not very much) before the sync
pulse starts, and the period after the sync pulse is not displayed
anyway, so it effectively includes the back porch.
The front porch is the time after a PAL display stops outputting
non-black, and is there to allow the electron beam to run right off the
edge of the CRT before the sync pulse starts the flyback. It's pretty
small. Similarly, the back porch is there to allow the beam to reach
the other side, start moving again, and reach stability before any
picture data is output.
You need to include values for the front and back porch as well as the
sync width when you calculate what is the total time over which pixels
are output. Yes, I realise that what you mean by "Total time over
which pixels are output" is the useful scanline width, ie including the
borders, whether they're beyond the bezel of the screen or not. You
mean anything that one could possibly put some kind of data in, even
just edge-of-screen border data (as you can do on an Archimedes and
many other machines).
> For the image to be square, if overscan didn't exist horizontally,
> we therefore need 40/59 * 4/3 of 312
> scanlines to be visible. Which is 160/177 of 312 lines, or 282 (and a
bit) i.e. we need the full defined PAL visible
> area to be 59µs and 282 scanlines.
Um, no. 64 character cells, less the sync width AND the front and back
porch. Of course we don't know from the 6845 registers what the front
and back porch are so all we can do is take the figures from the PAL
standard. So 64 - 2 - 4 - 6 = 52. The reason I've put 2 in there for
the front porch, which should only be 1.5, is because the sync pulse is
"wrong", being 4 instead of 4.5. I won't really object if you want to
round it down instead of up, making the total character cells 53.
I don't understand what you mean by the rest, at all. I can't see why
you're trying to take some fraction of 312 lines -- sure there are 312
(and a half, with interlace) lines in a field, but what's that got to
do with the price of bread? I'm not being sarcastic or anything, I
really don't understand what you're trying to calculate.
59 character cells (as you calculated) or 53 (according to me) is 4/3
of the maximum possible image height, but that height is 288 scan
lines. Also, I don't understand why you're multiplying anything by
4/3. Are you trying to match pixels? You need a factor of 5/4 for
that (image resolution 320 x 256).
> That page says PAL active display area is 56µs,
Yes, the diagram near the top does, but the diagram is clearly wrong.
The numbers 56 + 1.5 + 4.5 + 6 add up to 68, not 64. However, the
table and text above both say 64, which is correct, and further down
the text in many places it also says 52, which is correct. Also the
table of 6845 registers shows 64 character cells used, which for an
8MHz pixel clock and 8-pixel characters means 64µs.
> so what we genuinely want 40/56*4/3 of 312 - 20/21*312 - 297
> active display scanlines.
No, we want 40µs out of a possible 52µs, not 40/56.
> The defined PAL visible area in scanlines is 288, so if we had a TV
> screen that displayed all 288 scanlines, we'd
> then want it to display just over 55.23µs of active display to get
> square pixels.
Sorry, but I don't follow. I can't see where 55.23 came from, using
any of the numbers on those lines. Is there a typo in there somewhere?
--
Pete Peter Turnbull
Network Manager
University of York