Hello and welcome back to broadcast focus.

My name is Russell Trafford-Jones.

Thanks for joining me on a show where we look behind the scenes of the media, entertainment and broadcast industry by talking to the people who make it happen.

As a small channel, I do want to just ask you to support it, obviously by watching, so it's a great start, but also by liking and subscribing.

It's a small ask, but it's very impactful.

And today we're on episode two of our look at Teletext, the transformational technology in the UK and around the world, not just for its subtitles feature, also known as captions, but also as a way of accessing a broad range of information in an age when the internet had yet to take off.

So do check out the last episode that we did on it, which is on the card here and also in the description.

So without further ado, Peter Weitzel, welcome back to the show.

Nice to be back.

Now, before we go to a recap, I touched on the importance and usefulness of Teletext, but how would you sum up its impact?

Well, basically, Teletext provided a news service and various other services instantly into the home, very much in the way in which we use the internet these days.

So that when you arrived home, you didn't have to wait for the news bulletin to get the news.

You just turned on your television set, selected text, and up came the text.

And you could then select whether you wanted news, national news, local news, weather forecast, programme listings or some other information.

So basically, it was a very primitive version of the internet that we know today.

It's probably worth just reminding ourselves what it all looks like.

This is a recreation of BBC Ceefax.

If I refresh the page, you can see in the top we've got that number was hunting through.

Perhaps if I type in another number, 601, into the remote, you can see that it's counting up or rather it's looking through the pages that it's receiving until it gets to 601.

And now we know what's on TV tonight.

This has been generated from the BBC website.

So we'd like to bring us up to date, Peter, and then we'll carry on looking at what it is that is Teletext.

Yeah, you can look at what the Teletext services are under two headings.

One is additional, which is the independent from the programme service.

That is things like news, sports results, and the like.

Text that you can see that is not really connected with the programme that's going on.

Or in fact, there can be pure data broadcasting.

BBC had a system called DataCast that did this.

More interestingly, is perhaps those that are associated with the programme service, the ancillary services of subtitles, programme listings, and PDC, which is a way of turning on video recorders in the days when we had those by a linkage from the broadcaster's transmission system.

Looking a bit more at the text services, they had multiple magazines and there's a lot of how you got the one line pair of the vertical blanking into, you know, that bit that lurks above the picture, gave you two pages per second.

And by determining if you've got say 80 pages in one magazine, how many lines you put on was how rapidly it updated itself.

We tended to look at about 14 seconds as about the read time for a page.

And then we look a bit further and you can then allocate more lines for one magazine than another.

And in fact, we can actually put multiple magazines of different numbers of pages per magazine on a particular line and then get all adjudged to try to get the 14, 15 seconds numbers there.

So, to be clear, magazine is all of the pages underneath the number one and number two.

Basically, Teletext has up to eight magazines.

They are, in engineering terms, zero is eight, which is mainly used for subtitles on page 888 or page 889.

And the others are used for different services.

So, in the BBC service, 100s are news, 200s are the stock market, 300s is sport, 400s are general magazine, as is 500, and 600 is the programme listings.

And 700s we use for special things on special occasions.

What happened next was the broadcasting bill came along, which meant that the government, in some peculiar reasons, had decided that the vertical blanking interval of the BBC was not being efficiently used.

And therefore, if any bit was spare, it could be sold off.

So, how does the BBC say that?

Not that it was necessarily particularly spare.

So, we have two things.

One is make it look full, which actually it did, and then to use all the lines efficiently.

And thus, if we have multiple services, rather than allocating, let's say, data broadcasting to one or two line pairs, it was a bit intermittent.

Let's see whether, if the data broadcasting wasn't using the line, we could get a Ceefax to use the line.

Ah, well, there was an interesting debate, which a statement from David Mellor, the minister, emphasising the use of subtitles, which are intermittent, but of great importance.

How he worked out that there will be some extra capacity for allocation, I just don't know.

But the bill, therefore, provided the capacity, can be notified by the Secretary of State to the ITC, which is the Interim Television Commission, which is the regulator for allocation.

Despite him having the full consultation, the BBC's response was, such assurances are welcome.

The cynical view is that consultation means different things to different people.

And quite what they were trying to achieve, I don't know.

But it motivated us to do something.

So we then moved to dynamic allocation.

Yeah, the BBC could be in a strange position of having to bid for the use of its space.

And there is no doubt that not only were they going to try to sell space on the television waveform, but also on the radio, for RDS on FM radio.

Most peculiar, I mean, it's quite interesting that the enormously relevant part of the television or radio waveform has such government attention.

