Home
Please note this wiki relates to TELSTAR 2.0 only. Telstar 1.0 is no longer under development.
TELSTAR is both a viewdata system and a viewdata service. The articles here relate mainly to installing and managing a standalone Telstar system. Details of the Telstar viewdata service can be found at https://glasstty.com along with details of the the Telstar Viewdata Client and details of how to connect to the service.
The TELSTAR viewdata system, described here, provides a simple viewdata/videotex platform similar to those that were prevalent during the 1980s such as Prestel (https://en.wikipedia.org/wiki/Prestel).
The viewdata implementation described here can be accessed over the internet using modern internet modems in conjunction with historic viewdata and videotex terminals and home computers of the 1980s. In addition, the Telstar Viewdata Client (https://glasstty.com) can be used with modern computers (macOS, Linux, Windows).
Telstar is implemented as a simple TCP service which makes it fairly simple to integrate the system with the Asterisk telephone system and the BPQ32 Packet Radio node as well as other TCP aware applications.
The system adheres to the standards used by British Telecom's Prestel system as far as is practical and includes the following features.
- Full duplex operation
- Support for response frames
- Support for Telesoftware frames
- Extensible via a very simple plug in mechanism
- Support for pages with frames exceeding 26 using Zero Page Routing
- Support for external frame editors such as Edit.tf and ZXNet.
- Full duplex bi-directional Gateway frames to other viewdata and non-viewdata systems.
- TCP Service providing simple integration with Telephone and Packet Radio systems.
- Baud Rate throttling to provide realistic 1970s transmissions speeds over TCP.
- API for content and user management including bulk uploads from the local filesystem or a GitHub repository.
- Primary and secondary database storage allowing content to be viewed before being published.
TELSTAR is designed to run in a Docker environment and is supplied as a series of Docker images. These are easy to install and are described below.
The system comprises of several components, each of which run in their own container, the containers are connected to each other by a docker network and each container has access to a shared volume for file storage.
The following is a list of the essential components
- Telstar Server - The Telstar Server is a simple TCP service that can handle multiple connected clients it is not a Telnet service.
- MongoDB database - Viewdata frames are stored within the MongoDB database as json objects. This allows frame metadata such as custom routing, text headings, navigation messages etc.
- Telstar API - The Telstar API is a restful API that allows json formatted frames to be uploaded and managed. In addition user management can be performed.
In addition the following highly recommended components allow the system to be easily managed using a web interface
- Mongo Express - This provides a web interface to the MongoDB database.
- Portainer - This provides a web access to the running containers.
As is typical with interactive viewdata systems, pages are numbered from 0 to 999999999 and consist of one or more frames with the suffix a-z, for example the first frame for page 200 would be 200a, the second 200b and so on ( see Routing for more details).
Content for the system is based on simple json files which include the page content as we as frame metadata such as custom routing, text headings, navigation messages etc. There are several frame types that can be defined within the frame's json file, this makes it very simple to define basic information frames, gateway pages, response frames etc. and content can be defined as plain text, markup, or by using one of the popular frame editors such as Edit.tf (https://edit.tf) and ZXNet (https://zxnet.co.uk/teletext/editorfor).
Frames are added and deleted using a cross platform command line utility, telstar-util, which provides a very simple way to access to the remote Telstar API. In addition, telstar-util can be used to perform bulk uploading of frames from either the local filesystem or from a remote git repository such as those provided by GitHub (http://github.com).
Whilst telstar-util provides a simple means of managing content via the API, the Telstar API is a restful API and can be used directly by any software making it simple to integrate into existing workflow as required.
Further details of the Telstar API and the command line utility can be found in the section The Telstar API.
There are several frame types that can be defined within the frame's json file, this makes it very simple to define basic information frames, gateway pages, response frames etc.
Full details of all of the frame types and how to create them is described in the section Frames.
Response frames are frames that allow a user to enter data that is to be processed i.e. a frame where a user enters data such as a form. The data from these frames would typically be processed using an external program or script referred to as a plugin. The plugin can be any software that can be executed e.g. a binary program or a scripts such as Python or Bash etc. All that is required is that the plugin returns a json result, this would typically be a frame or collection of frames.
As an example the Telstar Service (https://glasstty.com) weather page is handled using a response frame and plugin. The user is presented with a response frame asking for a town or city. This is passed to an external plugin written in Go (Golang) which accesses the Openweather API and returns the current weather and forcast as a collection of JSON frames. These are captured by Telstar and presented to the user.
Plugins are simple to create and deploy within a Telstar container and can be written in any language supported by the platform.
Further details of the Telstar Plugin framework and how to create them can be found in the section Implementing Response Frames.
Routing in Telstar is handled by a full duplex asynchronous process that allows for routing to occur whilst pages are being rendered. This means that a user of the system can navigate quickly to a desired page by simply entering the page number one character after another. Each successive key press will start the rendering of a page but as each subsequent key is pressed, the rendering is cancelled and the following page is rendered and so on until the desired page is rendered.
For example simply pressing 2 2 2 from the main index page (Page 0a) of the Telstar Service will result in the Guardians UK News being displayed. For this to work correctly, all intermediary pages must be present. Creating routes through the system such as the one described above, should be the aim when designing a viewdata system.
Users can jump directly to a known page by entering the page number using the format *page#, for example, entering * 92# into the current Telstar system will direct you to page 92.
Full details of page numbering, zero-page routing and how to modify routing tables can be found in the section Routing.
Details of how to install Telstar are detailed in the article Installing Telstar. Telstar can be configured and customised as required, see Configuration Options for details. Once the system is installed and running it can be managed using Portainer, see Managing Telstar with Portainer.
Whilst TELSTAR is accessed using TCP/IP it is not a Telnet Server. However, TELSTAR does include a Telnet parser which will respond to a very small subset of Telnet negotiation requests.
When a client first connects, TELSTAR attempts a simple negotiation with the client to establish two protocol settings;
- to ask the client to not use line mode;
- to indicate that the server will echo any characters received,
Non-Telnet clients can safely ignore this negotiation request completely.
TELSTAR is designed to operate at 1200 baud when accessed by non-Telnet clients (see below), this speed is set at the server. There are two main reasons why throttling exists.
- Prestel was 1200 Baud – This is not strictly accurate of course, it was the modems most commonly used with Prestel that received at 1200 baud, Prestel had a 300 baud service and other speeds were sometimes used for editors and administrators etc.
One of the aims of Telstar was to recreate the feel of an online system such as Prestel. The near instant access but slow rendering of pages sets it apart from Teletext page displays of systems such as Ceefax and Oracle.
- Menu Navigation – The way in which menus were navigated on a Prestel type system was primarily through single key presses, e.g. ‘2’ for the News Menu followed by ‘1’ for BBC News etc. A user pressing ‘2’ for the News Menu could immediately follow this by pressing 1 for BBC News and this would cancel the rendering of the News Menu and invoke rendering of the BBC News page. This may seem trivial today but this syetem worked really well and I particularly wanted Telstar to behave in this way to give users the full experience. This is only really possible with Telstar running at a throttled speed.
Whilst TELSTAR is accessed using TCP/IP it is not a Telnet Server. However, TELSTAR does include a Telnet parser which will respond to a very small subset of Telnet negotiation requests. see Telstar is not Telnet above.
If Telstar identifies the client as a Telnet client, the system will run at full speed. Non-Telnet clients can safely ignore this negotiation request completely. If you are writing a client and you want full speed access, simply send something like FF FD 03 after connecting. This is the IAC DO SUPPRESS-GO-AHEAD sequence.
For example Richard Russell’s BBC Basic client uses the following code just after successfully connecting.
REM Start the telnet negotiation:
init$ = CHR$255 + CHR$253 + CHR$3 : REM IAC DO SUPPRESS-GO-AHEAD
PROCout(init$)
Similarly if you want to use Richard’s client at the 1970/80s speed then simply remove that sequence e.g.
REM Start the telnet negotiation:
REM init$ = CHR$255 + CHR$253 + CHR$3 : REM IAC DO SUPPRESS-GO-AHEAD
REM PROCout(init$)
The website icon is derived from work by Dan Farrimond. This original work and the icon is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license (https://creativecommons.org/licenses/by-sa/3.0/deed.en).