Previous: Operating System
Up: Creating a Release Disc under the p-System
Previous Page: Operating System
Next Page: Creating a Release Disc under DOS

Dialogue Files

These are all components created and maintained by the Center as part of, or as support for, the dialogues.

SYSTEM.LIBRARY

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.

Ports, and all its segment routines:

Ports' segments, when copied individually (rather than by the S(elect command) should always be copied between code or library files by the C(ompilation unit command in LIBRARY, which guarantees that its ``family'' of segment routines will be copied with it.

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.

pDisplay:

Used by virtually every dialogue.

StringAnalysis:

Used by virtually every dialogue.

MenuDisplay:

often this is only used by the title program of a dialogue, but placing it in SYSTEM.LIBRARY assures that activities which may need to do so can also build menus consistent in operation with the main menu; and placing it in the library costs nothing extra.

PCVideo:

exports all the primitive screen control operations, including writing and drawing, that Ports needs. It depends on a particular host machine, to ease transport of Ports to new machines.

SpecialKeys:

supplies assembly-level 8086 keyboard drivers to handle special break keys without letting the dialogue break. NOTE: There is one version of this for development, which supplies print-screen facilities for the IBM PC graphics screen; the other version suppresses the break keys, and it is the one that must go on the release disc.

FastImage:

supplies bitmap-handling facilities, principally the routine DrawBlock. It need only be included for dialogues that have bitmap drawing; otherwise, it can omitted.

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.

SYSTEM.STARTUP

If the code file SYSTEM.STARTUP is on the root volume when the p-System boots or resets, it is executed. Release discs therefore name as SYSTEM.STARTUP the program which starts the whole dialogue from the host machine's reset. (Note that it must first be compiled to a name ending in .CODE, then changed to SYSTEM.STARTUP,or the filing system will not mark it as a code file.)

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.

SYSTEM.MENU

Following booting, the p-System normally presents a command promptline, consisting of a menu of choices for using the system. If the file SYSTEM.MENU is present on the root disc, it is executed in place of the promptline.

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.

ETC.CHARSET

This contains the bitmaps (8 pixels by 8 in present releases) of the characters printed for text display by the dialogues, through PCVideo. For dialogues displaying only the byte values 32 through 127, this file isn't needed, though its presence doesn't hurt: the character representations present in the R.O.M.'s of most PC's will do. However, the technical and mathematical nature of some of the dialogues requires special characters for which ETC.CHARSET has been designed. Since these characters not only don't have a standardised order, but often don't even occur in host-machine character sets, ETC.CHARSET must be included on release discs for dialogues using these characters (even if only one activity requires them).

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.

keyed file for the menu

The menu's keyed file supplies the messages and data for both the attract mode and the menu, even when they are separate programs. Though a standard format is followed, mostly dictated by MenuDisplay, each dialogue needs its own menu keyed file written for it.

executing code file for each activity

Every code file that the dialogue may execute must be placed on the disc. If any uses a unit that no other program uses, the unit may be placed either in SYSTEM.LIBRARY or in that code file itself (using LIBRARY.CODE), as other considerations dictate.

all keyed files for each activity

All the keyed files that each activity of the dialogue uses must be placed on the disc. For ease of organisation, it is suggested that each keyed file (or group of keyed files) be placed next to its code file on disc -- at least, in directory structures that permit this.

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.

any auxilliary files the activities require

Particular care must be given to making sure all additional files every activity requires are put on the disc. This may be difficult, because they are usually irregular, following no pattern; and because their absence may not be detected until a particular path of a particular activity is run. The documentation headers of the dialogue's sources must be carefully checked for mention of needed runtime files.