ASCII CHARACTERS 128 TO 255

INPUT CHARACTERS IN PILOT 

The ACCEPT statement allows codes 32 to 255 to be entered as part of student 
replies.  Characters in this range are echoed to the display so that the 
student sees what has been typed.  

Characters from 0 to 31 are reserved for special purposes; specifically, 
character 13 is the RETURN character which signals the end of the student 
reply.  Character 8 is a backspace character which may be used to back up and 
correct typing errors. And character 3 (ctrl-C) cancels a PILOT program 
immediately. Other characters in the range 0 to 31 are completely ignored by 
the ACCEPT statement (unless it is an ACCEPT-SINGLE, AS: in which case all 
codes other than ctrl-C may be entered).  

BASIC appendix G, pages G2 and G3, show the codes generated for most of the 
normal printable character keys on the keyboard. The chart below shows the 
codes generated for the various special keys on the keyboard.  

DEFAULT KEYBOARD CODES ON AN ACCEPT STATEMENT 

128-131     alt- 9 0 - =
132         ctrl-pg up
143         shift-tab
144-153     alt- Q W E R T Y U I O P
158-166     alt- A S D F G H J K L
172-178     alt- Z X C V B N M
187-196     f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
199         home
200         cursor up
201         pg up
203         cursor left
205         cursor right
207         end
208         cursor down
209         pg dn
210         ins
211         del
212-221     shift- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
222-231     ctrl-  f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
232-241     alt- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10
242         ctrl-prtsc
243         ctrl-cursor left
244         ctrl-cursor right
245         ctrl-end
246         ctrl-pg dn
247         ctrl-home
248-255     alt- 1 2 3 4 5 6 7 8

HOW TO CHANGE KEYBOARD VALUES

The  NX: statement allows the program to  change the  code  generated by any 
key from  the  value shown  in the above table (or in BASIC  appendix G)  to  
any other value from 0 to 255.  In  this manner the student can be informed 
regarding  an alternate use of the keys when responding.  Thus the following 
statements would make sense.  

       NX:153,227
       T: Dear student,
       :  If you wish to reply with the Greek letter
       :  PI in any of your answers hold down the
       :  ALT key while pushing the P key.
       
After the above NX: statement, any time the student typed ALT-P, character 
227 would be entered into the answer buffer and (assuming screen mode 0-3) 
the letter PI would appear on the  screen. The ability to re-define the 
keyboard keys allows the student to answer  with any  characters the program 
writer has chosen. The AX:  op code can be used to make the keys temporarily 
act like their normal defaults when it is necessary to be able to use the 
keyboard in two ways depending on the context.  