I would say that anything that generates money is going to have the attention, surely.

To a certain extent, but who's going to be money?

So, as I said, data broadcasting, lots of continuous data broadcasting of things like the runners and riders for a horse race.

You don't actually have to send that data very often.

But there are some important commands in that, like the stop betting command, which is very important for a betting shop to know that the race has already started.

Therefore, no more bets must be taken.

And even though there are ways of error protecting the data, if you lost a packet or two of data, you didn't really want this to happen.

And you also had other issues with exactly how it was handled.

So we got one service, data broadcasting, which was occupying two or three line pairs because it had to, without delaying data coming from a number of different sources, you need that capacity.

And that meant that there were a number of lines that were mostly blank and Ceefax was, let's say, a bit squashed up.

So, wouldn't it be nice if we could have a connection between a data bridge, which is the unit that inserts the data from the Ceefax engine into the outgoing signal that noted that there wasn't any data broadcasting coming in and told the Ceefax engine to put out some more pages.

And that's what was done.

It was done, but we were never too certain it really worked.

But there was another thing that came in, which was that the Ceefax data itself wasted space.

There's a strange thing called the page erasure interval.

The header, which is the first row zero of the text, which says things like Ceefax and usually has the time at the top right, sets the page number for the following packets.

The content of the page actually has no page number associated with it.

So, you put up a header which says, I've got page 101, and it then says, I'm now putting out a packet with, in magazine one, which is the first packet or the second packet or the third packet.

And because of that, in early decoders, there had to be a field interval for the decoder to work out what was going on.

So, you put a packet zero shown here in red, let's say, at the end of a vertical blanking interval, and then in the next vertical blanking interval, you put the remaining data.

Packet 27 is something to do with the fast text links.

And then you start transmitting 1, 2, 3, 4, as we have in this demonstration, up to 11.

Here we're doing 26 packets on 12 lines.

And you notice that all of a sudden, you run out of data after packet 24.

You've got a lot of space.

What would that work out at 10 VBI lines worth?

And actually, in three vertical blanking intervals there, you can actually transmit it, not on 12 lines, but you can actually transmit it on 9 lines.

So, we had some redundancy.

This is an extreme example, but that wastes space.

So, could we use those yellow bits for other services?

So, let's look at a more sensible example.

As you see in the right-hand column, you can see that you can get 5 or 14 or 32 or 40 spare lines, packets of data, per second.

And if you've got a 26-packet page, you can see that you can sneak an extra packet through if you're using 5-line pairs, and you're sneaking almost a half a page through on 4-line pairs.

So, basically, as long as the stream has more than 4 VBI lines, there is enough spare slot, and that was probably enough to drop data broadcasting in.

Data broadcasting just works in ordinary packets.

And we did the same calculation.

And as you see there, the right-hand side of each of those things, other than a 24-packet page, works very nicely and generates lots of spare capacity, or at least has lots of spare capacity, which could be exploited.

So, that means that a 24-packet page is like the best optimization of use.

If you're not looking for anything spare to drop in, you'd go for that option.

Yes, because if you have got a blank line in the text, you don't transmit it.

Even a normal page, which is a header, 24 lines of text, 23 lines of main body, and then the FastText linked text, and then packet 27, which is the FastText linked number.

So, you just have two blanks there.

You think that page, a bit complicated, because that actually has got 1, 2, 3, 4, 5, 6, 7, 8.

So, that page is 18 packets, because the double height means that you don't transmit everything.

There's then a space before Syria, the space before Morvan, the space before Louis, the space before France, and then there are two spaces.

Yeah.

So, this one is basically just one line that's just picking up two.

So, you're saving.

Yeah.

So, you do have pages like that, which are less than the 26 packets that you would normally have.

Data broadcasting could use spare capacity, but it would have to wait until Ceefax page, you've got a blank line in the VBI, but that would delay data broadcasting.

Delay was something we couldn't do.

We actually had a contract, which said that we had to be able to get it to anywhere in the country in under, with a spread of 20 milliseconds, i.e. one TV frame.

So, just onto this idea, just for a second, understand the importance of the delay, because I remember when Freeview started and perhaps Freesat did this as well, your set-top box would be able to download firmware over the air and update itself, that type of thing.

Nobody really cares if it's delayed.

It's probably going to be delayed two days just for the time it finds that it's exact firmware that's floating over the airwaves.

Whereas here, I think we talked last time about sharing card information about cards, which are going to be blocked and perhaps as betting and things like that.

