Previous: Operating System
Up: Creating a Release Disc under the p-System
Previous Page: Operating System
Next Page: Creating a Release Disc under DOS
These are all components created and maintained by the Center as part of, or as support for, the dialogues.
A p-System library is simply a code file, consisting of p-code segments, typically without a program segment. The only practical limit to the number of segments it can hold is available disc space. *SYSTEM.LIBRARY is the one which the p-System automatically searches for units needed by the program it's starting, and not yet found in either the program's own code file, or in SYSTEM.PASCAL.
Units which more than one program on the release disc need are placed in *SYSTEM.LIBRARY. This permits any number of programs to use the same units while keeping only a single copy of each unit on disc, rather than obliging each program's code file to hold its own copies.
The code files of units that the compiler produces contain the text of their INTERFACE sections. This is needed for compiling other compilation units that use the unit, but not for execution. Since the text is bulky, it is omitted from the release form of SYSTEM.LIBRARY. The standard tool LIBRARY.CODE has a setting to leave interfaces behind when copying units; see the manual from Pecan for details.
Standard units: These are the units on which all the Center's dialogues are built. Every release library must contain them, except where noted in the unit's description.
NOTE: Avoid using LIBRARY's command F(ill for copying Ports into a new library. One of the units Ports uses is SYSTEM.PASCAL's unit CommandIO (see below). A copy of this, with its interface, is usually kept in the development version of SYSTEM.LIBRARY, so that Ports can be compiled. However, for execution the version in SYSTEM.PASCAL must be used. But F(ill would copy the library's version regardless. It is therefore wise to rely on the C(ompilation command.
In addition to these, a dialogue will often have a unit or two of its own, supplying routines particular to the dialogue's needs.
Some older dialogues may still use the obsolete units VideoControl or IBMSpecial. As VideoControl would be very difficult to maintain (and IBMSpecial impossible), this use should be eliminated; or, if direct access to low-level screen support is truly needed, replaced with use of PCVideo.
The SYSTEM.STARTUP typically used on dialogues release discs presents an animated scene specific to the dialogue, for attracting the attention of the student (therefore called the ``attract mode''); and, unless there is a separate SYSTEM.MENU, presents the menu of the dialogues activities, and chains to the one selected. Eventually, one of the activities will chain back to this file (or to SYSTEM.MENU, if present). This means that when the student has finished with as much of the dialogue as he/she wants to use, the attract mode is presented again, not just the menu.
A standard unit, MenuDisplay, is provided for the construction and execution of the menu phase; but the attract mode must be written individually for each dialogue. Specific keyed file messages, with specific format, are required by MenuDisplay; consult its documentation, sources, or existing attract-mode keyed files for direction.
If the attract mode is desired only when the dialogue first starts, and not when the student has finished with it, presentation of the dialogue's menu should be removed from SYSTEM.STARTUP and placed instead in SYSTEM.MENU. Ports has been updated to try first to chain to SYSTEM.MENU, and to SYSTEM.STARTUP only if that fails. As with SYSTEM.STARTUP, when compiling the code that will be come SYSTEM.MENU, it must be compiled to a file ending in .CODE, or it will not be marked as a code file in the file system.
Documentation giving the exact composition of the character set is available in the ETC archives.
Whether a given dialogue uses any of these special characters should be stated by the documentation on its maintenance disc, or in its sources. But there may still be cases were it can only be determined by examining the dialogue's keyed files. Actually running the dialogue to find their use is unreliable, since dialogues usually have many paths, and only one need be omitted to miss a use of special characters.
Though most dialogue code files use only one keyed file each, there are those that use more, so care must be taken that all the keyed files an activity uses are placed on the disc.