Oakland CPM Archive

home *** CD-ROM | disk | FTP | other *** search

/ Oakland CPM Archive / oakcpm.iso / sigm / vol236 / cpmplus.tqx / CPMPLUS.TEX

Wrap

Text File | 1986-02-11 | 43.5 KB | 746 lines

CPM-PLUS ======== Robert B Davies, 16 Gloucester Street, Wellington, New Zealand. CP/M PLUS (alias CP/M 3) is Digital Research's latest update of their operating system for systems based on 8080 or Z80 microprocessors. I purchased a copy during a recent trip to the USA and now have it running. Here are my thoughts on it after trying it for a few months. OPERATING SYSTEMS --------- ------- First, I need to make a few comments on what an operating system is required to do. It is a program that provides the interface between a user's program and the computer's peripherals such as the disks, keyboard, display etc. In particular, it builds and organizes the disk directories, reads and writes files on disk, loads programs as requested by the user, regains control after the user's program has finished, as well as loading itself from disk when the machine is turned on. A diagram of the set-up for CP/M is given in figure 1. The heart of the system is the machine independent part called the BDOS. The machine dependent part, the BIOS must be written by the computer manufacturer or owner and supplies a more-or-less machine independent interface for the BDOS. It is this splitting of CP/M into the BDOS and BIOS that enables it to be readily adaptable to the large variety of machines on which it runs. The BDOS provides the interface with what ever program (the transient program) is currently in core and translates its complex file and input/output commands into sequences of simple commands for the BIOS. The CCP (console command processor) is a program that is automatically loaded when the machine is turned on or when user programs exit and is responsible for monitoring the keyboard, loading new programs when requested or, in the case of CP/M 2, processing the commands DIR, ERA, USER, REM, SAVE, TYPE. The cold boot loader is automatically loaded when the machine is turned on and is responsible for loading the BIOS and BDOS and then the CCP. The compilers, interpreters and applications programs are supplied by other organizations or at least separately from CP/M. However one does get a whole range of 'utilities' with CP/M including an editor, assembler, a program for copying files and these are usually regarded as part of CP/M although they are separate from the BDOS/BIOS and may be replaced by the user's own utilities. +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Power-on | | Disks | | Display, | | Other | Hardware | jump | +->| | | keyboard | |peripherals| | | | | | | | | | +-----------+ | +-----------+ +-----------+ +-----------+ | | ^ ^ ^ | | | | | | | | | | | | v v v | | +-----------------------------------------+ | | | | Machine | | | Basic Input Output System (BIOS) | dependent v | | | software +-----------+ | +-----------------------------------------+ | | | ^ ^ | cold-boot |<-+ | data | jump | loader | | buffers | vector | | v | +-----------+ +-----------------------------------------+ | | | +------------->| | Machine | Basic Disk Operating System (BDOS) | independent | | software | | | | | | +-----------------------------------------+ ^ ^ ^ | data | BDOS | locations | buffers | commands | 0-256 v | v __________________________________________________________ / | | | \ +-------+ +-------+ +-------+ +-------+ +-------+ | | | | | | | | |applic-| | CCP | |util- | |comp- | | basic | | ation | transient | | | ities| | ilers| |inter- | |pro- | programs | | | | | | | preter| | grams | +-------+ +-------+ +-------+ +-------+ +-------+ ^ | v +-------+ | | | basic | |program| | | +-------+ Figure 1: CP/M operating system. WHY A NEW VERSION IS NEEDED --- - --- ------- -- ------ CP/M, version 2, was released in 1979. At that time a micro-computer with 64K bytes of memory (ie 64 x 1024 x 8 bits of memory) would have been considered large and most micro-computers would have less. Similarly a floppy disk drive with 1 megabyte of storage (ie 1024 x 1024 x 8 bits) was again a lot of memory. Thus the fact that an 8080 or Z80 micro-processor can address only 64K of memory without complex bank-switching mechanisms wasn't really a problem. Similarly, CP/M 2's restriction that individual files could have a maximum length of 8 megabytes or a disk capacity also of 8 megabytes was no real problem. Further most micro-computer users were enthusiasts who were able and willing to deal with a system that was somewhat awkward to use in places and didn't have very high expectations for 'user friendliness' (or for good documentation). The fact that it worked at all, and, in fact, works reasonably well, was enough to keep most users very happy. CP/M based microcomputers have turned out to be most successful and an enormous amount of software is now available from a large number of software writers. It includes compilers for most of the major computer languages, numerous editors and text processing programs, data-base programs, spread-sheet programs (visicalc clones) and apparently every conceivable business program. However, in 1983, limitations of CP/M 2 are becoming very apparent. Because of the success of the micro-computer, users are becoming less sophisticated. They want answers fast and don't want to have to fight with the operating system or learn to interpret weird error messages. With the advent of the 64K bit memory chip, the price of memory has dropped by a factor of 3 or 4 ( not corrected for inflation or devaluation) and it is hard to imagine purchasing a machine for professional use with less than 64K of memory. At the same time hard disk units with more than 8 megabytes of memory are available at an almost affordable price. The Z80 or 8080 based machines are, of course, suffering from heavy competition from machines like the IBM personal which are based on more advanced chips. Eventually, the 8 bit machines will be completely eclipsed by these advanced machines, at least for the professional user. However, at present, because of the huge amount of software available for 8 bit computers, many manufacturers are still producing these machines. Nevertheless, in order to compete with the 16 bit machines with their much improved address range, one wants to be able to use every trick to increase the memory available to an 8 bit machine. Putting all this together, any upgraded version of CP/M for 8 bit machines should (i) be much more 'user-friendly' (ii) have proper documentation (iii) give the user access to more memory (iv) allow longer files and larger capacity disks (v) run programs that were written for CP/M 2 (vi) be implementable on a wide variety of Z80 or 8080 based machines (vii) be flexible enough to allow manufacturers to add extra features (viii) be ready now. CP/M PLUS ---- ---- First, the name. It seems to be called CP/M PLUS. However, once inside the covers of the documentation, it's CP/M 3. The term CP/M 80 seems to be a generic term referring to the family of CP/Ms for Z80s or 8080s. I ordered a 'raw' version, that is, not configured to any particular system. It came on two eight inch floppy disks and was accompanied by 3kg of documentation. The disks contain the files required to generate the BDOS, an example BIOS, a large HELP file, and numerous utilities including 2 assemblers, a debugging program, an editor, a linker, a library program as well as those required for routine file manipulation. The documentation came in two ring-binder files and consists of 5 modules: the User's Guide, Programmer's Guide, System Guide, Programmer's Utilities Guide and Symbolic Instruction Debugger Reference Manual. There is also a pocket guide to the Symbolic Instruction Debugger. The documentation is well presented and of a high standard. I recognize some parts as being lifted from the old CP/M 2 documentation but its largely new and a complete contrast to Digital Research's documentation for CP/M 2. It is impossible for me to be sure how new users would get on, but my guess they would handle the User's Guide with a little outside help. The rest is for programmers only and, apart from a few minor gaps, is fine for them. Incidentally, why do they call it a User's Guide - surely they expect more than one person to use it. In addition there is an extensive HELP file on disk which covers the same material as the User's Guide. I discuss this later. BANKED AND UNBANKED VERSIONS ------ --- -------- -------- CP/M 3 comes in two versions. The unbanked version is a slightly cut down version which is loaded into a single bank of memory - that is it can utilize a maximum of 64K bytes of memory - and requires the same hardware facilities as CP/M 2. Because is offers more facilities than CP/M 2 it occupies more core, about 13K instead of the 6 or 7K that CP/M requires (on my system) and hence less space is available for the user's programs. The banked version uses 2 or more banks (blocks of 64K bytes) of memory. One of these is used for storing one's program and about 4K of CP/M. The rest of CP/M resides on one of the other banks of memory and any remaining memory is used for disk and directory buffers. I will describe these buffers in the next section. Thus about 60K of memory is available for the user's program and a substantially larger than usual area is available for CP/M. To run banked CP/M 3 one must of course have a computer with at least two banks of memory and the necessary hardware for selecting the bank to be accessed. In addition, to permit communication between banks one must have about 4K of memory, at the top of the memory range, which is accessed independently of which memory block is currently selected. This is known as common memory. My CPU board (model CB2 produced by SSM) purchased in 1980 has 4K of memory which doesn't know anything about bank select and which is accessed in preference to external memory and so very easily provided me with the common memory facility. I don't know whether this was just luck or whether the board's manufacturers predicted the appearance of CP/M 3. My system currently has two 64k blocks of memory and one 16K one and a memory mapped disk drive. I have sketched out a map of its memory allocations in figure 2. Note that a copy of the CCP is stored in memory so that it can be loaded almost instantly without accessing the disk at each warm boot. 64K +---------+ | A | 4K of common memory - accessible +---------+ from all banks 60K +---------+ +---------+ | used by | | | | disk | | | A: used by CP/M |---------| | | B: disk buffer area | | | | | A | |available| | | | for | | | |transient| |---------| | program | | | | | | | | | | B | | | +---------+ | | | | | B | | | | | |---------| | | | | | CCP | 0K +---------+ +====A====+ +---------+ bank 0 bank 1 bank 2 Figure 2. Memory layout for CP/M 3. BLOCKED DISK TRANSFER ------- ---- -------- CP/M programs usually expect to transfer data to and from disks in records of 128 bytes. However the disks themselves frequently work more efficiently if larger blocks, say 1024 bytes, are used. If one wants to read a file sequentially, that is, starting at the beginning and then reading it in order, there is no problem. The operating system reads the first 1024 byte block into a buffer and passes each of the first eight 128 byte records across to the program as they are required. Then the second block is loaded and the process continues. Writing is similarly straight forward. The problem arises when a program is reading from and/or writing to several files. Usually there is only one buffer area for the blocks so if, for example, a program wants to read a 128 byte record from one file and then write a 128 byte record to another, the original 1024 byte block read into the buffer by the initial read will be destroyed by the write operation and will have to be reloaded when the second record is required to be read. In the worst situation each record read will require a disk operation as opposed to one every 1024/128 = 8 record reads and each write will require both a read and a write operation. Similar considerations will apply when one is randomly accessing files - that is reading or writing records in an order that is not sequential. The resulting disk operations are likely to be very slow and subject the disk drive and floppy disks to unnecessary wear. The obvious solution is to use several buffers so each file being read or written can have its own buffer. This is what CP/M 3 does, with the buffers being stored in the extra memory banks so that they don't reduce the space available to programs. To see what difference this makes in practice, I carried out a series of time trials with CP/M 2, the unbanked version of CP/M 3 with only one buffer block and the banked version with a large number of blocks available. The results are given in table 1. The first example was with ratfor, a program which reads a file containing a program written in ratfor ("rational fortran") and translates it to regular fortran. Thus one file is read and another is written. The program makes little attempt to block the input and output. The second example is a regular fortran compile with one file being read and two written. In this case the material does tend to be read and written in chunks so less rereading and rewriting of the buffers might be expected than in the ratfor example. Minor differences in the timings are probably not significant since the timings depend to an extent on the way the files are placed on the disk and this varies from run to run. Since no blocking is required for the disk using 128 byte blocks (a standard single density disk), CP/M 3 does not use its blocking-deblocking code and the timings for the two versions of CP/M 3 are the same. For the disk using 1024 byte records, CP/M 2 and the unbanked (or more accurately the single buffer) version of CP/M 3 perform about as well as for the disk with 128 byte records for the ratfor example and somewhat better for the fortran compile. However gains are made for both examples when the banked version of CP/M 3 is used. In fact, for the ratfor example the difference in disk activity was quite dramatic, almost continuous disk activity was replaced by just an occasional access when the banked version of CP/M 3 was used. The final set of tests was with a virtual disk - that is RAM memory being used to simulate a disk. 'Disk' transfer times are negligible and all 3 operating systems work equally well. I think the increase in speed with CP/M 3 is well worth having but it is not nearly as large as some people would have us believe. A similar system applies to the disk directories. Directory information for each file occupies 32 bytes so multiple buffer deblocking is also used for them. One can also configure CP/M 3 to use more efficient methods of scanning the directories to find a requested file. I can imagine such techniques would be important for high capacity hard disk but cannot detect any difference with my 1 megabyte floppy disks. Note that CP/M 3 does not use the buffers when it does not have to, for example when the disk itself uses 128 byte records or when whole blocks can be loaded directly into memory, say when loading a program. CP/M 3 does not appear to make a cponsistent effort to minimize disk operations with random access files beyond the simple buffering I have just described and so, for normal use, there is no sense in allocating vast amounts of memory to the disk buffers. Operating Disk Timing (seconds) System Ratfor F80 CP/M 3 banked \ 128 byte 93 81 CP/M 3 unbanked / CP/M 2 1K byte 94 67 CP/M 3 unbanked 1K byte 94 63 CP/M 3 banked 1K byte 72 51 CP/M 2 \ CP/M 3 unbanked Semidisk 61 30 CP/M 3 banked / Table 1: Timings for disk operations. OTHER IMPROVEMENTS ----- ------------ We have now covered the best known features of CP/M 3. This section covers the numerous minor differences which, when put together, really make the difference. BDOS commands: The BDOS commands are the commands that the transient program can direct to the BDOS part of the operating system. The include the commands for reading and writing to and from the current console and the auxiliary device (formerly the tape punch/reader), reading and writing to and from files, opening and closing files, setting options and finding the state of the system. CP/M 2.2 has 38 of these, CP/M 3 has 63. The extra ones are for file manipulation, implementing the extra facilities of CP/M 3 and include nice ones such as those for generating an FCB (file control block) from a file name and chaining to another program and a nasty one for returning CP/M 3's serial number. Apart from functions 7 and 8, access IO-byte, and 27, get disk allocation vector, all CP/M 2.2 BDOS functions work in CP/M 3. Maximum disk and file length: These have been increased from 8 megabytes each to 32 and 512 megabytes respectively. Since a disk on my system can hold a maximum of just over 1 megabyte, I haven't tested this. User numbers: As in CP/M 2 files can be assigned to any of 16 user numbers. User numbers are the poor man's version of the subdirectories used on some larger computers. Suppose, for example, the CP/M command "USER 9" has been entered. Then any file generated will be tagged as belonging to user 9 and under CP/M 2 only files so tagged will be accessible and these will be the only files whose names will be listed by a call to DIR. This provides a convenient way for several users (ie people) to use one disk without running into conflict over file names or losing their files amongst those of the other users in a directory listing. Similarly, it is also useful for separating the files of several different projects for a single user. Naturally users of floppy disks will tend to have a disk for each project or user so user numbers are not very important but for hard disk users I imagine that user numbers are essential. The problem in CP/M 2 was that programs would normally access only files tagged with the currently assigned user number so that, in particular, the standard utilities such as PIP, STAT, ED etc had to be stored separately under each user number being used with a consequent waste of space. Worse still, to get them there one would normally user the 'copy from another user area' option of PIP. But one first had to get PIP to that user area from the default user number, user 0. To do this one first loaded PIP with the debugging program DDT, exited, entered the USER command to get to the desired user area, and then used SAVE to save PIP in the appropriate user area. SAVE, however, wants to know the length of the file to be saved. In fact, DDT has printed this out - in hex. But SAVE wants to know it in a decimal number of 256 byte blocks. Its easy to work out, but the whole procedure is awkward and not for the non-computer person. In CP/M 3, if the system can't find a file in the current user area it will look under the system files under user 0 (files can be tagged 'system' and will not show up under a normal directory listing, but they are still there and can be accessed and manipulated), so the duplication of utility routines and adhoc methods of initially copying PIP are avoided. In addition if the current user number is not equal to zero, it is printed out with the system prompt, so one is reminded what user number one is working under. Command line editing (banked version only): A line being entered can be edited without having to delete back to the character to be edited. In addition, the last line entered can be recovered, edited and entered again, so that a line rejected by a program because of syntax errors need not be retyped. A grumble about this facility is that the editing keys have been fixed by Digital Research and may not agree with the corresponding keys used by one favourite editor. Also, one's display unit must backspace without deleting on receiving control-H. One now has the option to make the delete key backspace and delete rather than echo as it does with CP/M 2. Another command line facility enables one to enter several commands on one line. Disk change: CP/M 3 attempts to detect a floppy disk change so that it is not absolutely necessary to do a control-C when changing a disk. If the floppy disk drive sets a flag when the drive door is open then a disk change will always be detected. Otherwise, the directory is sumchecked every time a new program is begun and the sumcheck compared with the previous time this was done. In this situation a disk change will not always be detected and it is probably advisable to enter a control-C, particularly if the next program involves disk writes. Temporary disk: Several programs such as editors, SUBMIT described in the next paragraph, want to generate temporary files to be deleted when they finish executing. The current default disk is often not the appropriate disk for these files. CP/M 3 allows one to designate a particular drive as the default drive for these files. Submit: SUBMIT is another CP/M 2 command that appears in CP/M 3 in a much cleaner form. XSUB is now automatically included in submit (did you ever figure out the rules governing XSUB?). Suppose you frequently wish to enter the same set of commands or a single rather complex command, possibly with some unknown parameters. Then you make a file containing these commands with $1, $2, ... replacing the items you might wish to vary from run to run. Now you can SUBMIT this file, if necessary specifying the unknown the variable parameters, and they will be executed without further intervention. Data to be read by the programs from the terminal or alternatively from the submit file if each such line is preceded by the symbol <. At power-up the the system will look for a file PROFILE.SUB and submit this file, if present. This provides a simple way for setting the directory search order (see below) or displaying a logo when the machine is turned on. Submit files can, themselves, include submit statements, but each level eats up a little more memory - see the section on RSX's below. As in CP/M 2 SUBMIT writes a file to disk containing the submit commands. However, this disk, is the temporary disk, I have just described, and if this is a virtual disk much of the grinding of the disk drive associated with SUBMIT in CP/M 2 can be avoided. Programs can now return a 'return code' which can be used to indicate whether a program performed correctly. SUBMIT files can now contain conditional lines which are executed only if the preceding program returned a successful code. However the extra features of SUBMIT tend to make one think "wouldn't it be nice if it also did this" and I wouldn't be surprised if improved versions appeared. Directory search: Often the files one is working on will be on the drive designated as the default drive. However the utilities and compilers will be on another drive. CP/M 3 allows one to specify a list of up to four drives through which the CCP will search for a program to be executed. Note that this will not work for the (data) files which the program is to access. These must be on the default drive or have their drive names specified. In CP/M 2, to call a program, one simply enters the name of the program with the standard suffix, .COM, omitted. In contrast, one can configure CP/M 3 so that if a command is entered, the CCP attaches the suffix .SUB and attempts to find and submit the resulting file and failing this will try the suffix .COM and attempt to find and execute the resulting file. Since many of my programs are driven from files to be submitted, this is how I have CP/M configured on my machine. Alternatively, one can give .COM files precedence, or one can follow the same protocol as CP/M 2. Disk errors: In CP/M 2 if a disk read error is detected a cryptic error message is returned and the program exits with the loss of any data in core. This can be the source of many tears if one is in, for example, a word processing program and is just saving one's latest best-seller after many hours of work. Of course, one should regularly save a manuscript, so minimizing the possibility of losing a large amount of work through a system failure (or power cut). In CP/M 3 the error message depends on the author of the BIOS. However CP/M 3 gives the opportunity for a program to maintain control after a disk error and so a 'soft landing' can be programmed. IO device assignment: Like CP/M 2, there are five 'logical' devices, the console keyboard, the console display, the printer, the tape reader - now called the auxiliary input device, the tape punch - now called the auxiliary output device. However these can be assigned to a maximum of 16 physical devices defined in the BIOS. Five pairs of locations in the System Control Block (see below) replace the IO byte of CP/M 2 for determining the current assignments. Each logical device can be defined to more than one physical device, if output is to be sent to several devices or input is to be collected from more than one device. PUT and GET: One sometimes wishes to gather up the output from a program and store it in a file: for example one might be testing a program, or one might want sample outputs for documentation. This can be done by using the command PUT before running the program. Similarly program input normally entered via the keyboard can be picked up from a file using GET which is essentially a cut down version of SUBMIT. By using a PUT command followed by a GET command one can feed the output of one program into another simulating the pipes that UNIX addicts are so fond of. PIP and archive: PIP is essentially the same as in CP/M 2. However there is an additional option - the archive option. Files of a disk can be flagged as 'archived'. With the archive option set PIP will copy only files which are not flagged as archived and then flag these files also as archived. This provides a very convenient way of backing up new or modified files on a disk without having to copy the entire disk after each session. Date, password and disk label: Files can be 'time stamped' with their creation dates and either their last access date or last update date. To use this facility the disk directory must be reorganized with each fourth directory entry containing the data for the preceding three files. Thus the maximum number of directory entries will be reduced by a quarter. I haven't tested this facility as my computer does not have a clock. One can also label a disk. This uses another directory entry location. CP/M 3 also provides a facility for password protecting files against either unauthorized reading, writing or deleting. It's only limited protection as one could easily write a program to override it. It's my impression that security devices like this cause more trouble than they are worth. However, if you don't have an Official Information Act in your household you might want the limited amount of protection provided. Help file: CP/M 3 comes with a 62 kilobyte help file describing all the commands associated with CP/M and its standard utilities. It is organized with main headings, sub-topics, sub-sub-topics etc and comes with a little .COM file for accessing it. The help file can readily be edited or added to so you can add explanations of your own programs. It actually works pretty well, however again one keeps feeling 'wouldn't it be nice if they also included this facility'. The 62K length would pose problems for people with low capacity disks. DIR, ERA, REN, TYPE: The directory, erase, rename, type operations, DIR, ERA, REN, TYPE which were carried out by the CCP in CP/M 2 are now carried out by the CCP when in their most elementary form; if called with options they call separate programs stored on files DIR.COM, ERASE.COM, RENAME.COM and TYPE.COM. The options allow one to request a sorted directory with each file size and flags displayed, or request confirmation before erasing a file. RENAME does not have options, however, it prompts for the new and old name if these are not specified in the call and if a file with the new name already exists requests permission to delete it. An additional command DIRSYS is used for listing the names of system files. System control block (SCB): Numerous pieces of information about the current state of the operating system is included in a 100 byte block known as the system control block. This includes the number of console rows and columns, the directory search order, the input/output redirection data, the time and date, the current column position. There is a BDOS command for accessing and, in some cases, altering the SCB. Resident system extensions (RSX's): Frequently one would like to squeeze a some translation between ones program and the BDOS or perhaps add extra BDOS commands. For example, I have an inexpensive imitation of Visi-calc. This program is unable provide the correct cursor positioning commands required by my display. The simplest solution is to trap the console output commands and translate them to a form suitable for my display. CP/M 3 contains the necessary facility for doing this. An RSX is a small chunk of code which is attached to a .COM file and which automatically is attached to the bottom of CP/M when the .COM file is loaded. It intercepts the appropriate BDOS commands and passes the others on to the BDOS unmodified. It may be programmed to vanish when the program ends or stay until it is commanded to detach itself. SUBMIT, GET, PUT and also SAVE (which must be entered before the program to be saved is run) are examples of RSX's. Another obvious application, is to intercept the command that returns CP/M's serial number so you can run your friend's software despite a manufacturer's attempt to prevent sharing software - but you wouldn't do that, would you? THE UTILITIES --- --------- As well as the utilities I have already described, CP/M 3 comes with the utilities ED, MAC, RMAC, LINK, SID, LIB. In one sense it is quite a bargain, the prices of these utilities, if bought separately add up to about the same as the cost of CP/M 3. However, in fact, they don't add very much to the software I already own, and beyond what was required for generating the BIOS won't get much use from me. ED This is an augmented version of Digital Research's well-known editor. I have never used it or its predecessor and while I imagine it would have its uses if I ever came to grips with it, it seems very old fashioned compared with the screen editor I now use. MAC and RMAC MAC is an assembler (i.e. it compiles assembly language programs), very much more powerful than ASM which comes with CP/M 2, with extensive macro facilities. RMAC is a similar assembler which produces relocatable code to be linked into executable files by LINK or Microsoft's L80. RMAC's macro facilities are required for assembling some of the routines for the BIOS. However it accepts only Intel's mnemonics for the machine instructions plus some imitation ones for the Z80 codes. I consider Intel's mnemonics almost impossible to use and so prefer to use Microsoft's macro assembler, M80, which accepts the much more understandable Zilog mnemonics. LINK This is linking program used to link the output from RMAC, Digital's PL1 compiler, and also output from Microsoft's M80 and F80 into executable code. It has a number of options which enable it to produce overlayable code or code that is relocateable at run time. It is required for linking the BIOS for CP/M 3 or for building RSX's. To use the overlay capability one needs either DR's PL1 compiler to get the runtime overlay routines or one will need to do some detective work in order to write one's own. Unfortunately its run time is almost twice as long as for Microsoft's L80 so I won't be using it for linking standard programs. LIB This is a program for building and combining libraries of relocatable files of the type produced by RMAC. I haven't used it yet and cannot say how it compares with the equivalent Microsoft product. SID This is a very much augmented version of DDT (which comes with CP/M 2) and is used for debugging assembly language programs. I used it a little when bringing up CP/M 3. It, too, uses Intel mnemonics and it can be fouled up by Z80 instructions. I won't use it much as I don't do much assembly language programming. COMPATIBILITY WITH CP/M 2 ------------- ---- ---- - Of course, CP/M 3 must be able to run most programs written for CP/M 2 if it is going to have any acceptance. Programs are supposed to communicate only via the BDOS commands - see figure 1. However, some do access the BIOS commands or other parts of CP/M or even access the peripherals directly. The BDOS commands of CP/M 3 are extensions of those of CP/M 2 and so, as a general rule, we would expect programs that obey the rules to work correctly under CP/M 3. One exception is programs that access the disk allocation vector (which shows which disk blocks are allocated and can be used for seeing how much disk space is free). This vector, which is located using BDOS function 27 is not accessible under the banked version of CP/M 3 and so any programs that need it will have to be rewritten. A new BDOS function is available for finding the free disk space. I don't know whether this function is used much in commercial programs but as a last resort one could write an RSX to intercept BDOS function 27 and return the address of a simulated disk allocation vector with the correct free space. Programs which access BIOS functions may or may not work. The disk functions have been modified and in any case they would be unlikely to work under the banked version of CP/M 3 since they expect to be called from the first memory bank. However the character I/O commands should still work. CP/M 3 includes a special BDOS function for accessing the BIOS functions and presumably this gets the banking right. Accessing other parts of CP/M, will work only if those parts are in common memory in the banked version and can still be located correctly. Accessing peripherals directly via IN and OUT instructions should cause no problems. However, other methods of accessing peripherals may cause problems. My system has a memory mapped disk controller - ie, it is accessed by reading and writing to and from memory locations rather than by using IN and OUT instructions. The section of memory used is allocated to the first bank and so direct access to this is not possible under the banked version. Thus, in particular, my disk formating program which wants to access these locations will not run under the banked version and it is necessary for me to maintain an unbanked version to run this program. Some control characters seem to be handled slightly differently. In particular, while ^s is used for stopping output as in CP/M 2, a ^q is now required to restart it, rather than any character apart from ^c. Control characters ^p, ^q, ^s, are intercepted by BDOS function 6 unless it is specially instructed not to and this causes a minor problem for one of my programs, a problem which I could overcome by writing a suitable RSX. The IO-byte used for redirecting output is now replaced by a more sophisticated control mechanism and BDOS functions 7 and 8 now have a different use; this might affect a few programs. The functions of the utility STAT which accessed the IO-byte have now been taken over by a series of utilities, DIR, SHOW, SET but I don't think this will upset many users. One possible area for problems is with systems that use interrupts. An interrupt is a mechanism whereby the hardware can gain temporary control of the processor, perhaps to pick up input from the keyboard or modem or to send another block of text to the printer. I do not know whether interrupts are disabled when a memory bank other than the one holding the program is being used, but if not there will be trouble. ADAPTING CP/M TO YOUR SYSTEM -------- ---- -- ---- ------ The first problem is getting a copy of the raw version of CP/M 3. Digital Research appears to consider it too complicated for the hobbyist to convert it for his/her own system. In fact it isn't, although it is not a project to be undertaken lightly. I doubt whether Digital Research would offer any advice or support for any amateur attempting to this. It is not widely advertized but is available from a limited number of sources. CP/M 3 comes with reasonably detailed instructions. One needs to generate the BIOS (see figure 1), a cut down BIOS for the cold-boot loader and a program to load the cold-boot loader onto the system tracks of a floppy disk. One should start by building a minimal unbanked system and then slowly build it up till one gets the system one wants. Because the BDOS does the disk deblocking, rather than the BIOS, it is possibly a little easier than building an equivalent system for CP/M 2. The instructions for doing the full BIOS were reasonably good but I seemed to need to do a bit of detective work to build the cut-down BIOS for the cold-boot loader. The BIOS including the interface for the Semidisk involved about 1500 lines of code (a few hundred would have been copied from other sources), the cold-boot BIOS involved 270 lines and the program to set up the system tracks 350 lines. A program GENCPM is supplied for putting everything together and the process is much more logical and less mysterious than for CP/M 2. In particular, it seems very reasonable for an amateur who can program in assembly language to modify an existing CP/M 3 BIOS to accommodate any special requirements or new pieces of hardware. FINAL COMMENTS ----- -------- I hope I have indicated some enthusiasm for this new version of CP/M. It is true that many of its features such as help files, the improved directory searching, program chaining can be implemented under CP/M 2. In addition, there still some rough edges, perhaps brought about by the realisation that it is better to have the present version now, rather than the perfect version long after the 8 bit chips are dead and buried. However, within the limitations of being compatible with CP/M 2 and the need to release it sooner rather than later, I think it represents a substantial improvement over CP/M 2, bringing together a large number of new features in a unified manner, which together add up to quite a lot. I think there is the opportunity for a manufacturer to put his/her own mark on the system without making it incompatible with standard CP/M 3. An obvious example would be the addition of a visual CCP, perhaps with icons or pictures for program selection. However, I don't expect many CP/M 3 only programs to appear on the market. CP/M 3 is not really a new system and the casual user would probably not notice any difference except perhaps that the familiar CP/M prompt appears immediately after a program terminates and possibly that some programs that use a lot of disk accesses run a little faster. With further use, however, he/she would find that things go wrong less often. After reading the documentation or using the HELP file he/she would begin using the line editing facilities and perhaps PUT, GET and the improved facilities of SUBMIT and begin to appreciate the host of minor additions. At this point the user might think about reorganizing the way disks are used, particularly if the system has a hard disk. This would involve the use of user numbers, time stamping files, and systematically backing up the working disks using the archive option. A programmer would appreciate some of the extra BDOS commands, the more logical structure and the extra memory. Should you get CP/M 3? If you are given the choice, I think the answer is yes. If you are getting a hard disk system, this is a very strong yes (except that perhaps you shouldn't be buying an 8 bit system), otherwise it really depends on how much you can afford and the size of your system. t impossible to use and