drgeoff
Posts: 10343
Joined: Wed Jan 25, 2012 6:39 pm

Re: composite resolution too low to be of use for programming?

Thu Feb 23, 2012 10:39 pm

jojopi said:


drgeoff said:


Indeed not possible with the RP.


Do you mean to say that the Pi's overscan does not extend into any of the lines where any TV will recognize a teletext clock run-in, or that the available dot clocks on the Pi are neither high enough nor sufficiently close to a multiple of the teletext bit rate to allow the generation of a decodable waveform?



Those questions have caused me to realise that I wasn't thinking imaginatively enough before I pronounced "not possible".

For some reason my brain was locked into thinking that the GPU would need a couple of special areas into which ASCII characters would be loaded and dedicated circuitry would then covert that into teletext lines to be inserted into the composite video output.  Of course no one is likely to design a GPU that does that, now that teletext is effectively dead.

As jojopi has intimated, the telext lines can be thought of as just pixels whose values are set to fully emulate the clock run in and data portions of the teletext waveform.  Then the two questions posed are highly pertinent and I cannot answer either of them.

Thinking some more I'm not even convinced that the second question is critical.  The pixel clock does not need to be a multiple of the teletext clock rate; it does need to be high enough to satisfy Nyquist.  (That means higher than 6.9375 MHz for UK teletext).  Computation of the pixel values could be less intensive if the pixel clock has a fixed and preferably simple relationship to the teletext clock.  Is the GPU or the CPU the best choice for calculating the values? I don't know enough about the SoC to even hazard a guess at that.

So, I certainly retract my previous assertion of "not possible".  Maybe yes, maybe no.

carveone
Posts: 2
Joined: Wed Feb 22, 2012 4:08 pm

Re: composite resolution too low to be of use for programming?

Fri Feb 24, 2012 6:31 pm

I was thinking that the problem would be that the composite output stage would undergo some sort of filtering in order to smooth the picture and that would be the problem.

From a very naive standpoint - the one that makes you fall over with surprise if it actually works : 720 pixels in 52us is 13.846MHz which is very close to twice 6.9375MHz. Given the clock run in and framing sequence: 10101010 11100100, that locks the teletext clock to the data, it might be ok.

