The following article is abridged from “IEEE Transactions on Consumer Electronics”, July 1979, Volume CE-25,

Number 3. ISSN 0098-3063.

This material is posted here with permission of the IEEE. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by sending a blank email message to pubs-permissions@ieee.org. By choosing to view this document, you agree to all provisions of the copyright laws protecting it.

TELESOFTWARE: HOME COMPUTING VIA BROADCAST TELETEXT

J Hedger

Independent Television,

Southbank TV Center

London, UK

Introduction

Broadcast teletext, as operated by the broadcasting authorities in the UK has been available as a public service since 1974. As well as being an efficient means of decoding and displaying textual data, it was soon realized that the standard teletext decoder already contained many of the components required for a home computer. It was a character-generator for visual display, a page-store, and a very convenient numeric keypad for data-entry. With the addition of a few other components, the result is quite a powerful stand-alone computer right inside the TV set. By utilizing the teletext system to broadcast programs for such a terminal, a user needs only to select the teletext pages containing the desired program; once this has been read in, it may be loaded and executed by the terminal microprocessor without the need for expensive storage peripherals, telephone lines or special knowledge by the user.

Thus the word “telesoftware” was coined by W J G Overington (1) and refers to the transmission of such programs for a home-microprocessor by broadcast teletext. Telesoftware represents a very cost-effective form of personal computing since once the user has purchased a terminal ( a so-called “smart “ TV set) Telesoftware is a free service.

Experimental Terminal

Towards the end of 1977 it was decided to embark upon a project to design and construct a simple Telesoftware terminal for subsequent evaluation using the ORACLE teletext service as a source of broadcast software (2).

The aim of the project was clear: to produce quickly a terminal capable of demonstrating the concept of Telesoftware. As a result, the design was inherently simple and somewhat crude, being far from optimum. It was felt that by showing what was possible with the system that this would further stimulate the interest of decoder manufacturers and broadcasters who might continue the development.

Compatibility

Since at this stage the choice of the parameters for the experimental terminal was arbitrary, it was soon realized that it could not be allowed to interfere with the existing teletext system. For this reason, the work was based upon the use of wholly standard teletext transmission techniques, using normal characters in pairs to represent software bytes.

This result is the telesoftware pages being rendered as gibberish text on standard teletext decoders. This did not matter for the purposes of the project, but if such a system were adopted for public service, the UK Teletext Specification (3) provides for a control bit (C10) which may be used to inhibit the display of such meaningless text on normal decoders.

Terminal Design

A simplified block diagram of the experimental terminal is shown in Fig.1. For the sake of clarity, only the major interconnections and bus lines are included. Since the system was built for development as well as for demonstration purposes, the design includes a teletype interface and a monitor program which would not normally form part of a commercial product.

The terminal consists of three major parts: a domestic colour TV receiver with ultrasonic remote-control, a teletext card and a purpose-built processor card. For convenience the two cards were mounted together with power supplies outside the receiver itself, although clearly in a commercial design, the whole terminal would ideally be contained within the receiver cabinet.

The teletext card was of the standard Viewdata-compatible type; that is, with its data and address lines for the page-store being available on a connector. The processor card contains a microprocessor (Signetics 2650 type) and associated memory which together form a local microcomputer.

Although for obvious practicality at this stage, discrete components were employed, with subsequent large-scale integration, the whole design could probably be reduced to three or four integrated circuits.

General Description

The PAGE STORE is random-access memory (RAM) address by two bytes of indirect address; the first points to a row and the second to a column address. This memory would normally be used exclusively for teletext data storage.

The SCRATCH PAGE is 256 bytes of RAM used as a temporary store between the page-store and

SECONDARY MEMORY which is another 4K bytes of RAM forming the main memory of the microprocessor.

The CONTROL PROGRAM is 2K bytes of erasable PROM holding various subroutines. Its main functions are:

1 To accept and interpret commands

2 To validate incoming data

3 To transfer valid data to secondary memory

4 To re-read data incorrectly received

5 To go to the start of the program when it has been correctly loaded

The REMOTE KEYPAD is the command and user-data entry device.

Operation

