York Hackspace

This is the second post in a multi-part series about viewdata. A few members of the hackspace are working on a project to connect a ZX Spectrum with Prism VTX 5000 modem to an emulation of a viewdata system, providing a live demonstration experience.

Viewdata connections, much like dial-up internet access which followed later, relied on audio frequency telephone communication to transfer data between the user’s terminal and the information provider they were logged into. I’ll cover details of the signal modulation in a separate article; in this article I’ll describe how I connected a real Prism VTX5000 modem to a laptop’s sound card.

A UK telephone line, like that in most countries, is a relatively simple circuit. The line is supplied from a bank of batteries with approximately 50V DC, with earth on the positive side (to prevent line corrosion by offering cathodic protection). This would have originally been supplied via a pair of relay coils, which have three main effects:

• The coils have a DC resistance, which in practice limits the off-hook condition of the line to about 8V at 20mA
• The coils present a large inductance, which prevents AC (i.e. the audio signal) from being lost into the supply
• The relay contacts are used to detect when the line is off-hook

For the purposes of our simulation, we only need the line simulator circuit to behave like a line in the off-hook state. This means it can run from a low-voltage supply of 9-12V. We’re also not interested in providing a ring signal (typically around 90V AC), as it’s also not required for this project.

On a telephone line, the AC audio signal sees a resistance of around 600 ohms. Audio signals are coupled to the phone line via capacitors, which pass the audio signal but block the DC supply.

The line simulator therefore has the following requirements:

• To provide approximately 20mA at around 8V DC with a telephone connected off-hook
• To provide several kilohms of dynamic resistance at DC
• To provide around 600ohms of resistance to AC
• A means to inject an audio signal from a laptop onto the line
• A means to take off an audio signal to feed a laptop’s line input
• Protection to prevent overloading of the sound card

Starting with the DC requirements, a fairly simple transistor circuit can be made to act roughly like a current source, up to near the circuit’s supply voltage. Adding a bypass resistor permits the introduction of a controlled dynamic resistance at DC, and this also affects the off-hook voltage level.

To provide the required AC resistance and injection capability, the circuit can be coupled via a capacitor and series resistor to the laptop’s headphone jack. A second resistor to ground helps to block the DC supply. A headphone output has a very low resistance of a few ohms at most. A 680 ohm resistor increases this to a more suitable level. While this is slightly on the high side, it leaves some room for other parallel resistances of a few kilohms, which the circuit will introduce.

The protection and take-off requirements can be met simply by placing two signal diodes in inverse-parallel; this limits the line signal to 0.7V peak, and also limits the extent of transients when the line switches between on- and off-hook conditions.

Line Simulator Circuit Schematic

The complete line simulator circuit is shown above. The LED and series resistor are used to provide suitable biasing to the transistor. An unintended side-effect is that when the phone is on-hook, the LED supply is bypassed by the transistor, so the LED also acts as an off-hook indicator.

This circuit can easily be built on a small piece of stripboard. ADSL filters are widely available, and often going spare. These provide a suitable project box and, with the rest of the filter components removed from the board, a pair of phone jacks which can be connected to the line simulator circuit. Note that the circuit as presented is not suitable for connection to a PC microphone jack as the signal level is far too high; to use this an attenuator would need to be built in, which could be achieved with a simple resistive divider.

Once constructed, check the voltage at the phone socket is about right, then plug in an old phone to check it’s working. You’ll probably hear some quiet line noise, and the LED should light when the receiver is lifted. If you connect the circuit to a laptop or music player, you should be able to hear audio played clearly through the phone, complete with that lovely tinny quality.

This is the first post in a multi-part series about viewdata. A few members of the hackspace are working on a project to connect a ZX Spectrum with Prism VTX 5000 modem to an emulation of a viewdata system, providing a live demonstration experience.

Back in the early ’80s, before the world wide web was a thing, there was something a little like Teletext called Viewdata.

Viewdata pages look a lot like Teletext – they share the same frame formats – and viewdata terminals likely used the same IC to produce the video signal (The Mullard SAA5050, also used in the BBC Micro for its text-only mode). While teletext pages are transmitted in the blanking interval of a TV signal, in rotation so a receiver needs to wait for the right page, viewdata operates over a telephone line and so is more interactive.

When a subscriber wanted to log onto the service, they dialed the provider they wanted to access – for example Prestel – and provided their ten-digit ID number and password to log in.

Once logged on, the user was presented with the main page, and navigated using the number keys and enter. Pages were generally arranged hierarchically, so page 1234 would be below 123, and is reached from that page by pressing ‘4’. Like Teletext, viewdata pages could consist of multiple frames, so pages longer than one frame could be constructed.

Companies who wanted to host information on a viewdata service would pay the information provider (IP); this would involve a payment for a particular length of prefix (shorter prefixes would typically be more expensive), and also per page hosted. They could edit frames using special editing software, and then uploaded these to the IP. Frames weren’t restricted to being completely passive – “submission” frames could be authored, allowing people to order goods or fill in forms. Frames could also be marked with a cost, allowing companies to collect money against a user’s account when they accessed the information.

Often, information providers would have a mailbox system, allowing users to send each other messages, which could be retrieved and read when the user logged in. Some terminals would allow these, as well as other frames, to be retrieved and stored locally, so they could be read offline without the user keeping the line open.

As well as centralised information providers, such as BT’s Prestel, software later emerged allowing people to host their own viewdata systems – often bulletin boards – or set up peer-to-peer connections. Peer-to-peer connections allowed users to phone each other, and as long as they set their modems correctly, information could be transferred half-duplex. Bulletin boards could be run on systems such as the BBC Micro, and would present themselves in the same manner as an IP.

The modem standard – v.23 – used for viewdata is asymmetric. The forward channel (download) runs at 1200 bits per second (120 characters per second taking framing into account), while the reverse channel (upload) runs at 75 bits per second (7.5 characters per second). A terminal – apart from any storage functionality – is relatively “dumb”, and transmits key presses immediately. The information provider’s system reacts as needed – whether this means sending a new frame, or echoing characters typed into a response frame. The slow reverse channel is still generally fast enough to transmit the user’s keypresses, and is fairly noise-resistant because of the low bandwidth.

There are sites which contain demonstrations of some viewdata systems – https://www.viewdata.org.uk/ is a good example of this. Follow the “Logon Now” link to access an example.