So, these are super kind of to the moment uses, which are not quite the same as just downloading.

Yeah.

Basically, the most important data that the BBC ever transmitted was the stock betting information for corals for the Grand National.

Right, yes.

Although, actually, we were putting out slightly delayed stock market information.

There actually was one or two bits of information which are absolutely up to date.

Also, some of the receivers in those days were not very good at handling a very variable data rate.

If you think that you were putting out packets fairly regularly on a data burst, if that then got held up, so instead of having one packet going out every other VBI, it sort of saved them up and then put 10 out of them in one VBI, the instantaneous data rate would exceed what the receiver could take.

So, it fell over.

So, if we give data cast a higher priority, so long as there are no more data broadcasting packets than spare in the page as a whole, the page isn't delayed, so that we could start with a header.

Then, oh, some data casts come along.

All right, we'll put a bit of data cast out for two or three VBI lines, and then we'll start the page.

As long as there were three slots available on that page, the page wouldn't be delayed.

So, you wouldn't actually be able to see what was going on.

So, that was good, but we also discovered there were still more spaces and the government found out they'd go and sell it off.

So, can we try to use them to fill packets from other pages?

The requirement could be stated, a system to give one packet type a priority over another.

So, we have data cast, which is the top priority, and then data stream A, data stream B, etc.

All right, let's have a look at how it actually worked.

A teletext stream is one or more magazines that are operating over the same VBI lines.

So, for instance, you could have a stream that was magazines four and five, because if you're transmitting over a number of VBI lines and you could balance the number of pages and get the cycle rate about right, because if you've got a certain number of pages in each, you can judge by changing the VBI lines and how many pages in each magazine and the magazines that you're putting together on those VBI lines to get the right 14 seconds answer.

So, if we have a 25 packet page and we're using three VBI lines, that takes nine fields to transmit at five pages a second.

But if we just gain one packet, it goes out in eight fields, which gives us six packet pages a second.

So, if you have a look there, you'll see in the middle lines, lines 11, 12, 13, there's a stream there, shown in red.

And all of a sudden, the lines above it, eight, nine, and ten, run out of packets.

And all of a sudden, the red line, the red packets, go 17 on line 13, and then use the extra lines, eight and nine, that become vacant to go out, and therefore it's transmitted more rapidly.

And likewise, you'll see the bottom three lines, again, at the right-hand end, all of a sudden, 17, which is on line 16, goes to 18 on line 12, and then 19, 20, 22, so basically, we have got something which is very, very solid.

Every line is being used with a packet from one or other of the streams that we've got.

So, with cross-stream dynamic allocation, that means that without it, perhaps I should say that each VBI line is strictly for one particular magazine, but we add in cross-stream dynamic allocation, we're allowed to move some packets on to other lines.

Yes, and you can see there, it doesn't take very much with slightly selected numbers, but they're not atypical to actually speed the service up quite a bit.

So, we have a system there, where if you knew what the dynamics of the streams were, so that you'd have stream A with magazines 1 and 3, magazine B with 6 and 4, and C with 5, 2 and 5, you could then allocate priorities for each line to say, okay, roughly speaking, this shows what the previous slide said, that the beginning of VBI, line 9 onwards, will have stream A, line 12 onwards will have stream B, and line 16 onwards would have stream C, if there's a packet there.

If there is not, we then can allocate another stream to it.

So, let's take line 9.

If there's no stream A packet available, you put out a packet from B, and if there was no packet from B, you put out a packet from C, or actually, you might put out a filler packet.

We'll come on to why those are important later.

So, it basically meant that you would put out whatever you've got available, according to that particular rule, which there, magazine A does have a little bit more priority than the other magazines.

Just to confuse things, there's packet 830, which goes out those days once a second, but with PDC, it can go up to five times a second, and that's also got to be put in.

Question regarding this.

Obviously, you've got to remember that this was all done in a day when memory was not easy to find.

So, today, the typical way of doing this would just be to whack everything in a buffer, have everything with a detailed header, and then whatever comes in goes out and gets sorted out at the other end.

Just remind me, why is it that we prefer to keep certain things on certain VBI lines, rather than using up the VBI lines, you know, as much data as we've got?

Okay.

There are occasions, this actually ruins it, but traditionally, you would put magazines on different lines.

It meant that, I've got an example later on, you can actually blank lines and reinsert different things on different lines.

So, in the basic traditional system, you would put magazines on different lines, so that if you wanted to, you could actually blank a line out and replace that magazine.

Okay, yeah.