The microprocessor address and data lines are connected to the teletext address and data bus via suitable buffer circuits. As a result, it is possible for the microprocessor to read from or write to the teletext page store. To avoid a conflict of addressing, the page store is only accessed by the microprocessor at defined times during the field-flyback. The window-generator circuit prevents access at other times and also sets up an interrupt at the start of this window.

Commands from the remote keypad are received at the TV set, decoded and used to control aspects of the receiver (channel selection, volume, colour, brightness, etc.) In addition a serial data pattern and timing waveform are generated to form the I-bus. This I-bus is connected to the teletext card and controls the modes of operation and page selection. The same I-bus is also taken to an input port on the processor card in order that the microprocessor is able to respond to inputs from the keypad.

On the teletext card, the video processor, VIP, extracts data and data-clock information from the television composite video signal and feeds this to the teletext timing chain, TIC, and to the teletext acquisition and control, TAC. Working in conjunction with TIC, TAC selects the required page information and parallel-loads it to the page-store. Data in the page-store is fed to the character-generator, TROM, which generates red, green and blue colour signals for the television set when the page store is to be displayed.

The microprocess will be reset either upon power-up or by manual push-button. In addition, reset will occur whenever there is a major change of mode as a result of a keypad command.

After reset, the processor will run the control program. In this mode, it will read the page store looking for a special sequence of characters which would normally be found only at the beginning of a telesoftware page. until such a page has been found, and loaded into memory, the processor has no effect upon normal operation and the system behaves like a standard teletext/TV receiver.

If a telesoftware page is selected and loaded into the page store, the processor will perform error checks upon the data before loading it into the correct part of secondary memory, via the scratchpad. This process will be repeated for each new page received until all the pages which make up the complete program have been received.

If errors are detected, their location is noted and the erroneous bytes are retested on a subsequent pass.

Since programs generally need more than a single teletext page for transmission, they are divided into several pages which are broadcast in a pre-determined sequence using a single page-number. however, since the system may not receive the first page of the program initially, it has to be capable of loading the pages in any order. The pages contain special data to assist in this respect, described fully later.

Once the complete program has been loaded, a message appears on the TV screen requesting the user to key a response on the keypad. This achieves two results: firstly, the teletext card is set into a new mode so that no more teletext pages are received but the contents of the page store are displayed. Secondly, the microprocessor branches to the start of the new program in memory.

In this mode, the received program is run and will respond to inputs from the keypad and use the television screen as a colour visual-display.

The first 1K bytes of the control program may be replaced (via a hardware switch) by a monitor program. When the monitor has been switched-in, programs may be loaded into secondary memory from paper-tape using a teletype. The program may then be run in debug mode if required. When using the monitor, subroutines in the second half of the control program are still available.

It must be emphasized that in a “real” terminal no debugging or paper-tape facilities would be needed, since broadcast programs would have been fully debugged prior to transmission.

The Telesoftware Page

For the experimental project, telesoftware programs were broadcast as a series of teletext pages with up to eight pages forming a complete sequence. As previously mentioned, there is no way of determining which of the pages will be received first, so the terminal is capable of loading the pages in any order.

The format of the page is shown in Fig.2. and may be conveniently considered row by row.

Row 0 is reserved for the teletext page header and is not affected by telesoftware.

Row 1 contains a special password to identify the page as containing a program, and for this exercise we chose the combination “$%$%$%” placed at the start of this row. Since the remainder of the row is not used by the microprocessor, it may be used to display a meaningful program title.

Row 2 contains control data for the program and must therefore be very secure. This data is Hamming-Code (4) protected with each byte of data being represented by two contiguous teletext characters on the screen. To avoid using teletext control characters only six of the possible seven bits are used, giving a total of twelve usable bits. Eight of these bits form the data-byte and the remaining four

are used for error-detection.

Control data is further protected by a block-check character (BCC) and intotal uses sixteen screen characters. This control data is then repeated in the second half of the row as a further security measure.

The control data bytes are listed in Fig.2. and may be considered in order:

The Address Field is a two-byte address that specifies the loading address for the first byte of program data

The Count Field is a two-byte binary value specifying the number of bytes of program data on the page.

The Page Number uses a single byte for page identification and is in the range 0-7.

The Program BCC is a single byte and check the validity of the overall programme data.

The Control Line BCC is a BCC for the control data.

The remaining rows on the page (Row 3 onwards) are used to carry the program data. Like the control data, each byte of program is represented by two screen characters, each byte being Hamming-code protected.

