CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 33

CFOG On the Move to Skokie Public Library

by Benjamin H. Cohen

CFOG has a new home, at least for the Summer of 1988. My wife spotted a local newspaper story noting that the Skokie Public Library will be open on Sundays this summer: a new policy. When I called they advised that they were not taking on new groups on a regular basis, but on the other hand, they were getting two new IBM clones to augment their two Apples and had just started talking about a user group. So, we'll be the guests of the Skokie Public Library, 5250 Oakton Street, Skokie for our June, July, and August meetings.

The dates are June 26, July 31, and August 28, the last Sunday in each month. The meeting room on the second floor holds up to 75 people, so it's more than adequate for our current needs.

The Skokie Public Library is readily accessible from the Edens Expressway, by exiting at Dempster Street southbound, or Touhy northbound. From Dempster, go east to Gross Point Road and turn right. Almost immediately, you'll turn left (sort of!) to head south on Laramie one mile to Oakton Street. The library parking lot is straight ahead across Oakton.

The Touhy exit ramps are under repairs this summer; part of the time you won't be able to get off eastbound and part of the time you won't be able to get off westbound. It doesn't matter: take the one that is open. If you've gone east on Touhy, take Cicero Avenue north to Lincoln Avenue. Bear left on Lincoln. You will get to a stop sign before long where Lincoln intersects with Niles Center Road. Lincoln goes right, along with Niles Center Road. You go straight ahead on Galitz. Turn right into the library parking lot about half a block ahead.

If you have gone west on Touhy, go to Niles Center Road, about half a mile, and turn right. On Niles Center Road you'll get to that stop sign at the intersection with Lincoln Avenue. Turn left on Galitz and then right into the library parking lot.

The meeting room space is reserved for us from 1 to 5 p.m., the only hours that the Library is open on Sunday.

If the arrangements are satisfactory to us and the Library, there's a chance that we'll be invited to meet in Skokie every month on a regular basis.

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 36

A Bit of History

by David S. Tilton

