Maximum overscan screen size

discuss bbc micro and electron emulators (including mame) here!
garfield
Posts: 446
Joined: Mon Jan 03, 2005 1:38 am
Contact:

Maximum overscan screen size

Post by garfield »

Hello stardotters,

A two-part question:
1. What is the maximum overscan screen size that current BBC Micro emulators support?
2. What are typical "real world" overscan screen sizes that make sense with 1980s authentic display hardware (i.e. typical Ferguson/Philips/Sony tellys back in the day and things like Microvitec monitors).

( For part one, I am going on the assumption that the maximum size should approximate a PAL displayable field 768x288 pixels. Let us keep it in the realm of pixels for now, and ignore the complexities of interlaced frames and the analogue nature of rasterisation. )


I am presuming that this means that a BBC Micro emulator should be able to display this theoretical maximum screen size of approximately 96 CRTC characters wide by 36 rows high. This works out at about 27KB and in terms of a "MODE 1"-like screen would be 384x288. Are there any example programs out there that test the waters of BeebEm, or B2 or any other emulator in this regard? Or do they run into trouble with assumptions on stuff like the sync positions etc? :?:

...

For part two, would 80s contemporary TVs/monitors "throw a fit" if such a large screen was attempted to be displayed? Or would it display fine (despite maybe some cropping due the TV/monitor bezel obscuring the edges of the CRT tube) ? By fine here, I mean that a stable image is shown and no sync or rolling trouble is encountered... :?:
Coeus
Posts: 2159
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Maximum overscan screen size

Post by Coeus »

garfield wrote:
Mon May 03, 2021 8:10 pm
1. What is the maximum overscan screen size that current BBC Micro emulators support?
B-Em now dynamically adjusts the size of window it asks for according to what border option you have chosen but if you choose "full borders" which gives the biggest gap between the edge of the drawn on area of the standard screen modes and the edge of the window, the size is 832x308. The vertical direction is doubled, either by interfacing, line doubling, or scaling depending on what you choose.
garfield wrote:
Mon May 03, 2021 8:10 pm
For part two, would 80s contemporary TVs/monitors "throw a fit" if such a large screen was attempted to be displayed? Or would it display fine (despite maybe some cropping due the TV/monitor bezel obscuring the edges of the CRT tube) ? By fine here, I mean that a stable image is shown and no sync or rolling trouble is encountered... :?:
Remember that many sets had h-size and v-size controls. That means that, even BITD, many people didn't operate with the large borders that the definition of the standard modes would seem to suggest, i.e. people would adjust the size controls to get the useful part of the picture to occupy as much of the CRT as possible, except that going right into the corners would expose any imperfections in pincushion compensation.

That's why b-em offers the three border options because "full" which looks huge on a modern PC is not necessarily any more authentic than a slimmer border.

So I suspect, as you make the displayed part of the line bigger, it will extend to the edges of the screen and, once it has gone off the edge, you would be able to get it back on screen again by reducing h-size and likewise in the v direction. Eventually, though, I would expect it to lose sync. But there are some people with a much more detailed knowledge so hang around.
Last edited by Coeus on Mon May 03, 2021 8:47 pm, edited 1 time in total.
tom_seddon
Posts: 471
Joined: Tue Aug 30, 2005 12:42 am
Contact:

Re: Maximum overscan screen size

Post by tom_seddon »

b2 displays 736x288 - 92 x 2 MHz CRTC columns wide. This is wide enough to display Boffin (90 CRTC columns wide); that filled the entire width of the CRT I was testing with at the time. I figured anything significantly wider would be unlilkely.

(I don't remember the exact details, but my slightly unclear notes from the time about why 736 rather than 720: https://github.com/tom-seddon/b2/blob/a ... conf.h#L95 - suspect I just didn't quite get the TV emulation correct. This hasn't been a big issue, but now that I'm thinking about it, it is kind of annoying. So I may revisit this in future.)