For the experimental terminal, programs were broadcast using machine code appropriate to the microprocessor being used since this represented a compact and convenient method.

The maximum amount of program that may be contained in any one teletext page by the above method is 420 bytes.

Experimental Programs

For the terminal to be evaluated, four simple programs were produced to illustrate some of the main application areas for the system.

MORTGAGE CALCULATOR was design to calculate mortgage load repayments given user variables of sum borrows, period of loan and interest rate. Thus it enabled a user to calculate the effect of a rise or fall in interest rate.

INSURANCE QUOTATION allows the user to obtain a quotation for automobile insurance by entering numeric or multiple-choice responses to a questionnaire.

ESP was a number-guessing game, again requiring only numeric response from the user. This program incorporated a random-number generator.

FIRST-AID was an example of a simple educational program, designed around multiple-choice responses to a set of situation-type questions.

Software Constraints

The decision to use machine code for a single microprocessor was really for convenience in this particular experiment. When a final specification is agreed for telesoftware it would be more desirable to transmit programs in an intermediate or high-level language rather than in object code (machine code). This would allow different microprocessors to be used by the use of a resident interpreter, permitting far more flexible manufacturer design.

A compiler approach would be possible but impractical for telesoftware, since because both source (high-level language) code and object code have to be held in the terminal (albeit temporarily) at the same time, more memory is required. Also, the execution of the object program may not commence until the source program has been received and compiled, which results in undesirable delays.

Using the interpretive approach, the source program is broadcast and held in terminal memory, and each statement is individually “interpreted” into a sequence of calls to machine-code subroutines which form part of the interpreter.

It should be noted that at no time would the source program use the terminal hardware directly with this approach; only via the interpreter. This afford protection against any malfunction in the source code. It is true that the interpretive systems results in programs executing somewhat slower than using a compiler; typically 30 times slower, but with the current generation of microprocessors this is still acceptably fast.

Apart from deciding upon whether to use an interpreter or compiler approach for the future implementation of telesoftware, a suitable high-level language must be found and defined. This will form the subject of on-going research (5).

It must be remembered that a broadcast telesoftware service would, in the UK at least, be aimed primarily at the domestic user as a cost-effective method of personal computing. Thus the majority of users would not be experienced at all in the traditional usage of a computer, seeing the terminal in concept as more a “smart TV” than a “home computer”. So accepted computer-type operating systems, with error-messages such as FIELD OUT OF RANGE or INVALID OPERATOR (!) could not be used. Instead, very careful design of the programs would have to take place to ensure their high reliability in a run-time-only environment and the inability of the terminal to produce meaningless, obscure or incorrect information to the user, regardless of information input by him.

Applications for Telesoftware

As with any new process, specific applications crystallize over a period of development. It would be impossible at this stage to predict all the applications for telesoftware, but several groups of applications can be identified, and these groups will hopefully highlight the fundamental requirements which future applications will demand of the system. Some of these are now described.

Self-Assessment

For example, mortgage calculation, tax assessment, welfare rights. This group is of a question-and-answer nature with numeric and logical calculations being performed by the program upon data provided by the user interactively. Many uses would require only numeric input, needing only minimal keypad requirements, while others would have to use a full alphanumeric keyboard attached to the terminal. A characteristic of this application area is the high quantity of textual information held in the program.

The tremendous strength of telesoftware is its ability to update information. Consider the changes which might be imposed upon a tax assessment program by a parliamentary budget; with telesoftware, only the broadcast version of the program need be changed; once this has been done, it effectively updates every terminal in the country with the correct version of the program, which it can do the instant the new program is broadcast.

Video Games

These really divide into two groups; verbal reasoning games and dexterity games. The former are ideally suited to telesoftware since they involve the manipulation of straight textual data and should generally only require the normal numeric keypad for input. Exmaples of dexterity games, where factors such as hand-to-eye co-ordination figure, represent different requirements, the most obvious being the need for paddles, joysticks and other control devices extra to the keypad. A real-time clock might also be necessary to control game timing functions.

Education

This is a large and important area in which telesoftware has a great deal to offer. It provides two significant advantages: firstly it is completely free once the relatively inexpensive hardware (a TV set with minimal extras) has been obtained; secondly, any number of concurrent users may be supported – there is clearly no loading problem with the Ether!

