ftp.update.uu.se

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

/ ftp.update.uu.se / ftp.update.uu.se.2014.03.zip / ftp.update.uu.se / pub / rainbow / msdos / decus / RB141 / varug04a.arj / V4N3ASC.ASC < prev

Wrap

Text File | 1990-05-20 | 64KB | 1,026 lines

Vancouver Area Rainbow Users Group N e w s l e t t e r May and June, 1990; Volume 4, Number 3 Editor: David P. Maroun, 9395 Windsor Street, Chilliwack, BC, Canada V2P 6C5; telephone (604) 792-4071 Publisher: DECUS Canada, 505 University Avenue, 15th Floor, Toronto, Ontario, Canada M5G 2H2; telephone (416) 597-3437 ----------------------------------------------------------------------------------- Unless the contrary is indicated, any part of this newsletter may be freely copied or distributed unaltered and with credit given to the original source. While the information provided is believed accurate, the editor cannot take responsibility for contributions of other writers. ----------------------------------------------------------------------------------- Deadlines: For our July and August issue: June 30, 1990 For our September and October issue: August 31, 1990 Almost any legible format is acceptable for submissions, but the ideal is ASCII form on diskette. Diskettes should be accompanied by covering letters describing the files and indicating disk format. We can handle Rainbow CP/M, Rainbow MS-DOS, IBM PC-DOS single-sided, and some others as well (check about them). ----------------------------------------------------------------------------------- Editorial: Are We Really So Different? by David P. Maroun Several months ago, I was a guest speaker at a BC VAXLUG meeting. I spoke on microcomputer communications. The VAXLUG chose the topic. I was surprised that a nominally VAX-oriented group wanted to hear about microcomputers, but I was told BC VAXLUG members deal with a great variety of machines, so the group gave attention to personal computers and UNIX workstations as well as VAXes. Our own group is supposed to be a personal computer group, but its members also deal with VAXes, PDPs, and IBM mainframes. So, there is a fair overlap with the interests of the VAXLUG. Computers and their users are not so disparate as some people would have us believe. ----------------------------------------------------------------------------------- Messages To The Membership Mr. J.R. Parent, a resident of Dollard des Ormeaux in Quebec and a contributor to this newsletter on several occasions, telephoned recently. Mr. Parent mentioned that our newsletter is appreciated in more eastern parts of the country. Tony Klanchar would like to hear from users of DEC Professional 300 series computers, and offers help to them. Interested parties can contact Tony Klanchar 914 Sycamore Drive Kamloops, BC V2B 6S2 Telephone (604) 579 8345 (home) (604) 374-9717 (work) ----------------------------------------------------------------------------------- Corrections And Clarifications We have sometimes recommended the CP/M-80 utility LHRD.COM for removing files from archives created by LHARC under MS-DOS. We recently ran into a limitation of LHRD: It would not extract a very large text file from an LHARC archive. When extracting, LHRD reports on the screen the amount of the file it has expanded. In our case, LHRD put '150 k' on the screen, then the computer stopped responding until the user did a system reset. The computer was a Rainbow, but someone else said he had the same problem on a different machine. That person also suggested something similar might occur with a companion CP/M-80 utility, UNZIP, which handles ZIP libraries. We ourselves have yet to run into trouble with UNZIP. We do not consider this difficulty severe enough to make us stop using LHRD or UNZIP altogether, but we do advise some caution. ----------------------------------------------------------------------------------- Recent Additions To The VARUG Library Our library of shareware and public domain software grows continually. Here is a list of some files added within the past few months: ---------------------------------- 4DOS221 ZIP COMMAND.COM replacement. On Rainbows, works best with Code Blue. ACV ZIP Converts IBM characters to DEC or vice versa. AME86-72 ZIP CP/M-86 emulator with source code BROWSE22 ZIP Paging, scrolling text viewer for Rainbows CAD ZIP Drawing program for Rainbows CLEANP60 LZH Eliminates virus-infected programs. CSHELL ARC COMMAND.COM substitute; works best on Rainbows with Code Blue. FAMTREE LBR A family tree program for Rainbows; with C source code FANFOLD LBR Prepares text for both sides of fanfold paper. Can reformat and delete blank spaces. GPDB EXE Database for Rainbows; self-extracts; requires RUNGPDB. GW_DUMP ARC Fast screen dump from Rainbow GW-BASIC to an LA50 printer ITAX89 LZH Lotus 1-2-3 version 2 Canadian income tax sheet for 1989 KEDTMS ARC A text editor for the Rainbow LH114B EXE LHARC version 1.14 beta archiver; self-extracts MSVRB1 ZIP Rainbow KERMIT communications version 3.00 PI-COMP LZH Compares groups of files; may conflict with RAM drives. PKZ110 EXE The PKZIP archiving family, version 1.10; self-extracts. QBX300A LZH Cross-reference for QuickBASIC; use with Code Blue on Rainbows. RBHIST80 ZIP Expanded command history for Rainbow MS-DOS; version 8.0 RUNGPDB LZH Allows running GPDB on Rainbows. SCANV60 LZH Scans disks and memory for viruses; version 6.0 SCRIVNER LBR CP/M-80 mathematical text processor TCL ARC Digital Command Language for MS-DOS UTEV2 ZIP A drawing program for Rainbows V3N6ASC ZIP VARUG newsletter, volume 3, number 6 V4N1ASC ZIP VARUG newsletter, volume 4, number 1 V4N2ASC ZIP VARUG newsletter, volume 4, number 2 VIEWANSI ZIP Paging, scrolling text viewer for ANSI systems XTRACC11 LZH Extracts specified characters from files. ---------------------------------- FAMTREE.LBR, FANFOLD.LBR, and SCRIVNER.LBR are designed for CP/M. All other files are set up for MS-DOS. Please note that GPDB.EXE and RUNGPDB.LZH go together. Most files are generic and can be run on a variety of computers. Those which are not are indicated in the preceding list. For more information, contact Ken Alger 6001 Pine Park Place Nanaimo, BC V9T 3B6 Telephone (604) 390-4482 ----------------------------------------------------------------------------------- Charlie's Museum Of MS-DOS Horrors Does Anybody Really Know What Time It Is? (Does Microsoft Really Care?) by Charlie Gibbs One thing that becomes apparent after working with MS-DOS for awhile is that it's designed to be used for awhile during the day, then switched off when you go home. Not that you can't leave an MS-DOS machine running 24 hours a day, but there are a few things you have to watch out for, such as the clock. MS-DOS machines use a number of different battery-backed-up clocks--especially XT clones, many of which have no built-in clock and need some sort of add-on clock. These add-on clocks are many and varied, and some (such as the ones which need a driver specification in CONFIG.SYS) might not get along too well with other software. But once the machine has been booted and the time read, I would think (although I might be wrong) that the operating system itself should take care of maintaining the time of day internally. DOS's internal clock (which is distinct from the battery-backed clock from which it's initially set) is not necessarily too reliable around midnight. Try typing in and running the following BASIC program: 10 TIME$ = "23:59:55" 20 OLDX$ = "" 30 X$ = DATE$ + " " + TIME$ 40 IF X$ = OLDX$ THEN 30 50 PRINT X$ 60 OLDX$ = X$ 70 IF RIGHT$(X$,2) <> "05" THEN 30 80 END Each time the returned date and time changes, it will display the new value. You might be surprised at what comes out. Here's what the program displayed when run on my system: 12-05-1989 23:59:55 12-05-1989 23:59:56 12-05-1989 23:59:57 12-05-1989 23:59:58 12-05-1989 23:59:59 12-05-1989 00:00:00 12-06-1989 00:00:00 12-06-1989 00:00:01 12-06-1989 00:00:02 12-06-1989 00:00:03 12-06-1989 00:00:04 12-06-1989 00:00:05 Note that on the stroke of midnight, it briefly returned the old date before rolling it into the next day. Other systems can give other results. I have seen a time of 24:00:00 returned on the stroke of midnight, before it resets to 00:00:00. One machine only advanced the date about half the time, so after a week its date would be three days or so behind (although the time was, for the most part, correct). Other systems don't advance the date at all. I discovered these lovely things when I wrote a real-time data collection routine which does date and time stamping in addition to kicking off special processing at midnight. For it to run properly on all systems, I've had to add some fairly sophisticated code to check for the above problems and, if necessary, advance the date itself if the system doesn't bother to do so. Note that it's a good idea to wait a second or so after midnight before checking the date. One system took long enough to advance the date that my program decided it wasn't going to. Taking the matter into its own hands, my program advanced the date, only to have DOS then advance it as well. As a result, the date would jump two days every midnight. Personally, I don't think it's asking too much for a system to always return a valid, proper date and time. How many extra microseconds would it really take for the system to finish updating them before handing me a value which is otherwise half-baked and useless? But there it is. I hope this little description of the difference between what is and what should be can help others write programs that work correctly in real time--all the time. ----------------------------------------------------------------------------------- In The News Suitable Solutions Plans To Discontinue Its Rainbow Business ------------------------------------------------------------ Suitable Solutions has announced that effective May 31, 1990, it will discontinue providing products for the DEC Rainbow. In a letter dated April 23, 1990, Julie Starr, Suitable Solution's business manager, said, "We will be closing June 1 for an indefinite period of time while our company makes plans for a new business direction. . . . The demand for Rainbow add-on and upgrade products is no longer able to support our business." She further indicated that the company has reduced prices on most of its inventory of Rainbow accessories. For more information, interested parties can contact Suitable Solutions 1700 Wyatt Drive Suite 12 Santa Clara, CA 95054 Telephone (408) 727-9090 Lotus On The VAX ---------------- Lotus Development Company has announced two new versions of its 1-2-3 spreadsheet, one for VAX/VMS and one for All-In-1. Both are based on Release 3 of the program. The new versions provide links between work on a VAX and on personal computers in a network. DEC Takes Steps To Protect The Ozone Layer ------------------------------------------ Digital Equipment Corporation has announced it will change its process of cleaning circuit boards to avoid freeing chemicals which are likely to damage the ozone layer. Details of the new procedure will be passed on to the Industry Cooperative For Ozone Layer Protection. DEC And Concordia Agree To Collaborate -------------------------------------- The Management Information System of Concordia University of Montreal has agreed to purchase computer equipment from Digital Equipment Corporation of Canada. The agreement is valued at millions of dollars. DEC and Concordia have also agreed on a long-term partnership to develop the university's computing and communications facilities. ----------------------------------------------------------------------------------- Another Look At Disk Caching By Wilson C.Y. Chang My review of the Mace utilities in the last issue of this newsletter included a discussion of disk caching and concluded that they were of little help, at least on a Rainbow. However, I drew a conclusion about caching under MS-DOS 3.10 although my tests were all done under MS-DOS 2.11-1. With some encouragement from certain other people, I made more tests. This time I did not use the Mace disk caching systems but only the BUFFERS assignment in CONFIG.SYS. The computer was the same as before: A Rainbow 100A equipped with an NEC V20 microprocessor, 852 000 characters of random access memory, and floppy drives but no hard disk. My main purpose was to compare disk caching under MS-DOS 2.11-1 with caching under 3.10. There are several versions of MS-DOS 3.10 for the Rainbow. The one I used was the original from Suitable Solutions, not one of the pre-production models that have been passed around nor the more recent 3.10b from Suitable Solutions. Let me review first the meaning of the BUFFERS assignment. MS-DOS allows setting aside part of memory for temporary storage during access to disks. Information is written to this part of memory, for example, before being written to disk. The purpose of using memory this way is to speed up access to the information. The size of the section of memory set aside is determined by the BUFFERS assignment. If you write BUFFERS=10 in a CONFIG.SYS, and boot your computer, you set aside some 5 100 characters of memory as an intermediary between a disk and the program you are running. You should not put too much faith in that number 5 100; the actual amount varies from one system to another. Roughly 512 characters of memory for each unit in the BUFFERS assignment seems correct for the Rainbow I was using. Under Rainbow MS-DOS 2.11-1, the minimum number for the BUFFERS assignment is zero; under Rainbow MS-DOS 3.10, the minimum is one. If no BUFFERS assignment is made in a CONFIG.SYS file, the system chooses a default value. I have not checked on what it is, but I am told two (corresponding to 1 024 characters of memory). The maximum is said to be 99, but I have not checked on that either. The Mace utility CACHCTRL.EXE is designed to test disk caching systems. The program creates a large file on disk and then reads it sequentially forward, sequentially backward, and randomly. I used CACHCTRL.EXE to test different BUFFERS assignments under the two Rainbow operating systems. CACHCTRL runs directly under Rainbow MS-DOS, but does not give a screen display. The IBM emulator Code Blue is needed to get the display. Code Blue's '/V' option is not needed--and a good thing, too, since it slows a Rainbow down by about a third. I used CACHCTRL first without Code Blue and then with Code Blue version 1 to get details of the runs. To do a test without Code Blue, I loaded an operating system and set up a RAM drive E: containing a batch file and some auxiliary files, then ran the batch file. The batch file read TIME > E:TESTDSK.DOC < E:CR E:CACHCTRL TEST B: < E:Y TIME >> E:TESTDSK.DOC < E:CR E:CR was a file containing just a carriage return. E:Y contained a 'Y' for 'YES'. These two auxiliary files responded automatically to prompts. The batch file put the starting system time into a file E:TESTDSK.DOC, made CACHCTRL.EXE run a test on disk B:, then put the ending time into TESTDSK.DOC. Since I used a RAM drive for the batch file and its helpers, little time was used up by the batch file itself. I made several runs, sometimes with MS-DOS 2.11-1 and sometimes with 3.10, with different BUFFERS assignments in the CONFIG.SYS files Here are the results: ------------------------------------------------------------------ | Operating system | 3.10 | 2.11-1 | ------------------------------------------------------------------ | Buffers | 1 | 20 | 0 | 20 | | Time (minutes) | 58.7242 | 16.3825 | 15.991 | 15.569 | ------------------------------------------------------------------ The table is evidence for what I said in my last article: Under MS-DOS 2.11-1, using buffers for disk caching makes little difference. But here also is proof I was wrong in extending the conclusion to MS-DOS 3.10. Under that operating system, disk access was much faster with a BUFFERS assignment of 20 than with one. Please note that even with 20 buffers, MS-DOS 3.10 took longer to run the test than MS-DOS 2.11-1 took with no buffers. On floppy disks at least, speed is sacrificed in going from MS-DOS 2.11-1 to 3.10. Now for a few details of the runs. I installed RNP, a memory-resident utility which allows saving screen displays to a file, and ran CACHCTRL.EXE under Code Blue. With MS-DOS 3.10 and 20 buffers, CACHCTRL reported: Record map of test file CACHETST.FIL Sequential write: 218.73 Sequential read (forward): 119.82 Sequential read (backward): 261.27 Random Read: 379.10 Free base memory: 355200 The times given by CACHCTRL are in seconds. Under MS-DOS 2.11-1 with 0 buffers: Record map of test file CACHETST.FIL Sequential write: 219.31 Sequential read (forward): 119.85 Sequential read (backward): 223.54 Random Read: 406.79 Free base memory: 377568 With MS-DOS 2.11-1 and 20 buffers: Record map of test file CACHETST.FIL Sequential write: 218.73 Sequential read (forward): 119.85 Sequential read (backward): 229.19 Random Read: 369.44 Free base memory: 369120 Evidently, for random reads, MS-DOS 2.11-1 is faster with the extra buffers, and MS-DOS 3.10 with 20 buffers beats MS-DOS 2.11-1 and no buffers. The other operations offset these results. I hope this article sets the record straight. ----------------------------------------------------------------------------------- Program Autoloading Under Rainbow CP/M by Paul Olson (Editor's note: This article is taken from one that appeared in "Rainbow News", September, 1988. The utilities AUTO.CMD, DU.COM, and BOOT.CMD which Mr. Olson mentions are available from our own VARUG library as well as from the WARUG [Washington Area Rainbow Users Group] library.) One function which users of MS-DOS are afforded is the ability to run a batch job at system boot time. The file used for this is called AUTOEXEC.BAT. I am sure that if you have used DOS at all, you have encountered such a file. It can contain things such as directory path specifications, system buffer set-ups, device set-ups, and prompt specifications. It is found in the root directory of the system disk. Each time the system is booted under DOS, the AUTOEXEC.BAT file is run in batch mode before the user is presented with the system prompt. Unfortunately, CP/M does not have this type of functionality, at least it is not readily obtainable. CP/M users can get around this problem with a slight variation. At system boot time, one thing the loader does is move the file CPM.SYS into memory. This file, you may remember, contains the base page information as well as the code for the CCP (Console Command Processor), the BDOS (Basic Disk Operating System), and the BIOS (Basic I/O System). One thing contained within the base page, an area reserved in memory for system data structures, is the Direct Memory Access buffer, otherwise known as the DMA buffer. The DMA buffer is used by the system as a temporary storage area for keyboard input as well as disk I/O operations. Each command entered from the keyboard at a system-level prompt is placed into the DMA buffer for processing. Once a carriage return is pressed, the system parses this information, looking for a command, such as 'TYPE', 'PIP', and so on, and any command tail information. All we need to do to autoload a command is to place the command into the DMA area within the CPM.SYS file. When CPM.SYS is loaded into memory at boot time, a command will already be in the DMA buffer and the system will automatically execute it. Adding Autoload Commands ------------------------ Adding a command to CPM.SYS is actually easier than you might think. There are a few different utilities you can use to add the command information to the CPM.SYS file. These include DDT86, DU, AUTO, and AUTOEXE. DDT86 is supplied with the CP/M distribution. If your current system disk does not contain DDT86.CMD, look for it on your distribution disk copy. The next two utilities which I mentioned are available from the WARUG library (DU.COM and AUTO.CMD are both contained in volume 3). For the sake of this example, I will discuss modifying CPM.SYS with DDT86. As described in one of my previous articles, the DMA buffer is formatted as shown in Figure 1. If you are familiar with Turbo Pascal, the DMA buffer has the same ----------------------------------------------------------------------------------- | offset 0080 hex | | +----+----+----+----+----+-> >--+----+----+----+ | | | | | | | | > > | | | | | | +----+----+----+----+----+-> >--+----+----+----+ | | byte 0 1 2 3 4 125 126 127 | | ^ ^ ^ | | | +- These bytes contain the command and its tail. | | | | | +--------Contains the total length of the command and command tail. | | | ----------------------------------------------------------------------------------- Figure 1. The DMA buffer format format which a variable of type STRING[127] has, that is, it is 128 bytes long, with the first byte containing the length of the string the variable contains. In our case, the first byte of the DMA buffer contains the length of the command and any optional command tail. The remaining 127 bytes contain the command and command tail as entered at the keyboard. In memory, the location of the DMA buffer within the base page is 0080 hex (128 decimal), with the text of the command beginning at 0081 hex. In the CPM.SYS file, the DMA buffer begins at position 008A hex offset from the beginning of the file, with the command and command tail characters beginning at position 008B hex. Therefore, the positions we want to modify begin at position 008A hex offset from the beginning of the CPM.SYS file. Because everyone has a copy of DDT86 on the distribution diskette, I will use it in the example which follows. DU.CMD basically has a superset of the functionality of DDT86, and has documentation on WARUG volume 3. AUTO uses a single command line to insert a command into CPM.SYS. Unfortunately, it will only allow a single word to be inserted, not a command with a command tail. AUTOEXE.CMD is a menu-driven program and its operation is rather obvious. I will not discuss it further other than to mention that the copy which I used did not place the length of the command in position 008A. Instead, it placed a letter 'P' in that position for unknown reasons. This caused the SUBMIT command which it inserted not to work properly. I had to change the value at 008A via DDT86 to be the length of the command. Otherwise, AUTOEXE functions as expected. The first step in performing the modification is to create a copy of your distribution diskette or the diskette which you are currently using as your system diskette. If you are using a hard disk, create a copy of CPM.SYS on a floppy. Once the modifications are made and verified, you can copy CPM.SYS to your working diskette or hard drive. Be sure to copy the CPM.SYS file and the .CMD or .COM file which will be invoked at boot time, if a transient command is being used. Also, make the CPM.SYS file writable. Otherwise, you will receive an error when you attempt to write the modified version of the file back to disk. This can be done by the MAINT utility. If you want to invoke an eight-bit program, you will also have to copy the Z80CNF.SYS file to your test diskette. The other thing you should have is an ASCII character set table which lists the character codes in hexadecimal format. DDT86 requires hex values when modifying bytes within a file. For example, the letter 'L' is represented as '4C' in hex format code. If you are able to convert from octal or decimal, any ASCII chart will do. For the first example, assume we want to obtain a directory listing of the non-system files on the system disk immediately upon booting. The 'DIR' built-in command performs this function. Also assume the copy of CPM.SYS to be modified is located on the diskette in drive B:. The first step is to determine the hexadecimal equivalents of the letters 'D', 'I', and 'R'. Referring to our ASCII table, we determine the hex values for the letters to be 44 for 'D', 49 for 'I', and 52 for 'R'. To flag the end of the command for the autoloading procedure, we must place a null (00 hex) at the end of the command. We must also enter the length of the command in the first byte of the DMA area. The length is four, the letters 'D', 'I', and 'R', and the null. (Editor's note: For the length of the command, I have entered various numbers from 01 through 0F hex--that is, 15--into the first byte of the DMA area and noticed no problems. Apparently, CP/M allows much leeway in the entry at location 008A.) Now we are ready to modify CPM.SYS by using DDT86. In the examples that follow, all user entries are underscored. Example 1 shows the first step in performing the modification; DDT86 is invoked and CPM.SYS read into memory by the read file 'R' command entered after the DDT86 hyphen (-) prompt. In the example, the file name 'B:CPM.SYS' immediately follows the 'R' command. ----------------------------------------------------------------------------------- |E>DDT86 | | ----- | |DDT86 1.1 | |-RB:CPM.SYS | | ---------- | | START END | |3AFD:0000 3AFD:5C7F | ----------------------------------------------------------------------------------- Example 1. Reading the CPM.SYS file Once the file is read into memory, DDT86 reports the beginning and ending memory positions of the file. The number following the colon is the offset value in hex format. Thus the CPM.SYS file was loaded into memory segment 3AFD and occupied positions 0000 through 5C7F within that segment. If all this is gibberish to you, don't worry. If you follow the examples, you shouldn't have any problems modifying your own copies of CPM.SYS. Just remember that your segment number will be different from those shown in the examples. (This is because I used Concurrent CP/M to obtain the screens. Concurrent CP/M uses a memory allocation scheme different from CP/M-86/80's.) The next step is to dump the contents of the memory locations. This is done via the dump command 'D'. Example 2 shows the contents of the memory locations. Because we are interested only in positions after 0080, the dump command issued is for positions 0080 through 010F. DDT86 displays three groups of information. The first group, on the far left, indicates the beginning memory position of the first 16 bytes of information displayed on the line. The second group, the double characters, are the hex representations of the 16 bytes of memory contents. The third group, located on the far right, is the ASCII equivalent of the hex values. Notice that for values falling outside the printable ASCII character range, DDT86 uses a period to represent the value. As can be seen in the example, the memory contents at positions 009B through 00BF contain the copyright notice. If the ----------------------------------------------------------------------------------- |-D0080,010F | | --------- | |3AFD:0080 E9 2A 03 E9 21 03 E9 02 03 7F 00 20 20 20 20 20 .*..!...... | | -- | |3AFD:0090 20 20 20 20 20 20 20 20 20 20 20 43 4F 50 59 52 COPYR | |3AFD:00A0 49 47 48 54 20 28 43 29 20 31 39 38 30 2C 20 44 IGHT (C) 1980, D | |3AFD:00B0 49 47 49 54 41 4C 20 52 45 53 45 41 52 53 58 20 IGITAL RESEARCH | |3AFD:00C0 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... | |3AFD:00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ | |3AFD:00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ | |3AFD:00F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ | |3AFD:0100 00 00 00 00 00 00 00 00 00 00 00 CD E0 8C CD 8E ................ | ----------------------------------------------------------------------------------- Example 2. Dumping the contents of the memory locations command to be autoloaded is long, the copyright notice will be overwritten. Don't worry about it. So if the copyright notice is located in the DMA buffer area, why doesn't CP/M attempt to run it as a command upon booting? If you look closely at the dump in Example 2, you will notice two zeros underscored in the line beginning with 3AFD:0080. The underscore will not appear in your own dump. I just put it there for emphasis. This 00 hex value is located at position 008A. (if you count positions to the right beginning from the E9 in the example, and use 'A' for 10, 'B' for 11 through 'F' for 1, the 00 is located at position 008A.) This indicates to CP/M that the length of the command in the DMA buffer is zero, and therefore, CP/M ignores everything contained in the DMA buffer. This value will be reset when the modifications are made. Example 3 shows how the set memory command 'S' is used to modify memory locations. This is the command which is used to insert the hex values of the characters of the commands we want to autoload. ----------------------------------------------------------------------------------- |-S008A | | ----- | |3AFD:008A 00 04 {This is the length of our command.} | | -- | |3AFD:008B 20 44 {This is the hex value of the character 'D'.} | | -- | |3AFD:008C 20 49 {This is the hex value of the character 'I'.} | | -- | |3AFD:008D 20 52 {This is the hex value of the character 'R'.} | | -- | |3AFD:008E 20 00 {This is the hex value of the null character.} | | -- | |3AFD:008F 20 . {This is an invalid hex code to terminate input.} | | - | |-D0080,00AF | | ---------- | |3AFD:0080 E9 2A 03 E9 21 03 E9 02 03 7F 04 44 49 52 00 20 .*..!......DIR. | | -- -- -- -- -- ---- | |3AFD:0090 20 20 20 20 20 20 20 20 20 20 20 43 4F 50 59 52 COPYR | |3AFD:00A0 49 47 48 54 20 28 43 29 20 31 39 38 30 2C 20 44 IGHT (C) 1980, D | |-WB:CPM.SYS | | ---------- | |-^C | | -- | |E> | ----------------------------------------------------------------------------------- Example 3. Modifying the memory contents and writing the file back to disk The CP/M-86 Programmer's Guide, which contains the description of DDT86, states -------------------------- that the 'S' command should be followed by the memory location of the first byte to be modified. In our case, the first memory location to be modified is 008A, the command length byte of the DMA buffer. As can be seen in the example, this memory position immediately follows the 'S' command. DDT86 then presents the memory location followed by the current position's byte value in the hex format. After DDT86 presents this information, it expects one of three things to be input: 1) a carriage return indicating no change; 2) a hex value followed by a carriage return indicating the new value for the memory position; or 3) an invalid hex value followed by a carriage return indicating the termination of the 'S' command. In the listing shown in Example 2, I have underscored the input values. Each value is followed by a <Return>. I have also commented the example to indicate what is being input. For your purposes, the input will not be underscored. Also, do not attempt to put in the comments. To double check the work, the dump command 'D' was used again, this time dumping memory locations 0080 through 009F. As can be seen, the new byte values have been inserted. I have underscored the modified positions in the example. Both the hex values and their ASCII representations are marked. With the modifications now complete, the only task left is to write the modified CPM.SYS back to disk. The write command under DDT86 is 'W' followed by the file specification. Memory contents between the start and end locations are written to the file. We'll replace the CPM.SYS file in drive B:. A <Ctrl> <C> returns control to the CCP, the 'E>' prompt is issued; the DDT86 session ends. Now that the modifications are complete, the only remaining task is to reboot the system to verify the modifications. Once the changes are proven to operate as expected, copy the new version of CPM.SYS to the system disk. If you are running a floppy-based system, you can customize the various versions of CPM.SYS for each system application floppy. An Example--Autobooting A 100A From The Hard Drive -------------------------------------------------- All this is fine and good, but does it have a real application? If you have a 100A with a hard drive, it sure does. One advantage of owning a 100B system is that it allows the user to boot directly from the hard drive partitions. In addition, 100B users can specify an autoboot partition to be used at system power-up time. Because this is a firmware function, users of 100A systems do not have this option. By using the command autoloading capability of CP/M, 100A users can simulate the 100B functionality. Volume 41 of the WARUG library contains a DEC-written utility called 'BOOT'. BOOT allows a user to boot the system from any hard disk partition which has had the loader information copied to it. The utility LDCOPY included with the CP/M-86/80 distribution is used to copy the information contained on the load tracks of one disk to the load tracks of another disk. Once this information is copied to the load or boot tracks of the hard drive partition, a floppy can be created to boot the system from the hard drive. The only other information which needs to be copied to the floppy are the CPM.SYS and BOOT.CMD files. The CPM.SYS file will be used for the initial boot. The BOOT.CMD file is needed as it will be executed during the initial boot autoload operation. To do this, follow the examples above to insert the 'BOOT' command into the DMA area of the CPM.SYS file located on the floppy. Use the help information provided by BOOT to determine the proper command tail for the BOOT command. You can list this information by running BOOT and pressing the <Help> key. Each time you boot the system from the floppy, the system will reboot itself from the specified hard drive. This way, you will no longer be tied to the floppy drive to perform your work. My use of floppies has become quite limited since I set up a floppy to perform the system reboot. AUTO.CMD is also included on Volume 41, so if you do not wish to use DDT86 to patch CPM.SYS, AUTO is readily available. AUTOEXE.CMD is available on many of the Rainbow-oriented Fido BBS systems. I will add it to the WARUG library soon. Summary ------- True AUTOEXEC.BAT functionality can be obtained by inserting the 'SUBMIT' command into the DMA area of the CPM.SYS file. SUBMIT will parse a .SUB file and execute the commands which the .SUB file contains before placing you at the system prompt. This is directly analogous to the MS-DOS capability. With the information provided in this article, you should be able to create your own custom applications system disks. I have found the autoloading capability of CP/M to be quite useful in my activities. I am sure you will find it useful in yours. ----------------------------------------------------------------------------------- What Is Available (This section provides information on products likely to interest users of personal computers. Information presented here is based on that given by suppliers, with some editorial comments.) PRO-C: The C Source Code Applications Generator ------------------------------------------------ Vestronix Incorporated's PRO-C is designed to automate the generation of C-language source code. For example, if you wish to create a pop-up window in a C application program, PRO-C will allow you to paint the window on the screen, and will generate the C source code for the programmer. PRO-C works with C compilers, not entirely on its own. PRO-C requires MS-DOS 3 or later, 640 000 characters of random access memory, and 3.5 million characters of hard disk space. A VMS version has been introduced recently. Also needed is a compatible C compiler. Microsoft C, Turbo C, Lattice C, Watcom C, and Zortech C are all acceptable. A demonstration version of PRO-C was supplied to this newsletter. The demo ran on a Rainbow 100B equipped with a hard disk, over 917 000 characters of memory, MS-DOS 3.10b, and Code Blue 2.01 patched to take advantage of the operating system. Code Blue's '/V' option was needed. Some 600 000 characters of hard disk space were used up by the program. PRO-C provides an interactive menu-driven environment for developing C programs. Some 500 000 characters of context-sensitive help is available at the press of a key. Generated code is available for inspection and includes comments. Debugging (getting rid of errors) is largely eliminated. PRO-C uses prompts in plain English. PRO-C can generate accounting systems, payroll programs, sale and order processing software, tax computations, and stock control programs. PRO-C can create data files compatible with dBASE III, ORACLE, C-ISAM, and C-TREE. PRO-C comes with two file managers, PRO-TREE and Btrieve 5.0. PRO-TREE's source code is included. Vestronix has recently offered PRO-C Work Bench, the C source code libraries for customizing applications, at no extra cost. From the PRO-C main menu, the user can go to any of six modules: Data definition, menus, screens, reports, batches, and the compilation and testing module. The data definition module allows defining each field in the data file. Each definition is stored in a template file. PRO-C requires a primary key for each data file, and also supports alternate duplicate and alternate unique keys. Each file may have up to 64 keys. Available data types include any characters, alphabetic, alphanumeric, floating point, double precision floating point, short integer, long integer, and date. Cross references between files are permitted. The menu module lets you create menus in your application. You can define the prompt that will appear on the screen and the associated action, which may involve running an independent program not necessarily created by PRO-C. You can specify hot keys--keys that a user can press to call up an option or menu quickly. You can also specify what happens when an exit is made from a menu. A menu painter allows controlling the appearance of the menu. Work in the menu module is stored in two files, one which contains the relationships between prompts and action, and one which stores the appearances of the menus. The screen module allows creating screen programs related to the data. You can create conditional expressions with the operators '(', ')', '+', '-', '*', or '/'. String and numeric constants, all fields in the template file, and all fields in cross-referenced files are available. You can filter data through validation routines or create computed fields; set a field to a constant value; move a value from another field, including computed fields and fields from cross-referenced files; or auto-increment a field. You can use a screen painter to design the appearance of the screen. If you want a sub-screen, you just draw it in a box. The report module permits generating programs for mailing labels, form letters, columnar reports, or page reports. Each report is based on the template file. You can define mathematical calculations and computed fields for reports. A screen painter permits designing the appearance of the report entry screen. If you wish, you can include a C-language routine written outside PRO-C. The batch processing module allows manipulating all related records in the system. A primary data file controls the process. Four options are available: Inputting information without changing it, updating information, appending records, and creating a new data file. You can impose conditions for the choice of records to be processed, move information between records, set fields to constants, or delete records. A final module allows compiling the files generated by other modules, edit with the user's favorite text editor, or run a compiled program as a test. On systems that have Intel 80x86 chips, PRO-C uses the large memory model for compiling, but the user can change this feature. For more information, contact Vestronix Allen Square 180 King St. S. Suite 550 Waterloo, Ontario, Canada Telephone (519) 745-2700 (800) 265-2682 (toll free) Fax (519) 745-3660 DECstation 210/316/320 Personal Computers ----------------------------------------- The DECstation 200 and 300 personal computers from Digital Equipment Corporation are industry-standard machines based on the Intel 80286 or 80386 microprocessor. The three machines are compatible with the IBM PC, use MS-DOS 3.3, and can be integrated into a Digital network. The DECstation 210 uses a 10-MHz 80286 microprocessor; has a built-in 3.5-inch, 1.44-megabyte disk drive; has 640 000 characters of random access memory; and has four front-panel device slots for floppy disks, hard disks, or tape cartridges. There are five 16-bit and two 8-bit industry-standard expansion slots, a dedicated 16-bit memory expansion slot, a keyboard and chassis lock, and a 101-key industry- standard keyboard. The DECstation 316 and 320 use the Intel 80386 microprocessor with a 32-bit data path. The model 316 has a 16-MHz clock, while the 320 runs at 20 MHz. Each machine has a 3.5-inch 1.44-megabyte floppy disk drive, six AT option slots and two XT-style option slots, and a dedicated 32-bit memory expansion slot. Each has room for two more 5.25-inch front panel devices. The 316 has a million characters of random access memory standard; the 320 has two million. Either computer can have up to 16 million characters of RAM. Any of the three computers comes with a vector graphics adapter (VGA), a 9-pin RS-232C serial port, and a parallel printer port. Any of the machines can use Digital's Ethernet controller and personal computer integration package for networking. Any of the three machines can be purchased with a small computer systems (SCSI) interface; a 40-, 80-, or 170-megabyte hard disk; or a 150-megabyte SCSI tape cartridge system that uses quarter-inch tape. 80286 and 80386 mathematical coprocessors are available. Fourteen-inch monochrome and color red-green-blue (RGB) monitors are available. The RGB monitor displays 320 by 200 picture elements (pixels) with 256 colors, or 640 by 480 pixels with 16 colors. Both monitors are compatible with a VGA. A serial-parallel adapter allows adding a second printer or communications port. For more information, contact your Digital dealer. ----------------------------------------------------------------------------------- Questions And Answers Do you have a computer-related problem? Send it to us. We can publish it, and if we do not know a solution, perhaps someone else in the users group can provide one. QUESTION: A Rainbow has a serial printer port. Which serial printers will work with a Rainbow? ANSWER: A Rainbow will work with any serial printer that uses XON-XOFF or ready- busy protocol. That covers any serial printer we know of; if any reader knows of an exception, we would like to hear about it. A Rainbow uses XON-XOFF protocol by default. To enable ready-busy control, just run the SETPORT utility (provided with recent versions of MS-DOS and available free for CP/M) and enable the data terminal ready signal. There are, of course, details to arrange. You must have a suitable cable to connect the computer and printer--and serial connections are notoriously variable. Then you must set the transmission rate (the "baud" rate), the parity, and the number of data bits so that the computer and printer agree. You can use the Rainbow's set-up mode or SETPORT for these characteristics. You will likely have to set so-called DIP switches on the printer. Finally, you must have your software agree with the printer's codes. You may need a special driver, for example, to make your favorite word processor print as you wish on the printer. By the way: If you get a serial-to-parallel interface, you can use a Rainbow with a printer that has a parallel port. Depending on the design of the interface, you may still have to run SETPORT to enable ready-busy protocol. QUESTION: Is there a shareware or public domain spreadsheet which is compatible with Lotus 1-2-3? On what machines will it run? ANSWER: The shareware AS EASY AS spreadsheet is similar to Lotus 1-2-3 and saves its data files in a compatible format. Versions 3.01 and later of AS EASY AS are compatible with version 2 of Lotus 1-2-3, and allow three-dimensional spreadsheets. Version 4 claims to permit linking the current spreadsheet with others on disk. The VARUG library has versions 3.0 and 3.01. AS EASY AS will run on MS-DOS machines compatible with the IBM PC. Rainbows equipped with Code Blue 1 and enough memory for that program's '/V' option can run AS EASY AS 3.0 or 3.01, but without graphics. We have seen version 4 running on a Rainbow that had 852 000 characters of random access memory, MS-DOS 3.10b, and Code Blue version 2.01 (with its '/V' option) modified to take advantage of that operating system. QUESTION: Which archiving utility produces the smallest archives? Should I use LHARC, PAK, or PKZIP? ANSWER: The results vary depending upon the files being archived. We have usually found that LHARC compresses binary-coded files (.COM or .EXE files, for example) the most, while PKZIP compresses medium-sized to large text files the most. However, there are exceptions, so do not be surprised if you see PAK compressing .COM files more than either of its competitors. On one occasion, we compressed a group of small text files the most by putting them uncompressed into a .LBR file and then applying the CP/M-80 utility CRLZH.COM to the .LBR file. As for which compression utility you should use, that may depend on other factors besides the amount of compression produced. If you are passing compressed files to another party, that party must be able to decompress your files, so you may be required to use a particular utility. Some bulletin boards standardize on one compression format. For example, Computing Canada On-Line uses PAK archives, while a Chilliwack board specializes in LHARC's .LZH files. Another consideration is the time taken by the compression utility. PKZIP is noticeably faster than PAK and still faster than LHARC, so if you have much archiving to do, you may prefer PKZIP. On the other hand, PAK is compatible with older .ARC files; if you have many of them, PAK may be your archiver of choice. Finally, LHARC is not shareware, but free (the VARUG library has the source code). If you deal with an organization which insists on public domain software, LHARC may become your favorite. Still more: There are CP/M-80 de-archivers for dealing with PKZIP and LHARC archives, but (as far as we know) none for handling PAK's crushing and distilling techniques (but PAK can also use crunching and squashing, and CP/M's UNARC is compatible with those). If all this bewilders you, be assured that many other people feel as you do! QUESTION: Does PC-FILE allow mathematical calculations? If so, how? ANSWER: PC-FILE permits calculations in special calculation records and also as parts of reports. The documentation gives details. QUESTION: What is shadow RAM? ANSWER: Shadow RAM is random access memory into which routines are loaded from read-only memory (ROM). Having these routines in shadow RAM is supposed to provide quicker access to them. QUESTION: Can I send a file to the printer during an SEDT editing session without leaving SEDT? ANSWER: Recent versions of SEDT have a ':PR' command for just that. This command may or may not be incorporated in a key definition file. Your editor's custom key definition file uses <Gold> <Ctrl> <P> to send a file directly to the printer without leaving SEDT. Note, however, that if you use a Rainbow 100A with MS-DOS 2.05 or later, SEDT 3.3 and later is overly sensitive to incoming signals. Turning a printer or modem on or off while SEDT is loaded causes the computer to reset itself, or to stop functioning until the user turns it off. If you try to print and the printer sends an XOFF or busy signal when its buffer fills, you will get a similar crash. This problem seems to be absent on a 100A under MS-DOS 2.01, and also absent on a 100B under any version of MS-DOS, as well as on other MS-DOS machines we have tried. If you use SEDT on a 100A under (say) MS-DOS 2.11, we suggest you save your file to disk first, leave SEDT, and then copy the file to the printer. ----------------------------------------------------------------------------------- Buy, Sell, Or Swap This section is presented as a service to members. There is no charge for advertizements placed here, though donations will be accepted. Only items related to computing will be advertized; if you wish to sell an old car, we respectfully suggest that you publicize elsewhere. Advertizements are not accepted from suppliers. In accordance with DECUS policy on commercialism, we do not print prices. Ads should preferably be submitted to the editor in writing or as ASCII computer files, but may also be phoned in. ---------------------------------- FOR SALE: VAX 11/730 unlimited user with MicroVAX II as end node Rainbow 100Bs with keyboards, monochrome or color monitors, 10 megabyte hard disks, and 256 k or more of RAM DEC Rainbow version of dBASE III version 1.0, unopened Contact Charles Haynes at (604) 985-6125 during business hours. FOR SALE: Poly-XFR CP/M communications software for Rainbow 100; CP/M-86/80 operating system version 2.0. Both software items are in the original packages and have documentation included. One AC fan for a Rainbow 100A (also fits many other computers). 7.6 cm (3 inch) adding machine rolls. Three 65 536-character DRAM (memory) chips. These items are just taking up space now, so all offers will be considered. Telephone David P. Maroun at (604) 792-4071. WANTED: The manual for version 1.5 of the WPS-80 word processor. Any information about the communications sub-menu would be welcome. Telephone Doug Nicol at (604) 792-0025. FOR SALE: Peachtree business modules for MS-DOS: PeachCalc spreadsheet, general ledger, accounts payable, accounts receivable, personal calendar, job cost system, and inventory control. Any offer will be seriously considered. Note: These modules require Code Blue and maximum memory to run on Rainbows. Contact David P. Maroun at (604) 792-4071. FOR SALE: One 192 k memory expansion board for a DEC Rainbow. Contact Ken Alger at (604) 390-4482. FOR SALE: One 3-high and one 4-high cabinet (suitable for Ra81s) with power distribution. Numerous Qume and VT102 terminals. Contact Marcus Schack at Vancouver Wharves, telephone (604) 985-3177. ----------------------------------------------------------------------------------- What Do You Think Of This Issue? Please tell us what you liked and did not like. The best articles were:__________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ The worst articles were:_________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ Comments or suggestions: Send your opinions to The Editor, VARUG Newsletter, 9395 Windsor Street, Chilliwack, BC, Canada V2P 6C5.