I guess, just to make the analogy then, because what that allows you to do is it allows you to still treat the video signal as a video signal, line by line, you can manipulate those lines with stuff that knows nothing about data and only knows about video, and so that maintains compatibility and potentially adds functionality.

Yes.

Okay, makes sense.

So, actually, there's a 28-line pair output going to the transmitter.

You actually could use 13-and-a-half-line pairs of output from the Ceefax engine to use all the, or most of the redundant packets.

So, that actually took the output from 24 to 27 pages a second.

So, you've got eight more pages going out.

It did actually require you to know quite a bit about the nature of the packets and how many packets per page and how many lines you were going out on and how you were setting a unit that the data bridge that did this, a priority one, priority two, priority three, etc.

It worked if nothing changed very much, and there were only a few units that you actually could manually reconfigure.

You're saying it's not scalable?

That was not readily scalable, but it worked and proved that it worked.

We then worked out a different algorithm.

Rather than being commanded by the configuration of the box that said, okay, put stream A out on this line, followed by stream B, followed by stream C, it actually worked without knowing how the output was streamed.

So, we got a whole vertical blanking interval that was, in theory, totally filled up with the packets almost as they came in.

Actually, it's a bit cleverer than that because it actually did also try to keep the input streaming so that it would tend to, let's say that you wanted magazine one on low line numbers and magazine six on higher line numbers, and it would tend to do this.

We'll look at the equipment later, but for each of six inputs to this device, you could allocate what lines and packets to put into which buffer.

Then, on the output, you worked out what buffer you would take to be put and what priority.

Then, if there was nothing there, you'd put a filler, which is traditionally packet 825, or actually just a blank line.

So, it was rather complicated.

The advantage of having filler packets in was that you knew that you would never overload the system.

So, if you were monitoring it and you saw that you were getting, let's say, one or two filler packets per second, you would know that you actually were not losing any Ceefax data.

The system actually was very clever that if it started to feel that, for some reason, it was getting full up, it would buffer one magazine and wait until it's got 24 packets worth of data being buffered, which was a page, and it identified the page, and then it just wouldn't transmit the page, which immediately was able to purge 24 packets from other streams to the output.

But we were most insistent that we didn't want to lose anything.

Therefore, by monitoring, we're seeing an occasional filler packet that just sort of kept us happy that we weren't actually overloading it.

Ah, yes, this thing got very complicated.

The Ceefax editorial staff would want to have certain pages being transmitted more rapidly than others.

And the Ceefax transmission engines would normally run on a sequence, 100, 101, 102, 103.

But from time to time, particularly page 100, you might put out every five seconds, because that was the page you wanted people to see when they press the text button on the television.

So, on average, they'd only have to wait two and a half seconds for it to come up.

So, it's page 100.

So, it's your index, really, to know everything.

So, you don't really want to wait a long, like, 14 seconds.

Yeah.
So, that was, that was important.

And likewise, packet 200, the 100, 200, would likely to be transmitted fairly often.

So, basically, you would have an in-sequence queue and an out-of-sequence queue on a timer, so that the output process of the Ceefax generation engine was, okay, I'll take the next page.

Is the timer set?

Oh, timer is set for this page.

Okay.

Rather than the next page, I'll output page 100 again.

There are great problems if everything is out-of-sequence, because you never quite know whether you're actually overloading the stream.

Because if you're just taking the next page, and it just fills up the number of lines that you've got to go out on, and you then have the next page when the previous page has used all of those lines, it self-regulates.

If you said that every page had to go out once a second, you'd rather fill the vertical blank into people with packets, and you just cannot get all the pages through.

Sadly, Ceefax went on air with a new system where they had all the pages out-of-sequence, and there was one page that was in-sequence, and that had a cycle time of 2 minutes 40 seconds, which was not good, and most of the pages were getting lost.

So, as we thought that we were really quite clever with the downstream processing I've been talking about, and all of this processing was downstream because it was mixing DataCast feeds, other feeds, and Ceefax, I thought, okay, well, let's have an individual packet priority, where you could identify a page to have a waiting or target cycle time, or just best efforts, i.e., put it in the next pages.

That needed simulation warnings to editors, and it was not implemented because it all got very, very complex to explain, particularly when all they did was to just change the design of a page by one packet's worth, and that took more space, and it would all then fall over if they tried to put too many pages through.

Okay, let's move on to what we ended up with.

Right at the top of the page, we would have data broadcasting.

We limited that to packets per field.

So, the top two lines, lines 7 and 8, could have data broadcasting on.

The rest of those lines could have Ceefax on, or actually packet 830.

