Page 1 of 1

Re: Composite output: resolution and overscan

Posted: Wed Sep 14, 2011 11:21 am
by Emanuele
I assume that you'll get a framebuffer [email protected] (PAL) or [email protected] (NTSC). Is this a fair assumption?

What about overscan? While a few window managers are highly configurable, I would guess that most maximize windows to fill all the screen and put panels at the border. What about giving the option to let X use only part of the screen (e.g. 640x480 or 640x400)? Same problem with the Linux console I guess.

Somehow related, I've found this to simulate composite artifacts (e.g. color bleeding):

http://slack.net/~ant/libs/ntsc.html

It's easy to use and works well, but I don't know how realistic it is for high horizontal resolution. Anyone knows of alternatives? Incidentally, I think that an OpenGL ES 2.0 fragment shader that lets you see on a new HD LCD how a game would look like on an old CRT TV would be cool. While I have an OpenGL 1.4 card myself and I cannot check, I think that Stella has something that could be used as a starting point.

Unrelated (but there's no point in bumping a dead thread), can anyone with an alpha board confirm that you can use X without a mouse (AllowMouseOpenFail)?

Thanks in advance

Re: Composite output: resolution and overscan

Posted: Wed Sep 14, 2011 2:54 pm
by stuporhero
In days of old (think Amiga, etc) most outputs were 640x480/512 (NTSC,PAL) via composite. Whether this was a monitor limitation or hardware is beyond me I'm afraid. Beware interlace!

Also, I read a blog post... somewhere... the other day with someone with the same trouble, who figured out how to bypass mouse detection. I'm afraid it's down to Google to find the answer though :(

Re: Composite output: resolution and overscan

Posted: Wed Sep 14, 2011 3:33 pm
by Emanuele
Funny that you picked the Amiga! I had one and it was probably the most flexible system in that regard. The OS would limit you to 640x512 by default, but you could easily increase the resolution and open up the borders. On the other hand, on the other systems I think you were indeed very limited in what you could do.

Re: Composite output: resolution and overscan

Posted: Mon Sep 26, 2011 5:24 pm
by Bacan
I was thinking more of Apple ][ video on a USofA TV screen. Where readable text was 64 columns x 16 rows on a TV set. Or will it be broadcast/DVD/VHS quality video?

I'll expose my ignorance about TVs. Will the composite signal from the R-Pi work on all three types of TVs; NTSC, PAL and (something else). I've read in other forum posts where R-Pi boards are wanted to be used anywhere in the world.

Will we need to somehow select which of the three broadcast standards to output from the R-Pi?

Re: Composite output: resolution and overscan

Posted: Mon Sep 26, 2011 5:38 pm
by obarthelemy
something else is SECAM, which of course is far superior to the others ^^

Re: Composite output: resolution and overscan

Posted: Mon Sep 26, 2011 5:58 pm
by Bacan
Upon reading/digging further in the forum, I found this additional answer to my question.

We are still working in how the user can define these parameters. Probably a (text) configuration file on the SD-card. The same holds for the composite video output. It can do PAL-BGHID, PAL-M, PAL-N, NTSC, NTSC_J. It just a matter of programming the TV-out hardware. We might not support all standards from the beginning though.

So as a Developer, I can see where version/build control of an application for world wide release is getting complex, really quick!

Re: Composite output: resolution and overscan

Posted: Mon Sep 26, 2011 7:18 pm
by Gert van Loo
I had a Eurocom-II machine (6809). It had 16K (512x256) complete graphics screen. That is all memory from 0x8000-0xc000 was always displayed) On the Eurocom they got 80 characters on it by using a 7x5 font (with one pixel space). The SW would 'merge' the end of one byte with the beginning of the next to add a character. So it got an 80x32 text screen.
The 16K was taken away from the total 64K the 6809 had, so for some programs which required more space I would redirect the output to a file and add the16K to the working space. You could see the program running on the screen. You could easily recognize the stack point at the screen top.
I even used it to check for a 'running away' stack: You put the stack on the screen and see it go down further and further the longer the program run. That is real 'graphics debugging'.
Later I piggy-backed the 64Kx1 SDRAMs with another 64K and added bank switching. (The processor would switch in a 16K page, update it and switch it out again) Even later I replaced them with 256Kx1 SDRAMS Those where the days.....

Re: Composite output: resolution and overscan

Posted: Mon Sep 26, 2011 7:20 pm
by tufty
I'll expose my ignorance about TVs. Will the composite signal from the R-Pi work on all three types of TVs; NTSC, PAL and (something else).

NTSC : "Never the same colo(u)r" - Probably the worst standard to choose technically, because it's crap. 486 lines vertical, with Kell factor introduced restricts you to a vertical resolution of ~410 pixels or so. Add in its renowned quality of colour reproduction and resistance to colour bleeding, and you have a recipe for suckness. NTSC is / was used in the US, and can stay there for all I care.

PAL : "Picture Always Lousy" - Better than NTSC. Marginally higher resolution (576 lines, maps pretty well to 480 lines with Kell factor accounted for) and vastly better colour handling (i.e. your image doesn't bleed like a stuck pig). Likely, as the RasPi team are in the UK, where PAL is king.

SECAM : French version of PAL, more or less. SECAM will play on PAL sets and vice versa (but without colour). Sound and luminance encoding, as well as the number of lines, are identical, what's different is the way colour is encoded. As a brit, it shames me to admit that SECAM is, in fact, a better system in technical terms than PAL, and it was invented by the bloody frogs. Before we invented PAL, even.

The good news is that most relatively modern cathode-ray TVs and pretty much all flatscreen TVs with a composite input will at least have a shot at handling all 3 standards. A PAL TV might not be able to extract colour from (eg) an NTSC signal, but it should at least give image and sound.

[edit] Ah, we'll get the choice. Super!

Re: Composite output: resolution and overscan

Posted: Mon Nov 07, 2011 2:10 pm
by Burngate
NTSC : Never Twice the Same Color
SECAM : Something Essentially Contrary to the American Method
PAL : Perfection At Last
SECAM might be technically better in some ways, but not for the studio - you can't mix two SECAM signals with just an adder. That's why most SECAM studios originated material in PAL then transcoded for transmission. Now of course it's all originated in digits - and mostly HD - and transcoded, first to a compressed data stream (or several), then where necessary to analogue, often right at the transmitter. (I've put a longer version of this https://sites.google.com/site/burngateh ... AtLast.Rtf)

But of more interest is the way the Pi is going to be configured - if it's just a text file then it's easy. But if your TV won't show a picture if the standard is wrong (admitedly most should) then how will you edit it? Are the Pis going to be shipped ready-configured for the destination?

Re: Composite output: resolution and overscan

Posted: Mon Nov 07, 2011 3:15 pm
by Emanuele
Quote from Burngate on November 7, 2011, 14:10
... But if your TV won't show a picture if the standard is wrong (admitedly most should) then how will you edit it? ...

Personally, I would vote for a key combination during boot that enables something like speakup (http://www.linux-speakup.org/). I would then be able to use "ed" to edit the configuration file.

Re: Composite output: resolution and overscan

Posted: Thu Nov 10, 2011 12:30 am
by st599
Tufty: before who invented PAL.

Secam was a nightmare, it was only really used in transmission.

Re: Composite output: resolution and overscan

Posted: Thu Nov 10, 2011 2:50 am
by kme
And then there was SECAM-West (France) and SECAM-East (Sovjet Union) :-) Happy days or maybe not...