I should do another round of testing with this, really, as since then I've somehow accumulated 4 CRTs...

--Tom
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

garfield wrote:
Mon May 03, 2021 8:10 pm
What are typical "real world" overscan screen sizes that make sense with 1980s authentic display hardware (i.e. typical Ferguson/Philips/Sony tellys back in the day and things like Microvitec monitors).
The maximum area that any standard CRT TV or monitor would be expected to display (because broadcast 625-line television never contains picture content outside that area) is 52 μs x 576 lines, or with a 16 MHz pixel clock (e.g. MODE 0) that's 832 x 576 non-square pixels.

How much more a CRT TV might be able to display by reducing the width and height controls will depend on how fast the horizontal and vertical flyback are, and that is likely to have been quite variable. In any case the linearity would almost certainly suffer at the extreme ends of the scan.
I am going on the assumption that the maximum size should approximate a PAL displayable field 768x288 pixels. Let us keep it in the realm of pixels for now
You can only refer to "pixels" if you make an assumption about the pixel-clock rate, and of course analogue TV has no such concept. Your figure of 768 seemingly corresponds to the square pixel clock rate of about 14.77 MHz, but since that's not a clock rate used by the BBC Micro its relevance is questionable.

The pixel clocks used by the BBC Micro are 4 MHz (MODEs 2 & 5), 8 MHz (MODEs 1, 4 & 6) 12 MHz (MODE 7) and 16 MHz (MODEs 0 & 3).
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
tricky
Posts: 5524
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Maximum overscan screen size

Post by tricky »

Richard is the most knowledgeable person about this that I know ;)
garfield wrote:
Mon May 03, 2021 8:10 pm
...
2. What are typical "real world" overscan screen sizes that make sense with 1980s authentic display hardware (i.e. typical Ferguson/Philips/Sony tellys back in the day and things like Microvitec monitors).
...
When I was doing my Pac Land demo, I checked four of my 14" portable CRTs and found that in MODE 1, at the widest part, 384 pixels were visible on one and 386 on the other three. Vertically all were between 33 and 34 character rows. I have seen CRTs that only show 31.5 vertically, but not checked their horizontal visible time.

On b-em, I had assumed that full borders was fixed to the sizes that Richard specified, normal was roughly what I found my CRTs to be, that is some kind of average visible and small was just what was visible (displayed by the 6845) at the time. Should I take it that this is wrong?
User avatar
1024MAK
Posts: 10716
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Maximum overscan screen size

Post by 1024MAK »

As sold, CRT TVs are deliberately set up so that a television picture will completely fill the displayable area of the screen. So even with a normal TV picture, you don’t get to see the edges of the transmitted picture.

Details on how a set should be set up are here.

This is one of the reasons that most home computers have a border around the main part of the picture area (the others being that it helps to keep the video circuitry cost lower and allows some flexibility between 625 line and 525 line TV standards).

Also keep in mind that the user controls (if any) on CRT TVs and monitors only allow a limited range of adjustment to the horizontal and vertical size. Even the techinican presets inside the set will have a limited range.

Mark
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

1024MAK wrote:
Tue May 04, 2021 12:48 pm
Details on how a set should be set up are here.
That's somewhat misleading since it stems from the late 1960s when colour CRTs (and their masking faceplates) had very curved sides, and were often more like a 5:4 aspect ratio than 4:3. As CRT technology and scan stability improved, the visible screen became more like a true 4:3 rectangle (think Sony Trinitron), and I for one always adjusted our TVs so that the picture edges, as indicated by the arrowheads, could be fully seen.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
hexwab
Posts: 40
Joined: Wed Jul 08, 2015 9:27 pm
Contact:

Re: Maximum overscan screen size

Post by hexwab »

Richard Russell wrote:
Tue May 04, 2021 9:31 am
square pixel clock rate of about 14.77 MHz
Further investigation reveals that this frequency seems to be based on SMPTE RP 187's PAR of 1132:1035 (and Rec. 601's 13.5MHz sampling frequency): 13.5*(1132/1035)~=14.7652MHz.