[Reprinted from the Letters to the Editor column of the November 1987 Dr. Dobb's Journal of Software Tools.]

In the December 1986 Letters column was a letter from a Mr. Hawkins in which he was complaining among other things about the terseness of the C language. He attributed this "propensity for the least possible typing" to the authors of the language being two fingered typists. More likely it was what they were typing on that inspired them to opt for the least possible typing. C is an older language than many realize since although it was born in the early 1970s along with Unix, it did not escape its birthplace, the Bell Laboratories, until around 1980. The standard terminal in use back in the early seventies was the Teletype machine. In many operating systems from CP/M to Unix the abbreviation TTY, used for things related to the terminals, makes sense only if it is realized that the terminals were originally Teletype machines.

The Teletype machine was an electromechanical device, not an electronic device, and was therefore very slow by today's standards. Typically it operated at 110 baud or ten characters per second. Furthermore, after a key was struck you had to wait a full tenth of a second before striking the next key or it would be ignored. Since most people, especially when thinking at the keyboard, tend to type unevenly, the average typing speed was often much less than ten characters per second.

In spite of their slowness the Teletype machines were the most practical terminals for multiuser systems (then called time sharing systems) and for small computers. The electronic terminals using a CRT were at that time dumb terminals and very expensive. Furthermore, if hard copy was desired it was necessary to buy a printer which would cost almost as much as a full Teletype terminal. The wide-spread use of Teletype machines as terminals left its mark on computer standards in many ways besides the TTY abbreviation. The most important is probably the ASCII code. This was developed for the Teletype machines and then adopted by computers when the Teletype machines were adopted as terminals.

Many computerists are puzzled by the fact that all of the control codes except DEL are at the beginning of the codes while DEL is at the very end. The old name for DEL, RUBOUT, gives a clue to this mystery. Because it was very difficult to type at a rate anywhere near the maximum of ten characters per second on the Teletype machines, most teletypes were equipped with a paper tape punch and reader. The message was punched into paper tape off line and then transmitted at the maximum rate by the tape reader on line to save expensive on line time. But suppose you made a mistake and hit the wrong key near the end of punching a long tape. Once a key was struck there was no way to un-punch the holes in the tape and it would be very frustrating to have to do the whole tape over again. Instead the tape was manually backed up to the error and the error overpunched with the RUBOUT code which punched all the hole positions. The receiving Teletype was set to ignore RUBOUT codes so that errors simply didn't print.

The paper tape units came in at least two versions, the 7-bit and the 8-bit types. The 7-bit type was common for most communications uses but for computers and for communication channels with a parity bit the 8-bit units were used. With computers paper tapes were used for off line storage and for distributing software. For computer use at the computer high speed paper tape punches and readers were developed and became so common that CP/M had input/output channels reserved for them. Many of the earlier and less expensive Teletype machines were upper case only and this is one of the reasons that BASIC as developed at Dartmouth College would work with all upper case. Apparently the Bell Labs could afford the more expensive Teletypes with the full character set and both C and Unix are case sensitive although Unix has a provision for translating upper case to lower case for upper case only terminals and both tend to use mostly lower case. Some Teletypes could transmit either case although they printed upper case only, translating lower case to upper case when receiving. Note that all of the older text editors such as ed on the Unix system are line editors and that only the newer editors such as vi are fullscreen editors. That is because with the Teletypes as terminals there was no screen.

This is not the first case where decisions made in the past for valid reasons persist in standards long after the reasons for making those decisions no longer apply. After all the gauge of modern railroads was set by decree of an ancient Roman emperor and the layout of the standard typewriter keyboard was made to discourage fast typing and thus avoid key pileups. After a standard has been in use for a while there are many things around embodying that standard that would be obsolete if the standard were changed so old standards linger long after they are obeolete.

Incidentally the slow Teletype machines hooked to a timesharing system seemed like a big advance to programmers who previously had to punch their programs on a card punch and submit them for batch processing every time they wanted to try something. Then they would wait hours or even days for the results which might be only a cryptic error message. Think how that would affect your debugging procedures.

David S. Tilton

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 37

VDE Updated Again

VDKCOM: A Function Key Compiler for VDE

by Benjamin H. Cohen

A few weeks after the March 28 issue of PIP was mailed out one of my friends dropped by and asked whether, as long as he was here, he could get a copy of VDE Version 2.64. I told him that I regretted that it was not possible: I had already discarded it in favor of VDE Version 2.65. Groan!

I've stolen the following from the VDE265.UPD file, with a few revisions.

VDE Version 2.65 Update

The problem with command prompts on some computers has been fixed. As this was the principal reason for the new release, there are only a few changes from Version 2.64.

A new command [CTRL]OA sets Auto Indent mode, useful for typing outlines, structured program source code, etc. When on, you will see an "AI" flag in the header. When you press [RETURN]:

(a)
If text exists on the new line, the cursor advances to it;

(b)
If you are adding new text, it is indented to match the previous line.

The Variable Tab set/clear commands ([CTRL]OI,N) now prompt for a column, just like the margin sets. Hit [RETURN] for the current column.

In addition, the Set command [CTRL]OI accepts two options. Both options wipe out any existing tabs. First, "@nn" sets tabs every "nn" columns, so if you want tabs at 5, 10, etc., all the way across, just enter [CTRL]OI@5[RETURN]. To clear all tabs, enter @[RETURN] at the prompt.

The second option allows you to set a number of tab stops with one [CTRL]OI command. Just enter a number symbol [#] before the number of the column where you want each tab stop and use commmas to separate the settings. For example, after you enter [CTRL]OI, enter #6,#11,#16,#31,#61[RETURN] and you'll have tabs at 6, 11, 16, 31. and 61.

A new command [ESC][TAB] moves backwards (left) to the previous tab stop, whether in hard or variable mode. This can be useful for moving about in tables, etc.

In VINSTALL there is a User Option allowing you to DISABLE the help menus. If you do this you will have about 1K more free RAM for editing. There is a User Option to set initial header display to off if you prefer it that way. You can still toggle it on with [CTRL]OQ.

DOSDISK users will be delighted to know that there is no longer a need for an option disabling warm boot trapping. VDE now works nicely with DOSDISK.

VDKCOM: A Compiler for VDE Function Key Macros

You may recall that one of the items on my 'wish list' in the March 28 issue was the alility to create VDE function key macros in an ASCII file and then 'compile' them into VDE. This would eliminate the need to laboriously enter each new function key through VINST, especially when it came to complicated macros. Retyping a 100+ character macro time an again while debugging it can get tedious. Or what if you discover you just left out one character in a 100+ byte simple macro (your firm name, address, etc., all centered) for the THIRD time! Ouch.

Well, Fred Haines, sysop of the Glendale LADERA RCPM, had read my wish list in a message to Eric Meyer (and added one of his own, which you may recall from the March 28 issue of PIP). Fred and I exchanged messages on the subject and about ten days later I had the first Beta test version of what Fred calls VDKCOM. While it might be simpler and more direct if Eric Meyer had worked this into VINST, VDKCOM does the trick, and I've written a small SUBMIT file that makes the process as smooth as glass.

VDKCOM works two ways. First, if you already have your definitions installed in VDE, VINST will put them into a VDK file. VDKCOM will convert your VDK file to a VDT file which is an ASCII file that you can edit with VDE. If you haven't already put your function key macros into VDE with VINST, don't: just create an ASCII file (using VDE's ASCII or non-doc mode) and have VDKCOM 'compile' it into a VDK file which can then be loaded into VDE with VINST.

I've automated the process with the following SUBMIT file:

vde benz.vdt a
vdkcom benz.vdt
vinst vde.com benz.vdk

When you run this your VDT file is loaded with VDE, you can edit it as necessary. When you save and exit from VDE, it is then quickly [VERY quickly] compiled, and loaded onto VDE with VINST. All you have to do is hit "S" to save, and your new copy of VDE is ready to use.

If you want to have several VDT/VDK files, substitute $1 for "benz" and you can add the name of the file on the command line. This process is very quick.

Thanks to Fred Haines for this great new addition to the VDE arsenal of tools. Fred has also incorporated into the VDKCOM library his favorite macros for VDE, so even if you haven't begun to experiment you'll have something to work with.

The latest version is VDKCOM12.LBR [as of May 6, 1988]. Version 1.1 works the same but is slower. Version 1.0 has a bug or two.

When Did I Miss This One?

VDE's [CTRL-O]W command creates a window in the lower half of the screen containing half-a-screenload of text, freezing the text starting at the cursor location while you continue to edit normally in the top half of the screen. Although the documentation always mentioned it, it never occured to me that you could freeze text from one file in the lower half of the screen and then load another file and edit it while the frozen text from the first file was still on display in the window.

Somehow I just missed that one. What brought it to my attention is that when I opened a window in Version 2.65 I discovered that the line between the top and bottom halves of the screen now shows the name of the file that contains the text frozen in the bottom half of the screen. That made it clear that it was possible to load a new file while still retaining the frozen bottom half of the screen. Expect the unexpected in nice little touches from Eric Meyer: this one's not a documented change.

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 38

Reformatting with VDE and Indented Margins

by Eric Meyer

[Sometimes I use VDE with indented margins. This is common for quotations in legal briefs and other documents. There's a minor problem. Eric Meyer explains the problem and how VDE tries to cope with it in a message left on the CFOG II RCPM. -- bhc]

Reformatting with left margin [other than 1] will sometimes catch you offguard because VDE has to guess at the indentation. The rule is simple, but often forgotten if the line where you press [CTRL]B is indented relative to the following line, that difference is assumed to be the paragraph indentation, and except for that everything formats to the new left margin. So if the current line begins in column 10 and the next line begins in column 5 and you set the margin at 20 and reformat, you'll still have a 5-character indent from the margin at 20. Clear as mud?

[Conclusion: VDE works fine when you simply change indented margins and reformat, but will give you unintended results when you edit an indented paragraph and reformat. To prevent this, you need to delete the existing offset. -- bhc]

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 39

DOS DOINGS

by Steve Lucius

Does software bloom more in the Spring? Several major software vendors have announced updates of their products. Ashton Tate has announced dBase IV with full SQL support, which should put them back into the competition as a leading edge data base vendor. Micropro has announced Wordstar 5 for DOS with a May ship date, however if you call to order it they say not until July. Wordperfect is expected anytime (scheduled release was April) to release version 5.0 of their word processing package. Lotus on the other hand used Spring as a time to announce that their planned release of Lotus 3 had been postponed for 6 months.

AST has released a new driver for their EEMS products such as the Six Pack Premium and Rampage. They also released a new driver for the clock in the Six Pack products. There was no documentation on their board for the clock, however the EEMS driver now allows AST products to support the new LIM 4 standard for expanded memory announced by Intel. The driver can be obtained for $10 by calling the AST tech support number (714-553-0340), dialing into CFOG 2 (filename is REMM40.SQS) or visiting a meeting and getting it from the DOS library. The AST support BBS has several files relating to whether or not one of their products is compatible with a given PC clone and can be reached at 714--852--1872.

CFOG's MS-DOS Library

The CFOG MSDOS library at present has 46 disks and will add at least 2 during May. There is a listing of the library on the BBS under the filename of CFOGLIB which is updated monthly.

Word Processors in the Library

The latest addition to it will be NYWORD (a word processing package), more artificial intelligence software, and PC Magazine's benchmark series of tests for PCs.

Speaking of word processing programs, if you are looking for a source for VDE version 1.2 it was in the library for last meeting, as well as on the RCPM.

Another useful word processing package in the library is Galaxy, which has a command structure that looks like Wordstar but can also be run from function keys or pull down windows. Like VDE version 1.2, it also supports windows which can be very convenient for writing a column in window 2 while you look at your notes in window 1, or writing a program in the second window while your use the first to look through similar programs you have written to find known working code modules to incorporate and move into the one you are writing.

More Library News

Another useful program in the library is DUPDSK. For 360k disks it allows speeded up mass duplications by reading the master disk into memory and them dumping it to blank disks in both A and B disk drives without rereading the master. It also formats blank disks. DUPDSK is menu driven.

A program that looked good but didn't make it into the library was NARC2O, a menu driven archive program. It worked fine for small files, but locked up the computer on anything over about 30k. Since ARC and PKARC work on files up to at least 3 meg, the biggest one I have tried, that puts NARC at an extreme disadvantage. The documentation contains a good discussion of the whole subject of archiving, however at least on my machine it won't handle anything but small files.

New XT Chips

Due to the tariff on Japanese computers and chips the price of memory chips remains high. Since the tariff on AT compatibles is higher than XT compatibles the Japanese are introducing some very powerful XT class computers. They are using some of the newer Intel and NEC microprocessors such as the Intel 8088-1 (NEC V20--10), and the Intel 80186 (NEC V-40). Both of these are hytrid 8/16 bit microprocessors and take clock speeds as high as 10 MHZ, producing some very fast computers. I have seen Norton sysinfo ratings for them as high as 3.9. (On this scale an original XT is 1 and the original 6 MHZ AT is about 6.) The Intel versions of these chips approach the speed of an 8086 which as a 16 bit chip gets a higher tariff, so isn't used. The NEC V30 is also faster, but is also a 16 bit chip.

With the addition of these the microprocessors available for PC clones has grown. They are listed below in order of speed.

16 BIT
Intel 80386	16 and 20 MHz clocks
NEC V50	Almost never seen
Intel 80286	6, 8, 10, 12, 16 MHz
NEC V30	4.77 and 8 MHz
Intel 8086	4.77 and 8 MHz

8/16 BIT
NEC V40/Intel 80186	8 or 10 MHz
NEC V20-10/Intel 8088-1	10 MHz
NEC V20-8/Intel 8088-2	8 MHz
NEC V20/Intel 8088	4.77 MHz

Another factor complicating buying a new PC is that with the release of Norton Utilities 4.0 a new Norton speed index was released. The Norton version 3 index (SYSINFO) checked only processor speed. The new one (SI) consists of CI (a processor and memory speed index) and DI (a disk speed index). Of the 3 machines I have checked the old SYSINFO and the new CI agree within a margin of one tenth. I have seen at least one vendor multiply the standard clock speed of 4.77 MHz times the CI index for a V-20 chip of about 3.2 and claim that the machine had a CI index of 15 MHz which is pretty bad advertising as there are no units on the CI index. Read computer ads very carefully: if it looks too good to be true it probabiy is.

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 40

CFOG II RCPM News

CFOG's RCPM has moved to Rogers Park, on the North Side of Chicago, much to the joy of certain members who now find it in their 'nickel' calling area, so that they can call for as long as the system allows for just about a nickel. Despite the worst that Illinois Bell could do, failing to install the needed new line on the appointed day and giving system administrator Bill Kuykendall an incorrect number to post for the week before the move, over 50 calls were received in the first 36 hours after the system went back 'on the air' after the move. Thanks to Bill's efforts the move went smoothly and the system is up and running.

Thanks to Mike Andrews the MS-DOS sections of the RCPM have been filled to over-flowing with public domain software and shareware. Steps are being taken to archive some of these programs so that more new stuff can be added. For example, more than 700K bytes were devoted to programs and templates for preparing 1987 Federal and state income tax returns. These are still around if you still haven't gotten your return filed, but you'll have to ask for them.

The CFOG Board has approved the ordering of a WestWind Perfect XI system to add to the RCPM. This is an 11 Mb floppy disk system. This means we'll be able to practice what we preach: a complete backup of the files on the RCPM [we do have a backup of the system files, but we don't cherish the task of backing up 65+ Mb of software on 183 Kb floppy disks!]. In addition, the Perfect XI also will provide another 10+ Mb of on-line storage.

Oh, yes. The new number for the RCPM is [312] 764-5162.

CFOG Library Expands

Thaks to Peter Cook and the Hoosier Osborne Group we've added a number of new FOG disks and several updates. We're now complete through FOG CP/M disk number 190.

Through the courtesy of the Association of Shareware Professionals we're receiving a number of MS-DOS shareware contributions. They are generally being added to the library as Steve Lucius groups them with other files. One exception is a complete set of disks from ButtonWare, Inc. We have PC-File+ Version 2.0, PC-Type+, PC-Calc+, PC-Dial, PC-Stylist, XD (Extended DOS), and the Baker's Dozen Utilities.

As with all shareware offerings, these are for evaluation only. If you want to use the software on a regular basis you must register. ButtonWare offers discounted prices on user group orders, but KaftorWare Corporation will offer CFOG members a 15% discount, better than we could obtain without a purchase of at least ten units.

Speaking of MS-DOS, Steve Lucius has completed the first groups of MS-DOS disks for CFOG's public domain and shareware software library. They are available at both Sunday and downtown meetings. The categories (with the number of disks in parenthesis following) are: file squeezing utilities (1); Games (4); data base (2); CP/M emulation (1); artificial intelligence (1); communications (6); finance (3); taxes (3); graphics (2); disk utilities (2); text files (3); languages (1); spreadsheets (4); word processing (4); miscellaneous utilities (10); tutorials (1).

Some of the programs included are the popalar file compressing programs, ARC521, ARCE, ARCMAS2O, LU86403, NSWP19, PKARC, UNCR231 (to uncrunch files crunched with the CP/M CRUNCH). Games range from ALLEYCAT to WRDSRCH. Data base programs inclued WAMPUM, a dBase III clone, DOCDATA, the Doctor Data mailing list manager, and ROLODEX. Communications programs include QMODEM, PROCOMM, MSKERMIT, and PCTALKB. Disk utilities inclued FRAGS, which lists fragmented disk files; HDDIAG; hard disk diagnostics; REPEATS, which look for duplicate files; and WHERE3, a program to search your hard drive. Text files include HELPDOS, on line DOS help.

Word processing programs inclued GALXY22C, VDE12, and New York Word, and you'll also find there WORDCT, which counts words, and, for reasons best known to Steve Lucius, CED, a command line editor. Miscellaneous utilities include CALENDR; CASIOZ; calculator watch on screen; CATS22, a floppy disk catalog program; CFORMAT, a quick floppy formatter; COVER, which make covers for disk; DUPDSK2O, to copy disks; FKEYOVLY, to make functon key overlays; GO, to go direct to a directory; FF, which fast formats 360k floppy in 2 drives; HISTORY, to recall previously used commands; SIDEKICK, an ARC with Sidekick utilities; UNDEL, to undelete erased files; and QFILE30D, a disk and file maintenance utility.

MS-DOS users with modems have access to a much wider selection of public domain and shareware software, but Steve's hard work now makes many of these programs available to users without modems. As always, there is no charge for disk copying at CFOG meetings; members are encouraged to bring machines (MS-DOS machines are especially needed) to the Sunday meetings.

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 41

NAJ'S ZCPR GUIDE

by Naj Najarian, President, Lehigh Valley Computer Group with editing by Bill Snell, newsletter editor of LVCG

PREFACE

To date, all the instruction manuals and articles on ZCPR have been written for the highly computer-literate reader. There is no guide introducing the reader to ZCPR which explains all that computerese jargon and gives concrete, useful examples. The extant guides are written by and for the assembly language programmer. What about the rest of us?

So this dissertation will strive to be an introductory guide which leads the reader into ZCPR, starting out with an explanation of not only what ZCPR is, but why it was developed and what advantages it offers to the regular computer user. Not the software developer, not the industrial technician. It will be a biased guide.

Expect lots of pig-headed opinions and few apologies, but all for the sake of practicality. The examples are based on personal use, with some reference to how others could use the same techniques. So I'll probably wander a bit too.

It means that the examples will get detailed, but, I hope, not so detailed as to become incomprehensible. I want to show how I use certain ZCPR techniques to make life on my Kaypro easier. I don't intend to show everything about ZCPR and all its tools. That's a whole book, if not a whole series of books. I hope also to update this guide constantly, so that as new tools and new revisions of old tools come out, you can keep up to date.

I. JUST WHAT IS ZCPR?

This question requires a little discourse on operating systems. ZCPR stands for Zilog Command Processor Replacement. It's designed to replace CP/M (which stands for Command Processor for Microcomputers). The Console Command Processor (abbreviated as CCP. Fair warning: computerese is rife with three-letter abbreviations. Given enough time, I'll collect them into a glossary) is the part of the operating system of the computer that a) tells the computer to load and run a program when you give it the name of one (It knows to load the file called WS.COM and run it when you say WS) or b) to run the built-in commands TYPE, DIR, SAVE, REN, USER and ERA (these are called resident commands because they reside in the computer's memory; the other type, the kind that take up space on the disk, are called transient because they're only in memory when you run them.)

