Date : Tue, 30 Mar 2004 01:37:27 +0100 (BST)
From : Pete Turnbull <pete@...>
Subject: Re: Aspect ratio question
On Mar 29, 18:51, Thomas Harte wrote:
>
> Sorry if this reply seems somewhat short, I've just
> lost my original reply and its put me in somewhat of a bad
> mood.
I do that all the time :-)
BTW, how come your posts have such short lines? It makes it incredibly
difficult to read...
> > With all due respect, the timing isn't what matters,
> > nor is the fraction of the display used.
>
> When we're talking about how wide the display is compared
> to how high it is, the question is exactly and explicitly
> interested in the fraction of the display used. The
> emulator part was just my justification for asking.
Well, OK, but the real answer is found in the dimensions, measured in
pixels or OS units (so long as you know that they're square, or
whatever). And the ratio is 5:4.
> > The fact is that a Beeb displays pixels,
> > and an emulator must display matching pixels if
> > it's to be accurate.
[...]
> > Something that turns two pixels into three can't display that
> > correctly.
>
> Yes it can. Check the comp.graphics.algorithms FAQ for various ways
> of reinterpretting sampled signals that amount to image
> scaling with a much greater display quality than you imply is
> possible.
I've done my share of graphics manipulation, and whilst I'm not an
expert to the extent that some of the FAQ writers are, I know that
there's a big difference between doing that for an ordinary image and
doing it for fine line graphics. It simply doesn't work for fine line
stuff, in any implementation I've ever seen. You always get aliasing
or some degree of incorrect line spacing, unless the scale factor is an
integer.
> See http://electrem.emuunlim.com/images/AcornUserMode7.gif
> for an example of such a scheme in action, displaying a
> Mode 7 display at the correct width - i.e. the same width
> as the normal display, not significantly thinner as many of
> the older emulators are forced to.
I don't quite understand what you're getting at here. That image is
640x512 pixels, which is 5:4 (as I've said) and it looks about right
when I compare it on my 1280 x 1024 correctly-adjusted (so circles are
circles) to the BBC Micro screen beside it.
On my Beeb, Mode 0 takes a shade more screen height than Mode 7, and
Mode 3 takes about the same.
> All that is beside the point though. As I said, my emulator
> is using an overlay surface. Which means a programmable pixel
> clock. I get the correct aspect ratio without any pixel
> scaling. See the last binary version of my emulator in
> full screen mode as evidence of this
I don't use MS Windows so I can't see it. However, your description of
an overlay surface isn't what I understood that to mean. I thought you
were talking about DirectDraw (or whatever it's called) overlay
surfaces, where the image is interpolated by the hardware -- no clock
changes. If you do use a programmable clock, and scale the pixel size
(rather than their number) then there's no problem -- two pixels are
still two pixels, but larger than normal. However, then the image is
not made up of 923 pixels, or whatever you said, generated from 640.
It's made up of 640 larger pixels. Yes? What kind of graphics card
do you need to do thaT?
> > Well, it does use square pixels. The manuals even say that's a
> > square-pixel mode. Obviously if your screen is not correctly
> > adjusted it won't *look* square :-)
>
> Could it be that they are square when viewed on a monitor
> rather than a TV? For an 8bit micro, a surprising number of
> BBC owners seem to have acquired monitors at some stage. Otherwise,
> I guess the problem could be Electron vs BBC, but as they are
> based on exactly the same underlying clock speeds (don't
> believe people who say the Elk had a 1.7Mhz clock, or
> anything like that) I don't see how that could be true.
Well, many TVs are slightly out of adjustment, unfortunately. If both
are properly adjusted, it shouldn't be any different on a TV or a
monitor, since we're talking about PAL-standard (or mono equivalent,
with the same timing) monitors. The reason so many people used
monitors on Beebs was simply that the higher resolution screens look
awful on colour TVs -- the TV bandwidth is too low and text in Mode 0
or Mode 3 looks crap (and hard to read).
I've been using, repairing, and programming Beebs and Electrons (and
Archimedes and...) since 1982, so I know the differences -- and 1.7MHz
is as you say, a myth. I suspect it's because the Electron is somewhat
slower than a Beeb for some tasks, and someone somewhere calculated it
to be equivalent to 17/20ths of the speed. Or maybe they were trying
to take the average of the speed when accessing RAM and when accessing
ROM, for some "average" mix.
> I invite an explanation of how my calculations are incorrect.
OK. You describe taking 40 microseconds out of 52, which is 10/13.
But then you take that fraction of 1024 pixels in a 1024 pixel screen.
That's not right; the 52 microseconds on a PAL-compatible display
extends beyond the viewable area within the outer bezel of the screen,
but the 1024 pixels doesn't, in fact on a normal CRT there's a
considerable margin on each side of that 1024 pixel wide area.
Similarly, you take 256 scan lines out of 288 displayable, which is
about 9/10 (0.88888...) but again fail to note that some of those
"displayable" scan lines are off the top and bottom of the viewable
area. This is called overscan. Therefore your ratios are wrong.
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 (or twice
as high as they are wide, in some modes), as are the OS units used
internally, and it makes more sense to measure the aspect ratio of the
displayed image in those terms, rather than trying to deduce it from
the timing. Instead of doing a lot of arithmetic and trying to guess
how many of the 288 *theoretically* displayable lines in a
non-interlaced display are missing from top and bottom of the screen,
and how the width (and overscan) is actually adjusted, just look the
screen sizes up in the manuals!
--
Peter Turnbull
<postmaster@... >