So, the priority was zero.

Packet 830 format 1 is, or goes out once a second, is a timestamp.

Format 2 go out four times a second, and are the flags that command the video recorder to turn on.

Data broadcasting, we limited, and then the rest of the line pairs were the text down to 19.

Line 22 was subtitles.

Line 21 had insertion test signals, and line 22 was quiet, except that we sometimes used that for test purposes.

The reason behind that is line 23, or at least the second half of line 23, is the first active line of picture.

So, what we got was, working up from the top of the picture, a quiet line, so a black, followed by an insertion test signal, which was static, followed by one line of subtitles, which sort of flashed off and on, and then a solid block for the rest of the active VBI.

Was that 22, 335, were they quiet just because they're right next to the image and you weren't sure?

We had made that decision.

There is an ETSI document telling you how you might consider reallocating the VBI.

One of the issues that you have got is that, internationally, the insertion test signals are on lines 18 and 19, and that is a bit of a problem when you've got Ceefax, and you want to put as much Ceefax as possible.

You might have to allocate it round the insertion test signals.

Also, the German version of PDC, called VPS, for some very Germanic reason, decided that that would signal on a particular line.

Therefore, you have got a particular line allocated, so you have to put your text round that.

You also have to realise that a television set that is sold in Germany would ignore the teletext data on that line because it thought that it was getting VPS signal, which meant that when they imported them into the UK, all of a sudden they had a bunch of televisions that put holes in Ceefax as was seen by the people.

Again, because in those days we were not using dynamic allocation, it was very, very easy just to see that every third line down the page was missing.

And that really important question, how did we know it was all working?

Well, when I started all of this lot, the test equipment we had was a standard waveform monitor, a scope.

We just looked at the waveform and you could see if the waveform was there or not.

And to see whether you had got the teletext service, the Ceefax service running, you had a television set.

And as I mentioned with the VPS, there were some occasions when you, if you had something that would blank a VBI line, that would actually help you see what was going on.

Tektronix then came up with this marvellous engine, the VM700, which is a sampling waveform monitor, which was able to give very, very pretty outputs of ordinary standard waveforms in active picture.

You could print the output, you've got macros available so that if you had standard tests, you could do things like that.

The BBC said, oh, this is marvellous.

Wouldn't it be good if we could actually also have a look at the teletext and the dual-channel sync, so that in particular, we could measure the eye height of the digital waveform.

There also were other advantages with it.

This is what it looked like.

Is that right?

Yes.

We're very familiar with it.

And the major thing that it could do was it could lock onto the teletext plot and therefore actually show you the teletext waveform as a waveform and measure how far away it was from the start of syncs, because sometimes the insertion of the teletext data, A, in the specification, it did actually invade line blanking.

If your blankers were set fairly wide, you would lose some teletext waveform.

So the ability to actually look and measure where the timing reference was on the teletext waveform, which is not first one, it's the third position, was very, very useful.

And again, measuring eye height, if it goes through a large transmission chain, it does get rather bent, and that was useful, particularly actually for data broadcasting applications where it sort of had to work.

But if a data broadcasting application was a typical betting shop, you could guarantee that the aerial that had been installed a long time ago, so they could see BBC One television racing, was not quite good enough for teletext.

And as I said, we also did the dual-channel sound in syncs, which is even more complicated because that has paternary codes, but that enables us to see what was going on.

And for the actual service, MRG Systems, who were making the data bridges, came up with Teletext Analyser No. 1, which was developed because they had to prove that dynamic allocation was working.

So the supplier must demonstrate that it works without losing packets.

So they invented a very agile teletext card and tuner, which went in a PC running DOS, which enabled you to have a look at what was going on on each line, each magazine, and on which UHF channel.

And you could display it by line or by the data.

You could set it up by page number.

You could tell it to remember one packet configuration and to flag up when that packet next appeared, and things like this.

So we could measure cycle times dead easily.

So it just made an awful lot of what had been done previously very, very manually, fairly automatic.

It still was a bit basic.

It tended to print out or create a file, which then you might need to analyze further, a bit like Wireshark in some ways.

So we could see what pages were being transmitted.

We'll come to the fact that the page range actually goes up to 256.

It's not just 100 pages, it's 256 pages.

So we could see both decimal and hexadecimal ranges.

We could see the page.

We could see control codes.

We could see what packets were on which data lines, on what magazines they were.

And it really was quite clever.

It also decoded all data broadcasting, which was very, very useful, because you could then see which service was actually transmitting.

