composite resolution too low to be of use for programming?

[mixedfruit]

I have just had a thought...

I have not seen a r-pi used on a portable 14" (ish) crt tv in composite mode yet?

if developing countries are going to learn to program, are they not most likely going to be using old portable crt tv's and connecting it to the composite output of the pi?. Can you imagine trying to use for example the python gui on a fuzzy composite tv! the old c64/speccy etc were limited to around 256x192 pixel displays and 32x24 characters due to this inherent composite video smear picture problem(and the width of the phosphor lines on the tube)...yes, higher res screen modes were available but the text was then totally un-readable.  im also a bit worried about the linux distro resolution on the pi (both in native text and x desktop) if thats going to be a readable res on a small composite crt tv... has anyone on the pi dev team connected the pi to a old portable tv and is the linux gui readable? + is the composite output pal I, pab b, pal g, pal n, pal m, ntsc, ntsc-m, ntsc4.43, secam, 50hz,60hz or another flavour, or combination of above?

[Chromatix]

You should be able to use 640x480 (VGA) resolution, which isn't so bad.  You might need to use larger fonts than you would on a proper monitor, but a bold 8x8 font - giving an 80x60 console - should be readable enough for basic (or BASIC!) programming.

Given that I learned on a BBC Micro whose highest resolution allowed just 80x32 text, and didn't even have a proper text editor, I wouldn't be too worried.  The likes of the C64 and Apple ][ didn't even have that capability, and a standard VT100 series terminal had an 80x25 matrix.

[panzerboy]

There are two main reasons why resolutions on old 8 bit micros were so low.

Most important was memory. Look at the tricks the Spectrum pulled to get 'hires' colour graphics 256x192 single bit with an overlayed 32x24 16 colours. This took up a little over 6k a significant chunk from an 16k RAM machine. The other part of the memory equation was because the graphics memory was shared, the screen refresh meant the CPU couldn't access the memory. So the more memory you threw at the screen the less time the CPU had to do its work.

The other reason was RF modulators. 640x256 on the BBC looked dreadful through an RF modulator, composite was usuable if a little fuzzy (which encouraged folks with enough dosh to buy RGB monitors).

I wouldn't want to edit text at more than 288 lines (PAL), more than that and the interlace will make horizontal lines flicker.

I suspect 640 pixels in width is a little too much for composite, 480-512 should look fine though (60-64 chars)

[ctoon6]

Id imagine eventually when oled technology is put into large scale production, cheap displays could be printed out by the roll. So something like a 10'' 640x360 (1.77:1 or 16:9) could end up being sub $40 in the next 5-10 years, perhaps sooner. A whole raspberry computer system (mouse/keyboard/screen/raspberry pi[possibly a solar panel]) could be sub $100 and run off a solar panel or a crank generator.

[roelfrenkema]

What a load of crap really, you want higher resolutions? Just ssh into console and you can have any resolution you want.

[mixedfruit]

thanks all for your replies, so it should be a bit better than i feared, but still possibly not quite usable for python?   and i cant wait for the flexi printed monitor although possibly roelfrenkema mis-read the question i asked? it was not about higher resolutions, it was about the maximum usable resolution (from experience) on a composite o/p to 14" crt tv.  (thanks anyway). having not used linux at a low res like 640x480 is it quite usable? or a bit like windows xp at 640x480 where everything is so large that output screens wont scale down enough to fit on the screen, menu's disappear off the screen and won't allow you to scroll down far enough to click on the bottom item? i would have tried it myself using debian but i only have a pc monitor and it does not support the low res of 640x480....for some annoyingly bizarre reason!

[Chromatix]

It very much depends what software you're running.

If you stay at the text console (or, nearly equivalently, in a terminal emulator in X11), you should have no real difficulties - and this is possibly the mode you would use for Python.  This is basically what I assumed above.

For GUI apps in X11, you might find that some windows refuse to resize down to the screen resolution, and thus will overflow beyond it.  This *is* annoying (personal experience from an early netbook with 800x480), but you can still move these windows to reach the hidden areas using Alt-Drag.  This will probably be less of a problem if you choose a lightweight desktop such as LXDE or XFCE, as opposed to a full desktop like KDE or Gnome.

In both text and X11 modes, the size of text can be customised to strike a balance between readability and space.  The defaults should be pretty readable, so adjusting these a-priori is not necessary.  It should be fairly easy to find out where to adjust these settings.

One application that will definitely suffer from a low resolution is the web browser.  VGA screens were already a limitation for those 15 years ago when I first encountered the Internet.  Fortunately, Web browsers tend to have their own font customisation settings which might help some sites.  If all else fails, you can use the Lynx or Links browsers which run in text mode - very good indeed for reading documentation on a small screen on a small computer.

(Add two fat ladies and get sweet sixteen?  I'm not sure how that works...)

[rurwin]

From memory, if you can use composite video, then you can use 80x24 (eg BBC micro mode 0 was 80x32 or 640x256 pixels). It isn't perfect, there is quite a bit of bleeding, but it is usable. A cheap TV could render 40x24 very well and that is what most of the micros of the time used as standard. If a teenager is going to buy all the kit themselves, then they are probably limited to a second-hand CRT TV which will be at least this good, maybe better than it was in the 1980s.

I've just done some experimentation here, and emacs is barely usable in a 40x24 window but it does work. 80x24 is of course how it was designed to work.

So in the worst case, it is possible to program in text mode with any TV. I think we need to find out how to switch the text mode resolution from the command line, and have that easily available on the default SD cards. I'll do some digging now but if anyone happens to know the correct incantation...

[Chromatix]

I think that would be done using the consolefont system, which is probably handled by a different init script in each distro.  The appropriate incantation should be derivable from there.

BTW, I would probably recommend nano to Linux newbies rather than vi or emacs.  Being much simpler, it's much harder to get lost in - and it even has on-screen help which explains how to exit (etc).  All good features gained from a user-centric rather than hacker-centric design.

[Steady_Bear]

Chromatix said:


BTW, I would probably recommend nano to Linux newbies rather than vi or emacs.  Being much simpler, it's much harder to get lost in - and it even has on-screen help which explains how to exit (etc).  All good features gained from a user-centric rather than hacker-centric design.



Heathen! Vi only, Grr.....*

I recall there being a problem with CRT TVs having pictures larger than the screen due to the way the work (Hence important info being in the middle of the pic). Is this a problem only with RF feeds, or does it exist with composite too. I don't have a TV, so no way of finding out. If this problem does exist, then that may be a bigger issue.

* I'm being really, really serious by the way.

[Tomo2k]

Yes indeed, overscan is part of PAL (and probably NTSC, but I don't like NTSC).

PAL specifies 625 lines, of which 576 lines are (generally) expected to be visible.

In the UK, some of these extra lines were used for Teletext information (that might be an amusing way to have Help info, or even a console!)

Broadcast reference monitors can show the full image (inc. the bit at the top used for Teletext), but most consumer screens will not. The Broadcast ones generally have an outline marked on them to show the part of the image that will actually be visible.

Horizontal resolution is an interesting one, given that the PAL and NTSC signals are analog across the width so there isn't actually a fundamental 'pixel' idea.

- Wikipedia suggests 720 pixels/line, though I have no idea where it gets that idea from.

When I've used PAL TV as a display I usually used 800x600 resolution, but there was some cropping. I forget how much.

[Condemned]

For PAL (and probably NTSC too) there's a portion of the 'visible' video signal that's considered 'text safe' and will be visible on all TVs. For 4:3 SD TV, the BBC used to use the centre 80% width and 80% height as 'text safe' for captions, titles etc.

Vertically, this works out as the centre 230 lines of each field (two fields per frame, giving 460 lines interlaced). Most modern TVs will show much more than this though.

I would guess at 640x480i to be reasonable for most PAL TVs - some modern LCD TVs might even make it quite pleasant!

If you really want more details, I've got a page of notes on composite video timings.

[Steady_Bear]

So, what I'm getting at in a round-about sort of way:

How do you make sure you can view the whole terminal on a composite screen, or does the GPU->composite generation take the overscan into account and pad the data with black edges?

If not, is there a way of producing drivers so people using CLI don't have their first and last few characters disappearing?

X isn't such an issue as you can recenter open windows (assuming you aren't relying on the taskbar at the bottom, which may drop off. But, it may still put people off the device if it is a problem.

This may all have been considered, without getting my hands on a) a Pi, b) a TV I'll never know! Unless, someone with more knowledge on the hardware posts an answer.

[DavidS]

Ok with Composite (both PAL and NTSC) you have 640 pixels + overscan for the horizontal resolution (most will do 720 with Overscan) though due to the limited frequency of the color signal (3.57954MHz for NTSC or 4.43361875 for PAL) the posible rate of change for color is approximately one-half that, so for 640 by X graphics on a composite display you would have to either use a monochrome signal (no color carrier) or interleave the color between frames to get a good sharp image.

[DavidS]

And yes for a full vertical resolution you do need interlacing, this does cause some flickering.   The flicker can be reduced enough to be comfortable by putting a simple $5.00USD polarizing filter (vertical orientation) in front of the display.

[richardp]

Steady_Bear said:


Heathen! Vi only, Grr.....*

* I'm being really, really serious by the way.


My word! .. what a way to scare people away from Linux.. Vi!  heavens above!  Xerox invented the GUI ~40 years ago, I am not going back to typing cryptic commands to copy/paste/delete, and to be quite honest I wont force that on anyone

/me waits for the Vi fan club to attack and is ready with his Emacs/SourceInsight stick

[Steady_Bear]

richardp said:


Steady_Bear said:


Heathen! Vi only, Grr.....*

* I'm being really, really serious by the way. **


My word! .. what a way to scare people away from Linux.. Vi!  heavens above!  Xerox invented the GUI ~40 years ago, I am not going back to typing cryptic commands to copy/paste/delete, and to be quite honest I wont force that on anyone

/me waits for the Vi fan club to attack and is ready with his Emacs/SourceInsight stick


Scare them away? Trial by fire, only the strong shall survive, etcetera.

** I wasn't really being serious!

[Chromatix]

Using 512 lines of the display is too much even for PAL - I remember on the few occasions when I used a BBC with a TV, it was necessary to realign the scanout by one (text) line so that it would all fit within the visible tube area.  Two lines would be too far.  There was no problem with horizontal alignment though.

There was no such problem with RGB monitors - and although these still had trouble resolving the individual horizontal pixels of Mode 0, this didn't matter because the fonts were big enough to not require it.

So for PAL at least, 640x480 seems to be quite usable.  But what about NTSC?

[jwatte]

640x480 works on NTSC.

My first own computer (bought with allowance saved for over a year) had something like 20 rows of 22 characters -- programming could be done just fine. You just have to not have the tastes and requirements of a modern-day pro

[Vindicator]

All I can say is if your typing here you should have an out for your Rpi but if your a kid in a home without a computer or monitor, Composite or nothing may be your only choice.

Millions of game consoles are still used on composite video(Xbox,Xbox360,PS1,2,3,GameCube, WII etc. ad infinitude)

Composite is definitely better than nothing and all of us who went through the Timex sinclair/z81, BBC micro Etc. ERA have survived composite video LOL and even survived monochrome Era. (eyeball burning screen burnin monochrome)

To millions of kids this may be their only choice.

Not the best choice but the only choice, so let hope some of us are smart enough to make it work for them who may need it.

(P.S.) thankfully BASIC has pretty much died and Python and Kids Ruby is it's replacement and the tape drive has been replaced with SD Card's, at least they don't have to suffer those indignities.

[mixedfruit]

Well i decided to see what the score is running debian at 640x480 in oracles vm virtualbox, lxde and scale the window to 14 inches using a tape measure lol. (monitor settings at 642x481)  its awful! menu's are off the bottom of the screen, some menu's wont even display they just flicker and disappear (due to extending off screen, this includes the edit menu in python using idle). Output windows and prompts are no better some you can scale to fit, others just refuse. i tried adjusting the font size to squeeze more into the menu but not even close. So from my experiment i think we can quite safely say that running any x desktop in linux at 640 x 480 is a no-go, there just is not enough screen real estate ...  i then scaled upto 800x600 and its a different story, its real world usable! but i would think at the output quality of a composite output to a 14" crt (or even lcd) it would look more like a tv in the fog at 20 paces. So not ideal! the other thing i noticed (this may sound a bit silly) is that the linux boot sequence text is also very small including the login prompt. Could be a bit of a problem, and really needs to be a larger font or i expect your first experience owning one of these new boards through composite is text too small to read to do anything and thinking you need glasses! lol. So is a composite output limited to the nano editor (not vi !!) and no web?? :-0

[Joules]

Keep it in perspective, the composite output isn't for rooting tooting high end graphics.  It allows you to program in a text environment.  For simple programs and graphics it's fine.

Remember, the whole point of this project and try to put yourself in the shoes of someone in a position of ONLY having a TV to use as a VDU.

Sometimes I scratch my head at the expectations that people have for the Raspi.  It's not a CRAY.

[DavidS]

720X480 is quite usable on 98%+ of NTSC displays.  In my own HardWare Projects I have done quite a bit of composite video testing.  It does take a good of thought on the video output Hardware design, though I would imagine that BroadCom has this covered.

[Graith]

Excellent - I think it's a good thing to have limitations like this for new users and new programmers to get to grips with.

My first computer didn't have hi-res graphics at all - only text and I could display a single character in six blocks (for that old Asteroids game). There's lots of programmes you can write with only text display and it's actually easier for beginner programmers too.

[super_tnt]

The screen I plan on using also connects via rca but it gives out a resolution on the description so this means I can use the pi at that resolution, right?