Scor­pio News

The above example may appear trivial, but the concept can be extremely useful in Error Handling, or controlling the flow of a command chain. The feature is not essential to the successful operation of the Z system however, and may be omitted to save the .5k it occupies, if memory conservation is important.

The Input/​Output Segment.

This segment is optional, and its size is dependent on what facilities the user has included. In the memory map Fig 1, it is shown as being 1.5k bytes long. Since this segment is hardware specific, it becomes the responsibility of the user to write this software. An example source file for an IOP is provided, to show how it may be done. Since I have only one Screen and Printer, and have no great need of the facilities available in the IOP, I have not implemented this segment at present, so no memory is lost to it on my system.

The purpose of the IOP is to provide more flexible control of system I/O and to allow redirection and so on. It becomes easy to switch to different terminals and printers. If it is implemented, it can to a large extent replace BIOS I/O, and this could result in a smaller BIOS, offsetting the extra memory needed by the IOP.

The Wheel Byte.

The purpose of this Byte has been described shove. It is just a one byte location, allocated somewhere in memory. In Z2, address 003BH was used. In Z3, the author has switched to 004BH in the documentation, but has not explained the reason for the move. Since this would restrict the External Path length, I have left the Byte at 003BH. The byte may be examined, set or reset as described above, and a utility to manipulate it is also provided.

The External Path

The path may be made internal to the CCP, but would then disappear when programs are loaded. The author chose to use locations from 0040H in both Z2 and Z3, and this seems reasonable. The path may be as long as one likes, but is in reality restricted by the memory space available for it from 0040H, and the fact that the longer it is, the longer a search takes, especially when one has type a ‘dud’ file name. Z3 can be assembled to minimize the path so that locations that appear more than once are only searched once. The current drive and user are ALWAYS searched first anyway, so do not appear in the path. On my system I currently search up to seven locations after the current DU. They are:

$0 – A0, – A15, – A$, – B0, – B$, – C0 where $=Current Drive or User

bearing in mind that A:, B: are the two parts of a Winchester, C:, D: are Floppies. The free memory of the TCAP could be used for the Path and Wheel byte

ZCPR3 utilities

There are too many Z3 utilities to describe more then a few in any detail. All of them are designed to work with Z3, although some will run on standard CP/M. Many of them read the ENV segment and make use of the screen facilities defined there, resulting in an improved display, and allow the cursor keys to be used. Many also make use of the various buffers and stacks described above.

In other words Z3 and its command utilities are an integrated system. Together they form remarkable system, Z3 without its utilities is still good. Many of the Z3 utilities will not work on a non-Z3 system. They fall into several natural groups, depending on the function.

Copying –

MCOPY is appropriate when multiple copies or complex strings of commands are required. It copies files from any DIR/DU to any other (including users between 16 and 31), verifying the copy and reporting errors. It will perform multiple