Many different subjects could lend themselves to telesoftware implementation, including numeracy, science subjects and mathematics. Also, many existing and proven techniques for computer-aided learning can be translated directly to telesoftware.

However, in order to be reall efficient, a significantly large portion of a teletext database would be required to be devoted purely to the broadcasting of educational programs to provide the necessary diversity and complexity required.

Database Broadcasting

An example of this area is a system proposed to detect credit card fraud. In this application a telesoftware terminal is located near points-of-sale in stores and shops. A small telesoftware program is loaded into each terminal at the start of the working day and throughout the day a list of stolen or lost credit cards is broadcast at intervals and used by the program to update the list held within the terminal. The storekeeper when presented with a “dubious” credit card, keys its number into the terminal. The terminal then tries to match this number with one from its latest broadcast list. If it is successful then the storekeeper is advised to take preventative measures.

This illustrates the technique of a broadcast “database” which is of particular relevance where the amount of data is fairly small in total, but subject to very frequent updating. Depending upon the appplication, all or part of the database can be held in the terminal after it has been broadcast leading to fast searches through the data. Alternatively, data could be allotted fixed time-slots for broadcasting, and the terminal could wait for the data to be broadcast before examining it. This raises the possibility of closed-user-groups, where the data broadcast at particular times could be of interest only to a limited number of users.

System Enhancement and Standardisation

Clearly, some of the applications described above would be impossible or impractical with the hardware produced for the experimental project. At the time of writing, much work is underway to establish technical standards for a future telesoftware system and these will obviously include recommendations for terminal design. However, the degree of “tightness” of such a specification has to contrast very carefully between flexibility and economics. An ultra-flexible system would tend to be uneconomic in the early years, while an inflexible system could be very economic at the start, leading to rapid market growth, but would become increasingly restrictive as applications became more advanced and hardware even less expensive.

The over-riding factor in any such specification will be the need for telesoftware to become a compatible extension to teletext, so that existing decoder hardware is not rendered obsolete.

By the use of various enhancements telesoftware could also provide such facilities as high definition vector graphics and dynamically-redefined character sets, extending compatibly the capabilities of broadcast teletext itself.

Standardisation of a hardware interface could allow alphanumeric keyboards, printers, audio-cassette recorders and floppy disks to be attached to a terminal as peripherals. It might be desirable if such an interface could be compatible with devices already manufactured in quantity for traditional home computer systems.

Conclusion

The implementation of telesoftware using broadcast teletext has been shown to be able to provide a practical means for home computing and compatible extensions to the facilities offered by broadcast teletext itself. With mass-production of LSI units, the extra cost of incorporating a minimal telesoftware facility into a standard TV/teletext receiver would be in the order of $100 and such a figure could only decrease as the market became established. However, the limitations of the system have also to be recognised: it can never order a plane-ticket or make a hotel reservation, which are applications exclusively of two-way wired systems such as Viewdata. But its advantages of simplicity and low-cost make it ideal for the future domestic market, where it will provide the home user with many useful and imaginative facilities; all available under the homely guise of his TV set!

Acknowledgement

The author would like to express thanks to Mr. R C Eason (Mullard Ltd., UK) for this considerable assistance in the preparation of this paper.

References

1 Overington, W J G

“Telesoftware”, Computing Vol.5. No.18 pp25, May 1977

2 Hedger, J

“Telesoftware: Using Teletext to Support and Home Computer”, IEE Conference Publication 166, pp273-276, September 1978

3 Joint IBA/BBC/BREMA Publication

“Broadcast Teletext Specification”, September 1976

4 Hamming, R W

“Error Detecting and Error Correcting Codes” Bell Systems Technical Journal, Vol.26, No.2. pp 147-157, April 1950

5 Green, N W

“Software for Telesoftware”, Independent Television Companies Association, London. Report under preparation.

Biography

John Hedger was born and educated in London, England. He joined London Weekend Television in an administrative capacity but later spent some time working in programme production. He joined the ORACLE teletext project at its commencement and has since been closely involved with all aspects of the development of broadcast teletext. He now holds the post of System Co-Ordinator, and has special responsibility for subtitling for the deaf, telesoftware and related new technology.