Scor­pio News

based system, space was not available in RAM for all of the features that I normally assemble into my BIOS, unless the code was allowed to expand beyond 5k.

Each installer must come to his own decision on what is considered to be the optimum trade off between TPA, BIOS size and Z3 support. Some of the considerations above show how adaptable the installation may have to be.

It is necessary, during installation, to find out the current address at which the CCP, BDOS and BIOS are residing. Before CP/M is relocated lower in memory to make room for Z3, the current operating address is needed, so that, after subtracting the extra RAM to be allocated to Z3, the new addresses are known. BIOS workspaces must also be allowed for, and it would not be safe to just look for the end of the cold boot in the system image (which is normally sign-on messages), subtract 2100H (start of BIOS in standard Gemini system Image), and take the result as indicating the BIOS length. A better guide is to find the BIOS starting address on a running CP/M system and to subtract this from the top of RAM, (or ROM address if ROM based software is used in the system, as in the Alphatronic PC).

Having decided on the addresses of each segment and buffer to be incorporated, the files Z3HDR.LIB and Z3BASE.LIB must be edited. This will allow the correct assembly of the Z3 CCP and will provide the information needed by other assembly operations that also read these .LIB files. Z3BASE defines the system addresses that have been chosen, and Z3HDR defines the commands and parameters available or trance to the Z3 CCP. The .LIB files for SYSFCP, SYSRCP, SYSENV, SYSIOP and SYSNDR may then be edited, but if any one or more of these segments is not to be used, edit of those .LIB’s may be skipped.

These files may then be assembled (e.g. MAC ZCPR3 $SZ PZ) to produce the relevant .HEX files. The $SZ and $PZ parameters suppress output of the Symbol and .PRN listing files otherwise produced during assembly. If MLOAD is available, the .HEX files may be loaded, and the resulting .COM files should be given the name SYS.RCP, SYS.ENV, SYS.NDR, SYS.FCP and SYS.IOP as appropriate, since the names used MUST be acceptable to LDR.COM. If MLOAD is not available, DDT or ZSID will have to be used to read the .HEX. This is explained in more detail later.

Once SYS.NDR and SYS.ENV have been constructed, any future mods. to these could well be made with SPZ.COM or a debug program, since these files are very short. Reference to the installation manual for the .ENV and TCAP will give the required information. There is little in the SYS.ENV that would need to be altered, once set up, unless a system ‘shuffle’ is made. Several different named directory segments could quickly be made by copying, renaming and editing with SPZ or DU.

The BIOS cold boot alterations are made to appear unnecessarily complex in the installation manual. If the source code of the BIOS is available, revised signon messages and all sorts of frills are possible, but all that is really needed, just before the jump to warm boot, from cold boot, ie:

a) Code to clear Buffers and segments.
b) Code to set the Wheel Byte.
c) Code to set up the Default Path.
d) Code to set up the Startup Command string.

If the BIOS code is available, or an installer is prepared to do some work with a debug program or disassembler, then the necessary code can be ‘patched’ into the BIOS.

Appendix A lists an example of the code needed in source code form. The code listed assumes that the source code of the BIOS may not be available, and so the listing indicates additions] modifications, in mnemonic form, that are required to be patched into the actual BIOS code to redirect the cold boot jump to access the new code before it jumps to the warm boot. It also assumes that there is enough room on the disk system tracks for the extra code. If this is a problem,