(Windows only) This option causes A-Shell/Windows to emulate 'field' attributes (i.e. like the AM62A) rather than the 'mode' attributes which are otherwise normal under Windows (as well as the AM65 and VTxxx terminals.) In the normal 'mode' operation, all video attributes (such as reverse and underline) work just like dim and bright, except that the on and off commands cause a space to be output (unlike dim and bright, which do not.) That is, the attribute for a character is determined by the chronological sequence of attribute commands which preceded the display of the character.
When the FIELDEMU option is active, the attribute for a character is determined by the position of that character on the screen relative to attribute on/off commands which may be embedded in the display. The chronological sequence of the commands has nothing to do with it. For example, consider the following statements:
PRINT TAB(-1,0);
PRINT TAB(10,15);"What am I?";
PRINT TAB(10,9);TAB(-1,32);TAB(10,25);TAB(-1,33);
In field operation, the "What am I" string will appear in reverse video, even though the reverse ON command (-1,32) was sent chronologically later than the "What am I?" string. However, in mode operation, no reverse video will display at all, because no characters were actually displayed after the reverse video on command and before the OFF (-1,33) command.
To allow the above program to work correctly in both field and mode environments, it should be changed as follows:
? TAB(-1,0);
? TAB(10,25);TAB(-1,33);TAB(10,9);TAB(-1,32);
? TAB(10,15);"What am I?";TAB(-1,33);
The first TAB(-1,33) is superfluous in mode operation, and only serves in field operation to limit the screen flash that would otherwise appear when the TAB(-1,32) command is given. Since the TAB(-1,32) is sent before the "What am I?" string, as well as positioned to the left of the string, the string will appear in reverse in both field and mode environments.
Finally, the last TAB(-1,33); is superfluous in field operation (given that we already stored a reverse-off attribute in that position in the previous statement) but it is needed in the mode environment to prevent subsequently output characters from appearing in reverse.
The sole purpose for implementing the OPTIONS=FIELDEMU feature is to allow programs that were written strictly for field devices (like AM62A terminals) to work properly under A-Shell/Windows. Previously, the only option available to prevent such programs from displaying their attributes all mixed up was to specify OPTIONS=NOFLDATTR, which simply disabled the field attributes.
If your programs are able to run in both field and mode environments, then they will probably run faster and cleaner under A-Shell/Windows in the normal 'mode', since the performance advantage of certain field operations on a serial terminal (like moving a menu bar up and down) is lost in Windows where there is no noticeable screen I/O bottleneck.
Two other notes about the implementation of field attributes: 1) unlike on the AM62A terminal, A-Shell will automatically terminate the field spillover effect at the end of the line, rather than letting the attribute spillover to the end of the screen. Technically this is incorrect, but it is so rare for software to be deliberately written to take advantage of that spillover, and so common for the spillover to produce an unwanted screen flash, that we decided this was an improvement. 2) A-Shell does not currently support the blinking attribute.
Under A-Shell/Unix, the choice of Mode vs. Field is determined entirely by the choice of terminal driver, which in turn is determined by the TERM environment variable setting.