In theory, you could have used that to work a billing system, that if you were billing people by how much had been transmitted.

All right, now we've got it all working, let's have a look at the actual equipment that we're using.

All of this is downstream from the Ceefax, or Data Broadcasting Origination Systems.

But we had to combine these things.

So let's have a look and see how we did it.

And these are the sort of stages that we went through.

This is in the good old days of up to 1991.

We had a feed from a network control room, which had subtitles on it, an insertion test signal generator, which output a field of syncs, which told the data cast system to put out, time itself in, and the Ceefax system to time itself in.

And those were actually hardware.

There was no buffering in the ITS generator, so you had to get those things timed.

And in those days, that was looking, trying to look at a waveform on a waveform monitor and not using a nice VM700.

Oh yes, and because it was a straight resistive mix onto the TV line, the signal coming out of the data cast generator and the Ceefax generator had no syncs on it.

So it was a bit of a nightmare to actually work with.

So you just got black level with some data on it, and you just had to look at the output to see whether it was in roughly the right place.

It worked, so long as you got it working and didn't touch it.

So then in the nations and regions, they had that sort of arrangement.

BBC network distribution has sound in syncs, which means that the sync pulses were full of sound data.

Typically, when a station opted out, it was done in the sys domain, right on the output of the station, which meant that you were likely to lose some VBI data.

And so coming in from the left there is the feed from London.

Normally, most of the time, it goes up on the top path, over the top and down straight out.

So it's almost a cable from input to out, a few distribution outliers in there.

When the studio opted out, it would then go through a sys decoder, which then meant that you had decent sync pulses to take it through the studio.

A data bridge bridged the VBI back onto the output on an ITS generator.

The data bridge and the ITS generator locked themselves together so that that all worked nicely.

You then sys encoded it and it was sent to the transmitter.

Actually, the precise sequence and way in which it all worked was different in every single region.

And sometimes the data bridge was in the sys domain.

Sometimes the data bridge was fed in a different way so that you got the wrong network data going out if you weren't careful.

It really was rather primitive and it was different in every single region.

So, along comes the next idea.

Let's make it ready for extra lines of regional Ceefax.

Now this was quite a cunning idea.

The idea was that if we could put what was different between the regions, on the whole, the football results, the stock market, the sort of entertainment recipes and the like were the same.

Magazine 1 for news would have some local news in it.

Magazine 6 for television listings would have the local ITV company as well as the BBC variations, etc.

Therefore, let's have a look at doing it this way so that you've got Magazine 6 and Magazine 1 on a particular set of lines.

So, is this the early 90s this came in?

Yeah.

So, basically, in the early 90s, what we did was put a data bridge in onto the ITS generator so that Datacast and Ceefax were both fed from the 6a pulse chain.

So, they were on absolutely rock steady pulses.

The feed for the network control room came in, was looped into the data bridge for subtitles.

DataCast and Ceefax got added, absolutely immaculately tied back into the ITS generator and off to the network distribution.

And Ceefax would be streamed so that Magazines 1 and 6 were on particular lines which we could sort out later.

So, we had that in London.

And in the regions, we had a lot of work to be done in the presentation areas in the regions.

So, while we were making all the regions work stereo with new dual channel sound in Sync's kit and replacing the network identities with the new BBC 1 balloons and similar things, we also took the opportunity to make all the nations and regions look the same.

So, we had a new ITS generator which worked on line 21 and a simple data bridge which blanked two lines to add two lines for a magazine, a regional magazine.

And you see there that we actually had got the ITS generator and data bridge working in the sound in syncs domain.

And that meant that we would, we never would lose a packet of DataCast because the data coming in was bridged onto the ITS generator right at the output rather than having to go through the opt switch.

And that really was a much simpler arrangement.

And by moving the data bridge and the ITS generator into the sound in syncs domain, you sort of knew that it would always get the output.

And you then could add a Ceefax generator doing two lines, let's say, into the data bridge.

The data bridge was very simple.

It had an optical switch which said which input you were looking for for that particular line.

So, for instance, you would set line 20 to pick up on that one, as it's shown there, sort of input one, which would be subtitles.

And then let's call it input six right at the far end, which is carrying the Ceefax and data broadcasting.

You would set that to pick up lines seven, eight, down to sort of 16, 17, and then 17 and 18 or something like that will be the local two lines for the magazine on input three.

However, there was not a regional magazine.

Rather than have a regional magazine, Ceefax decided that they were going to put a Ceefax generator in every region, which meant that they could make whatever magazines unique to the regions and put in national differences in Scotland, Northern Ireland, and Wales.