There is another part of CP/M that comes with your computer, called the BDOS (Basic Disk Operation System) which is the part of the operating system that finds, creates and deletes files, prints characters on the screen, figures out file size -- all the basic operations that programs use. If a program wants to start a new file, for example, it tells the BOOS, "Hey, BOOS, open up a new file and call it ELEPHANT.TXT," and the BDOS will do just that. It saves programmers from reinventing the wheel with every program they write. The BDOS handles all the common operations.

This system also lets programs work on any machine with CP/M's BDOS because the BDOS does not vary among different brands of computer. The BDOS on a Kaypro is virtually the same as the BDOS on an Osborne, is virtually the same as the BDOS on an Apple running CP/M (Note that I hedged my bets with "virtually." Where the BDOS is stored in memory will effect its exact coding, but that should be the only difference). That means that the only part of the operating system that varies from computer to computer is the BIOS or Basic Input/Output System. That's the part that tells the different chips in your computer what you've got (how many disk drives, how many different ports, whether or not you have a built in modem or clock, what type of keyboaid is attached) and how to operate. A program that wants to create a new file sends a code number to the BDOS which tells the BDOS to open a file and the BDOS in turn sends a code to the BIOS telling it to open a file on a specified drive.

All that was to explain to you that there's an additional piece parallel to ZCPR which replaces the CP/M BDOS just as ZCPR itself replaced the CP/M CCP. ZRDOS (for Zilog Replacement Disk Operating System), when paired with ZCPR, makes an integrated operating system known as Z-System. It is the only part of all this Z-stuff that is not Public Domain (abbreviated PD, really!) and costs money. [A program released for free copying by the public, without any copyright being retained by the author, is said to be in the public domain. We often apply the term loosely to refer also to programs whose copyright is held by the program author but released for free copying for non--commercial purposes.] Consequently, ZCPR systems (those without the ZRDOS) are much more common than full Z-systems.