Now, with the best of intentions, I somehow doubt putting two white pixels (actually 66% isn't it?) and then two black for the 1 and 0 will actually work, but it would be pretty darn cool if it did! Something else to try in the list of thing to try.

Phil Spiegel
Posts: 210
Joined: Tue Jan 17, 2012 8:17 am
Contact: Website

Re: composite resolution too low to be of use for programming?

Fri Feb 24, 2012 7:02 pm

IF the Colour Burst can be turned off or disabled, then the resulting monochromatic video will not be ruined by  subcarrier, and 80 character text would be readable on a monchrome (not cheap shadow mask or PIL tube) CRT display…an LCD panel of a TV should be perfectly adequate: e.g. 1024 x 768 minimum native, scaling the 576 active lines.

Most 7"LCD screens only have about 240/280 lines – so halving vertical 'domestic' resolution, as well as limited horizontal size.

It was an early hardware mod on a BBC model B micro to add colour, or make it switchable on its baseband video output. (A capacitor linking the s/c from the modulator's feed,  to the BNC)

Unfortunately, in many ways, later colour tubes had lower resolution than their predecessors! and particularly towards the edge of the screen – because customers preferred slim TVs (110 degree tubes) instead of deep heavyweights which doubled as room heaters.

However, a very early (pre-release) demo of the BBC B at the IEE showed that it could redefine its font sizes: even to fill the screen with a single letter! (very legible from the back of the hall)

The Archimedes/RISCOS introduced Anti-aliased text (which windows barely understands?) as used  in broadcasting, and scaleable fonts  … hopefully Linux is not a backward step,,,  or [ I'll be running RISCOS on mine-) ]

drgeoff
Posts: 10343
Joined: Wed Jan 25, 2012 6:39 pm

Re: composite resolution too low to be of use for programming?

Fri Feb 24, 2012 7:43 pm

carveone said:


I was thinking that the problem would be that the composite output stage would undergo some sort of filtering in order to smooth the picture and that would be the problem.

From a very naive standpoint - the one that makes you fall over with surprise if it actually works : 720 pixels in 52us is 13.846MHz which is very close to twice 6.9375MHz. Given the clock run in and framing sequence: 10101010 11100100, that locks the teletext clock to the data, it might be ok.

Now, with the best of intentions, I somehow doubt putting two white pixels (actually 66% isn't it?) and then two black for the 1 and 0 will actually work, but it would be pretty darn cool if it did! Something else to try in the list of thing to try.


Filtering, if any, should not be a problem as the teletext signal is lower bandwidth than composite colour video.

SD digital video conventionally uses a 13.5 MHz pixel rate.  (  A nominal UK PAL spec active line is 51.95us which would be just under 702 pixels.  The 720 pixels in a digital active line gives some slack which is enough to cover the analogue tolerances on where the active line starts and it length.)

The essence of sampling theory and Nyquist is that a waveform can be reconstucted from samples if the sampling rate is at least twice the highest frequency component present in the waveform. With the pixel clock not being an integer multiple of the teletext clock rate it would not be a case of two 66% pixels for a '1' and two black pixels for a '0'.  There would be pixel values between 0 and 66% and they would vary along the line as the phase of the pixel clock changed relative to the phase of the teletext clock.  Might better be done with lookup tables than repeated calculations.

A synthesised  teletext clock needs to be of quite accurate frequency as the clock recovery circuit in  a decoder has a high Q in order to recover the clock from signals where the clock energy is low.  (Recall the teletext 'clock cracker' test page.)

drgeoff
Posts: 10343
Joined: Wed Jan 25, 2012 6:39 pm

Re: composite resolution too low to be of use for programming?

Fri Feb 24, 2012 7:59 pm

Phil Spiegel said:


IF the Colour Burst can be turned off or disabled, then the resulting monochromatic video will not be ruined by  subcarrier, and 80 character text would be readable ..



It isn't the colour burst that needs turning off; it is the modulated subcarrier.  The way to do that is to make the colour difference signals be zero.  That is, to only generate video in which every pixel has the same value for its Red, Green and Blue components.  It is no coincidence that such video contains only grey scales.

(Strictly speaking "monochromatic" means "one colour"; not necessarily black and white.  Too late to put that one back in the bottle. )

Phil Spiegel
Posts: 210
Joined: Tue Jan 17, 2012 8:17 am
Contact: Website

Re: composite resolution too low to be of use for programming?

Fri Feb 24, 2012 8:52 pm

I meant 'not adding the subcarrier' (as was the situation with the BBC mod I described) :- by saying 'switch off the burst' I was implying no colour coding (subcarrier) either -since there would be nothing to reconstruct the frequency or phase from  - but also with the additional feature that, identified by the lack of burst, a monitor would/could/should switch out its 4.43MHz notch filter and therefore be capable of showing the full 5.5MHz bandwidth.

Phil Spiegel
Posts: 210
Joined: Tue Jan 17, 2012 8:17 am
Contact: Website

Re: composite resolution too low to be of use for programming?

Fri Feb 24, 2012 8:58 pm

As for 'monochromatic; I meant exactly that! - it might be 'grey' - but I wasn't going to discuss colour temperature of displays, Illiuminant C D or otherwise 8-).

Equally, many colour monitors provided an option to switch off  guns giving eg a green screen free of convergence errors -or used a long-persisitance green phosphor if monochromatic and  intended for vdu use. I thought theearlier post made the  point clearenough though.

fanoush
Posts: 508
Joined: Mon Feb 27, 2012 2:37 pm

Re: composite resolution too low to be of use for programming?

Mon Feb 27, 2012 3:28 pm

As for generating teletext, there is a solution in python here

http://al.robotfuzz.com/conten.....t-software

BTW, see also  generating dvb-t http://bellard.org/dvbt/ . This is not applicable here but it is similar crazy idea.

trs79
Posts: 11
Joined: Fri May 25, 2012 10:10 pm

Re: composite resolution too low to be of use for programmin

Tue Jul 10, 2012 10:06 pm

I just hooked up the composite out to a tv grabber and ran the osc program from the zvbi tools. Unfortunately no matter what combination of overscan I tried, there wasn't any activity in line 21 of the VBI, so it appears the Pi doesn't allow writing to that area.

Do any of the engineers know if there is any way to get at the vbi area?

LuaPie
Posts: 11
Joined: Tue Jul 10, 2012 12:52 pm

Re: composite resolution too low to be of use for programmin

Sun Jul 15, 2012 3:13 pm

Composite resolution is possible, the YaBasic programming thing that came with the Playstation 2 used composite. I think it can get 55 characters across the screen. The main problem YaBasic had was the lack of a keyboard and mouse to navigate (unless you bought them seperately) and a lack of documentation and the thought that if you really wanted to do programming, you might aswell just do it on a proper computer.

tahrey
Posts: 3
Joined: Fri Oct 19, 2012 9:03 am

Re: composite resolution too low to be of use for programmin

Fri Oct 19, 2012 9:50 am

If a personal account is of any use...

I've recently been re-introduced to the 16 bit computing world on buying a Philips monitor off eBay for my Atari ST ... which happened to come with an Amiga 600 and a large bundle of software :? :roll: :lol:

The Miggy's computer-to-monitor cable was actually damaged, leading to the interesting quirk where the screen that came with the machine could then only be used with its older rival. But, no matter - unlike the ST, the A600 has 3x RCA composite/stereo output built in!

And I must say it actually works quite well. This Amiga, after all, has modes from 320x200 going up to 1440x576 on a standard-definition monitor (and a couple VGA ones if you hook up a multiscan). The very highest ones still displayed on both the CRT and LCD televisions I connected it up to, but weren't exactly usable. You'd need a special reason for trying to use a 1280 or 1440 pixel wide mode for anything on a standard def TV. I can only assume that, given how it also had a rather slow update and very limited colour depth - 4 colours from 64 instead of 64 from 4096 - it was meant for very detailed "serious" work on a monochrome (and therefore effectively "infinite" horizontal resolution) screen with an anamorphic lens in front of it as a cheap substitute for a proper hi-rez monitor...

However, the lower modes look just fine. 320x200 thru 360x288 for gaming are perfectly crisp and clear. 640x200 thru 720x288 are good for regular productivity uses on my old 14" CRTs, no problem reading the text at all. It's not quite pixel-sharp, especially on the one that's actually a salvaged CCTV monitor (makes little difference in this day and age, both monitors and analogue TVs need a freeview box) which only appears to have about a ~450 pixel physical horizontal resolution, but you don't have any trouble making out what each letter is with a standard 8x8 font.

Better yet, 640x400 thru 720x576 look just spiffy on the LCD - it basically has a built in "flicker fixer" in order to upscale interlaced material to full screen progressive, after all. Interlace mode still works on the CRT, but it's kind of hard on the eyes because of how any single-height horizontal line (including lines that are part of letterforms) flickers at 25Hz instead of the just-about-tolerable 50. On the LCD, it's steady, smooth and readable, with just a little shimmer around any moving objects. I think the screen doesn't have a quite large enough screen buffer (probably has 1mb? which means with a typical 18-bit LCD colour depth, you can only fit 704x576 not 720x576), so there is a little bit of uneven-looking horizontal resampling in 80-column mode, but it's not too bad. ((NB this happens even with smaller resolutions in the same actual "mode", as the Amiga achieves, say, 640x512 by simply limiting the active screen area to the central 88% of the actual generated signal, and the rest of it is a blank "overscan" border that would normally disappear off the side of a TV - my CRT can actually manage about 680x540 maximum)).

There's also a little bit of horizontal colour smear around finer objects, but it doesn't affect the *monochrome* clarity. A pure primary colour on black, secondary colour on white, or one colour on another will give a fuzzier result (40-character is about your absolute limit for any kind of readability), but secondaries on black, primaries on white, and most particularly black/grey/white combinations are nice and clear.

All in all you can get a very nice output for word processing (actually tested!), programming, using the console (I totally don't understand AmigaDOS even after reading the manual several times, it's just weird), a nice high-contrast GUI (workbench themed et al) and the like in 80-90 columns over a decent composite output with a moderately recent (last 20 years?) TV. With 25-32 lines on an interlaced CRT, and at least 48 lines on even the cheapest, nastiest, smallest standard-def LCD.

Wouldn't recommend 6x6 font for anything but all-caps labels, though. Like the Atari used for disk and file icon names :-)

I've also run PCs via converters from 640x480 up to 848x600 (and, with internal downconversion, 1024x768), which worked with varying degrees of over/underscan and readability. I still found the best results were to be had by getting an advanced-level driver (either OEM or third party tool) which let you tweak the exact resolution and timings, setting the equivalent of a standard 720x576x50 overscan screen (something like 768 x 625 actual lines... the interlacing was done separately, at least, so you could set it to 50p with 625 lines) for the actual signal timing, and then defining a custom resolution within that frame to nicely fill the display without losing anything important in the corners, say 688x528 (you can usually guess that the extreme edges of a windows screen with a maximised program are going to be, clockwise from top left, Window Menu, Close Box, Clock, and Start Menu).

Question is, what resolution does the Pi default to, especially on composite if it can autodetect what output is being used? And does it have any kind of built in de-flickering filter? IE something that will blur slightly between the individual lines of a full rez interlaced screen? If it's 640x480 with a moderate filter, preferably a software switchable one (ie it can be turned off for use with an LCD TV) we're good to go for basic use. If it's higher with either an overly aggressive filter or none at all, that makes things a bit more difficult.

(Incidentally, in terms of filters, back when I was manually making VCD and then DVD menu images from scratch, I found you could get a very good illusion, on a CRT, of full vertical resolution with minimal or no flicker on the text and finer details by pre-filtering the image; basically I applied a one-pixel vertical motion blur to the whole thing after finalising the look and the layout, then did a couple test runs to determine whether it looked best with no filter, full filter, or an image that merged 50% between the two. Usually one of the latter tended to win, depending on actual contrast and text size, so something like a 50 to 75% vertical softening filter might work well if you had to choose a single "strength" setting. Often it would allow somewhat smaller, readable detail text than could be displayed either unfiltered or in a 240/288-line mode, as well as a finer-lined font or more striking high contrast outline/shadow effects for the titles, without producing horrific flicker. Of course, it had no effect on the horizontal resolution...)

Hope that's maybe of some help or guidance!
:ugeek: :mrgreen:

tahrey
Posts: 3
Joined: Fri Oct 19, 2012 9:03 am

Re: composite resolution too low to be of use for programmin

Wed Oct 24, 2012 8:36 am

Phil Spiegel wrote: Equally, many colour monitors provided an option to switch off  guns giving eg a green screen free of convergence errors -or used a long-persisitance green phosphor if monochromatic and  intended for vdu use. I thought theearlier post made the  point clearenough though.
So THAT'S what that was for! We always thought it was just for reducing eyestrain off of trying to do WP with black text on a glaring white background. :lol:

But then again we always used our own green-switch equipped monitor with a computer that had a relatively wide colour palette (512 rather than 8 or 16 eye-rending primary/secondary colours) that could be altered with a fairly standard desktop utility. I found inverted shades that approximated a typical amber screen (later, on being given an IBM with an amber Hercules display, I found out how strangely close I had got just with random tweaking) with a couple of highlight colours was the easiest on the eye when doing "serious" work (much kinder than the default primary black/green/red on white). It also helped that our particular Philips must have been very well made - the R/G/B guns were in perfect alignment all the way out to the corners, and it had a pretty small dot pitch, so text -clarity- wasn't an issue at any point...

tahrey
Posts: 3
Joined: Fri Oct 19, 2012 9:03 am

Re: composite resolution too low to be of use for programmin

Wed Oct 24, 2012 8:41 am

drgeoff wrote: SD digital video conventionally uses a 13.5 MHz pixel rate.  (  A nominal UK PAL spec active line is 51.95us which would be just under 702 pixels.  The 720 pixels in a digital active line gives some slack which is enough to cover the analogue tolerances on where the active line starts and it length.)
Hmm, that would explain the slight iffiness in horizontal pixel placement on my LCD then ... I wonder if there's some way of tweaking the Amiga to have a very slightly slower clock rate and so 18 less pixels across the screen, but all of them perfectly aligned?

(Too bad I can't get anything except a load of very low contrast greyscales out of the ST when connected to that screen... totally baffled what might be causing that. Could use it to make a comparison of 80-column mode clarity and stability otherwise... it only offers 640 pixels unless you do some hackish programming, but it does have full width borders (of unknown pixel dimension) either side and I have a tape measure... :D )

Return to “Staffroom, classroom and projects”