Wikipedia claims[1] that "To convert analog video lines into a series of square pixels, the industry adopted a default sampling rate at which luma values were extracted into pixels. The luma sampling rate for 480i pictures was 12+3⁄11 MHz and for 576i pictures was 14+3⁄4 MHz." and that RP 187 came later[2] (and was widely ignored). Is this correct? Why would SMPTE specify such an arcane ratio more than a decade after the fact rather than going with 59:54 or 35:32 or even 12:11?

What pixel clock and PAR did, say, Quantel use?

Tom.

[1] https://en.wikipedia.org/wiki/Pixel_asp ... conversion
[2] https://ieeexplore.ieee.org/document/7289664 suggests 1995(!)
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

hexwab wrote:
Fri May 07, 2021 6:51 pm
Further investigation reveals that this frequency seems to be based on SMPTE RP 187's PAR of 1132:1035 (and Rec. 601's 13.5MHz sampling frequency): 13.5*(1132/1035)~=14.7652MHz.
No, that's putting the cart before the horse; after all the 'square pixel' clock frequency could have been (and probably was) calculated before 13.5 MHz sampling was ever proposed!

You can easily derive it from 'first principles', i.e. the values in the White Book (for those not familiar, that is the term used universally in the broadcast TV industry for the 'Specification of Television Standards for 625-Line System I Transmissions in the United Kingdom').

From the White Book we can discover that the picture width is 51.95 μs (section 3.1) and its height is 575 lines (section 2.3); it also tells us that the aspect ratio is 4:3 (section 2.5). That's all we need to know. From the height and aspect ratio we can calculate that the number of square pixels across the width of the picture would be 4/3 * 575 = 766.666... pixels. So from that value and the width we can calculate the clock frequency as 766.66 / 51.95 = 14.757777 MHz.

This isn't quite the 14.77 MHz that I quoted because in the 'digital environment' it's convenient to pretend that the picture height is 576 lines (not 575), so the number of square pixels across the picture width is 4/3 * 576 = 768, and also that the picture width is 52 μs (not 51.95). Using those figures gives us a frequency of 14.76923 MHz, but the difference isn't significant.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
scarybeasts
Posts: 749
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: Maximum overscan screen size

Post by scarybeasts »

tom_seddon wrote:
Mon May 03, 2021 9:17 pm
b2 displays 736x288 - 92 x 2 MHz CRTC columns wide. This is wide enough to display Boffin (90 CRTC columns wide); that filled the entire width of the CRT I was testing with at the time. I figured anything significantly wider would be unlilkely.
Good old Boffin! I also calibrated beebjit's default screen based on being able to fit Boffin.


Cheers
Chris
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

hexwab wrote:
Fri May 07, 2021 6:51 pm
Why would SMPTE specify such an arcane ratio more than a decade after the fact rather than going with 59:54 or 35:32 or even 12:11?
I didn't address that in my previous reply, but to derive the PAR for 13.5 MHz sampling one only needs to divide the square-pixel clock rate by 13.5, so depending on which figure you choose you get in the region of 14.76 / 13.5 = 1.093333. Comparing with the rational values you listed:

Code: Select all

1132:1035 = 1.0937198
59:54     = 1.0925925
35:32     = 1.09375
12:11     = 1.090909
I actually think 47:43 is more accurate than any of those!
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
Pernod
Posts: 2538
Joined: Fri Jun 08, 2012 11:01 pm
Location: Croydon, UK
Contact:

Re: Maximum overscan screen size

Post by Pernod »

If I'm following this correctly then it sounds like a resolution of 768x576 would be the ideal size to render, assuming square pixels?
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