Around this time, dynamic allocation was coming in.

And of course, the simpler data bridges wouldn't work.

Well, they would just about, but it got complicated.

And the ITS generators were a very advanced design when they had been done, but seven years or so had passed, and they were showing that the age of the components couldn't be placed.

So, we commissioned and bought some new ITS generators.

So, in new dynamic allocation bridges, we actually had got the same architecture in London and the nations and regions.

So, have a look at how it was actually laid out.

You have got there the idea that you have got a data bridge with six inputs.

Input A would carry the subtitles from the input video.

B would take the output for the data cast engine.

C we would not normally have connected.

D and E were two Ceefax generators, and the data bridge itself would do an auto changeover between them.

So, we actually had got four Ceefax origination engines, one for BBC1 A, one for BBC1 B, Ditto for BBC2, and we might have got one spare for test purposes.

The box also took in some PDC information and put that out as well.

And then it got syscoded, sent off to the nations and regions, where the input to the regions were taken all the way round into an input F, which basically was set to take the data cast and packet A30s through.

Those would always bypass.

Those would always bypass.

Likewise, subtitles into A. We had no local data cast, so B and C would not be used.

D and E did a changeover like they did in London, except that the region had only three units, a Ceefax for BBC1, a Ceefax for BBC2, and a Ceefax that was putting out something that looked a bit like BBC1 and BBC2, sort of mixed up a bit, that if the BBC1 or BBC2 Ceefax failed, that would then mean that it would fail over to input E, which had got a service which was regional, but didn't quite look like either BBC1 or BBC2, because they only had one box generating it.

Just in case, if all Ceefax engines failed, input F would then take over and take the London feed and feed that out.

So, very much belt and braces.

That was because Ceefax was being used by so many people, just like the internet is used today.

So, it basically had not got to fail.

We then had some other uses.

The BBC had a service going out to Europe.

Think, sort of, the best of BBC1 and BBC2 as a channel.

The key thing that you want on a television channel in those days, as is now, you want to know what the programme listings are.

One way of doing it would have been to add an extra Ceefax transmission engine and call it a BBC Ceefax, because we didn't want to use Ceefax in Europe and we wanted to promote the BBC's name, and to generate that.

That was very expensive.

So, wouldn't it be a good idea to be able to pick and choose the pages that you've got on BBC1 or BBC2 Ceefax, combine those into a single text service, if appropriate, translating the page numbers, and if you could then store the programme listings, you could transmit that once into the bridge, which would then store the pages and then transmit them at the appropriate time.

Yeah, because it's got less in, it'd actually be able to do it quicker and more often.

Oh yes, it's actually output on 11 lines, when in the UK we were actually going out on nine lines.

It required mainly like Ceefax, but with pages omitted and replaced.

The time display on the header of each page had to be in CET and the branding was changed.

As I mentioned, this would require an additional database and an additional transmission engine, which was 50% increase in the amount of equipment.

Very expensive.

So, what did we do?

If you take Ceefax and store it, and then have a command page, which transmitted alias pages, if you're storing the service, you could transmit a page number that wasn't being used on BBC1 or BBC2 to get extra content, and you could then change the time and type change packet 830.

So, we had a command page, which had what the text had to say, rather than Ceefax had to say BBC Fax.

It had to put the date in and time offset from UTC, so that it could work that out.

A list of pages to be deleted, so that they were never stored, and a list of those that were aliased in a human readable form, so that you could actually see what pages were not being stored and those that were being put in to replace it.

And then the output streaming, because it was being distributed by satellite to cable headends, and some of the cable headends had encryption equipment in, which used different lines.

And so, from time to time, a request would come in that we had to change the lines allocation, and it's very easy to do by just typing it in the Ceefax office.

Alias pages.

Yeah, this is great fun.

There are 256 pages available, 00 to F0, or 0F. So, we then carve up the space.

A 10 by 10 bit at the bottom, which is a normal 1 to 99, or 0 to 99 space.

And then, it then gives you two areas, 10 by 5 or 5 by 10.

If you imagine that you could overlay those over the 10 by 10 space, so that conceptually the top lot, the OA to OF, moves down to take the top of the space, and yet you turn over the 5 by 10 to light the bottom.

That gives you a complete overlay of your 10 by 10 decimal space.

It's got there, that example there, which is far more complicated to work out.

So, 1A0 is 100, and 1C7 is 127.

So, the last 50, you just swap it around the other way, so that you then have 150 being 10A, and 12C is 172.

And that's how you code it into that space.