II. WHY ZCPR?

CP/M was designed to work on an 8-bit chip called the 8080. developed by Intel Corporation. It works also on an earlier chip, the 8085, and a later chip from a competitor, Zilog Corp., the Z80. The Z80 chip does everything the 8080 does and then some. Rick Conn, a developer who works for the Department of Defense, realized that CP/M could be rewritten to take up less memory and run faster if it took advantages of the added instructions of the Z80 chip. And so, over a period of years, he and a cadre of programmers have gradually improved CP/M with a fully compatible operating system which now does more than CP/M ever did. Similarly, ZRDOS operates much faster than the CP/M BDOS. I recently updated one of my Kaypros on which I had run ZCPR and the old CP/M BDOS for a long time. I was stunned by the improvement in speed of disk operations. I didn't do any timing because, truthfully, I didn't expect to notice the difference. But the system runs so much faster that I probably could time the difference with a plain old stopwatch. (I should go into additional improvements in ZRDOS, but this is about ZCPR, not ZRDOS.)

Later on, I'll discuss how switching to ZCPR affects your system in terms of actual diskspace. The guts of it reside on the same place as CP/M did, that is, on the place reserved on every disk for the operating system, called the SYSTEM TRACKS. It's the part that gets SYSGENed onto any disk you want to keep in drive A:. Which is to say you lose no disk space, and need it only on the disks you want to keep in drive A:. True, some of the other features do take up extra space, but we're talking about perhaps as little as 10K. If that worries you, jump ahead to the section labelled COSTS. It's worth it. Don't take my word for it; ask any other Z-System user.