Pernod wrote:
Fri May 07, 2021 10:46 pm
If I'm following this correctly then it sounds like a resolution of 768x576 would be the ideal size to render, assuming square pixels?
That's very close to the size of the active picture in 625-line TV but the BBC Micro doesn't output square pixels and I don't know of any emulator that attempts to make a correction for this (it would be likely to result in ugly scaling artefacts or blurring or both). So you are more likely to see the maximum rendering size as 832x576, after adjustment for 16 MHz sampling, giving a sharp output but not quite the right shape.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
hexwab
Posts: 40
Joined: Wed Jul 08, 2015 9:27 pm
Contact:

Re: Maximum overscan screen size

Post by hexwab »

Richard Russell wrote:
Fri May 07, 2021 8:03 pm
No, that's putting the cart before the horse; after all the 'square pixel' clock frequency could have been (and probably was) calculated before 13.5 MHz sampling was ever proposed!

You can easily derive it from 'first principles', i.e. the values in the White Book (for those not familiar, that is the term used universally in the broadcast TV industry for the 'Specification of Television Standards for 625-Line System I Transmissions in the United Kingdom').
Good to know! See, this is why I should've gone with my original question ("how is this frequency derived?") rather than being lulled into a false sense of understanding after half an hour on the internet.

Do you know the derivation of the equivalent frequency for NTSC systems?

Also, bringing this back to Beebs for a minute, the "square" pixel modes (modes 1 and 4), should they actually have square pixels, would result in an image aspect of 5:4. Given that the pixels are actually skinnier than square (I make it 14.77MHz (square pixel frequency) / 8MHz (actual pixclock) * (288/575) (correction for only using half the available vertical resolution since both fields are the same) = 0.92473043 PAR) that gives a resulting image aspect ratio of 5/4*0.92473043=1.155913, or even further from 4:3 than if the pixels were actually square.

(Another way of looking at it: each scanline contains 40µs of actual pixel data out of a possible 51.95µs, and uses 256 out of a possible 575/2=287.5 scanlines, for an image aspect ratio of (256/287.5) / (40/51.95) = 1.15645, which is not quite the same number.)

How do these figures look? Does this imply that Beebs have wider horizontal borders than vertical ones? Was wanting square pixel modes and/or an image aspect close to 4:3 a design consideration at all?

Tom.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

hexwab wrote:
Sat May 08, 2021 8:23 am
Do you know the derivation of the equivalent frequency for NTSC systems?
Because NTSC originates from such a long time ago (even before the days of colour) and there was less of a formal specification process back then, the figures aren't so clear-cut. In addition (unlike 625-line systems) the nominal 'analogue' height isn't a convenient number of lines for digital systems so 'digital' NTSC tends to be rather different.

So take these figures with a degree of scepticism but one calculation runs as follows, derived from SMPTE T14.22/082:

Active picture width = 52.86 μs (section 6.4)
Active picture height = 485 lines (figure 5)
Aspect ratio = 4:3 (assumed)
Square-pixel frequency = (4/3 * 485) / 52.86 = 12.2336 MHz
bringing this back to Beebs for a minute, the "square" pixel modes (modes 1 and 4), should they actually have square pixels, would result in an image aspect of 5:4.
True, but that's not the 'picture' aspect ratio because you're not going to want the nominal extent of the graphics output to fill the entire active picture area (not least because of overscan).
How do these figures look? Does this imply that Beebs have wider horizontal borders than vertical ones? Was wanting square pixel modes and/or an image aspect close to 4:3 a design consideration at all?
The aspect ratio of the nominal graphics output area (which is dependent on MODE anyway, and is changeable by reprogramming the 6845) is unlikely to have been a design consideration; I don't think anybody cared much about whether the horizontal borders were wider or less wide than the vertical borders.

But the shape of the pixels will have been a concern, because so many programs assume that they are square; indeed with the advent of the Graphics Extension ROM, which includes primitives for drawing circles and ellipses, this was frozen into firmware. I think the BBC did argue early on for using a 14.75 MHz 'master' clock, but since this would have slowed the entire machine down a little it's understandable that Acorn weren't keen.

