Scor­pio News

During installation of Z3 on an a friend’s Alphatronic PC, some very peculiar errors arose. An oversight had resulted in the SYS.NDR segment not having been loaded or initialized, and the locations in question were filled with random rubbish. The data found there by the Z3 CCP was being interpreted as the NDR segment, and select errors were prominent amongst the reported errors.

The installation notes suggest clearing (part of) each discreet segment or buffer area in turn. This works well, but it requires rather more code, since the code required is virtually repeated for each area to be preset. It is much simpler and does not take much longer to clear all of the Z3 memory area. Initialization of startup commands, paths etc, can then follow. This reduces the total amount of code needed for cold boot patches, and could simplify installation where BIOS source is not available.

The standard method of system initialisation in the Cold Boot routines is to clear buffers and segment areas, initialize the path, wheel byte, and startup commands, print signon messages and then boot the system. The startup command uses the supplied utility LDR.COM to load the required segments. On a floppy based system, there does not usually appear to be much alternative to this method of booting due to space limitations on the system tracks of the disk, but if one has spare space on the floppy system track, or a Winchester, there is a better way.

A track on a Winchester disk may be 8k – 8.5k bytes long. If two tracks are reserved for the system, then about 16 – 17k of space is available. After subtracting BDOS, CCP and Cold Boot Loader, over 10k is available for the BIOS end Z3 segments and buffers, and BIOS workspaces. This means that the Z3 extensions can be considered to be part of the system, and loaded with the system at cold boot. Since the buffers can be optionally loaded from the system tracks as well, already initialized to zeroes, or with set messages, commands, etc, the amount of cold boot initialisation becomes minimal, with only the default path and wheel byte needing setting up, although these could be defined somewhere in the Z3 memory area and loaded with the system too. This has the further advantage that no BIOS modifications are needed, except in the Screen Edit routine. It then also becomes unnecessary to use LDR.COM, except to change the default segments for special purposes.

If this approach is used, but only some of the areas are loaded from disk (e.g. where on say a floppy system there is some spare room on the system track, but not enough for ALL of Z3), then initialisation of non-loaded Z3 segment and buffer areas must be selective, to avoid erasing data that have just arrived in RAM from the system tracks. It then becomes a good idea to group the program segments together just above the BIOS workspace, and to group buffers above this.

Whatever the system adopted, disk space for the system is not a problem. The amount of RAM allocated to the system is a problem however, since all extensions of the BIOS or Z3 eat into the TPA. My extensively customised BIOS, together with workspaces, takes up just under 5k, end the Z3 system uses 3.5k resulting in a total system size of 14k, including CCP, and I am determined not to allow it to get any bigger. Since I am also always trying to add features to the BIOS, I am also looking for ways to economise on space. One thing that I have recently done is to utilize some 80 spare bytes in the TCAP part of the ENV segment, to hold the system message Clock string that are displayed on the (normally locked) top line of the screen. This has released 80 bytes in the BIOS area for more code, but of course, means that that particular configuration of the BIOS will only work correctly in a Z3 environment.

The BIOS plus Workspace size is one of the important considerations, since this is considerably larger then BIOS plus Cold boot routines. I have no problem in expanding cold boot activities, and in providing extensive signon messages. The amount of workspace area needed is determined by the hardware used, and so is relatively constant for a given system. This means that the BIOS permanent code is the part that needs to be kept in check. I have recently helped two friends instal Z3 on systems based on Nascoms, and the big problem was in the amount of space required by the BIOS code for the keyboard routines. With a Winchester