The picture and colour facilities are discussed together here because both of them are supported from disk. The reasons for choosing a disk are:
Of course there is nothing new about storing infinite information on a finite machine, so this paper is just a record on what have been done and unavoidably we may have to muddle with the implementation detail at times.
Picture definitions are stored on disk as they are read in blocks of 376 words (octal). A directory is kept in the memory and each entry in the directory is 2 words long which contains information on picture numbers, states and addresses. There is also an execution vector which keeps a record on each picture which is still active.
As with III, picture. definitions cannot, be nested, but requests to draw a picture may be included within a picture definition. Pictures of the ID frames are still kept in the central memory partly to keep that option open and partly to avoid unnecessary overheads on small jobs. Picture definitions will he lost at the end of a job (or as soon as it is deleted). The conflicts between colour and picture will be discussed in section 3.1.
In order to avoid changing the colour filters too often, it is decided that a colour filter will remain there from when it is first inserted till at frame advance. It may be true that the colour concerned may not be required all the time when the filter is there (see diagram-2) and this is dealt with by blanking the PLS (effectively that means nothing is to be recorded). Obviously this may not be ideal for certain jobs, but at the moment we are more interested in the result averaged over a large number of mixed jobs. Nevertheless the design is flexible enough to accommodate future changes should the result prove to be unfavourable.
Basically, if two colours {or more) are required, the instructions will be repeated once for each colour. This is quite understandable if we have a situation like diagram-1. On the other hand, the situation may be as shown in diagram-2. Suppose the colour filter is changed when C(2) is required, then a repeat is quite unnecessary. But as we have just said, although C(1) is not required in region B, the filter is still kept there until ADV is processed and that means region B has to be repeated for colour C(2). It is all because we may have a situation as shown in diagram-3. From now on we shall call region B in the three diagrams as a "MULTI-coLOUR-RANGE" to reflect the fact that more than 1 colour is required.
Graphic orders will be dumped to disc as soon as a multi-colour-range is detected, which means that this takes place at the same time as the_ instructions are obeyed. There are two problems (at least):
The solution to problem 1 is simple:
Picture definition and deletion is not allowed in multi-colour ranges.
There is no restriction in this respect. An overlay mechanism is provided to overcome the storage problem. It may be appreciated that it is not desirable to break the graphic instructions at any arbitrary points, for example, in the middle of a text or a 2- or more words instruction. On the other hand one must avoid to incur a large overhead in finding a suitable breakpoint. Briefly speaking the method we choose is to plant a breakpoint early enough so that even if we are in the middle of a text, there is still room to accommodate the rest of it. When the limit is about to be hit, an 'SOS' will be sent to the 'instruction dispatcher' which will then stop fetching further graphic instructions until the message is cleared. It has to be mentioned that as the message can only be seen by the dispatcher, so it will not be possible to break it at any convenient point. By introducing the breakpoints, region B is now divided into sub-regions (if necessary) B(0), B(1), B(2),... etc. When each B(i) is reached the system will go back to B(i-1) until all colours specified in that sub-region are processed. A table must be kept so that colours will be restored when the next sub-region is entered. Of course, more filter changes are necessary under this scheme. But bearing in mind that now we are talking about fairly large multi-colour ranges and so the overhead is justified. As the filter used in the previous region will be carried over to the next region., so the actual number of changes is not as many as one may expect. (There will be a check on whether that colour is actually being used or not, if not, the filter will be changed. This may sound contradictory to what is said before, namely, a filter will not be removed till frame advance, bu in fact that is not true because of the similarities between ADV and BREAK with respect to backspacing.)
At the moment the BREAK mechanism is hidden from the users as well as the graphics packages. But perhaps this is the right direction to follow if we want to remove the filters as soon as they are not required. That means, the users will be allowed to use BREAK explicitly at their own discretions.
All our efforts so far are channelled to overcome problems caused by using the disk. This is expected as the disk is not that widely used before on the FR80. A happier note is that at the end we have got not only the colour and picture facilities, but the disk facilities as well.
