A celebration of Ceefax

[ppppenguin]

A look back at Ceefax, which ended along with analogue TV transmissions in 2012:
https://www.bbc.com/ideas/videos/a-love-...x/p06gwxp2

[Nick]

Oooh! I remember those days.

The first serious business I was a director of produced Ceefax-compatible systems for a lot of the big UK travel agents - all DEC OpenVMS backends running through a Ceefax/Oracle display driver and racks of modems.

Most of the high street travel agents had Teletext terminals capable of Ceefax/Oracle - BT developed an interactive system called Viewdata and launced a product using 1200/75 baud acoustic coupler modems called Prestel which airlines used to supply availability, so we piggy-backed on that and used the existing kit.

At one point we were in every high street travel agent in the country.

As an aside - we had the database of all the login usernames in use in all travel agents in the UK - whilst bored one evening, I plotted a frequency histogram of first names, and would you believe it, the median was shared by "Sharon" and "Tracy" (I included alternative spellings, e.g. "Tracey") - these two were something like 16% of all first names.

[Doodlebug]

Way back, I built a Ceefax converter to use on a non Ceefax TV.
Took it round to Gerry Well's place and we tried it out there,
in his front room, with Charles and his girl assistant in attendance.

It worked OK.

[ppppenguin]

The vertical info visible for a second in this video is not teletext. It's VITC (vertical inteval timecode)

https://www.youtube.com/watch?v=0E0Jd8fi4No

I built the Wireless World teletext decoder c1976. I did it the hard way on matrix board (veroboard without copper strips) and got it working eventually. Part of the problem was that I didn't have a high quality off-air video source at home. Video tapped off my Thorn 2000 was mediocre, had to detune the set a little to get any result. It was much better at university. In the TV studio at imperial College we had a Decca off-air tuner and a very strong, clean signal. It worked a lot better there.

I hope Terry joins in this thread as I think he was responsible for a large teletext based systen at the London Stock Exchange.

[Terry]

I hope Terry joins in this thread as I think he was  responsible for a large teletext based systen at the London Stock Exchange.

Well, in fairness, I can't claim full responsibility for it but I was an important member of the team.

I went there in late 1969 to work on a 22 channel cable network called MPDS (Market Price Dissemination Service) which, in itself, was innovative for its time in using computer generated graphics for the text. This was made possible by means of a large magnetic drum memory made by Sperry and called a Digi-TV. The drum rotated at 50 rpm so each track held the data for a full TV frame. The Ferranti Argus computer which drove it still used a magnetic core store!

It carried prices for nearly 800 stocks on 16 channels, had two pages for feature stocks such as fast movers not normally carried, new issues and so on. The final 4 channels carried company news.

It was an outstanding success but there was no more bandwidth for additional channels and, despite many requests, there was no real possibility of producing the information in colour. The requests came about because jobbers price boards on the market floor and in the broker's offices used red and blue marker pens to indicate falling and rising prices respectively. A quick glance at one of these boards was sufficient to see if the market was rising or falling without reading the actual prices.

The announcement of CEEFAX, followed shortly by ORACLE pointed the way to a possible solution and I was charged with researching Teletext and following its progress to see how we could best use it. There was no way that the delay of up to around 25 seconds to receive a page was in any way tolerable but using all 16 lines and reducing the magazine size to around 70 pages gave an average access time of about one second which seemed to be ok.

I did, in fact, improve on this and devised a system whereby the incoming syncs would be stripped off in the receiver and replaced with locally generated syncs with the field sync delayed by multiples of 16 lines determined by decoding the requested page number. Only 50 pages would be carried in each 16 line block and each channel could carry the full 800 pages spread over 256 lines.

However, this never got beyond the drawing board because the times, they were a-changing ...

With improving communications facilities becoming increasingly available, some of the larger firms were moving out of the city, leaving only their dealers to carry on trading. One broker moved to Tunbridge Wells - and there was no way the cable system was going to get  that far!  So, the decision was taken to go for a wired teletext solution - it had to be described like that to avoid confusion with BT's planned service. Eventually, though, BT applied to register Viewdata as a trade mark but it was refused because it was judged to be a generic description. So we could all start talking about viewdata systems while BT reinvented their service as Prestel!

Being a wired system, it could also be offered to provincial brokers for the first time. Ever conscious of the speed comparison with the existing cable system, we wanted something a bit faster than the standard 1200/75bps speed which took 8 seconds to write a full page.  The fastest baseband modem available at the time came from a Canadian manufacturer, Gandalf, and worked at 9,600bps. Hardly fast by modern standards but it meant that a full page could be transmitted in a second.  As the line of price changes rarely reached the end of the row, actual refresh speeds were faster than this. Unfortunately, these modems required a metallic circuit to function but BT practice was to add a DC block to lines crossing from one area to another, so this speed was only achievable in the central area which was fine, as it still covered all the users used to the cable TV service.

Any user further out had to be content with a 1200/75bps service.

Terminal were fed from muxes with, initially, 8 terminals fed from each mux. As the input to the mux also communicated at 9600bps, the actual sped to the terminals could be slowed down if other users were also downloading data but the worst I ever saw was a brief slowing up or down as two requests overlapped for part of the page. In theory, all 8 terminals could have been fed with simultaneous 1200bps data on occasion but the probability of that happening was virtually nil.

The original MPDS was a standalone service but, as time progressed, there were more and more demands for much more data processing than simply being a large data store for pricing and the Argus was now merely a terminal device driven by EPIC (Exchange Price Information Computer) as was the new service, which was named TOPIC (Teletext Output Price Information Computer)

TOPIC could, in theory, handle an infinite number of pages, thus enabling a massive expansion of the amount of information handled. It went live in 1980.

[Terry]

Like Jeffrey, I also built the Wireless World teletext decoder. As this was well before Texas released their TIfax decoder, it was the first (and only!) decoder available for my early Stock Exchange experiments!

Like Jeffrey's, it was also rather touchy and error prone. This was mainly because the group delay specification for Teletext is far tighter than found in the average TV IF strip of the time. We also got a Decca monitor receiver which did improve things considerably but setting the optimum data slicing level was close to impossible - switch from CEEFAX to ORACLE, for example, and you would need to set it again!

In hindsight, the solution would probably have been to incorporate a peak level detector and set the slicing level at 50% of that, but it just didn't occur to me at the time!

[Nick]

The Tunbridge Wells lot would be KB. They were clients of ours as we were based in TW too (Vale Avenue, really close to Union House and KB).

We supplied massive videotext systems to many financial companies and also to many large tour operators, e.g. SunMed and Butlins. Originally based on PDP/11s running RSTS/E, we moved to OpenVMS, initially V4.1 ISTR...

[Terry]

   

Notes:

The separated graphics above the and below the double height line should be flashing.

The second row of the double height text contains text saying : NO DOUBLE HEIGHT.

The yellow underline is produced using  New Background and contains embedded text, also in yellow, saying NO BACKGROUND COLOUR.

The three rows of colour bars are produced using Graphics Hold with Alpha colour control characters on one row and graphics control characters on the next.

The third row used the New Background method.

I designed the other test pages to assist the Servicing guys as, in the City, for obvious reasons, all service calls were made on foot, so I saved them having to cart lots of hefty test gear around with them.