80-Bus News


January–February 1983 · Volume 2 · Issue 1

Page 27 of 56

The manuals and guides to CP/M should be consulted for more details.

CP/M uses RAM below 100H as a Workspace and Buffer area. Above the workspace, starting at 100H is the Transient Program Area (TPA). This is where all programs other than CP/M reside and operate. The TPA extends up through memory, including the CCP area of CP/M. In the systems drawn, the TPA will run from 100H to E000H/​E400H, which is around 56K or 57K bytes.

The Consol Command Processor (CCP) is the area of CP/M that interacts with the user. It supports commands like DIR, REN, TYPE, ERA, etc. and allows selection of other drives, loading of files etc; When programs are loaded and run, the CCP is not needed, so the 2K of space that it occupies can be used by programs.

Above the CCP is the Basic Disk Operating System (BDOS). The user accesses the BDOS through the jump at 0005H, to use the 36 or so Functions that are available such as Keyboard input, Screen output. Disk read, and so on. The BDOS is 3.5K long and cannot be overwritten.

The final unit, at the very top of memory is the Basic Input Output System (BIOS). Often called CBIOS, the C standing for Customized. i.e. altered to suit.). This part of CP/M is not supplied by Digital Research, but by the suppliers of the Computer. The job of the BIOS is to marry together the standard CCP/​BDOS to the thousand and one different Hardwares that have to run CP/M. The BIOS will therefore vary from computer to computer. The quality of the BIOS varies tremendously from system to system, and CP/M can get a bad name because the BIOS is poor. The various BIOS’s available to run on the Nascom/​GEMINT implementation contain features that are not always common. In some cases they are almost unique. Richard Beal, the author of NAS­SYS seems to have made a speciality of writing a very powerful CBIOS for Nascom/​Gemini systems that he calls ‘SYS’, and this article describes how to replace the origional CBIOS with ‘SYS’ CBIOS.


David Parkinson adds..

1) If you are overwriting the standard BIOS by one of your own you may find that insufficient space is available for it. The obvious solution to this problem is to generate a slightly smaller CP/M system to give yourself more room (eg MOVCPM 63 * in a 64k system). However this results in the loss of 1k of memory from the TPA, which seems quite excessive if you only want an extra 100 bytes. By changing one byte in the MOVCPM.COM file you can move the memory image of CP/M down (or up!) in increments of 256 bytes. The byte is at 23Dh and holds the number of 256-byte pages that MOVCPM.COM adds on to the system it generates to allow for workspace area for the BIOS. Increasing the current value of this byte by one will give you an additional 256 bytes of memory, and pro rata.

Remember that the extra memory does not appear out of fresh air, CP/M just moves down a bit to allow a little more room for the BIOS.

2) As Mr. Bowden points out, there is little point in saving a large workspace/​buffer area on the system track of the disk, and so all workspace should be placed at the end of the BIOS so that all the code, (which HAS to be saved on the disk), comes first. However an additional saving can be made in the BIOS memory requirements by realising that certain sections of the code are used once only on start-up. A prime example of this is the sign-on message, which only appears when the system starts up from cold, and then is never seen again. All the Gemini BIOS’s have the sign-on message stored in the area of memory that the BIOS uses for workspace, as it will be printed before the BIOS actually uses any of that area as workspace.

Page 27 of 56