192 @      224 `
193 A      225 a
194 B      226 b  
195 C      227 c 
196 D      228 d  
197 E      229 e
198 F      230 f
199 G      231 g
200 H      232 h
201 I      233 i
202 J      234 j
203 K      235 k
204 L      236 l
205 M      237 m
206 N      238 n
207 O      239 o
208 P      240 p
209 Q      241 q
210 R      242 r
211 S      243 s
212 T      244 t
213 U      245 u
214 V      246 v
215 W      247 w
216 X      248 x
217 Y      249 y
218 Z      250 z
219 [      251 {
220 \      252 | 
221 ]      253 }
222 ^      254 ~ 
223 _      255 Alt-8



Appendix C. STUDENT RECORDS 

The File In, File Out and Keep statements can be used in many combinations to 
perform custom student record keeping. The unique needs of any program can be 
accommodated by programming the desired record keeping functions into the 
program. There are however, several typical record keeping functions that may 
occur in substantially the same form over and over. Since these needs arise 
repeatedly PILOT provides a set of simple macros which can be used to include 
student record keeping in a program with minimal effort.  

To use these macros, the author would include them at the appropriate points 
in the program via the F7 key of the EZ editor.  

RESTART MACROS

The term "restart" implies that the student may leave the program prior to 
completion, and may resume at the same point in the program at a later time. 
These macros are used to build a student restart file which contains the 
student's id number, name, and the point at which the student should resume 
upon return to the program. These macros also provide for the preservation of 
data about the student's progress.  The size and nature of that data is up to 
the programmer.  

To use these two macros it is necessary to include the "RESTART.PIM" macro in 
the initialization section of the program. Then the "CHECKPT.PIM" macro is 
included at every point within the program where the student might be 
permitted to resume upon return. If the program is a series of distinct 
problems, the start of each problem might be considered to be a check point.  


PROGRAM ORGANIZATION 

The organization of the program should be as follows: 

       <your program initialization code>

       RESTART macro expanded here
       . . .

       CHECKPT macro expanded here
       <first section of the program>

       CHECKPT macro expanded here
       <second section of the program>

       CHECKPT macro expanded here
       <third section of the program>
       . . .

       CHECKPT macro expanded here
       <message informing user that program is completed>


THE  RESTART.PIM  MACRO

Prior to the RESTART macro, use EZ to write your dimension statements, set 
the screen modes, etc, and perform any initial code which would need to be 
done for any student whether returning to the program or starting for the 
first time.  

Then, still in EZ, position after the above statements, push F7 and enter the 
name RESTART.PIM.  The RESTART macro prompts for two parameters. The first is 
the name of the file to be used for keeping student data. You can enter any 
valid file name or just push the ENTER key to use the default file name 
"RESTART".  

The second prompt requests the size of the user data area to be set aside in 
each student record. This area is used to store any data your program might 
need to keep about a student. The restart macro records this data at each 
check point and restores it upon each program restart. The programmer can 
choose to retain from 0 to 500 bytes of student data. In the simplest case 
just push ENTER to indicate that no optional student data area is needed.  

Once the two parameters are entered the RESTART macro expands about 3 screens 
of PILOT code. When the program is executed, the code asks for the student 
ID, and name. It maintains the restart file and handles the branching of the 
student to the appropriate restart point upon return.  

THE  CHECKPT.PIM  MACRO

Next, determine which points within the program are check points. A student 
always resumes at the last check point passed prior to leaving the program. 
At the start of each section which is to be a check point, use the F7 key and 
enter the name CHECKPT.PIM.  This macro expands the code necessary to save 
the student restart data at that point so that restart can function.  

It is completely up to the programmer to determine how many check points are 
placed in the program, and where they are placed. Each time the student 
reaches a check point the location of the check point and the current value 
of the user data variable UDAT$ is recorded in the restart file under that 
student's id. When a student starts the program, the student's id number is 
used to look up the student record. The value of the user data variable UDAT$ 
is restored from the last data saved in the student record, then a Jump is 
performed to the last check point location saved for that student. 


SAVING USER DATA

The program can use the restart facility to save data about the student from 
one run to the next. To do so, when entering the RESTART macro, indicate the 
number of bytes to be reserved in each student record for optional data. The 
number may be from 1 to 500. The actual amount is up to the programmer. This 
data is saved and restored by the restart facility but its actual use in the 
program is determined only by how the programmer uses the data.  

The restart macro creates a string variable called UDAT$ which has a maximum 
length equal to the size specified for optional user data. Each call to the 
CHECKPT macro causes the current contents of UDAT$ to be recorded in the 
student's record on disk. When a student returns to the program the last 
value saved for UDAT$ is restored to the variable UDAT$ prior to jumping to 
the instruction just after the CHECKPT.  

The program can place any data within the string UDAT$ prior to each call to 
CHECKPT. And, if necessary the data can be moved from UDAT$ to other 
variables just after each call to CHECKPT. 

THE RESTART FILE

The student record file is in ascii text format and contains one line per 
student. Each line contains a 10 byte field for student id number, a 30 byte 
field for name, a 10 byte field for the last check point label, from 1 to 500 
bytes of optional user data, a return character and a line feed character. To 
list the file on the display enter the command: 

     TYPE  RESTART

To print the student record file enter the command:

     COPY  RESTART  PRN: 


Appendix D. GRAPHIC IMAGE PROCESSING

The PILOT GX: command can be used to display a graphic image stored in a disk 
file. The GX: command accepts an image in BSAVE format, so called because it 
is the format that is produced by the BASIC language BSAVE command. There are 
some limitations to this format and the GX: command. First, only the original 
CGA modes, 0 through 6 are supported, not the higher resolution modes of the 
EGA. Second, the pictures are stored as uncompressed bit mapped images, so 
each picture occupies 16K on disk regardless of the complexity of the 
picture. Third, the GX: command always displays the entire picture, and does 
not use any special effects in the display.  

PILOT includes a set of utilities to address these limitations. These 
utilities permit the author to: 

     Import a picture created by a graphics programs for 
     display from within a PILOT lesson.  

     Store the picture on disk in a compressed format which
     reduces the storage requirements.

     Display a picture in any graphics mode, including the
     EGA high resolution modes.

     Display an entire picture, or any portion of the picture.
     When a portion of a picture is displayed, it may be
     positioned anywhere on the display.

     Display the picture using a variety of special effects,
     such as horizontal and vertical wipes or fades.

The user must distinguish between pictures which will be displayed in low 
resolution modes (4, 5 and 6) and those which will be displayed in EGA modes 
(13, 14 and 16). For the low resolution modes, pictures are 320 by 200 
pixels, 4 colors.  PILOT programs expect these pictures to be in PIQ format.  
A picture to be used in a low resolution mode can be created with the GIE 
program which is included with PILOT, via a PILOT program which saves the 
picture via the GSX: statement, or by capturing the image from another 
program with the BSAVER utility. These image files can be compressed and 
stored in PIQ format via the PIQCMPRS utility. PIQCMPRS can also be used to 
convert a .PCX file created via PC/Paintbrush to PIQ format.  Then the images 
may be displayed in a PILOT program via the PIQI, PIQS and PIQF macros.  

For EGA high resolution modes, pictures can be up to 640 by 350, 16 colors. 
PILOT programs expect these pictures to be in PCX format as produced by 
PC/Paintbrush (trademark of Zsoft Corporation). These pictures can be created 
with PC/Paintbrush (installed for EGA mode), or by using the FRIEZE utility 
program (part of Paintbrush) to capture a screen image from another program. 
Since this format is already in a compressed form, PILOT does not require any 
further processing of the picture, it can be called up from a PILOT program 
in exactly the form created by Paintbrush. These images can be displayed in a 
PILOT program via the EGAPIQI and EGAPIQ macros.  
     
The various utilities for managing graphic images of both 
types are described below.  

LOW RESOLUTION PICTURES

Low resolution pictures can be used on an IBM Color Graphics Adapter (CGA) or 
Extended Graphics Adapter (EGA). These pictures are displayed in PILOT screen 
modes 4, 5 or 6. To use a picture of this form in your PILOT program follow 
these steps: 

     Create the picture with GIE, or via a PILOT program GSX:
     command, or with PC/Paintbrush (installed for 320 by 200
     mode), or via the BSAVER capture utility.

     Run the PIQCMPRS utility to convert and compress the
     picture to PIQ format.

     Use the EZ editor to expand the PIQI, PIQF and/or PIQS
     macros into your PILOT program.

The BSAVER Utility

The file BSAVER.EXE contains the BSAVER utility. It can be used to capture a 
graphic image from any program which operates in 320 by 200 screen mode (CGA 
graphics mode). To use BSAVER you first load it into RAM via the command 

     BSAVER

This does not cause anything visible to happen. Rather, BSAVER loads into 
memory and remains there until called up later.  

Having loaded BSAVER, execute the graphics program with which you will create 
the picture. Run it normally until the picture you wish to capture is 
displayed.  

Then push the PRTSC key (while holding down SHIFT). BSAVER wakes up and 
displays a prompt on the top of the screen. The prompt shows the file name 
BSAVER will use to save the current screen display. You can continue by 
pressing Enter, or you can type another file name to use. BSAVER increments 
the file name so that it is convenient to use it to capture a series of 
pictures without entering a new file name for each.  

The files created by BSAVER are in BSAVE format. These files can be processed 
by GIE, by the PILOT GX: command, or by the PIQCMPRS utility.  

If the image captured by BSAVER is a text mode image, it can be used directly 
in a PILOT program by setting the appropriate screen mode, and referring to 
the file via the GX: command.  Though the same method would work for a 
graphics mode image, it is reccommended that the image be converted first to 
PIQ format.  This saves space and enhances the possible display options.  

The PIQCMPRS Utility

This utility is used to convert a BSAVE or PCX format picture to PIQ format. 
It is valid for CGA graphics modes only, 320 by 200, 4 color. To use it enter 
the command: 

     PI PIQCMPRS

Then follow the prompt to enter the name of the input file. If the input file 
name ends in ".PCX", it is assumed to be in PC/Paintbrush format. Otherwise 
it is assumed to be in BSAVE format. The graphic image is then saved in a 
file with a suffix of ".PIQ". 

The PIQI, PIQS, PIQF and GETFILE Macros

These macros can be included in your PILOT program to display pictures which 
have been prepared via the PIQCMPRS utility. The EZ editor is used to expand 
these macro calls in your program. To expand a macro, move the cursor to the 
desired position in the program file and push the F7 function key. Then enter 
the macro name (complete with the .PIM suffix). Then respond to each prompt 
as necessary. The use of each macro is detailed below. 

PIQI.PIM

The PIQI macro must be expanded toward the start of the program. It reads in 
the binary file PIQSHOW.BIN and prepares for display of PIQ images. PIQI need 
only be executed once per program. The file PIQSHOW.BIN must be present with 
the program when it is executed. The macro files need only be present when 
the program is written. 

PIQF.PIM

Once the PIQI macro has been executed once, any number of PIQF macros can be 
used. The PIQF macro causes the display of a picture, stored in a PIQ file. 
To use PIQF push the F7 function key in EZ, and enter the name PIQF.PIM. The 
following parameters must be entered in response to the PIQF prompts: 

     Filename

Here enter the name of the image file. Though the file name is of the form 
nnn.PIQ, do not enter the ".PIQ" suffix. Just enter the first part of the 
file name.  

     Wipe (C, D, E, F, H, I, L, R, U, V)

This selects the manner in which the image is painted onto the screen. One of 
the following letters must be entered : 

     C is from upper left corner. 
     D is down, from top to bottom. 
     E is explode from center out. 
     F is a fade in. 
     H is a horizontal spilt towards both edges. 
     I  is implode from edges inward. 
     L is from right to left. 
     R is from left to right. 
     U is up from bottom to top. 
     V is vertical spilt from center to top and bottom. 

     Option: Xor Mode or Border Color

This prompt permits input of additional wipe information. It may be used to 
specify the XOR option on any wipe except the fade. The xor option causes the 
image to be blended with the existing display rather than to overlay it. A 
second possibility for this prompt is to specify a number 0, 1, 2 or 3 for 
the down or right wipes. The number indicates that a border is to precede the 
down or rightward wipe. The number indicates the color of the border. If 
neither the xor or border option is desired, this reply may be left blank.  

     Change Window Parameters

This prompt requests a y (for yes) or n (for no) response. In fact, any 
response except y is taken as a no. The window parameters determine whether 
the entire picture, or just part of the picture is to be displayed. A no 
response indicates that the last window parameters executed on any PIQF or 
PIQS macro are to be used again. The default setting when the program begins 
causes the entire image to be displayed. A yes response causes four 
additional prompts for the window boundaries: leftmost column (0-39), 
rightmost column (0-39), top row (0-24) and bottom row (0-24). 

     Change Position Parameters

This prompt requests a y or n response. The position parameters can be used 
when a partial image is displayed to place the partial image at any screen 
location. A no response indicates that the last position parameters executed 
on any PIQF or PIQS macro are to be used again. A yes response causes two 
additional prompts for the new position: leftmost column (0-39) and top row 
(0-24). 

     Delay Time (0-254)

This parameter controls the speed at which the special effect is performed. 0 
indicates maximum speed, which with a D wipe is the fastest display possible. 
As the delay time is increased, the speed is decreased.  

PIQS.PIM 

PIQS, like PIQF, is used to display a PIQ image. PIQF is used to read the 
image from a file, then display it. PIQS is used to display an image which 
has previously been read into a string variable. PIQS is useful when one 
image is to be displayed repeatedly since it can avoid the overhead of re-
reading the image from disk. It can also be used when several images are to 
be displayed in rapid succession since all the images could be pre-read from 
disk prior to the display of the first image. To use PIQS the program must 
first have loaded the image file into a string variable via the GETFILE 
macro. The prompts for PIQS are similar to those for PIQF except that rather 
than entering the name of a file containing the image, the author must enter 
the name of a string variable containing the image. 

GETFILE.PIM

The GETFILE macro can be used to create a string variable and read the 
contents of a disk file into the string variable. It can be used to read in a 
PIQ image, a sprite table, a binary subroutine, or other data. Its use in 
conjunction with PIQ images is to pre-load a picture prior to using the PIQS 
macro. 

The PIQ Binary Files

There are several binary files associated with PIQ image processing. Each is 
of the form "PIQnnn.BIN". The only file which needs to be distributed with 
the final PILOT program is PIQSHOW.BIN. The other binary files, as well as 
the PIQ macro files need be present only when writing the program. 


HIGH RESOLUTION PICTURES

High resolution pictures can be used only on an IBM Extended Graphics Adapter 
(EGA), not on a Color Graphics Adapter (CGA). This facility can be used to 
display pictures in PILOT screen modes 13, 14 and 16. To display a picture it 
must be created via PC/Paintbrush using the corresponding screen mode. To use 
a picture of this form in your PILOT program follow these steps: 

     Use PC/Paintbrush (installed for an EGA color mode) to
     draw a picture. Save it in the normal manner. Or, use the
     FRIEZE utility to capture an image from another program
     in an EGA mode.

     Use the EZ editor to expand the EGAPIQI and EGAPIQ
     macros into your PILOT program.

The EGAPIQI and EGAPIQ Macros

These macros can be included in your PILOT program to display pictures which 
are in PCX format for EGA screen modes. The EZ editor is used to expand these 
macro calls in your program. To expand a macro, move the cursor to the 
desired position in the program file and push the F7 function key.  Then 
enter the macro name (complete with the .PIM suffix).  Then respond to each 
prompt as necessary.  

EGAPIQI.PIM

The EGAPIQI macro must be expanded toward the start of the program. It reads 
in the binary file EGAPIQ.BIN and prepares for display of EGAPIQ images. 
EGAPIQI need only be executed once per program. The file EGAPIQ.BIN must be 
present with the program when it is executed. The macro files need only be 
present when the program is written.  

EGAPIQ.PIM

The EGAPIQ macro may be used at any point in a program to display an EGA mode 
picture. EGAPIQI must have been executed prior to EGAPIQ. To use EGAPIQ push 
the F7 function key in EZ, and enter the name EGAPIQ.PIM. The following 
parameters must be entered in response to the EGAPIQ prompts: 

     Filename

Here enter the name of the image file. Though the file name is of the form 
nnn.PCX, do not enter the ".PCX" suffix. Just enter the first part of the 
file name.  

     Wipe (D, F, L, R, U)

This selects the manner in which the image is painted onto the screen. One of 
the following letters must be entered : 

     D is down, from top to bottom. 
     F is a fade in. 
     L is from right to left. 
     R is from left to right. 
     U is up from bottom to top. 

     Change Window Parameters

This prompt requires a y (for yes) or n (for no) response. In fact, any 
response except y is taken as a no. The window parameters determine whether 
the entire picture, or just part of the picture is to be displayed. A no 
response indicates that the last window parameters executed on any EGAPIQ 
macro are to be used again. The default setting when the program begins 
causes the entire image to be displayed. A yes response causes four 
additional prompts for the window boundaries: leftmost column (0-79), 
rightmost column (0-79), top row (0-24) and bottom row (0-24). 

     Change Position Parameters

This prompt requires a y or n response. The position parameters can be used 
when a partial image is displayed to place the partial image at any screen 
location. A no response indicates that the last position parameters executed 
on any EGAPIQ macro are to be used again. A yes response causes two 
additional prompts for the new position: leftmost column (0-79) and top row 
(0-24). 

     Delay Time (0-254)

This parameter controls the speed at which the special effect is performed. 0 
indicates maximum speed, which with a D wipe is the fastest display possible. 
As the delay time is increased, the speed is decreased.  


Appendix E. LARGE COMPUTER SIMULATION

With PILOT, a simulation program can be created to provide effective operator 
practice and training on the operation of a large scale computer system 
operator's console. Such a simulation can be used as in inexpensive 
substitute for the actual mainframe system for training purposes.  

Program example SAMPLE12.PIL is an example, derived from an actual full scale 
simulator, which shows how this type of program might be developed with 
PILOT. The goal of a simulator is to provide the user with a simulated copy 
of the target computer system that allows for practical hands-on training in 
a controlled environment. Though this example simulates a mainframe computer 
console, similar technics could be used to simulate other systems. Advantages 
of simulation include the ability to train operators and users before a 
machine is installed, or to train new personel without tying up the actual 
system.  

After a simulator is built, much of the same code might be used in a 
companion tutorial program which, together with the simulator would make up a 
complete training package.  

One approach for simulation of hardware systems is to build a complete 
simulator first, then build various tutorial modules to allow for task skills 
to be practiced be entering the simulator at different points.   The entry 
modules would thus set up the environment of the simulator for each new task 
to be learned.  After that task is practiced the student could return to the 
tutorial for more instruction.  

Building the Simulator 

Most mainframe systems accept command sequences that an operator uses to 
configure, start, stop, initialize control programs, and control the hardware 
of the machine from a console.  Each screen of control information is called 
a 'frame'. When any particular frame is displayed, there are certain keyboard 
actions that operator might perform. Some actions move to another frame, 
others might invoke commands unique to this frame, and yet others migh invoke 
actions that are available from many different contexts.  

A convenient organization of the simulator program is to write  a separate 
PILOT program module for each frame to be displayed and it's associated 
control code.  Each file would also contain the necessary code to accept 
keyboard input and perform the appropriate actions such as link to other 
frames.  

An alternate approach is to build each frame as a separate file without the 
control code.  Thus, you would have a set of files that contain only the text 
to be displayed and the control code in another file.  

The second approach may be more efficient in the use of space because of the 
reduction of duplicate routines.  Yet, if space is not a concern, you will 
find it much easier to use the first approach where debugging and controlling 
your program become less of a task.  

In either approach, a careful study and understanding of the machine to be 
simulated is required.  For each frame, you should also be able to simulate 
incorrect actions as well as correct actions.  Make note of the real 
machine's messages and displayed actions for every possible operator command.  
An action taken on one frame may effect the information displayed on another 
frame.  The frame text that can be changed or effected by student commands 
will have to be represent by variables called frame variables.  

Frame variables will have to be set to an initial value in your entry module.  
This gives you the ability to set the initial status or condition of the 
machine to be simulated.  It also allows you to break apart specific tasks 
you would like to have the student accomplish.  

Development Tasks  

The following sequence of tasks may be helpful in building your machine 
simulator: 

Study the operation of the target machine.  Make note of incorrect actions as 
well as correct actions.  

Determine the machine frames to be simulated.  Create a separate text file 
(nnnn.PIL) for each frame to be displayed.  In the text file type an exact 
copy of the frame display screen.  In naming your frame files, choose names 
which aid in the identification of the associated frames.  After you have 
created the text file, insert PILOT's (T:) command to type the text to the 
screen.  Most machine frames will have an area designated as the command line 
where the blinking cursor is located awaiting response.  This can be 
accomplished using the (TS:gx,y) command.  Use the ACCEPT (A:) command to 
wait for a response to be evaluated.  

Determine the machine commands that cause one frame to link to other frames.  
In some cases, an INDEX key on the console may have to be simulated by use of 
the ALT key.  Some frames may not link to other frames directly, yet have to 
go to a menu or index frame first.  Using PILOT's SYSX routine may be of 
benefit here.  In either case, MATCH statements or use of the function keys 
should direct the program to a LINK command (L:) that links the frame to 
another.  Once this is accomplished for one frame, much of the same code can 
placed in the other frame files.  

Determine the frame variables for each frame.  Frame text that is changed or 
effected by commands should be identified.  Once identified, you must create 
a variable name that represents that text item.  Use caution in selecting 
variable names.  Try to chose a name that can be easily associated with the 
text or function simulated.  Remember you must first dimension a string 
variable before using it.  The variable length is set when you Dimension (D:) 
the variable.  Next replace the text items with the appropriate variable 
names using ($var$) within the frame text.  Once the initial value of the 
variables is set in your entry module, you can change them using the COMPUTE 
(C:) command.  

Determine other machine commands that require simulation.  First, ensure you 
have a list of the commands to be simulated or acted upon from the command 
line.  Then create MATCH (M:) statements for each of the possible commands.  
Next determine what all should happen if a MATCH would occur.  Frame 
variables can be changed by using the Compute on condition Yes statement 
(CY:). Other variables may change depending on contents of other variables.  
For example, you may need a way to change a variable only if it's content had 
a particular string value. CY(var1$="content"):var$="new content" 

Determine error messages, not simulated commands and simulator messages to be 
used.  Although the goal is to provide a real as possible environment, it may 
not be practical to simulate every possible command or response.  In those 
cases, the author may want to provide error handling routines that provide a 
" Message from the Simulator" to be displayed on a predetermined area of the 
screen.  For example, a message might be "Message from Simulator -- Command 
not known or not simulated "  or "Simulated at greater than normal speed." 

Test the simulator next to the real machine.  This will allow you to see many 
things that you may not have noticed before.  Next, ensure your entry modules 
are task oriented.  You can provide a workbook that directs the student to 
try certain tasks and asks them what has changed or taken place.  

Sample Machine Simulator Program  

The SAMPLE12.PIL, and SAMPLE13.PIL files contains an example of a machine 
simulator that presents an Operator control frame similar to those on many 
IBM systems. Try it to see a section of a simulator in action.  


Appendix F. CALLING EXTERNAL PROGRAMS

Using the EXEC facility, a PILOT program can execute another program or DOS 
command. EXEC permits the program to execute any command line, as if it were 
entered to the DOS command line prompt. The command could perform DOS 
functions such as DIR or COPY. It could as easily execute a program written 
in BASIC or PASCAL, or execute another program product such as a word 
processor or spread sheet. The called program need not be written in any 
special manner, it is executed in an environment which is the same as if it 
were executed via a DOS command line. When the called program terminates, 
control is returned to the PILOT program which resumes execution at the next 
statement. 

To use the EXEC facility the file EXEC.BIN must be present. The GETFILE.PIM 
macro must be used to load and initialize the EXEC.BIN file. Once this is 
done any number of calls to EXEC may be performed via the V: statement. 

To use EXEC in a program follow these steps:

     Use the EZ editor to expand the GETFILE.PIM macro 
     in the initial portion of the PILOT program.
     GETFILE.PIM prompts for a file name, enter the name
     EXEC.BIN. It also prompts for a string name, use
     the name EXEC$.  

     At any point within the PILOT program use the following
     statements to call an external program:

          C:EXEC$(9,80) = "any DOS command line here"
          V:EXEC$

The string passed to EXEC$ may be any command line, exactly as it would be 
typed to the DOS command prompt "A>". For example, the following lines 
perform a directory command. 

     C:EXEC$(9,80) = "DIR"
     V:EXEC$

The following lines call a BASIC program named "HELLO". 

     C:EXEC$(9,80) = "BASIC HELLO"
     V:EXEC$

If the command does not execute as expected, then upon return from the V: 
statement, the following line would display an error code per the DOS Error 
Return Table found in a DOS manual appendix. 

     T:Return code is #(ASC(EXEC$(3)))

As an additional return, EXEC$ returns the drive letter in which the file 
COMMAND.COM was found in string position EXEC$(4). This information might be 
useful in determining whether a program is executing from floppy or fixed 
disk. 


Appendix G. SUPPLEMENTAL MATERIALS

This section describes various other printed and program materials that may 
be useful in PILOT program authoring.  

ADCIS

The "Association for the Development of Computer-Based Instructional Systems" 
has a PILOT Language Special Interest Group. This association holds annual 
meetings and publishes newsletters and the "Journal of Computer-Based 
Instruction". ADCIS national offices can be reached at (206) 676-2860. 

WCS

Washington Computer Services, the developer of PILOT, publishes several 
products and services for PILOT users: 

UPDATE SERVICE - New releases of PILOT are supplied. 

ADVANCED FEATURE LIBRARY - A package of utilities, special device drivers and 
useful subroutines to increase productivity for the PILOT programmer.  

LEARNPI and DESIGNER - A 3-diskette tutorial set, LEARNPI, written in PILOT 
on PILOT written by George Gerhold and Robert Urso. It covers basic 
programming and screen design topics.  

VIDEO SCRIPT EXECUTIVE - VSX is an authoring environment for presentations 
and lessons which may include video, text, graphics, mouse, touch screen and 
video. VSX can reduce program development time by isolating the author from 
programming details. The user can extend the power of VSX by coding in PILOT 
as necessary.  

For complete information contact Washington Computer Services directly. 
Phone: (206) 734-8248.  

SRA

SRA publishes beginner's level self-study course (book and diskette) entitled 
"Developing Computer-Based Training with PC/PILOT" by Kirk Richardson and 
Valerie Mock. 

ASYS

ASYS publishes PROPI a complete authoring system which can be used with the 
PILOT language to provide a comprehensive large-scale authoring environment. 
ASYS phone:  (206) 734-2553.  

