Philips/logical description
INTRODUCTION.
This document describes the Philips Terminal System (PTS) as it was used in Denmark in the 70's and 80's.
It's primary use was a front-office terminal system for local authorities, but it was also used by the State Railways for seat reservation, as well as a data entry system for budget transactions for the PTT. One of those (PTT) boxes is now in the process of being changed to a real PTS 6813.
You should be aware that this is not a tutorial, just some general remarks. If you want to dive into the bowels of PTS, you are welcome to dig into the documentation, which will be on-line at some as yet undefined moment.
It must also be said, that as it is about 35 years ago I generated my last Monitor (see later), it could very well be that some finer points have escaped me.
The hardware.
The basis of the hardware comes from the P800 series, which was very popular in industrial circles, e.g. for process control.
The PTS range was available with a selection of CPU's and memory sizes, but to the best of my knowledge only the P852 and P857 CPU were used in PTS.
The system was put together from a lot of standard OEM compoonents like printers from DataProducts, floppy drives from Shugart, harddiscs from Control Data, card readers from Documation, etcetera (this was quite common in the IT industry those days; Regnecentralen did the same). The hardware was connected to the PTS system via in-house (read : Philips Elektronik Industrier i Järfälla, Sweden) developped adapters.
The CPU box, about the size of a washing machine, could accommodate up to 10 adapters for the control of various hardware.
CPU, I/O processor, memory and memory management unit (MMU) were all on separate boards, leaving not many slots for external hardware, so an expansion box could be connected. The original expansion box is now being rebuilt, so it eventually will be working as a genuine PTS6812.
The Development System
The P800 system was "blessed" with a number of Operating Systems. I recall DOS and DOM (DOM should have been called something else, as DOM in Dutch means : stupid).
DOS was used as the Operating System for the development system, consisting of an 6810, 6812 or 6813, equipped with a console (PER3100), one or more harddiscs (6875 or 6876), with a capacity of 2x 2.5 resp 2x 5MB. To confuse things, the disks were also known as the X1215 and X1216 in other product lines. This is typical for Philips : the same hardware has different names, depending on where they are used. This is possibly due to the fact that the development of products was so decentralized.
For backup and for release distribution, a 800 or 1600 bpi magtape drive from Pertec was used. A 200 or 400 lpm printer with Centronics interface was also part of the system.
Generating Applications
Probably because of its origin in the process control industry, end-user systems were normally turnkey systems. This implied, that the operating system could be tailored to the needs of the end-user, which again implied that he could save a bundle on memory expenses. In those days, memory was very expensive, as memory chips had not been invented yet, so everything was done with semiconductors and ferrit core memory. It was therefore very common to have complete systems within 16 or 32K memory.
(A bit of folklore : I once worked on an IBM System/360 model 25 system. I had to do some statistics, and just could not get the program to fit in the 28K available. A complaint to my boss resulted in the LEASE of a 4K memory module).
Also, turnkey systems did not normally need expensive things like operator console, screens, etc. The system interaction was accomplished via toggle switches and pushbuttons.
When an application for a client was to be generated, we had to find out what type of external units he needed. How many keyboards (and what type), number and type of printers, did he need 3780 or SDLC or other communication protocols, etc.
The way to get such a turnkey system went like this :
Start the development system, and run a program called SYSGEN. This program would ask a lot of questions, like 'Do you need a keyboard?'. If you answered YES,you would be asked for the keyboard type (6231, 6234, 6271, 6272), and then you would be asked for details relevant to the selected keyboard.
The system would then generate a device driver, based on the answers. This would be repeated for every device supported by the software release.
Generating such a Monitor, as it was called, could easily take half a day, and if you selected e.g. a wrong keyboard, you could start from scratch again.
When the SYSGEN was satisfied with your answers, it would ask for how many of each device you wanted, and how the terminals were to be configured, and that would then result in a small file defining a number of lines, which at run time would set up the required blocks, so external units would not overwrite other units blocks. This worked in fact very nicely.
A typical configuration for a front office terminal was 1 numeric keyboard (6231) or 1 alphanumeric keyboard (6234), 1 triple-function printer, and one plasma display. This terminal would be used for the cashier function, where people could come and pay their taxes, or collect social support, etc. The printer was then used for updating their account card, so they could see how much they still owed.
Another typical one was 1 alphanumeric keyboard, 1 80x24 VDU, and 1 printer for fanfold paper. This terminal would be used for on-line communication with Kommunedata, which was the IT center owned (at that time) by the local authorities, f.eks. for requesting data from the CPR register.
So, a big local authority could have e.g. 5 local "cashier" terminals and 2 identical but remote terminals, and 2 Kommunedata terminals, another one could have 1 cashier terminal and a 3780 communication. As long as the devices used were idential, they could share the same Monitor.
It must however be said, that as time passed, we started to generate one monitor per customer, as we were reaching the maximum capability of the Credit language (see later) as well as the memory capacity available.
The data entered was not transmitted immediately, because that would have required a leased line to KOmmunedata. Instead, the transactions were saved on a floppy disc or an ECMA34 cassette, and sent to Kommunedata after office hours, via a 3780 protocol.
The connection of the terminals to the CPU box, was quite ingenious.
For every terminal, there was a local unit, called SUM (Selector Unit MOdular). This small box controlled the communication with the I/O adapter on one side, while controlling the dataflow to/from the various terminal devices on the other side. Each device had again its own card within the SUM, so they were very configureable.
There was also a SUL (Selector Unit Local), but that one was not configureable.
Sometimes there was such a large distance between terminal and CPU, that modems had to be used. This was not a problem, but the speed was limited. As I recall it, it could not exceed 2400 bps.
(MUCH MORE TO COME)