The MXTST demonstration The MSX operating system has a demonstration program in the file MXTST containing several tasks that run under MSX and serve to show a few of the things MSX can do. The system normally assembles for a 3 CPU configuration, and once running, will try to balance the processing load between all 3 emulated CPUs. To get started, you will find yourself in DDT, a symbolic debugger that has many MSX system variables predefined. Each emulated CPU must at a minimum have its CPU number entered. To do so, type a command like MX.CPU[1 2 to change the CPU number from its default value of CPU 1 to CPU 2. Each CPU number must be unique in the range 1 to 3 (larger ranges for a system with MXSTLS set up for more CPUs). Once this is done, you may then type $G (escape,G) to start the task. Once 3 tasks are running (at 3 terminals) you can begin real actions. (If less terminals are available, you can set CPU.PR, CPU.PR+2, and/or CPU.PR+4 to large numbers (positive) to tell MSX not to start tasks there. Be prepared for waits however as MSX times out its interprocessor communication when you do this. MSX uses an emulated bus that is fairly slow (about 1 second per message) to avoid loading the rest of the system too much. Once the system comes up, your console tasks will be active, one per CPU, and other tasks named A through E are able to be started. The console tasks prompt with "MSX CONSOLE>" and await commands. Each console task, and tasks A through E, have classification blocks you can alter. These are available through DDT, and will limit what communication or other activity may be done. The console device also has a classification. The format of a classification block is as follows: classification privilege word default classification (maximum permitted classification level) byte with current classification up to 10 bytes of special category numbers. The privilege word bits have the following meanings: 100000 Ignore all MLS issues 10000 Allow I/O to be asynchronous 4000 Violate special categories if MLS is violated on a device 2000 Violate special categories if MLS is OK on levels on a device 1000 Violate special categories if MLS levels bad on a message transfer 400 Violate special categories if MLS levels OK on a message transfer 200 Allow write to lower levels on device 100 Allow read from higher level device 40 Allow write to lower levels with message 20 Allow read from higher levels with message 10 Allow write to higher levels in device 4 Allow read from lower levels in device 2 Allow write to higher levels in a message 1 Allow read from lower levels in a message If the "asynchronous I/O" bit is clear, all I/O will take place synchronously and the task will not receive control until it has completed. The commands permitted at console level are the following AC A List all active tasks and their status in octal DD A Issue a BPT to get to DDT. The $P command resumes the program. SP a Spawns task a (a is A,B,C,D, or E) RQ a Requests task a (A-E). Differs from Spawn in that hierarchy is not kept. Note that spawns where the same classification cannot be given are treated as requests. AB a Aborts task named as a (A-E). If the task was spawned successfully, the task that initiated it will receive an error notification. SE a "message" Sends the text "message" (whatever you like) to task a (which may be A through E) and awaits its delivery or notice from the system that it cannot be delivered. Several special cases occur: Messages of form "c=message" are received as usual and echoed, but are RETRANSMITTED to the task whose letter is given as c after the first part is changed from 'c=' to 'a>' and then sent on. If the transmit fails, the task a will print an error message. When a message of form "c