So, you transmitted those pages, which no normal television set would pick up, and those would be stored in the box and transmitted out appropriately.

Also, looking at the coding space, we have those that have got an F in it, which were used for special purposes.

We use those, let's say for engineering monitoring, together with the dual hex pages, the 25 of those.

You could also put things up on there.

And that's the basic plan that we had.

So, you could go and transmit the program listings, so that you would have page 6A0 being page 600.

6A1 would be 601, i.e. BBC1 listings, and things like this.

This was quite clever.

And you just transmit those pages once every so often, and they were stored in the bridge.

Both neat and a little bit complicated.

It was complicated.

You had to be good at reversing numbers around and understanding hex, and then there were bits of scripts in Ceefax to actually control the roll-up of a listings page.

Listings pages are a bit of a confounded nuisance.

They start off with three or four sub-pages at the beginning of the day.

By the end of the day, they're down to a single page.

So, you have to decide when you're going to move on and retransmit it so that it moves from a four-page, multi-page set to a three-page, multi-page set, et cetera.

And that was done in the Ceefax engine.

It also meant that automatically, you were refreshing the program listings, which is probably the most important information that we were actually transmitting.

But again, because it was storing pages, those pages that would change rapidly, news pages were forever changing.

The chances would be that if anyone did get corrupted in some way, which I don't think we ever really had, it was very easy to just retransmit the page.

Ah, yes.

Telfax.

Staff communication systems.

We're now so used to seeing screens advertising what's going on, security announcements and similar things.

The requirement was that four BBC staff in London, or was it just in television, could be upgraded about what was going on before they would read it in the evening standard at three o'clock.

This was quite an important thing to do.

At the time, lots of things were changing.

Well, on the whole, around West London, we did actually have vision circuits.

So, we just generated a Teletext service and put that on top of the video that went to all sites as an internal viewing thing.

This is where you'd have program or channel launchers and things like this cover of what the DG was speaking.

They would do that.

Now, where the DG wasn't speaking and things like that, we had an InVision Teletext display as shown in the top right there, which meant that you could see a carousel of pages that just shows what the listings were, but you could put the BBC headlines up and the like.

So, that is actually what you could see.

Now, if you then attached television sets in all the corridors or lift lobbies or whatever, people as they're waiting for the lift could see what the latest news was from BBC management.

They went to their offices and they had a television set.

They could then actually dial in a particular page number and have a look at something in more detail.

So, it's a mix of sort of news headlines and what the news was on different pages that you could see.

It's all very well and good, but there were places like Elstree for London which did not have a video circuit.

So, how do we get the information over?

Well, the answer is data broadcasting.

So, we could turn the Teletext feed into a command to a data bridge that stored things and then put that over the air so that whenever a page was edited and actually on a background refresh basis, the pages would be transmitted as data as if they were going down a standard modem landline arrangement, except that the modem landline arrangement was actually through the air using DataCast.

Well, if we could do it to Elstree, it didn't take much imagination and you were using the DataCast system.

It didn't take much imagination, but you could do it to up to any other BBC region.

The North region had similar issues.

So, we have a system there that enabled them to receive the London pages and to edit their own pages in on inserters connected by landline in Manchester and Leeds and Newcastle, so that they could also get their local news added to the same service.

A very interesting use of data broadcasting, to say the least.

And again, using this facility of data bridges to store pages and actually to selectively erase, or not store, and replace pages with the in-vision character generators to put in-vision teletext up to display the information.

In-vision teletext generators actually had another use well outside the BBC.

They were used to blanket drinks adverts in the Nordic countries where you're not allowed to put drinks adverts out on television.

A satellite feed would have one of these things in the way and on cue, it would pull up a teletext page rather than the drinks advert.

So, we were using what was originally available in a slightly different way.

They'd be bringing up just a blank screen.

It's just a black screen, so you pull up the programme listings or an advert for something that wasn't drinks.

If we continue the internet comparisons, we can see that as a tool to spread information, you can basically use it in whatever way you can think of.

And in the same way as we use internet now for communications of all types, increasingly that's what teletext was used for as time went on.

And interesting to see the hand of the government.

Possibly one of the first times it's worried about what packets are going in people's houses.

I really appreciate you taking us through that.

There's yet more to cover.

We haven't really dived into subtitles.

We'll look at that next time and a whole lot more.

So please, if you haven't yet, click like and subscribe, then please do so.

Big thank you to Becky and Fiona at PageMelia PR for helping get the show on the road.

And obviously, thank you very much to Peter for joining us again.

Look forward to next time.