Teletext is a system of transmitting information on previously unus...
Whereas nowadays most TV remotes use infrared signals to communicat...
**Viewdata** was an interactive system by which a viewer retrieved ...
In teletext, pages are broadcasted serially along with television c...
It’s important to stress how early 1977 was in the development of h...
"Secure" here is more about "error resistance" than the modern unde...
In Teletext, textual characters and control characters are represen...
A page of Teletext consists of 24 rows of 40 characters. As explain...
Telesoftware: adding intelligence to teletext
J.
Hedger and R. Eason
Indexing
terms:
Television
applications,
Data-communication
systems,
Computer software
Abstract: The authors seek to show how, by using a microprocessor, teletext may be extended to provide
many new and useful facilities, while remaining compatible with existing teletext transmissions. The design
and implementation of an experimental telesoftware terminal are described, and a summary of current
thinking is given, indicating the probable future software and hardware constraints of the system and its
potential applications.
1
Introduction
Independent Television has been broadcasting Oracle as a
service of broadcast teletext since 1975.
1
It was soon
realised that teletext, as well as being an efficient means of
disseminating textual and simple graphic data, offered a
very convenient and cost-effective method of distributing
software programs for home computer systems. Further-
more, an existing teletext decoder already contains many of
the 'building blocks' necessary for a simple home computer,
such as memory, colour visual display and numeric data
entry. With the addition of a microprocessor, such a de-
coder may be transformed into a small, but potentially
powerful, personal computer inside the television set
itself.
By utilising the Oracle system to broadcast programs for
such an enhanced teletext decoder (with the programs
presented as pages of standard text), a user would need
only to select the pages containing his desired program.
Once received, this software could then be executed by the
microprocessor, utilising the existing colour display and
keypad, without the need for expensive storage peripherals
or telephone lines.
Thus telesoftware
2
represents a very inexpensive form of
personal computing, since once a user has purchased the
necessary 'intelligent' television set, telesoftware, like
teletext, is a free service.
2 An experimental terminal for telesoftware
To stimulate the interest of decoder manufacturers and
broadcasters in the concept of telesoftware, Independent
Television and Mullard Ltd. embarked, towards the end of
1977,
on a joint project to design and construct a simple
telesoftware terminal for evaluation, using the Oracle service
to broadcast the trial software. The terminal hardware was
built at the Mullard Applications Laboratory, Mitcham.
The aim of the project was to produce a prototype terminal
in a relatively short space of time, and so the design was
intentionally made somewhat simple, far from optimum
and not intended in any way to represent a definitive means
of implementation. However, this simplicity was far out-
weighed by the subsequent value of the terminal for demon-
stration purposes.
2.1 Compatibility with teletext
At this early stage there existed no specification or guide-
lines for the broadcasting of telesoftware, nor for its
implementation in hardware. It was realised therefore that
Paper 8451 E, first received 13th July and in revised form 9th
October 1979
Mr. Hedger is with Independent Television, South Bank Television
Centre, Kent House, Upper Ground, London, and Mr. Eason is with
the Mullard Applications Laboratory, Mitcham, Surrey, England
1412
0020-3270/79/121412
+
05 $01-50/0
parameters governing the experimental terminal, although
fairly arbitrary in their choice, could not be permitted to
interfere in any way with the existing teletext system. For
this reason, design work was based entirely upon the use of
normal teletext transmission techniques, using ordinary
characters to represent bytes of computer software.
2.2 Overall
design
The prototype terminal itself consists of three main parts: a
domestic colour television receiver with ultrasonic remote-
control; a teletext decoder card and purpose-built micro-
processor card. For convenience, the two latter items were
mounted outside the receiver together with their power
supplies; although ideally the whole terminal would be
housed within the receiver cabinet. Fig. 1 shows a block
diagram of the experimental terminal. For clarity, only the
bus lines and major interconnections are shown.
The teletext card contains a standard Mullard production
chipset, and is of the viewdata-compatible type. This
implies that the data and address lines to its page store are
accessible via a connector, a facility which is essential for
telesoftware operation. The microprocessor card contains a
Signetics 2650 microprocessor and associated memory
which together form the local microcomputer.
2.3 The telesoftware
page
For the experimental project, telesoftware programs were
broadcast as sequences of Oracle pages of text, using up to
seven to form a complete program. When teletext pages are
used in this way there is no means of determining which
pages of the sequence will be received first, and so the
terminal is designed to be able to load the pages in any
order. Fig. 2 shows the format of the telesoftware page, the
contents of which are as follows:
Row 00 is the Oracle page header and is not currently
affected by telesoftware transmission.
Row 01 contains a special sequence of characters which
identify the page as carrying telesoftware data. Since this
sequence is short, and the remainder of the row is not
scanned by the microprocessor, the space is used to carry
the program title.
Row 02 contains control data for the program itself and
must be highly secure. This data is protected by Hamming
code,
3
with each byte of data being represented by two
contiguous teletext characters. To avoid the use of teletext
control characters, only six of the possible seven bits per
character are used, giving a total of twelve usable bits. Eight
of these make up the data byte, while the remaining four
are used for error detection.
The control data are further protected by a block-check
character (b.c.c.) and use 16 teletext characters in total. As
a further security measure, the control data block is repeated
PROC.
IEE, Vol. 126, No. 12,
DECEMBER
1979
in the second half of the row; this allows the terminal a
'second chance' if the first occurrence of the block is
incorrectly received. The control data itself is made up as
follows:
(a) Address field: a 2-byte address that specifies the
loading address for the first byte of the program.
(b) Count field: a 2-byte value for the number of bytes
of program data on the page.
(c) Page number: a single byte for page identification
within the sequence in the range 0—7.
(d) Program b.c.c: a single byte to verify overall pro-
gram data.
(e) Control line b.c.c: a b.c.c. for the control data
itself.
Remaining rows on the page carry the data representing the
program.
The data represents machine-code instructions for the
microprocessor rather than higher level instructions such as
assembler instructions. As with the control data, each byte
is represented by two teletext characters with Hamming-
code protection. By using this method of encoding, the
upper limit of the segment of program which may be
carried on a single page is 420 bytes.
3 Description of terminal
The terminal has several distinct features which are now
described. The page store consists of random-access memory
(r.a.m.) addressed by two bytes of indirect address, the first
pointing to a row and the second to a column address. In a
conventional teletext decoder, this memory would be used
exclusively for storage of
a
single teletext page for display.
The scratchpad is a further 256 bytes of r.a.m. and is
used as a buffer store for data between the page store and
secondary memory which is another 4K bytes of r.a.m.
forming the main memory of the microprocessor.
The control program is held on 2 K bytes of erasable
programmable read-only memory (e.p.r.o.m.) and has the
following basic functions:
(a) to accept and interpret commands on the I-bus
(b) to validate incoming data and transfer verified data
to secondary memory
(c) to reread data incorrectly received
(d) to go to the start of the program when correctly
loaded
The remote keypad is the ultrasonic command device
normally used to control television set functions and which,
for telesoftware, additionally acts as a data-entry device for
the user.
3.1 Operation
The address and data lines from the microprocessor are
connected to the teletext address and data bus via buffer
circuits, permitting the microprocessor read/write access to
the teletext page store. To avoid a conflict of addressing,
the page store is accessed only within defined periods during
field flyback. A window-generator circuit prevents access at
other times and also sets up an interrupt at the start of the
,
window.
Keypad commands received by the television set are
decoded and are used for controlling receiver functions
such as volume, brightness etc. In addition, a serial data
pattern and timing waveform are generated to form the
I-bus, which controls the teletext operating modes and page
selection. The I-bus is also taken to an input port on the
microprocessor card, enabling it to respond to keypad
commands and data.
On the teletext card, the video processor (VIP) slices
data and data-clock information from the television com-
posite video signal. This is then fed to the timing chain
r
television \
receiver I
video
RGB
VIP
video
processor
etc!
remote
key pad
buffers
I-bus
from
TAC
teletext
acquisition
and control
TIC
timing
chain
TROM
character
generator
page
store
address
multiplex
and decoder
remote control receiver
|_
teletext card (VCT)
j
j^—
address
and
control
decoding
control
program
0000-07FF
interrupt
control and
window
generaton
program
0000-03FF
1F000-1FFF
secondary
memory
4000-4FFF
Fig. 1 Telesoftware demonstration system: simplified block schematic
PROC.
IEE, Vol. 126, No. 12,
DECEMBER
1979
1413
(TIC) and to the teletext acquisition and control (TAC).
The required page is selected by TAC and, when received, is
parallel-loaded to the page store. The character generator
(TROM) is fed with this information, enabling it to generate
red, green and blue colour signals for page display. Because
these colour signals drive the television colour amplifiers
directly, fully saturated display colours are produced.
After the microprocessor is reset, either by power-up or
by a major change of mode caused by a keypad command,
the control program will be run. This program causes the
microprocessor to scan the page store for the special identi-
fying character sequence which it will recognise as telesoft-
ware. Until this is found, the terminal behaves like a
standard teletext decoder, receiving and displaying pages of
text. However, if a valid telesoftware page is selected and
loaded into the page store, the microprocessor will, upon
recognition, perform error checks upon the data before
loading verified data into the correct part of the secondary
memory via the scratchpad. This process will be repeated
until all pages which form the complete program have been
received and loaded. If errors are detected, their location is
noted and the erroneous bytes retested when that page is
reread subsequently. Since errors are unlikely to occur a
second time in exactly the same place on the page, the
terminal stands a very good chance of accumulating a
perfect program after two passes even under relatively poor
decoding conditions.
Once the complete program has been loaded, a prompting
message will appear on the screen requesting the user to key
VIEWDATA on the keypad. This action sets the teletext
card into viewdata mode so that no more teletext pages are
received but the page store contents remain displayed; it
also starts the program now loaded into memory. From this
point, the program can run and will respond to inputs from
the keypad. The television screen becomes a colour v.d.u.,
fed by data loaded by the microprocessor into the page
store.
NATIONUinr
MORTGAGE CALCULATION
<ordinary repayment mortgage)
To compute your monthly repayments
complete the following questionnaire
using keys O to 9. Key * for next line.
SUM BORROWED Cup to 99999> £13300
INTEREST <currently 12.0O5;> 12.00%
TERM < 5 to 35 years > 2Syears
CROSS MONTHLY REPAYMENTS WILL BE
To start again key *
Fig. 3 'Mortgage calculator'program display
4 Programs for the experimental terminal
To evaluate the terminal in use, and also to provide the
basis for active demonstration, four simple programs were
devised for the terminal. These have been broadcast since
1978 on the Oracle service and are written in 2650 machine
code.
It is hoped that they serve to illustrate (albeit in a
somewhat limited way) some of the main application areas
for telesoftware. The four programs are as follows"
(a) 'Mortgage calculator' (Fig. 3) calculates monthly
mortgage repayments based upon user-input variables of
term, sum borrowed and interest rate.
(b) 'Insurance quotation' allows a user to obtain a
quotation for car insurance by entering responses to multiple-
choice questions with numerically oriented answers. The
questions parallel those to be found in a 'traditional'
proposal questionnaire.
0
1
2
3
U
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
A A BBMMNNPPQQRRTT
start of program data
A ABBMMNNPPQQRRT T
page header
pass word
control row
data rows
Fig.
2
Page
format
Characters AABB -* AB bytes = address field
MMNN -> MN bytes = count field
PP
-*•
P bytes = page number
QQ
-»•
Q bytes = number of pages
RR -* R bytes = program BCC
TT -• T bytes = control hire BCC
1414
PROC.
IEE,
Vol.
126, No. 12,
DECEMBER
1979
(c) 'ESP' is a number guessing game incorporating a
random-number generator within the program.
(d) 'First aid' is an example of a simple educational
program, again structured around multiple-choice question-
ing techniques.
4.1 Software considerations
For practical reasons during the experimental period, all the
telesoftware programs were written and transmitted in
machine code. This method is compact and convenient
when dealing with a single microprocessor and associated
instruction set but, of course, allows no real portability of
programs between one microprocessor and another. To
adopt this system as a standard for telesoftware would
impose severe restrictions in terms of having to define one
machine which must be used in all terminals, effectively
precluding competition between different manufacturers.
It would be more desirable to transmit programs in a
high-level language and to employ a resident interpreter
(held in r.o.m.) to translate this into machine-code instruc-
tions to be executed by the microprocessor. This would
permit many different microprocessors to be used for
telesoftware simply by writing interpreters appropriate to
the specific machine in use in each case. The interpreter
would also reduce substantially the amount of software
per program which must actually be transmitted, because
a degree of 'expansion' takes place with a high-level
language when the source code is interpreted into machine
instructions. Thus writing programs in such a high-level
language results in effective compaction, which is crucial in
telesoftware, because the longer the program, the longer the
user will have to wait to load the software from the teletext
system.
A compiler approach would be less desirable, since more
memory is required and the program could not possibly
start until it had been loaded in its entirety, resulting in
undesirable delays. The teletext system itself incurs delays
in that the most efficient way of broadcasting programs is
using the 'rolling pages' method previously described, with
finite times between each, but this would prove less of a
problem if a program could commence execution before
the whole of it had been received. With careful segmenting
of the program, this is possible with the interpretive
approach, but not with the compiler.
As well as deciding on whether a compiler or interpreter
is most appropriate for the future implementation of tele-
software, a suitable high-level language must be identified.
ITV's research to date has pointed to a modified BASIC
as being most appropriate,
4
but no final conclusions have
been reached.
It should be remembered that telesoftware is likely to be
aimed, not at the home-computer enthusiast, but at the
man in the street, as a television set with enhanced and
highly versatile facilities. Thus the vast majority of users
would not possess any knowledge of the traditional com-
puting techniques associated with the current generation of
personal computers. For this reason, accepted computer-
type operating systems with their attendant error messages
such as '*** ERROR INVALID OPERATOR OR TER-
MINATOR' could not be tolerated, or understood! Instead,
careful design of programs will have to take palace to ensure
that software is highly reliable in a runtime-only environ-
ment and to ensure the inability of the terminal to produce
meaningless, obscure or incorrect information to the user,
regardless of data input by him. However, since a real
telesoftware will still permit the broadcaster full control of
the programs that are broadcast (in the same way as he
retains full control of the content of teletext pages). It will
be his responsibility to ensure that strict quality-control
procedures are carried out on the programs prior to their
transmission on air.
5 Other telesoftware applications
It is difficult to assess how the use of telesoftware will
evolve until it becomes established as an important and
useful extension of teletext. However, work already carried
out has pointed to a number of areas where applications
seem most appropriate, and a few of these are now
described.
5.1 Se/f-assessmen t programs
Examples of self-assessment programs are mortgage calcu-
lators,
tax assessment programs, social-security benefits
assessment etc. These applications would normally take the
form of question-and-answer sequences with the terminal
performing numerical and logical calculations upon data
entered by the user interactively. In their simplest form,
programs would need only the numeric keypad for data-
entry, but others, of more complexity, would necessitate
the use of a full alphanumeric keyboard as an extra per-
ipheral. A characteristic of this area of applications is the
large quantity of text needed to be held within a program.
5.2 Education
Education is a large and important area in which telesoft-
ware could have a major role to play. It provides the
educationalist with two significant advantages: first, it is
completely cost free, once the relatively cheap hardware
has been obtained; secondly, any number of simultaneous
users may be supported (clearly, no peak-loading problem
exists in the ether).
Many existing and proven techniques for computer-aided
learning can be translated directly into telesoftware, such as
the teaching of numeracy, some mathematics and some
science subjects. However, to be really efficient, a signifi-
cantly large portion of a teletext database needs to be
devoted entirely to the broadcasting of educational
programs to provide the necessary diversity and complexity
required.
5.3 Video
games
Video games can be viewed as falling into two groups;
verbal-reasoning games and manual-dexterity games. The
former are ideally suited to telesoftware implementation,
since they involve manipulation of mainly textual data and
will need only a keypad, or at most and alphanumeric key-
board for data entry. The latter, however, deal with factors
such as hand-to-eye co-ordination and are nearer in concept
to the 'traditional' (fixed) video games; as such they
demand the use of paddles, joysticks and other control
devices. A real-time clock might also be necessary.
5.4
Database
broadcasting
An example of database broadcasting is a system proposed
to use telesoftware to detect credit-card fraud. A telesoft-
ware terminal located at the point of sale in a store could
be loaded with a small program at the start of the working
day. Throughout the day, Oracle would broadcast updated
PROC.
IEE,
Vol.
126, No. 12,
DECEMBER
1979
1415
list of lost or stolen credit-card numbers at intervals and
these would be used by the terminal to maintain its own
up-to-date lists. The sales assistant, when presented with a
'dubious' credit card, would simply key in on the keypad
the number of the card and the terminal would attempt to
match it with its latest list. If it succeeds, the assistant
would be advised to take 'precautionary measures'. This
system could permit terminals all over the country to be
kept constantly up to date without the use of expensive
computers or even a telephone.
5.5 Teletex t enhancemen ts
As well as providing a computer-type facility at low cost,
current thinking suggests that telesoftware could represent
an effective method of compatibly extending the facilities
offered by the teletext display, particularly in the areas of
high-definition graphics, vector graphics and dynamically
redefined character sets. Furthermore, since telesoftware
terminals will contain more r.a.m. than would be found in a
single-page teletext decoder, the memory can be used to
hold multiple pages, and perhaps even to store a succession
of related pages and display them interactively as the user
required. This could conceivably ease the access-time delay
inherent in the existing teletext system.
6 Standardisation of telesoftware
At the time of writing, much work is being done to establish
the technical standards for a future telesoftware system and
these will obviously include recommendations for terminal
design. However, the degree of specification will have to
balance carefully flexibility and economics. A highly
flexible system would tend to be uneconomic in the early
days,
possibly inhibiting the growth of the market
itself,
Whereas a rigidly defined system could be very economic in
the early days, perhaps leading to rapid market growth, but
probably becoming increasingly restrictive as applications
become more demanding and hardware even cheaper.
Perhaps the most important single factor in any such
specification is-the need to preserve compatibility between
telesoftware and the earlier generation of simple teletext,
so as not to render existing hardware obsolete overnight.
Consideration will have to be given to the range of per-
ipherals which are bound to be demanded by telesoftware
users,
such as cassette recorders, discs, printers etc., particu-
larly in terms of electrical isolation from the
e.h.t.
in the
television set. Consideration will also have to be given to
the hardware/software interfacing required.
7 Conclusion
The experimental work carried out so far shows telesoft-
ware to be a practical and cost-effective means of extending
teletext compatibly to offer facilities hitherto only possible
with more sophisticated and expensive solutions. With mass
production of l.s.i. (large-scale integration) units, the
incremental cost of minimal telesoftware facility in a
teletext-decoder/t.v. set would be of the order of £50, and
this would be a once-and-for-all outlay with no appreciable
running costs and a supply of free software.
However, certain limits have also to be recognised:
telesoftware can never order a plane ticket or place an
advertisement, which will be exclusive applications of two-
way systems like viewdata, but its advantages of simplicity
and low cost make it highly suitable for the domestic
market.
In a year or two from now, perhaps, inside every tele-
vision there will be a microprocessor trying to get out. Our
hope is that telesoftware will provide the key.
8 References
1 'Broadcast teletext specification'. Joint IBA/BBC/BREMA
publication, September 1976
2 OVERINGTON, W.J.G.: 'Telesoftware', Computing, 1977, 5,
p.
25
3 HAMMING, R.W.: 'Error detecting and error-correcting codes',
BellSyst.
Tech.
J., 1947, 26, pp. 147-157
4 GREEN, N.W.: 'Software for telesoftware'. Report under
preparation by the Independent Television Companies Association
1416
PROG
TEE,
Vol:
126-No: 12,
DECEMBER
1979
"Secure" here is more about "error resistance" than the modern understanding of digital communications security.
In this system, the software instructions would be broadcasted unencrypted on an open channel and therefore an attacked would be able to tamper with the instructions being transmitted.
In teletext, pages are broadcasted serially along with television composite video signal. When all pages have been transmitted, the cycle is repeated (although the broadcaster can opt to transmit some pages more frequently than others). When the teletext decoder starts processing the data stream, it can’t make sure that it will have started receiving it at the beginning, and therefore the decoder might have to wait for the next cycle to get the leading pages.
It’s important to stress how early 1977 was in the development of home computing and digital telecommunications. The Apple 1 was released a year earlier in 1976 and Usenet would only be established in 1980. Even tho the number of households with a computer was incredibly tiny, TV was already well established, with more than 97% of American households having at least one TV set.
Whereas nowadays most TV remotes use infrared signals to communicate with the TV, early remotes actually used ultrasonic tones. The first remotes were mechanical devices that required no batteries. When the user pressed a button the remote produced ultrasonic tones by physically striking the ends of tuned metal rods. Each of the metal bars emitted a different fundamental frequency, and circuits in the television detected these sounds and interpreted them as channel-up, channel-down, sound-on/off, and power-on/off.
*The "Zenith Space Command”, one of the first wireless remotes*
A page of Teletext consists of 24 rows of 40 characters. As explained above, the first 3 rows are not being used for program instructions. This leaves 21 rows of 40 characters for software. As stated, you need two characters to represent one single byte of program instructions. This yields: $$\frac{21 \cdot 40}{2} = 420\ bytes$$
**Viewdata** was an interactive system by which a viewer retrieved (mostly) textual information via a telephone line. Usually the user would need a TV monitor, a modem attached to the telephone line to convert the incoming signal and a keyboard.
*Example of a Viewdata interface*
In Teletext, textual characters and control characters are represented by a 7-bit code. Control characters (or control codes) are used to specify display attributes such as text color, double height, flashing, etc. Control characters would be displayed as a space character and its effect (such as changing the text color) would persist until the end of the row or until another control character came into effect (this means in Teletext it’s not possible to display adjacent letters with different colors).
Teletext codes are based on ASCII. Here is the Teletext code table:
Columns 0 and 1 are used for control codes. Columns 2 and 3 contain two variations - the graphics variations (2a/3a) are used if there is a graphics control code in effect. As an example, the letter “A” is at position 4/1 (column/row) and is represented by the binary code 1000001.
Teletext is a system of transmitting information on previously unused parts of the composite video signal. Teletext was designed in Britain in the early 1970s and came out of the efforts to provide subtitles for the deaf.
A Teletext decoder in the television extracts the Teletext data from the broadcast signal and makes it available to the user as a series of pages. The user can choose which page to display via their remote control. In Britain, there were two main Teletext services: 'Ceefax' which was run by the BBC, and 'Oracle' the service of the Independent Broadcasting Authority (IBA).
Teletext pages would typically included news, weather forecasts, sports results, among many other things. The system grew in popularity throughout the 80s and early 90s. In the 2000s, with the growth of the internet, Teletext systems started shutting down.
### How does it work
Teletext sends data in the broadcast signal, hidden in the invisible “vertical blank interrupt” (also known as the rollbar). The "vertical blank interrupt" results from the need for the raster to return to the start of the display after it reaches the bottom of the picture (in the process of drawing images on the display). During this shift there would be no data in the broadcast signal - this is where engineers placed teletext data. It is important to realise from the start that the final displayed teletext picture is generated by circuitry within the television itself in response to digital signals received (i.e. it’s not static video of that text being broadcasted over the air). Thus in the presence of noise or other interference, the effect is to produce errors in the text of the received information, rather than a noisy or distorted picture - which would be the case with a normal television picture under these conditions.
[Here is a useful video](https://youtu.be/bXMNeT3cv-A?t=1050) that explains how Teletext data is transmitted.
*Example of a Teletext page displaying the standings of the English Premier League*