It was always possible to justify non-square pixels on the basis that the Beeb would often be used with a custom monitor which could be adjusted to correct for the error. I don't know for sure, but it's entirely likely that Microvitec did adjust their monitors that way in the factory.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
garfield
Posts: 446
Joined: Mon Jan 03, 2005 1:38 am
Contact:

Re: Maximum overscan screen size

Post by garfield »

Going back to the original topic for a moment, I found these pictures on an Amstrad CPC forum.

The picture dimensions are 384x272 :
zynaps (final - title).png
zynaps (final - title).png (27.26 KiB) Viewed 379 times
.
Actual coverage on a CRT screen is:
zynaps.jpg
This is anecdotal, of course, and we don't know the particulars of the how this particular CRT monitor was tuned. But it does indicate that someone can get reasonable "full" overscan with such 384x272 dimensions.

If I was going down the practical route of designing an oversize picture, I would personally go down Tricky's route of trying it out first-hand on a variety of tellys and monitors.
hexwab
Posts: 40
Joined: Wed Jul 08, 2015 9:27 pm
Contact:

Re: Maximum overscan screen size

Post by hexwab »

Richard Russell wrote:
Sat May 08, 2021 11:13 am
It was always possible to justify non-square pixels on the basis that the Beeb would often be used with a custom monitor which could be adjusted to correct for the error. I don't know for sure, but it's entirely likely that Microvitec did adjust their monitors that way in the factory.
I actually measured this a few years ago on a Cub and IIRC got a PAR closer to 0.95 than the 0.9247 I calculated above. I've not had access to it since the before-fore times but I do have a photo of me trying to measure the extent of its overscan:
overscan.jpg
These are MODE 7 characters and I count about 50x28 of them (plus a bit of undrawn area at the bottom), and at 1µs per character that gives a displayed area of 50µs. This gives a square pixel frequency of 4/3*575/50=15.33MHz which I think is definitely edging nearer the Beeb's 16MHz clock (I calculate the mode 1/4 PAR as 15.33/8*(288/575)=0.95979) and lends support to the factory adjustment idea.

I don't have the program anymore either but I imagine it resembled the following:

Code: Select all

MODE7
FORA%=0TO1020STEP4:A%!&7C00=&1C1D1C1D:NEXT
?&FE00=1:?&FE01=57
?&FE00=2:?&FE01=58
?&FE00=6:?&FE01=29
?&FE00=7:?&FE01=30
All of which leads to the question: if you're writing an emulator/image converter/screen dumper/plotting routine and you have to pick a PAR, which PAR do you pick?

Tom.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

hexwab wrote:
Sun May 09, 2021 3:25 am
All of which leads to the question: if you're writing an emulator/image converter/screen dumper/plotting routine and you have to pick a PAR, which PAR do you pick?
I don't think you have a lot of choice. Assuming anything other than square pixels (PAR 1:1) implies some kind of scaling, and scaling the output from the emulated BBC Micro - indeed anything with sharp unfiltered edges - will result in artefacts. They could include aliasing or blurring, and quite likely both, and I think most people would conclude that they are unacceptable.

The only exception I can think of is when the emulator is rendering to a 'retina' display (or a printer), i.e. a device with such a high spatial resolution that one could approximate to the true PAR by an integer up-scaling ratio. A good approximation to the scaling required to reproduce the BBC Micro's 'true' pixel shape is 13:12 (that reduces the effective sampling rate from 16.0 MHz to 14.76923 MHz which is extremely close to square pixels).

So if one were to render each MODE 1 'pixel' to a rectangle 12 pixels wide by 13 pixels tall on the final device, it would have almost precisely the correct shape compared with feeding the output of a BBC Micro into a correctly-adjusted TV. But that would imply a total width of 3840 pixels and
a height of 3328 pixels for the graphics area!
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
hexwab
Posts: 40
Joined: Wed Jul 08, 2015 9:27 pm
Contact:

Re: Maximum overscan screen size

Post by hexwab »

