The 1456 implementation of the Java setXORMode and setPaintMode methods.
William Overington
Copyright 2000 William Overington
Throughout the design of the 1456 object code system there is a policy of seeking to provide opportunities for 1456 programmers to be able to utilize features of the underlying Java graphics system as they may choose, leaving the decision as to whether any particular provided feature is actually used to the 1456 programmer. Some features that are provided may be used a lot, some less so and some potentially not at all. Nevertheless, enabling 1456 programmers to make those decisions themselves is regarded as a highly important design feature of the 1456 system.
Accordingly, the eutodraw system now has facilities to allow 1456 programmers access to the setXORMode method of Java graphics to switch on the XOR drawing mode, together with the facilities for access to the setPaintMode which may be used to switch the XOR drawing mode off.
Access to these facilities is using the eutodraw table. Action code 88 will set the system into XOR drawing mode, with the chosen colour selected in the usual manner. The Java setXORMode method takes a colour as an argument. An often used feature of using XOR mode is that the chosen colour is the same colour as the background colour of the display. However, any colour may be used and interesting effects may be achieved. It is by no means certain that the same colour effects will be achieved on all browsers. However, a feature which is said to be universal is that drawing the same item twice in succession using XOR mode gets one back to the original display. As mentioned above, an often used feature of using XOR mode is that the chosen colour is the same colour as the background colour of the display. It would be nice to have a command explicitly for that purpose. Action code 89 is designated for that purpose, but is, at the time of writing unusable, as I have not yet found a method of programming it. (In the 1456 system, for action code 89 the colour code would be irrelevant, so that 8900 and 8906, for example, would mean the same, so 8900 is always used, by convention, to minimize any possibility of confusion.) It is an interesting problem. Hopefully there is a technique that can be used. At present 1456 programmers need to specify the colour parameter explicitly. For example, if the Print1456blue.class 1456 applet landscape is being used, a 1456 programmer may wish to use blue as the colour parameter of the setXORMode method of the underlying Java. Here a control code of 8806 will be needed, as 6 is the code for the colour blue in the 1456 system. Action code 90 will set the system into the paint mode, that is, putting the graphics system back as it started. However, items already drawn are not altered, the drawing mode appears to only be of relevance at the moment of drawing. Action codes 88, 89 and 90 do not set the drawing colour. As the use with a black background has been found to be particularly useful, a new version of the Print1456 1456 applet landscape is also being provided, namely the Print1456black 1456 applet landscape. Here is a link, together with a repeat of the link for downloading the Engine1456.class file. The Engine1456.class file has been updated at various times, yet all of the links to it throughout this set of documents all link to the same file, so they have all been automatically updated in their effects. The version at this stage is placed on this webspace on 20 November 2000.
It appears to be necessary that, if a 1456 programmer wishes to use the setXORMode facility, then XOR mode needs to be set each time that control is passed to the paint method of the 1456 applet landscape. This means that each time control passes to the 1456 engine at an entry label point that XOR mode needs to be entered if it is desired to use XOR mode. Although the 1456 software interrupt mechanism passes control back to the 1456 applet landscape, XOR mode need not be entered again after return from a software interrupt as the software interrupt is handled in the paint method of the 1456 applet landscape, so the system remains in XOR mode, unless the software interrupt is used to turn it off. However, it would do no harm to explicitly switch it back on after a software interrupt, just in case the software interrupt does some drawing. In this regard, it might be advisible to turn XOR mode off if a software interrupt that involves any drawing is being carried out, as the 1456 applet landscape may not reset the drawing mode. The two square illustrations on this page show the effect of using XOR mode by contrasting a diagram drawn using XOR mode, shown to the left of the page, with a diagram that is exactly the same except that the setting of XOR mode has been commented out. The use of XOR mode has enabled the presentation of a stylish graphic. As there is some uncertainty as to how the diagram on the left will appear on some browsers, let me here mention that it is intended to be a black background with three overlapping circles of colour. Where red and green overlap, there is a yellow area; where red and blue overlap there is a magenta area; where green and blue overlap there is a cyan area; where red, green and blue all overlap there is a white area. Feedback from readers as to how the diagram appears in various browsers would be appreciated please. The third diagram has been drawn to show that the drawing mode appears to only be of relevance at the moment of drawing and that items already drawn are not altered. The system is first set into XOR mode and red, green and blue discs are drawn in the left hand part of the area of the diagram. The system is then set into paint mode and red, green and blue discs are drawn in the right hand part of the diagram. The system is then put into XOR mode again and the upper white horizontal bar (a filled rectangle) is drawn. The system is then put into paint mode again and the lower white horizontal bar is drawn. Please note that this produces every permutation of drawing upon a previous drawing using XOR mode and paint mode. I would like that a control code of 8900 could be used, so that whatever the background colour, that background colour would be used as the parameter when setting XOR mode. Unfortunately this is causing problems for me at my present level of knowledge of the Java language. The background colour is set in the 1456 applet landscape. I am seeking to retrieve that colour within the 1456 engine, which is defined in the Engine1456.java class. The use of the action code 88, which is included so that any colour may be used as the parameter of the setXORMode method, means that, notwithstanding the fact that the action code 89 feature does not work (yet?), that the same effect can be achieved by setting the chosen colour to be that of the background colour explicitly using an action code 88 command to the eutodraw system, though I would like to resolve the problem of the action code 89 if I am able to do so. The achieving of this would add a portability advantage if, say, someone wished to copy some software prepared using a 1456 applet landscape with one background colour and use that software with a 1456 applet landscape with a different background colour. This is a similar goal as was achieved with the action code 91 command mentioned in a previous document, namely The eutodraw system, part 2. However, it needs to be mentioned that the use of XOR mode graphics is less predictable in its effects, so such a portability goal may perhaps not, in the event, have quite the advantages that may be presently imagined. Action code 90 will set the system into the paint mode. The paint mode is the mode at start up, unless the 1456 applet landscape causes XOR mode to be entered. It is unusual for the 1456 applet landscape to do that, but the existence of that possibility is mentioned for completeness.
1456 object code
Copyright 2000 William Overington