III. HOW ZCPR WORKS

ZCPR works its wonders by dividing up its memory into segments. Where the CP/M CCP was just one hunk of memory, ZCPR is divided by function. For example, the DIR, ERA, TYPE and other resident commands are stuck into one part of memory (called the RCP or Resident Command Processor), and the part that loads and runs programs is situated elsewhere. Other segments (ECP, FCP, Error Handler, and so on) have no equivalent in CP/M. There are so many different sections (segments is the technical term) that there's a segment that's an index of all the other segments (it's stored in a file called SYS.ENV because it describes the environment of the system).

Because the CCP is neatly divided up, different segments can be swapped in and out. An example for those who with an IOP (Input/Output Processor): if you're going to be editing and printing a number of files with the new version of WordStar, you could load the IOP that lets you print while you do other work on the computer (Background Printer, by name, or BP for short), until you get to some hellacious formating, at which point you'll load the keyboard re-definer into the IOP [NUKEY is thus far the only keyboard macro program written for the IOP; it's not nearly as nice as XtraKey, but it won't take up any TPA that WS 4.0 needs so much.)

[NUKEY is proprietary; for some systems the public domain Z33KEY.RCP gives keyboard redefinition capabality where you are willing to give up your resident command package, not a bad option on a fast hard disk system or a big RAM disk system. -- bhc]

An example for the rest of us: once in a while, while I'm editing, I'll want a calculator on hand. CALC is an RCP that replaces the TYPE, DIR and other commands with a tiny pocket calculator that you can use within any other program. So I'll load that RCP in and run WordStar. And as soon as I'm done editing, I'll load the regular commands back in so everything's back to normal. (Obviously Backgrounder ii would be ideal for these operations. ed.)

How the segments work.

Let's take a look to see how the CP/M CCP operates. When you type in a command, it first checks to see if it is a command that it has in memory (DIR, TYPE, and so on). If not, then it trys to load into memory from the disk a file with the command name, but ending in .COM, and then runs it. If there's no file by that name, then it prints on the screen what you typed followed by a question mark to tell you that it couldn't execute the command.

Generally, ZCPR functions the same way. You give it a command (or a whole series of commands seperated by semi-colons). First it checks the resident commands in the RCP (usually DIR, TYPE, ERA, sometimes COLD, CP, R, and a few others). If it's a resident command, it runs it. If it's not in the RCP, it checks the FCP (file command processor, you remember). That's where ZCPR holds all the IF commands.

Digression #1: Full list of RCP and FCP commands:

RCP Commands (mix 'n' match at install time)

CLS   clears the screen
COLD   cold boot (same as hitting the red switch in the back)
CP   copy a file
DIR   disk directory
ECHO   sends characters to screen (or printer)
ERA   erase files
TYPE   display file on the screen
LIST   send file to printer
NOTE   for comments in a command
PEEK   view memory
PEEP   view a file w/forward and backward scrolling and string search; not yet in common use (it's just been released)
POKE   set memory by sticking numbers into it
POR   view and set I/O ports
PROT   set file attribute bytes
REG   set and display registers in memory for own use
REN   rename files
R   reset disk system (when you switch disks, no need to press CTRL-C)
SP   show space remaining on disk
TST   test for program error
WHL   set the wheel byte (for BBS system security)
WHLQ   to find out whether the wheel byte has been set

FCP Commands

T   are there any false(s) thus far?
F   is there already a false lurking about?
AMBIG   is there a wildcard in the command line (like *.*)?
ARCHIVE   has file been backed up?
BG   is Plu*Perfect's Backgrounder running?
COMPR   is the file squeezed or crunched?
DS   ??? [Probably query for Plu*Perfect's DateStamper utility -- bhc]
EMPTY   is the file 0K big?
ERROR   have we goofed yet?
EXIST   does the file exist on a given drive?
INPUT   answer this question, and if you answer 'Y' or ' ' or [RETURN], continue
NULL   anything in the command?
LIST   is there a list of things in the command?
REG   does a register equal a value?
RO   is the file set for read-only?
SHELL   is a shell (like ZFILER) running?
SYS   is this a system file (not shown up in a DIR)?
TAG   has this file been tagged by a shell?
TCAP   got video capabilities (almost always yes)?
WHEEL   is the wheel byte set (for security)?
ZEX   is ZEX running?

Only first 2 letters of the conditions are important. With ZCPR 3.3 it is not virtually standard to have all the tests above available, because what can't be fit into memory is stored in a file named IF.COM that is loaded and run automatically when necessary.

A leading '~' negates; different conditions can be joined together by ANDs and ORs; a test is introduced by an IF, ended with a FI, and sometimes split by an ELSE. Values are tested by various operators, equals, different from, greater than, greater than or equal to, less than, less than or not equal to, which can be entered symbolically [but greater than and less than aren't on this print wheel! -- bhc] or alphabetically by EQ, NE, GT, GE, LT, and LE.

A trivial example which I've indented for legibility [and slightly modified to fit PIP's column width]:

IF EXIST C:*.BAK;
  IF INPUT DO YOU REALLY WANT ME
           TO ERASE THE BAK FILES?
    ERA *.BAK;
  FI;
  ELSE;
    ECHO THERE AREN'T ANY BAK FILES;
FI;

End of Digression.

So, the system checks the command on the command line it's a command that's in memory, a resident command. If the command's not in memory, then it'll try to load it from the disk. But not just from the logged disk. ZCPR will search the PATH, a set of different user areas and drives for the file. PATH, what's that?

Lengthy Digression #2: User areas

In CP/M, a drive is divided into 16 user areas, arbitrary divisions of a disk, distinguished by numbers 0 through 15 (actually, with ZCPR, through 31, but the last 16 really aren't useful except in hiding files from yourself). On a CP/M 2.2 system, you always start in user area 0. In fact, you probably have little reason to use more user areas and you pobably never knew that there were other user areas because you really don't need them.

On a hard disk, however, you have to have a way to divide up your hard disk. You wouldn't want all 8 megabytes in the same user area. Could you imagine the directory? It'd take half an hour just to list it to the screen. So the designers of CP/M developed the notion of a user area. You can store files on different user areas of a disk, and log into them almost as if they were different disks. But there's no cross--communication between user areas. If you're logged on Drive B: in user area 2, and you say go to Drive A:, you will be on drive A:, in user area 2. The system can't see a file on any other user area of any drive.

[Actually, the reason for this had nothing to do with large hard drives, which were rare and expensive in those days, but had to do with multiple users on a system. You isolated each user's work in a separate area. Hence the name user area. -- bhc]

There is vertical communication across boundaries, but not horizontal. That means, if you're running WordStar in A6:, it won't be able to find its overlays (WSOVRLY1.OVR and WSMSGS.OVR) in A0:. Ugh. There are two ways around that. One uses ZRDOS to define a whole area as PUBLIC, that is, a call from any area on the same drive will find the file if it's in any user area defined as PUBLIC. The other uses a slight modification of the CP/M BDOS to let you label certain files, instead of whole areas, as public. They'll be invisible when you do a DIR, but programs will be able to find them.

In CP/M 2.2, you can't change the logged drive and user at the same time. To change user area, you had to use the USER command. A royal pain: to move from A0: to B6:, you had to enter B:[RETURN] and then USER 6[RETURN]. In ZCPR a simple B6:[RETURN] will get you there. And to get to any area on the same drive, just the number and a colon. [CP/M Plus uses the same technique. -- bhc]

End of Lengthy Digression #2.

The PATH is a list, in memory, of drives and user areas to search for a file. You have to have a PATH, even if it's only to the current drive and user area, which is written in ZCPR as $$. If no path is set, the system will never find anything because it doesn't know where to search. After the current drive and user area, it is common to search the current user area on drive A:, written as A$. After that, you could have it search all over both disks (B0 B1 B2 A1 A2), but that slows down things a tremendously. And if you have no disk in a drive in the PATH, the system will hang as it trys to search an empty floppy drive.

Normally, the ROOT is the last drive and user area on the path, typically A15:. Some ZCPR tools know to go directly there instead of searching all over first. My path is rather brief: $$ A0 A15.

With ZCPR Versions 3.3 and later, do not need to include the current drive/user in the path. If you set the path so that it goes only to the root directory, and the program you want is NOT in the root, you can precede the command with a drive and user specifier in the form du:, or if you want the current drive and user, simply a period or colon, and the system will search the specified du: or the the current drive/user first, before going along the PATH. This is especially nice on a hard disk system, but in a floppy disk environment where the desired program is very likely in the current user area, I'm not sure it's an advantage.

In case you've forgotten, we're still tracing a command through ZCPR. When the command is found along the PATH the system loads the program into memory and then runs it.

Loading a program into memory and running it are two distinct operations for ZCPR. You can modify a program after loading it and before running it. GET, a resident command, will load a file into memory without running it. POKE, another resident command, will change a value in memory. And GO, another resident command, will then run the program that is already in memory.

Why would you want to do that, you ask? Because it gives you a lot of power. Most industrial strength programs contain sections of memory which are nothing but configuration bytes. WordStar and dBase are perfect examples. You can constantly re-install WordStar without keeping the install program on disk. Just GET it into memory, POKE in values for the variant installation, and GO. You can change insert, word-wrap, justification, margins, even printers on the fly. You'll need an index of patch points. One of the best articles is Ted Silveira's in PROFILES (July/August 1985 and republished May 1987). The WS-BIBLE also lists the different patch points. I use this method to give me a copy of WordStar that opens a file in non-document mode. I have an ALIAS which consists of the commands GET 100 WS.COM;POKE 0378 FF;GO; and does just that. I use the same technique to load more than one copy of dBase. One has everything set the way dBase normally is; another loads it with BELL OFF, INTENSITY OFF, ECHO OFF, and TALK OFF. And another is the same except for the addition of COLON OFF.

[Here's another digression: an ALIAS is simply a command or series of commands that goes by another name. Each ZCPR ALIAS is a COM file that contains one or more commands. Like SUBMIT files they can pass parameters, that is, they can accept and operate on additional information that you put on the command line. For example, you might have switched from SD.COM to DIRR.COM as your favorite extended directory program. You might create an ALIAS called SD that is simply DIRR $1 $2, so that if you forgot the change and entered SD *.COM $s[RETURN] you wouldn't get a silly SD? from the CCP. There are several ZCPR utilities that build ALIASes as COM files. BALIAS and SALIAS are two of them. Each is an editor-like program that creates a stand--alone COM file whose commands can be edited with the editor function of the program. -- bhc]

You can use the POKE and GO technique for even fancier tricks. Say you have two different copies of WordStar installed for your two printers, a dot matrix and a daisy-wheel. Since WordStar stores all of its printer settings in one chunk of memory, you could keep your regular copy of WordStar on your disk for common use, and a copy of only the printer chunk of memory of your alternative version for when you want to print with your secondary printer. You need only write an alias (call it FANCYWS or some such) to load the primary copy into memory (GET 100 WS.COM), overlay the chunk for the secondary printer (GET 300 DAISY.BIN), and then run what you've got (GO $*). The only hard part is getting a copy of the printer part of your alternative WordStar (DDT WS.COM[RETURN] M300,F800,D100[RETURN] G0[RETURN] [note that's a zero and not an oh] SAVE 5 DAISY.BIN[RETURN]). Now you have two WordStar's set up for different printers (complete with the different Pause-for- Paper-Change settings) at a savings of 16K.

When you exit WordStar, ZCPR will take the next command on the command line (everything after the semi-colon up to another semi--colon), if there is one, and go through the whole process again. Your whole command line can be up to 200 characters long. Very useful for ALIASes.

But what if after checking the RCP, FCP, CCP, and the PATH, ZCPR still hasn't found the command? Then it runs a program called CMDRUN.COM which it expects to find in the root of the PATH (and if there's no file by that name in the root, go on to the next step). This is called the ECP, or extended command processor. You can rename any program CMDRUN.COM, and ZCPR will run that program. That means, if you find a program that does nothing but put out a long beep, you can have it do something as silly as beep to alert you that you goofed.

It is common now to use ARUNZ. ARUNZ uses a text file called ALIAS.CMD, which contains your ALIASes as lines of text, rather than as stand-alone COM files. Each series of commands can have more than one name or ALIAS. [For example, the series of commands that I use to edit, save, compile, and overlay on VDE a new set of function keys can be called as EDITVDT, EDITBENZ, BENZ, EDIT, or VDT, all with the same result. -- bhc]

ARUNZ is short for ALIAS RUN ZCPR and is explained exhaustively in an article by Jay Sage, its designer, in issue #31 of The Computer Journal. Lately, the the term SCRIPT has become popular or the series of instructions invoked by an alias because the computer performs them as would an actor reading a script. A potent metaphor.

My ALIAS.CMD file is huge, but here are a few samples, followed by explanations.

A xdir A: /aauog
BACKUP crunch $1 $"To where " [$"Today's date: "] /oa
NWS get 100 ws.com;poke 0378 ff;go $*
ZF=XF=VF=VFILER=XFILER=ZFILER zf
: lx / $0 $*

If I enter A[RETURN] (that's it, just the letter A), and a search of memory and the PATH turned up nothing, then in ARUNZ.CMD the system will find the command that tells it to run the program called XDIR to give me a directory of all files on all user areas of drive A:.

You can even prompt for input in an ALIAS. When I want to backup a file or a user area, I just type BACKUP B0:*.*. The ALIAS prompts me to put in the destination drive and the date stamp with the strings between the quotes preceded by the dollar sign.

When I enter

NWS PROGRAM.ASM [RETURN]

ZCPR won't find NWS as a resident command, won't find a file called NWS.COM along the PATH, but will find in ALIAS.CMD, the ALIAS NWS and execute the following: get, that is load WS.COM into memory at 100 (where most programs are run); poke, that is put the value FF at memory location 378 (hexadecimal); and run the now modified edition of WordStar that is in memory with the file PROGRAM.ASM as the one to edit. The $* tells ARUNZ.COM (renamed CMDRUN.COM, remember) to add everything in the line after the NWS to the command. It's one example of the sophistication of the Z-System I don't have to specify the number of parameters that will be on the command line with $1 $2 $3 as we do with SUBMIT.

One final example: when I switched from the program VFILER to the new improved version, ZFILER, it took me the longest time to remember the program was ZF.COM, not VF.COM. Sometimes I would even type XF by mistake. Now, no matter what I type, it knows to run ZFILER (truly named ZF.COM). That's what all those equal marks do.

Now, if the command is not in ALIAS.CMD either, then the system would execute the line after the colon at the bottom. Used to be, that was ECHO I DON'T KNOW HOW TO "$0", YOU MORON. That means the command name would be substituted for the $0, and the system would print a line on the screen, using the ECHO command from the RCP, saying, for example, I DON'T KNOW HOW TO "SBASE", YOU MORON. Clever, but not terribly helpful. Now it sends the command line to a program called LX. That gives me effectively two ECP's in one (LX used to be, and sometimes still is, run alone as the ECP; renamed CMDRUN.COM and put on the root).

LX tries to run commands from a library (by tradition in the root directory) called COMMAND.LBR. And what that means is you can store a whole lot of ".COM" files in a library and run them. That saves disk space, and neatens things up. At this writing. I have 35 files in mine (takes up 190K) and saves 30K. The larger your block size the more space you'll save. Those with small floppies and 1K blocks won't save much space at all. Those with hard disks with 4K blocks will save lots of space. Plus that's 35 names I don't have to look at every time I do a DIR. You can keep all your editing utilities in there: FTNOTE, INDEX, FILTW, maybe even BRADFORD and others. By the way, LX will let you run programs in other libraries elsewhere too. Just remember to precede the directory with an hyphen: LX -B6:UTILITY WSDOCON LESSON1.MSS will run WSDOCON.COM from within the library called UTILITY on b6: on the file called LESSON1.MSS in the default directory.

That / option in LX let's us take advantage of the final part of the processing system, the ERROR HANDLER (Hey! No abbreviation!). If LX doesn't find the command as a COM file in COMMAND.LBR, it passes the command to whatever program has been installed as the error handler (usually you just run the program, and it installs itself as the error handler). Some people use Z33ERROR, which makes an analysis of the type of error and makes a report. I prefer VERROR which loads the whole command line (the offending and all subsequent commands), and let's me correct my mistake, using WordStar control keys to move about the command line. I either correct the command, add to it or zap it away with a CTRL-Y. [A newer error handler/shell is called EASE. -- bhc]

[Naj describes a complete Z-System extended command processing rigmarole. Unless you have an exceptionally quick system you may find that all this sometimes seems to take all day. My own choice is to use ARUNZ with its ALIAS.CMD file as the end of the process, with no error handler. Using EASE only as a history shell allows me to recall previous command lines and edit them when that's desirable. -- bhc]

IV. INSTALLATION

So what does ZCPR cost you? In terms of memory, a decent ZCPR installation will take up some memory. By decent, I mean a full ZCPR setup, with or without an IOP. I have only 58K instead of the Kaypro CP/M standard 63 or so. But it's not important memory space unless you want to run a humongous program with lots of add-ons. [See my separate article "TPA -- What It Is and How Much You Have" elsewhere in this issue of PIP. -- bhc]

In my set-up, I can run WordStar 3.3 and a keyboard redefiner set up with more than one set of keys. The only time I've ever found a memory limitation is when I run a commercial outliner program written in TURBO Pascal. The program runs fine, but it takes up so much memory that it won't let me also add a keyboard redefiner in the background. The same is true with the new 4.0 version of WordStar. It'll load, but you can't add any other memory-hungry background program. You have to replace or eliminate your IOP instead, if you've got one.

As for compatibility, don't worry about it. ZCPR is by design 100% CP/M compatible. Except for memory limitations (and those are EXTREMELY rare, there can be no such thing as a program that runs in CP/M and not in ZCPR. And I still have yet to find a program so large that it won't run alone in ZCPR.

So what about disk space? This is a concern of floppy users alone. The different system segments (SYS.RCP, SYS.FCP, SYS.ENV) must reside on disk so that you can load them into memory. And you have to have a way to load them. If you use LLDR.COM, you can stick them all in a library, and load them from within the library. LLDR.COM takes up 8K, and the library of segments will take up at least 3K. When ZCPR cold boots, it tries to run a program called START.COM. You can get away without it, but you're only asking for trouble. For the sake of flexibility and ease, you oughta include that too.

That file is an alias with the instructions to execute at cold boot (when you turn your machine on, or press the reset button). It will include at the very least a line telling the system to load the different segments, something like:

LLDR ZPACKS,SYS.ENV,SYS.RCP,SYS.FCP

START.COM will take up the minimum file size for your system, usually 1 or 2K. Disk costs thus far: SSDD, 12K; DSDD 14K. That's really all you need, but I'd go nuts without ARUNZ as my ECP (ado another 4K), and that means an ALIAS.CMD, file, too. I've got 2K worth of aliases in mine; let's assume you will too. That's 18K or 20K. Now, in order to recoup some of that, you may want to include LX.COM (3 or 4K) so that you can run stuff from within your COMMAND.LBR. Disk expense: 21K for a single-sided Kaypro floppy system, 24K for double--sided.

All the literature says you can install ZCPR yourself. Don't you believe it. It is physically possible, but it's not worth the mental aggravation. Let someone experienced do it for you, or at least guide you. Because the watchword of ZCPR is customization, there are a lot of options to choose. Let someone who knows what each does help you. There are all sorts of hidden considerations. I boot from A15: because I want to hide my ZCPR files down there. That creates some problems that need to be worked around. I also thought it silly to have to correct someone else's choice of PATH on startup. I've had to correct other bugs in the system. Some users may want the possibility to name every user area (ZCPR lets you call a user area by an eight letter long name which you can use just as you would the drive and user number. EDIT:[RETURN] would log the user area named "EDIT"), but the default maximum is only 14. I know one fellow who wants 48 for his 3-drive hard disk system.

Your local ZCPR guru can explain things to you and turn your computer into a custom workstation.

But watch out. Once you're comfortable with your new ZCPR system, you'll refuse to go back to CP/M. Or to anyone else's setup. I've become so addicted that I had to design a SSDD version so I could boot my workstation on a friends ancient (read unmodified) Kaypro in order to work on his machine.

One last expense consideration. Money. ZRDOS is the only part of ZCPR that is not in public domain. Everything else is free. The files, the programs, the tools, all have been placed in the public domain. The only thing you need invest is time. And that you'll spend lots of. Getting to know ZCPR in order to customize it is a learning process. And since ZCPR is constantly being rewritten and expanded, it is a continual learning process. You will never know it all because there's always more to know.

[There has been a change in the marketing of Z-System. The indicated cost of ZCPR's latest incarnation plus the latest version of ZRDOS should be in the vicinity of $120. I believe the newest version will be or is called NZ-COM. It has a host of new features, including but not limited to dynamic reconfiguration of the system, and there will be one for just about everybody even CP/M 3 folk like Osborne Executive and Commodore 128 users will be able to install a Z-System simply and easily, without a lot of help from a local guru. -- bhc]

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 47

As a special witness to The President's War on DOS Committee, Bill the Cat reveals his sordid past

"At first, I just did it on weekends, with my friends, you know? We never wanted to hurt anyone. The girls loved it. We'd all sit around the computer and do a little DOS. It was just a kick. At least that's what we thought. Then it got worse.

It got so I'd have to do some DOS during the weekdays. After a while I couldn't even wake up in the morning without having that crave to go do DOS. Then it started affecting my job. I would just have to do it during my break. Maybe a Mode command or two. I eventually started doing DOS just to get through the day. Of course, it screwed up my mind so much that I couldn't even function as a normal cat. DOS got me fired from my job.

I'm lucky today. I've overcome my DOS problem. It wasn't easy. If you're smart, just don't start. Remember, if a weirdo in a blue suit offers you some DOS, just say no.

MSDOS...
Just Say No

A special message brought to you by The President's War on DOS Committee. © 1987

 

 

 

 

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 48

Call for Articles

Let's hear from you. If the articles in PIP aren't what you want, it's because someone hasn't written them. You can help, by writing about subjects that interest you. Or, here are some subjects I'd like to hear about:

1. Your favorite utility program for MS-DOS. Write a short article about it. What does it do? What makes it better than other solutions that you know about?
   
   
2. What you've done to your Ozzie to make it better than Adam's. There are lots of things our Ozzies can still do, and lots of ways to get over the limitations of the little screen, 52 column display, small disk capacity, slow I/O, etc. How do we keep those machines alive? Have you added ROMBO? Put in double-sided drives? Implemented ZCPR3? Is it a commercially available product, or home brew? Would you be interested in or willing to help others do it, or do it for them? There must be some of you who have done something that we haven't heard about. Write it up.
   
   
3. Bradford, version 2, is out. Someone with an MS-DOS or CP/M machine and an Epson or Star Gemini printer ought to do a review. It's loaded with features.

Maybe you have something else you could write about. PIP always needs articles, especially by CFOGGers! Send disk copy (any 48 tpi CP/M format or MS-DOS 2.x, but label the disk as to what format it is!) to PIP, Box 1678, Chicago 60690 or upload to CFOG II (use the command:

KMD RP <filename.typ><cr>

for a 'private' upload. Please leave a message for Benjamin Cohen telling the name of the file).

 

---

CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 48

Downtown Meetings

The next downtown meeting will be held on June 9, 1988. We get only a few members at our downtown meetings. They are on the second Thursday of each month at 6:00 p.m. at 55 West Monroe Street, #2400. Pizza from Edwardo's is served [$6.50] for those who don't have a chance to go home and eat first.

The downtown meetings do not normally have a planned program. We try to deal with as many individual problems as we can on a personal level. There are several Osborne and Kaypro CP/M systems in the office where the meetings are held, and a Kaypro 16 MS-DOS system, so it's not necessary to bring a computer for disk copying. Both MS-DOS and CP/M libraries are available.

Join us.