Richard Russell wrote:
Sun May 09, 2021 10:48 am
I don't think you have a lot of choice. Assuming anything other than square pixels (PAR 1:1) implies some kind of scaling, and scaling the output from the emulated BBC Micro - indeed anything with sharp unfiltered edges - will result in artefacts. They could include aliasing or blurring, and quite likely both, and I think most people would conclude that they are unacceptable.
Sure you do! Screen pixels in JSBeeb bear no relation to framebuffer pixels. b2, despite not having the constraint of running in a browser (where precise pixel control is much harder), takes the same approach, and appears to use a PAR of 0.96.

Of course, there are absolutely people who dislike scaling artefacts (this is the entire rationale behind hoglet's RGBtoHDMI project) but I suspect most people think it's just fine, especially given the discrepancy between the monstrous resolutions of modern display devices and the piddling ones of those forty years ago.

But even if you're right about emulators, there are plenty of other use cases where you can pick an arbitrary PAR. Let's say you want to draw a 200-pixel-diameter circle. Nothing stopping you from drawing a 190-by-200-pixel ellipse instead.

Or take the Dithertron, which takes an input photo, downscales it to the target resolution and only then does colour quantization (with dithering).

(I should probably fess up at this point that I have been doing some Dithertron hacking myself recently, and one of the reasons for asking all these questions is reaching a better understanding of what PAR would be best for converting images to the Beeb. Sadly if Microvitec's monitors were consistently calibrated to be wider than a TV there might be two "right" answers, one for the most common display device used with the Beeb BITD and one for everything else.)

Tom.
Coeus
Posts: 2159
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Maximum overscan screen size

Post by Coeus »

hexwab wrote:
Sun May 09, 2021 12:48 pm
Of course, there are absolutely people who dislike scaling artefacts (this is the entire rationale behind hoglet's RGBtoHDMI project) but I suspect most people think it's just fine...
I'm not keen on artefacts and I have also had a bug report raised for B-Em to the effect that the default windows size was slighly miscalculated and resulted in artefacts. B-Em does allow you to have the correct aspect ratio if you want - it doesn't start up that way but you can re-size the window to make it so. At the moment it doesn't give you any help with that, but you could plot a circle and then adjust until it is round.
hexwab wrote:
Sun May 09, 2021 12:48 pm
..especially given the discrepancy between the monstrous resolutions of modern display devices and the piddling ones of those forty years ago.
Yes, we have many more pixels on screen now than then, but for many PCs we have not reached the point where we can ignore issues relating to scaling and artefacts any more than we can dispense with anti-alising for font rendering. This becomes quite aparent if one switches from using a mobile phone or decent tablet back to using a PC. But then my reference for that is a 24" minitor at 1920x1080.
hexwab wrote:
Sun May 09, 2021 12:48 pm
But even if you're right about emulators, there are plenty of other use cases where you can pick an arbitrary PAR. Let's say you want to draw a 200-pixel-diameter circle. Nothing stopping you from drawing a 190-by-200-pixel ellipse instead.
No, though you may have an optimised machine code routine avaiable that plots circles and not elipses.
hexwab wrote:
Sun May 09, 2021 12:48 pm
Sadly if Microvitec's monitors were consistently calibrated to be wider than a TV there might be two "right" answers, one for the most common display device used with the Beeb BITD and one for everything else.)
I think you have to accept that what people viewing something see is, to some extent, down to them. I imagine many TV performers who filmed material in 4:3 would have been horrified at the thought of it being scaled to 14:9 or even 16:9 because the manufacters of wide screen TVs though people who had paid for a wide screen wanted to see if filled and would not be interested in such detail as what aspect ratio the original material was filmed in.
Last edited by Coeus on Sun May 09, 2021 2:09 pm, edited 1 time in total.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

hexwab wrote:
Sun May 09, 2021 12:48 pm
Let's say you want to draw a 200-pixel-diameter circle. Nothing stopping you from drawing a 190-by-200-pixel ellipse instead.
There's a big difference between drawing a 190-by-200-pixel ellipse and scaling a 200-pixel-diameter circle to 190-by-200! A BBC Micro emulator is inevitably going to have to do the latter, it doesn't have the opportunity of intercepting the drawing commands and modifying the coordinates (and even in principle you can't scale text that way).

Scaling is a tricky subject, and it took me years to understand it to the degree that I needed to in my career at the BBC (my CO6S/514 DVE for Virtual Production won the Video R&D Achievement of the Year award at the International Broadcasting Awards in 1996). One problem is that it's almost impossible to avoid the rather non-intuitive mathematics of Sampling Theory, but I tried to in this paper.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

[Off topic] My CO6S/514 DVE, the scaling/warping is done in the eight HSP43168 chips which are configured as 16-tap Finite Impulse Response filters:

IMG_20210509_141625.jpg
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
guesser
Posts: 576
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: Maximum overscan screen size

Post by guesser »

Coeus wrote:
Sun May 09, 2021 2:05 pm
I imagine many TV performers who filmed material in 4:3 would have been horrified at the thought of it being scaled to 14:9 or even 16:9 because the manufacters of wide screen TVs though people who had paid for a wide screen wanted to see if filled and would not be interested in such detail as what aspect ratio the original material was filmed in.
That is horrifying, and anyone who sets their TV up to force widescreen for 4:3 material should have their TV remote privileges revoked. Broadcasters who set the aspect ratio flags incorrectly should be fined per infraction :lol:
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

guesser wrote:
Sun May 09, 2021 2:46 pm
That is horrifying, and anyone who sets their TV up to force widescreen for 4:3 material should have their TV remote privileges revoked. Broadcasters who set the aspect ratio flags incorrectly should be fined per infraction :lol:
What's even more horrifying is the number of people who do watch stretched pictures, and when it's pointed out to them cannot see anything wrong. :shock:
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
hexwab
Posts: 40
Joined: Wed Jul 08, 2015 9:27 pm
Contact:

Re: Maximum overscan screen size

Post by hexwab »

I wasn't intending to ignite a holy war here, or condone (or condemn!) the scaling behaviour of existing emulators. Suffice to say I do absolutely know how the sampling theorem works.
Richard Russell wrote:
Sun May 09, 2021 2:09 pm
There's a big difference between drawing a 190-by-200-pixel ellipse and scaling a 200-pixel-diameter circle to 190-by-200! A BBC Micro emulator is inevitably going to have to do the latter, it doesn't have the opportunity of intercepting the drawing commands and modifying the coordinates (and even in principle you can't scale text that way).
I agree! I think mentioning emulators was a red herring; I was merely pointing out that if you're drawing something using known-not-to-be-square pixels then compensating for that at the time of drawing is a useful thing to do. Especially if you're just drawing a prerendered bitmap and it's the same amount of work either way, which is what I'm currently trying to do.

(Why am I now imagining Elite with such compensation? They must've done it for other ports where pixels weren't remotely square no matter what video mode you used (*cough* Apple II *cough* DOS)... right? Right?! I just know I'm gonna regret asking youtube...)

Tom.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

hexwab wrote:
Sun May 09, 2021 3:24 pm
I was merely pointing out that if you're drawing something using known-not-to-be-square pixels then compensating for that at the time of drawing is a useful thing to do.
Indeed, and I think it was a mistake to include circle drawing in the Graphics Extension ROM (and the CIRCLE statement in BASIC 5 and later) because it builds the assumption of square pixels into the system. In my opinion it would have been better to provide only the more general-purpose ELLIPSE capability, and leave it up to the programmer to make the necessary adjustment for the pixel shape (or not).

I expect it comes down to the relative efficiencies of the Bresenham (etc.) circle- and ellipse-drawing algorithms, and not wanting to have to use the slower ellipse routine all the time. But I still disapprove, and in my own BBC BASIC antialiased graphics library (aagfxlib.bbc) I do indeed provide only outline and filled ellipse routines, not circles.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
garfield
Posts: 446
Joined: Mon Jan 03, 2005 1:38 am
Contact:

Re: Maximum overscan screen size

Post by garfield »

Richard Russell wrote:
Sun May 09, 2021 2:56 pm
guesser wrote:
Sun May 09, 2021 2:46 pm
That is horrifying, and anyone who sets their TV up to force widescreen for 4:3 material should have their TV remote privileges revoked. Broadcasters who set the aspect ratio flags incorrectly should be fined per infraction :lol:
What's even more horrifying is the number of people who do watch stretched pictures, and when it's pointed out to them cannot see anything wrong. :shock:
I think a worse 'crime' is television broadcasters who, at source, crop the top and bottom off vintage 4:3 TV programmes, in a bone-headed way to produce 16:9 "non-letterboxed" shows.

( Not only that... but some even don't understand field de-combing... and they broadcast converted 1970s/80s TV shows with these interleaved fields obviously jagging especially in panning movement shots. )
:(

I fear that the original video/film is increasingly lost to time now... and all we have access to are these botched cropped digital conversions.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

garfield wrote:
Sun May 09, 2021 11:41 pm
Not only that... but some even don't understand field de-combing... and they broadcast converted 1970s/80s TV shows with these interleaved fields obviously jagging especially in panning movement shots.
To be fair, this is sometimes out of their hands. For example if the material was originally captured as a film recording, separating the two fields is then pretty much impossible.

The good news is that (arguably) the best method for de-interlacing, Martin Weston's 3-field-aperture spatio-temporal filter, is now out of patent protection and is available in software suites like FFmpeg. So there's no need to resort to some of the, frankly awful, alternatives.
I fear that the original video/film is increasingly lost to time now... and all we have access to are these botched cropped digital conversions.
Not in the case of the BBC! Enormous efforts have been put into preserving archive material without any irreversible degradation. If it originated on 2" quad videotape it will usually have been transferred via D3 tape, then the Transform PAL Decoder, then either DigiBeta tape or ingest into a digital storage system. The resulting programme looks better than it ever has, including when it was originally broadcast!

Admittedly 'non-technical' issues can get in the way. For example the BBC is currently repeating Fawlty Towers, but it's not the immaculate Transform-decoded version but some crappy transfer made years ago. Why? Because that version has already been cleared for Copyright, Performing Rights and so on issues, whereas the newer transfer hasn't. :(
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
Rich Talbot-Watkins
Posts: 1742
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Maximum overscan screen size

Post by Rich Talbot-Watkins »

Richard Russell wrote:
Sun May 09, 2021 10:48 am
I don't think you have a lot of choice. Assuming anything other than square pixels (PAR 1:1) implies some kind of scaling, and scaling the output from the emulated BBC Micro - indeed anything with sharp unfiltered edges - will result in artefacts. They could include aliasing or blurring, and quite likely both, and I think most people would conclude that they are unacceptable.
Not for me. I think, not only are they entirely acceptable, but are also the only way to get a decent representation of MODE 7 without changing the appearance of the glyphs. I would be perfectly fine with an emulator which scaled and filtered rendered scanlines to a more precise ratio. No idea if I'm alone on that though.
User avatar
Richard Russell
Posts: 2230
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Maximum overscan screen size

Post by Richard Russell »

Rich Talbot-Watkins wrote:
Mon May 10, 2021 10:18 am
I think, not only are they entirely acceptable, but are also the only way to get a decent representation of MODE 7 without changing the appearance of the glyphs.
I certainly don't want to re-start the heated, and frankly at times quite unpleasant and personal, argument about MODE 7 glyphs. I would simply say that scaling (that is, scaling of an unfiltered signal) does change their appearance, so you are comparing two different ways of doing that rather than one that changes their appearance versus one that doesn't.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
Post Reply

Return to “8-bit acorn emulators”