THE LDOS QUARTERLY October 1, 1982 Volume 1, Number 6 -------------------------------------------------------------------------------------- Table of Contents INTRODUCTION FROM LSI: EDITOR'S NOTES ........................................................... Page 2 VIEW FROM THE BOTTOM FLOOR ............................................... Page 3 LSI NEWS ................................................................. Page 5 FROM OUR USERS: EDAS IV for the Model I/III .............................................. Page 9 The Communicating Micro .................................................. Page 12 LDOS and BASIC file structure from a beginner's view ..................... Page 20 LISP Language and LDOS ................................................... Page 26 Use JCL to control those FORTRAN and COBOL compilers ..................... Page 32 LDOS and the Hayes Smart Modem ........................................... Page 34 Patching for LDOS compatibility - Visicalc ............................... Page 38 Using the LOOS disk I/O routines ......................................... Page 43 LSCRIPT patches add versatility .......................................... Page 45 Super-Short Terminal program + new ALIVE command ......................... Page 50 Using NEWSCRIPT 7.0 with Model I double density systems .................. Page 55 PARITY = ODD - by Tim Daneliuk ........................................... Page 59 .... er .... - Assembly Language Programming by Earle Robinson ........... Page 64 FROM THE LDOS SUPPORT STAFF: ITEMS OF GENERAL INTEREST ................................................ Page 66 Includes TCHRON, TTIMER patch and Assembler code RUN "PROGRAM",V - Chain those BASIC programs by Dick Konop ............... Page 69 THE JCL CORNER - by Chuck ................................................ Page 72 Patch LSCRIPT to be run with a JCL file RTC - Roy talks about - - - .............................................. Page 76 Information on many different system functions LES INFORMATION - by Les Mikesell ........................................ Page 83 Input from the RS-232 in LBASIC, plus a new *CL filter LATE BREAKING NEWS, ETC .................................................. Page 92 Includes SuperScripsit patch, FIX Disk news, and more Copyright (C) 1982 by Logical Systems, Incorporated 11520 N. Port Washington Rd., Mequon, WI 53092 (414) 241-3066 Page 1 EDITOR'S NOTES This is the sixth and final issue of Volume One of the Quarterly. It marks the end of a year and a half of LDOS support and development. We have made many changes and improvements in both the Quarterly and the LDOS system in that time, and will continue to pass on new information in the pages of this publication. Besides a new cover design, this issue of the Quarterly marks a major happening in its development - user contribution. Besides the regular user columns from Tim Daneliuk and Earle Robinson, we have a whole section of user contributed programs and articles. Maybe it was that offer of free software .... Anyway, this issue contains many interesting articles, including a review of the LISP language and patches for Enhanced Visicalc. The normal staff columns are, as usual, full of many different things about the workings of LDOS. So, sit back and enjoy. We are looking for reviews of any languages for our next issue. We currently have or will be getting reviews on LDOS "C", STSC APL, PASCAL 80, and ALCOR PASCAL. If you are currently using another language or one of the previously mentioned languages from a different author, we would be interested in seeing a review. The LDOS Quarterly policy on the submission and payment for articles is as follows: Articles sent for consideration should be accompanied by typewritten or lineprinted copy. An ASCII text file, Scripsit or SUPERScripsit file MUST accompany the printed copy! Please do not send in printed text without a disk, or send a file that has been created by routing the printer to a disk file!. No matter what the word processor used to create the file, it is much easier to format an original file than one that has been "printed" via a route of *PR. Payment will be made in the form of a product from LSI, or $25.00 per page ("page" is defined as page in the then current newsletter format). The size of the article will determine the value of the product, although no reasonable request will be refused. Please include your name, address, telephone number and LDOS serial number with your submission. LSI is extremely interested in seeing submissions from our users, and is open to suggestion on any ideas for the Quarterly. Submissions should be sent to: LDOS Quarterly Editor 11520 N. Port Washington Rd. Mequon, WI 53092 The LDOS Quarterly is copyrighted in its entirety. No material contained herein may be duplicated for commercial purposes without the express written consent of Logical Systems, Inc. or the article's author. Page 2 V I E W F R O M T H E B O T T O M F L O O R ======================================================= by Bill Schroeder In my last column I asked for suggestions for possible new locations for Logical Systems. Many thanks to the people that responded with very interesting suggestions for that "perfect place". One person even suggested the North Pole..... for some reason I don't think he was a totally satisfied LDOS user..... oh well, we try. As of now, no decision has been made and will probably not be made until early 1983. We will keep you all informed as to our relocation plans. As I am sure most of you know, the LDOS operating system (version 5.1.3) has been chosen by Radio Shack as the operating system that will be provided with their new Hard Drive system for the Mod I and III (cat. #26-1130). We are very proud that after seriously considering all of our competitor's products, support and companies behind those products, Radio Shack selected LDOS and Logical Systems. Also available through Radio Shack will be LDOS 5.1.3, both Mod I and III, floppy disk based systems, as catalog #26-2213 and 26-2214, respectively. This system will sell for $129 and will be virtually identical to the LDOS 5.1.3 available in the LSI packaging. LDOS and official LDOS support products from LSI will continue to be available through our worldwide dealer network. The only substantial difference between the LDOS sold by Radio Shack and the LDOS sold by our dealers is some statements in the manual and the absence of TWOSIDE/CMD on the Mod I system. The operating system itself is the same. Any program that is completely LDOS compatible will run just fine on the floppy and hard drive versions of LDOS provided through Radio Shack. Many people have asked about how support will be handled for the LDOS product that is to be sold through Radio Shack. The answer is quite simple. Radio Shack will be providing support for LDOS as they do for all products they sell. But of course LSI will always be willing to assist any LEGITIMATE LDOS owner, no matter where that LDOS was purchased. Many of our users have TRS-80s that are not quite TRS-80s such as PMC-80, PMC-81, Video Genie, LNW or Model III computers that have had NON-Radio Shack disk controllers installed. Unfortunately we do NOT have all these machines and are having a difficult time supporting these. The main problem is the foreign disk controllers in the Model III. These controllers, in most cases, do not function exactly the same as the official Radio Shack controller. The disk drivers in the LDOS system are designed and written for the TRS-80 and Radio Shack provided controllers. Use of LDOS with other controllers and/or computers may or may not work and may not always be as reliable as when used with the hardware that LDOS was written for and tested on. So please understand these problems. We would like to help with any problem that an LDOS owner has. However, some problems are impossible for us to address, because we don't, in some cases, have the same hardware as the customer. We have only official Radio Shack hardware, all components (except disk drives) are pure Radio Shack. So when you consider new hardware please call or write. We will be happy to tell you if the product is supported by LSI or is known to work well with LDOS. If you don't check with us, you are on your own. When purchasing new software, make sure that the author or publisher will firmly state that the program in question IS IN FACT LDOS COMPATIBLE. If not, don't buy it and expect it to work with LDOS. There are many LDOS users groups and special interest sub-groups popping up around the country. If you are involved with an LDOS group of any sort, please let us know where it is and how other users can get in touch with the group. In the next issue of the Quarterly we will be publishing a list of these groups. So let us know where they all are as soon as you can. Include: name of group, name of individual in charge, phone number, mailing address, meeting address, meeting times and dates and how to become a member. Page 3 In my last column, I mentioned our new LSI HOT-LINE (414/241-4100). We had some trouble with the answering machine that was to answer this line with a 3 minute message. We still don't have this 3 minute arrangement resolved but we have installed a machine with about a 1 minute message on that line. If you wish to call the HOT-LINE you will get this short message. We will have the longer message machine ready shortly, one way or another. As of LDOS 5.1.3 there are no longer /FIX files included on the master disks. This is due to the changes needed in these fixes as the programs they are intended for change. There also would not be enough room on the disks for all the fixes we would like to provide. As a solution to this problem we will make available on October 1st, both hard copy versions and diskette versions of all available /FIX files. The hard copy set will be available for $5.00 and the diskette version will be $10.00. Postage will be paid by LSI on either version. (Foreign add $3.00 for Airmail). Either /FIX package will contain all of the official patches that have been developed to allow non-LSI products to function with LDOS. Some user contributed patches will also be included for products that have not been checked by LSI. It should be understood that this will be an ongoing process of patching programs and that the purchase of a /FIX package is strictly "AS IS" on the date purchased and no patch is guaranteed to produce any desired result. We will not offer updates or upgrades to these packages. If you require a patch that is developed after you purchase your /FIX package you will have to purchase the package again. With many thousands of users to service with these products, we must provide them in this way. Please check with us to confirm what patches are provided. To help you in determining if a particular patch is available we will publish a directory of the /FIX disk in each issue of this publication along with any new /FIX files, starting with the January issue. Those who wish to have back issues of this publication can obtain them through LSI for $5.00 each postage paid. This is issue #6; we still have some copies of EVERY PREVIOUS ISSUE on hand for those who want them. The FILTER concept is very important in the LDOS system and allows LDOS to do many things that cannot be done with other systems. Last year LSI offered a package called FILTER PACKAGE #1. It contained over a dozen useful filters WITH COMPLETE SOURCE CODE, at $60. So that even more of our users can enjoy the benefit of this package, LSI is permanently reducing the suggested retail price from $60 to $40. This super package has become even better with a new low price. LSI will provide you with complete info on this package for the asking. So don't forget the top notch FILTER package from LSI for just $40. Also check into FILTER PACKAGE #2 containing a whole new batch of handy filters for just $30. IMPORTANT: If you order both FILTER PACKAGE #1 and #2 at the same time you receive them both for just $60 (that was the old price of the FILTER #1 alone). A NEW product that we are very proud of at LSI is The BASIC Answer (TBA). This is our BASIC program source processor which was a year in the making. BASIC programs can now be written WITHOUT LINE NUMBERS, use 14 CHARACTER VARIABLES, CONDITIONAL PROCESSING, GLOBAL AND LOCAL VARIABLES, and FULL CROSS REFERENCING during processor run and more. Don't miss out on this whole new world of BASIC programming. I'm so confident that this product will be the BASIC programmers best friend that I am offering a MONEY BACK GUARANTEE on TBA and a special TBA package. TBA has a retail price of just $69. During this special offer LSI will provide you with TBA and LED for just $79. That's right - buy TBA and LED (our text editor) together for just $79 (a $109 value). Don't delay too long though. This offer is only good for the rest of 1982. If you are not satisfied with this package for any reason, return it with the original invoice (postage paid) to LSI within 10 days of receipt and you will receive a FULL REFUND, no questions asked (But I would appreciate knowing what you did not like about TBA). This special money back guarantee is available on just TBA for the $69 price or the TBA & LED special at $79 until December 31, 1982. NOTE: This special offer is available only when purchasing directly from LSI. The first 50 TBA packages will also have a special FREE suprise included. Page 4 Radio Shack has now released the long awaited Super-Scripsit and Extended Visicalc products. I have spent some time using each and find the new Super Scripsit to be an excellent product worth much more than the asking price (note: some small bugs have been found, but should be corrected shortly). Both of these packages will run on LDOS with little change. LSI is about to release several new products. Very shortly, we will be releasing TBA, FILTER PACKAGE #2, UTILITY PACKAGE #1, QUIZ-MASTER, THE LDOS USERS GUIDE, our new LDOS 513 REFERENCE MANUAL (Model I & III combined) and our /FIX products. Many of our users have asked about our RAM BASED LDOS project and how it is coming. The answer is simple; it is ALIVE AND WELL. It will be using the LDOS SVC structure as is optional in 5.1, will reside below 3000H and will be called LDOS 6.0. No upgrades, exchanges, trade-ins or updates will be offered for this product. LDOS 6.0 should appear on several Z-80 ram based machines in the first half of 1983, and yes the TRS-80 Model II is being considered as one of the possible implementations. Arrangements are being worked out for offering a Microsoft compatible BASIC as well as an EDITOR ASSEMBLER, a "C" COMPILER, many system utilities and hopefully a PASCAL for use on LDOS 6.0. So standby - it is going to happen. By the way, this new LDOS will have FULL DEVICE INDEPENDENCE! You can even filter a file!!! The popularity of the LDOS 5.1 system has grown to the point that there are books being written exclusively (or mainly) for the LDOS user audience. One of these is by Tim Daneliuk, a long standing LDOS user and a prominent author for BYTE, 80-MICRO, 80-US and INFOWORLD. His book will be called "LDOS - A Systems Guide" and should be available around the turn of the year. I have seen the first two chapters of this book and they look excellent. We will also see a work from a MAJOR industry author that will be published by IJG (Harv Pennington) that will be an encyclopedia of using LDOS & TRSDOS. This one will be a "biggy" so contact IJG in Upland, California if you are interested or want info on this one. The Snapp TRIAL PACKAGE has gone over quite well. For just $10, you get complete documentation and a chance to try out ALL of the SNAPP modules. This is a very pleasant way to determine which, if any of these extensions to LBASIC will be of value to you. NOTE: this is a TRIAL package!! It will create only ONE functioning disk, good for a limited number of uses. When that disk wears out or fails, you will no longer be able to use the products and the $10 is not refundable. If you are interested in taking a look at the best BASIC extensions in the TRS-80 world (and their excellent documentation) contact Bob Snapp, toll free at 800/543-4628. As discussed in the "Late Breaking News" section at the end of this newsletter, the prices on all the SNAPP BASIC (LDOS type) products have been reduce by about 50%! The trial package and SNAPP Extended BASIC are available through LSI as well as through SNAPP Inc. On September 23rd to 25th LSI hosted a very special TRS-80 industry meeting here in Mequon. A majority of the successful and innovative individuals providing products to the TRS-80 industry attended. The official participants were: Bob Snapp (SNAPP INC.), John Lancione (AEROCOMP), Kim Watt, Dennis Brent, Renato Reyes (POWERSDFT), Roy Soltoff (MISOSYS), Harv Pennington (I.J.G.), Irv Schmidt, Cameron Brown (80-US MAGAZINE), John Harding (MOLIMERX England), Tim Daneliuk (TRS-80 Author), John Dunn (Associated Services), Roger Billings, Kirk Hobart (LOBO DRIVES), Earle Robinson (SoftERware), Les Mikesell (MODEM-80), Bill Schroeder, Chuck Jensen, Dick Konop, Doug Kennedy, Rich Hilliard, Sue Dunn & staff (LOGICAL SYSTEMS). This meeting was very productive (exceptionally so for the non-Mequonites). 80-US magazine was on hand to cover this event and do interviews with the participants. These interviews will be published in upcoming issues of 80-US. Page 5 Speaking of magazines, I am often asked about the publications available to the TRS-80 user. I get all of these publications and find that the best all subject TRS-80 publication is, without a doubt, 80-US followed by TAS (The Alternate Source). Of the more general publications, EVERY Micro computer user should subscribe to INFOWORLD. For those wishing to get just one or two magazines my choice would be 80-US and INFOWORLD. For those of you who are not familiar with 80-US, we have arranged for you to get one FREE. All you have to do is write or call 80-US and give them your LDOS serial number. They will send you a FREE copy of 80-US for your review with NO STRINGS ATTACHED. They are at 3838 5. Warner St. Tacoma, Washington 98409 - (206) 475-2219. There is a coupon for this offer attached at the end of this newsletter. 80-US is also actively seeking articles directed towards the LDOS user. So if you are inclined to write and are an LDOS user, send your works to 80-US. I'm sure they will get prompt attention, and TIMELY PUBLICATION. There is a company call Langley St. Clair Instrumentation that is providing both GREEN and ORANGE replacement video tubes for the TRS-80 Model I and III. We have both a green and orange tube installed here at LSI and are very pleased with them. We will be putting them in all of our TRS-80s this month. They are very easy on the eyes and are a snap to install (I'm not a tech and it only took me about 15 minutes total to put one in). These new tubes sell for as little as $79 and are worth every penny of it. For more info on these contact Langley St. Clair Instrumentation at 132 W. 24th Street, New York, NY 10011 - (212) 989-6876. Tell them Logical Systems sent you. Last month our industry was shook by the passing of Harold Maush, the founder of PERCOM DATA in Dallas. Our sincere and heart felt sympathies go out to the Maush family and Harold's co-workers. The TRS-80 industry has lost a great supporter and innovator that will most certainly be missed by us all. Thank you all for your on going support of LSI products. I hope that you and your families will have a pleasant and safe holiday season. Until next year...... (the January '83 issue)...... BYE. LSI NEWS ======== This section contains a list of products available from LSI either now or in the near future. It also provides a timetable as to when a product will be available for shipment. Due to circumstances beyond our control, it is possible that products may not meet their stated delivery dates. LSI acknowledges this fact, but will make every effort to provide delivery on the date specified. Some of these products are provided by outside vendors over whom we have limited control. If a product is announced but is not available on the specified date, we hope you will have patience as we fully intend to provide all stated products/services eventually. The following products have previously been announced and detailed in previous newsletters, and are either available now from LSI or will be available within the next 30 days: The BASIC Answer (TBA) - $69.00 (see Page 4 for a special offer). LDOS "C" - $159.00 EDAS 4.x Mod I/III - $100.00 Utility Disk #1 - $50.00 LDOS 5.1.3 Manual - $59.00 (or $29.00 exchanged) LDOS Operator's Guide - $10.00 Page 6 LDOS Operator's Guide This is a short publication that is intended for the new LDOS user. It describes how to start using your TRS-80 with LDOS. In the future, it may be included with LDOS systems sold by LSI. Included are specific instructions on moving programs from other operating systems onto LDOS, creating working LDOS disks and making backup copies of them, and other information aimed at the novice user. LDOS 5.1.3 Combined Manual This is the LDOS manual that contains all the current changes in Library commands, Utilities, and the Technical section as relevant for version 5.1.3. The LBASIC section has been expanded to include descriptions and examples of all disk BASIC commands as well as the complete disk BASIC error dictionary listing. The JCL section has been re-written and grouped into beginning and advanced sections, with certain areas explained in greater detail. The Technical section has been restructured to include all Model I and Model III information, including a listing of both machines' entry point addresses and SVC's (where applicable) and all new system vectors and entry points. The layout is also in a more logical order. For those of you doing development on both machines, it is definitely a worthwhile investment at $29.00 + $4.00 S&H, exchanged. To order this manual, you should send in the proper amount along with your old manual. Be sure to KEEP your binder, tab inserts, and addendum section, as these will not be provided with the new manual. UTILITY DISK #1 This disk will contain a multitude of useful programs, some of which have been requested by our users. As of press time, the contents of the disk are as follows: COMP/CMD will be a file/diskette compare program. In the file compare mode, it will do a sector by sector compare of two files and send the differences to either the video or printer. It will also compare two diskettes sector by sector. DCT/CMD is a utility primarily useful for those developing disk drivers or using non-standard disk drives. It provides an easy method to set up a DCT entry. DIRCHECK/CMD will check a disk's directory, looking for incorrect GAT and HIT entries, as well as checking for bad file FPDE/FXDE chaining. Certain types of errors may also be corrected. FIXGAT/CMD will re-create an unusable directory GAT sector. The user will be prompted for certain information, such as the number of cylinders, density, and number of sides on the diskette. TYPEIN/CMD is a combination of JCL and KSM. It allows the user to have a specified string of characters or commands fed into the system to control operation. Unlike JCL, the characters can be fed to any program requesting keyboard input. This means that even Visicalc, Lscript, LBASIC INKEY$ statements, etc. can be answered. The characters can be directly typed in from the keyboard or can be picked up from a previously constructed file. It even can be called in the middle of JCL file, and can convert a specified number of lines to single character input. HIGH/CMD will show a display of high memory usage, as long as the modules conform to the standard LDOS memory header format. MAKEFILE/CMD is similar to the CREATE Library command in that it allows allocating space for a file by specified size in K or by the number of records of a given LRL. It also will allow file to be filled with a specified byte. The file can be marked as wither CREATEd or normal. Page 7 MAP/CMD will display a list showing where on the disk a file is stored. It will be broken down by extents and sector used in each extent. Killed files may also be mapped, including an indication if any of their previously used allocation is currently in use by some other file. RAMTEST/CMD is a memory test utility that tests both high memory and that used by the resident LDOS system. READ4080/CMD will allow a 40 track disk to be read in an 80 track drive. This will allow copying files from a 40 track disk with the COPY command and the BACKUP and CONV utilities. READII will display a directory of and copy files from a Model II TRSDOS disk. RDTEST/CMD will do a non-destructive read test of a diskette, providing a verification of all tracks and sectors. RWTEST/CMD will do a write/verify test of a diskette. This will be useful for checking the operation of a disk drive or diskette media. UNKILL/CMD will restore a file that has been accidentally KILLed or PURGEd. LC - The LDOS "C" Language Compiler ------------------------------------ LC is an integer-only implementation of C which provides all C statements except "struct", "union", "goto", "switch-case", and "typedef". All data types except "float" and "double" are implemented; "long" and "short" declarations are accepted, but 16-bit fields are used for all integers. In LC, "char" variables are implicitly unsigned. Single-precision and double-precision floating point operations are supported via functions supplied in the FP/LIB library included with the LC compiler. LC accepts multiple input files, with four levels of nesting for "#include'd" files. The compiler generates an EDAS Version IV assembler source file which is then assembled with the standard library and any other libraries needed to resolve function references in order to generate the executable program. The value in generating assembler source is twofold. First, you can obtain a complete machine code source listing which could prove invaluable in debugging complex code. Second, local optimization of assembler source code can be performed as required by the experienced assembler programmer. The LC standard library provides such functions as standard I/O redirection, dynamic memory allocation, automatic standard I/O opening and closing, and program chaining. In addition, functions specific to LDOS and the Model I/III are supplied in an installation library, to provide access to such functions as graphics and system entry points. LC supports separate compilation; programs may be compiled in segments, and frequently used functions can be pre-compiled. You can create your own 1ibrary of commonly used functions with the Partitioned Data Set utility (PDS is not included with LC but is available as a separate package). The assembler source code output by LC is designed to use the extensive SEARCH and conditional assembly support in EDAS Version IV. The assembler and companion assembler cross-reference utility are supplied with the LC package. You need nothing more to start writing and running C-language programs except your LDOS-equipped computer and a copy of the book "THE C PROGRAMMING LANGUAGE" by Kernighan and Ritchie. A 48K-RAM two-drive Model I (lower case video) or Model III is required. Some highlights of the "elsie" compiler are: o Integer subset of the C language. o Access to floating point routines in ROM via function calls. o All statements supported except STRUCT, UNION, TYPEDEF, SWITCH-CASE, GOTO. o All operators supported except "->", ".", SIZEOF, and (TYPENAME). o UNIX-compatible standard I/O library. Page 8 o Standard I/O redirection with complete device independence. o Input using FGETS or GETS functions support LDOS Job Control Language. o Dynamic memory management (ALLOC, FREE, SBRK). o Sequential files open for READ, WRITE, and APPEND. o Generates Z-80 EDAS Version IV source code as output. o User libraries in Z-80 source ISAM-accessed PDS files. o Compact one-line invocation of the compiler. o LC's interactive friendly interface provides easy way to learn LC options. o Supports separate compilation of functions. o Compiled programs run under both Models I and III without modification. o Installation library gives access to graphics and LDOS entry points. o Supplied with example programs and utilities in source form. o LC/LIB includes: FPRINTF, PRINTF, ALLOC, FREE, SBRK, and String functions. o The LC package is Model I/III LDOS compatible and includes LC/CMD, LC/LIB, FP/LIB, IN/LIB, EDAS-IV, XREF, and more than 200 pages of documentation. A New Version - EDAS-IV by Marc Leager The following is a review of some of the features of the new Model I/III EDAS 4.1. Some programs are terrific when they are first released, then a new version comes out which is five times better than the original. LDOS is one of these programs. EDAS is another. MISOSYS has recently released a new version of its editor/assembler called EDAS-IV. It is the most exciting piece of software I have seen in a long time. It not only provides the best editor/assembler around, but combines many of the latest features of micro-computer program storage into a single working system. Please read on to discover what the new EDAS can do for you. First we need an introduction for those who have not yet used EDAS. As its name implies, EDAS is a program editor and an assembler. The primary use for EDAS is in maintaining assembly language programs. But wait! As you read further you will see how the new EDAS can be used for other languages also. The traditional EDAS is a superior program editor for assembler language programs. It loads the entire program in memory so there are no disk accesses during an edit session for a single module. Line numbers are maintained for all program lines, so reference to a printed listing of the program during the edit session is possible. Best of all, EDAS allows all input to be in lower case. It automatically converts the actual language instructions to upper case, leaving comments and strings in their original typed form. At any time, the module in memory can be assembled by pressing a single key. If the module is a complete program, then the assembly is done instantaneously without disk access. Some programs are large and must be stored in several modules. For these, EDAS is able to load modules into the work space using the *GET operator to assemble the full program. The first reason for using EDAS is that it works well. Other editors for assembly programs constantly turn the disks on for reading another 256 bytes of source, and tend to scramble the code when modules get larger than 0 code lines. EDAS is quiet and doesn't wipe out your hard fought code lines. Another reason is its speed. Assembly with EDAS is very fast for single-module programs. Even for multi-module programs, it is faster than assembling modules separately, then linking them together with a linkage edit program. A third reason for using EDAS is its friendliness. Mentioned before was the upper/lower case support. This produces a very readable program where code is upper case and comments are lower case. The search, insert, edit, print and display commands are also easy to use. They work quickly and correctly every time. If you are wondering whether you would get any use out of this sophisticated editor/assembler, consider these items. LDOS is a fully documented, wide-open operating system. We are encouraged to write our own filters and drivers and special routines. With LDOS you can easily open and read DIR/SYS from any language, and from Page 9 assembly language you can read or write ANY part of the disk if you want to. Also using assembly language, you can write filters, drivers, and special routines to fit your individual needs. LDOS is designed for this type of user enhancement. (Note: LC, the "C" compiler, will include EDAS-IV as its assembler. "C" is another language which is well suited for system-type programs.) If you have been thinking of taking full advantage of the LDOS architecture by writing a few assembly programs for special effects, EDAS is a good editor/assembler for this purpose. Now for descriptions of some of the outstanding features of EDAS-IV. I assume you have a moderate understanding of the basic purpose of the original EDAS. Some of the features described here are extensions of the original, and some are new. Since the most exciting features are entirely new, this article should still be informative for many of its readers without prior EDAS understanding. First is the treatment of line numbers. EDAS-IV supports line numbers similarly to EDAS 3.5.2, but the default for EDAS-IV is unnumbered lines. This may be startling to some, but now EDAS-IV can read any valid source file, numbered or unnumbered, without any specific action by the operator. Previously, you had to know whether each source file had line numbers, and also whether it had the standard EDAS 7-byte header. Now all of this is handled automatically! The reason for preferring unnumbered lines on disk is to save file space. In a typical source file, the line numbers take up 16% of the space. It also allows EDAS-IV to process the source for any language which does not require line numbers in the source file. One more wrinkle with line numbers is that if you want the numbers, and you intend to use the M-80 assembler, EDAS-IV has an option for using the M-80 line number format when the file is saved. This is imperative when you are using M-80 to produce listings of your assembled programs. Some new commands have been added with EDAS-IV. First is Copy. You may wonder how this is done since the operator is already in use for string replacement. The answer is the now does both functions. If you follow the with a number, then EDAS-IV assumes you are entering line numbers for a copy operation. Otherwise, it processes your keym as a string replacement operation. Due to popular request, the operator has been added. You may wonder what does, and the answer is that it does anything you want it to. EDAS-IV has a 50-byte patch area just for users, and can be used to jump to this patch area. I have been thinking of using this function for several things, such as showing the name of the module currently in memory, or changing the default extension during an edit session, or presetting assembly options, or plugging in my alternate keyboard routine, or ... Another keyboard feature in EDAS-IV concerns the BREAK key. In EDAS 3.5.2, if BREAK was the last key pushed before a Write operation, the BREAK could sometimes reappear during the write, aborting the write and producing a null file on disk. This was very disturbing, since there was no indication of this event to the operator. Now in EDAS-IV, all is well with BREAK correctly handled. Now we will begin some new features in EDAS-IV. The *GET operator has been enhanced and a *SEARCH operator has been developed. These operators tell EDAS-IV during an assembly to read more source code from files on disk. They are a way of expanding the module in memory to larger than memory size, and of including standard functions into an application program. The *GET operator just reads the named source file and inserts it in the current module at the current location. The enhancement to *GET is to allow nesting of up to five levels. This allows you to collect subroutines or macros (!) from separate locations into standard sets using a series of *GETS. The sets can be included en masse by naming the desired collection with a single *GET in your source module. *GET can appear at any point in your program; in the beginning for declaring equate names or defining macros, or in the body for loading standard subroutines. The *SEARCH operator is similar to *GET since it accesses files stored on disk, but what a difference! *SEARCH doesn't read sequential files. Instead it processes members from a partitioned data set, PDS. This is an exciting feature since *SEARCH will only load the members from the PDS which are referenced in your program. This means you can collect your standard subroutines into a PDS library, then search the library when assembling any program. Advantages are that the PDS saves space on disk, allows standardization of your subroutines, encourages centralization into a small number of subroutine libraries, and makes your application source much cleaner. You can even Page 10 begin packaging your subroutine libraries for exchange or distribution among other EDAS-IV users, for mutual benefit. The net effect of the *GET and *SEARCH operators is to standardize and reduce the effort of writing new code. The last new feature we will cover here is Macros. Of all the enhancements in EDAS-IV, this is the most exciting. You may wonder why it is mentioned last. The reason is that macros are a very complex feature, and I felt that some groundwork was needed before introducing them. Despite the complexity, the implementation in EDAS-IV is comprehensive; probably the best you will find in any micro-computer assembler. First, we will define a macro as an expression in a single line of code that is expanded by the assembler to produce many lines of code. The LDOS JCL feature is somewhat similar to assembler macros. Using a macro, you name none, or one or more values which are to be assigned to variables in the macro. The assembler then takes the values, inserts them in the necessary lines of code contained in the macro, and produces useable source code for further assembly. Doing this, you can tailor the effect of any macro by changing the values you use for parameters. For instance, a macro to move data from one area to another might be MOVE MACRO #FR,#TO,#LG LD HL,#FR LD DE,#TO LD BC,#LG LDIR ENDM To use this macro you could code ... MOVE FRAREA,(TOPTR),50 This single statement would be expanded to the four Z-80 instructions needed to perform the move. Notice that one area was defined by name, one was defined by a pointer, and the length by an explicit value. This shows the way you can use a standard macro to produce code from a wide variety of value expressions. The macro processor in EDAS-IV covers all bases in code expansion by allowing both positional and keyword notation. This means it is very flexible in the structures it can handle. For example, the above macro call could have been coded ... MOVE #FR=FRAREA,#LG=50,#TO=(TOPTR). These features alone are extremely useful to the assembly programmer, but EDAS-IV does more. It has implemented a full range of tests and comparisons on the macro variables for conditional logic within the macro expansion. With this you are truly able to generate any code structure desired. For instance, you can test how many parameters were coded in the macro statement, you can test the value of any parameter against a string or against an assembled label. You can test to see if a label named by a parameter is defined elsewhere in the program, or is referenced elsewhere. The tests can be nested to eight levels. The ELSE operator is available for either/or constructions. I may have left out some features, but EDAS-IV seems to have enough strength to handle the most sophisticated macro construction imaginable. Some macros I have already written do the following: initialize a program to run on the Model I or III, move data (see above), create a BASIC dummy program so an assembly program can define arrays in BASIC, read a line from a disk file similar to the @KEYIN vector for the keyboard, and on and on. At last, a summary. You should be very excited by EDAS-IV for several reasons. The macro processor is super. You can plan to use it for simplifying your coding. As in the MOVE example, it reduced the code lines by 75 percent. You can build a macro library, again using EDAS, then access it with *GET for each assembly. By putting *LIST OFF at the head of the macro library, and *LIST ON at the end, you can avoid having the text of the macros print in your program listings. The *SEARCH feature is also a terrific addition. You can build one or more subroutine libraries, then let EDAS select subroutines only as needed from them. (Note that the MISOSYS PDS program is required if you plan to build your own libraries.) These two features, macros and *SEARCH, should make assembly language much easier for many of us. Unfortunately, there is even more in EDAS-IV that could not be included in this review. You can be sure that the other features not mentioned are just as well implemented as the superstars we covered here. In closing, let me say that I am really enjoying EDAS-IV and hope that you will too. Maybe we can share an idea or a subroutine or a macro sometime as the new EDAS makes us more proficient programmers. Page 11 THE COMMUNICATING MICRO Gordon B. Thompson, Bell-Northern Research, Ottawa, Canada Even amongst the experts, a communicating personal computer is perceived as being a small computer that has been programmed to behave as a smart terminal for accessing large mainframe computers, or other similar services, via a communications link. The terminal programs that are on the market today stress this "mother and child" relationship, although most do offer some kind of symmetrical facility for transferring files. As small personal systems proliferate, other patterns of intercommunication can begin to emerge. However, if the models that the users have of the basic communication processes are too simplistic, they will fail to see the utility of those richer modes of interaction. The Shared Space Model of Communications. ----------------------------------------- The common, familiar telephone creates a common acoustic space that can be shared by two people, who may be many miles apart. The calling and the called parties can interrupt, talk simultaneously, and even share a cry, or whatever. As evidenced by their behavior, this simple property of the familiar telephone, this sharing of a common acoustic space, is not conceptually understood by most users. The shared space model of interpersonnal communication recognizes the prime importance of periods during which both communicants are talking, overlapping each other. The simple two wire telephone allows both parties to talk simultaneously, should they so desire. When this happens, we can say both parties are sharing the common acoustic space that the telephone provides. They are occupying the same space, at the same time. Perhaps one of the reasons Picturephone failed to achieve any significant market acceptance is that it really added very little to the size of the common information space that was shared between the communicating parties. That the Picturephone doesn't have a shared visual space can be demonstrated by considering what must be done to play a simple game of tic-tac-toe. When we start, you have the grid which I can see on my screen. Where do I put my cross? On the screen? That won't work because you would not see it. No, I must copy your grid onto a sheet of paper, viewed by my camera, and place my cross on that grid. Now, you, in turn, must copy my cross which you see on your screen, onto the grid on your paper. And so it goes. Because the two visual spaces are different, they can't be shared. The Shared Visual Space. ------------------------ A shared visual space is one where the people at both ends see the same thing at all times, and both have equal access to altering what they both see. In order to initiate an interrupt, they must be able to input to the common viewing screen simultaneously. They must share both the seeing and the creating or altering, just as they do on the telephone, when they can, at the same time, both talk and listen. Today's technology allows the creation of various forms of shared visual space. We can share a graphics space wherein we both see the same things, and can both input into that space. However, should our inputs collide, we must not react as computer purists and strive to protect the integrity of the individual data streams. NO! We must permit the streams to collide and produce what they will. An interruption is, after all, a change in the expected way the world is to unfold. Page 12 Also, as the shared visual space only makes sense when the two parties are also connected by telephone, any confusion, loss of synchronization etc., that might result, can be quickly resolved. Proper simultaneous voice-and-data shared space communication makes the computer scientist a bit uneasy. It relates to enhancing human interaction, not computer niceties. As the new technology got cheaper, and our ability to apply it improved, it became easier and easier to achieve simultaneous shared acoustic and shared visual spaces. Some spectacular teleconferencing experiences were generated this way. However, it was soon discovered that most people were not capable of operating in an unconstrained shared graphic space. Cartoonists had demonstrated what could be done, but for most people, the results more closely resembled the graphic outpourings of preschoolers. The more proscribed visual spaces of word processing and electronic broadsheets were then examined. This work was started using Radio Shack Model I machines, back in the VTOS era. Versions of ELECTRIC PENCIL and VISICALC were prepared that exhibited many of the shared space characteristics. However, with the advent of Radio Shack's TRS-80 Model III, and Logical Systems' LDOS 5.1.2, with its superb communications and device filtering features, a truly workable and fully practical system could be easily produced. The Reflex Connection. In the course of this work, a new form of interconnection between two stand alone computers was defined. In deference to the mirror like symmetry that the particular connection method features, the term "REFLEX" was used to describe it. In operation, both machines scan their incoming data lines every time they scan the keyboard. If a locally generated keyboard character is available, they send that character to both the local CPU and to the outgoing data line. if a character is found in the RS232 incoming register, it is passed only to the ocal processor. In effect, both machines are fed from both keyboards, and respond equally to keystrokes from either. They are fully symmetrical, in a reflexive sense. Such a connection produces a shared visual space when the two machines are similar and are running similar software. If your TRS-80 is loaded with SCRIPSIT, suitably patched so as to use the LDOS keyboard driver, and the REFLEX filter is active, and if my machine is similarly configured, we can connect the two machines together via a data line and, while talking on the telephone to each other, jointly edit the same contract, or whatever. Whatever you do to your copy happens instantly to mine, and vice versa. And while this is happening, we are talking to each other about the changes we are making. We will arrive at a very powerful, democratically achieved consensus when we do this. With today's modems, this style of working requires two separate telephone lines, one for the telephone connection and one for the data connection. With such an arrangement, two lawyers, separated by perhaps many thousands of miles, can confidently and very quickly, jointly produce or examine a contract, and so arrive at a mutually satisfactory one in a mere fraction of the time required if the mail, either electronic or conventional, were used. Press releases can be jointly perused, and a strong consensus built about the document, even though many miles may separate the communicants. It is far more meaningful to be able to see exactly what it is that is being discussed than to see the face of the person at the far end. Any significant information contained in the facial clues is also present in the aural clues, already available over the phone. The labels of Appendix I were composed using a Model I and a Model III running Scripsit reflexively. However, our experience to date in demonstrating and eliciting usage of the reflexive way of working with another person suggests that although this might be the world's greatest mousetrap, few are trampling down our door. It is much too early to be certain about the causes of this resistance, but one hypothesis suggests that not only does our ability to learn new languages diminish significantly during our teens, but so does our ability to learn new modes of communications. If this is the case, then the big market for shared space or reflexive word processors must wait for a generation to come of age that has a different communications background, one that involves more sharing of information. Page 13 In the meantime, those who are at the leading edge, the explorers, can be encouraged to use the technique. Consequently, we have chosen to place the requisite software in the public domain, and publish in journals that have a readership most likely to apply the ideas of simultaneous voice and data shared space interaction between communicating micros. The LDOS operating system is, if not the only viable one, far and away the most suitable one, to support REFLEX. Two appropriately programmed communicating personal computers can be so linked over a simple low speed data line as it is only the key strokes that get transmitted, and not the screen updates. The resident application package, present at both ends, be it SCRIPSIT, VISICALC or whatever, handles the demanding chore of updating the screens at both ends. Consequently, any low speed data facility, such as a 300 baud link, is very adequate. Perhaps, as familiarity with this shared space mode of working grows, and a market develops, smart modems specifically designed for this particular way of communicating may evolve. Such modems would eliminate the need for two telephone lines by sharing one line for both data and voice. As the data rate requirement of this mode of communication is extremely variable, ranging from an upper limit set by the need for speedy file transfer, down to a few keystrokes per second, the development of such apparatus, and the requisite interfacing drivers for the computers may not be easy. Since it is only the keystrokes that are sent, non-similar machines using identical man/machine protocols can communicate. VISICALC, if properly modified, can run between an Apple and a TRS-80 in a fully reflexive, shared space way. The only difficulty is that the Apple lacks a full set of cursor positioning arrows, and needs some interfacing software to make up for this deficiency when connected to other machines with the full up/down, left-right arrow key complement on the keyboard. A "preloader" that conditions an Apple II to interpret the standard Apple VISICALC disk in such a way that VISICALC runs reflexively is now commercially available. Vast differences in display sizes, such as that between the Apple and the TRS-80 are insignificant when the subject matter is viewed on a full screen editor that is driven by cursor position. The interest area is always where the cursor is, and not at the other side of the screen, where the display disparencies cause different material to be seen. In the case of the 40x20 display of the Apple and the 64x16 display of the TRS-80, the discrepancy was essentially unnoticed in operation. The REFLEX filter, when active, allows any application package that runs on the TRS-80, and uses the system keyboard driver, to be run reflexively with another similar machine. Model I machines can work with Model III machines, for LDOS makes them sufficiently similar. As LBASIC, the LDOS version of BASIC, uses the system keyboard driver, anything written in BASIC, that does in fact use the system keyboard driver, can be run reflexively. Prosoft's current version of NEWSCRIPT, being largely written in BASIC, uses the system keyboard driver for the majority of its commands, and so can be made to operate quite well with REFLEX. The BASIC code must be modified somewhat, however. The Prosoft driver, NS/CMD, must be placed at the top of memory as it is not fully relocatable code. The various BASIC programs look at the Keyboard DCB to determine the scratch memory's location. However, once the LDOS keyboard driver and the REFLEX and MINIDOS filters have been put in place, the DCB no longer points to where it was expected to point. By setting the particular variables involved to -1765, the problem is avoided. Once the LDOS driver is installed, the overflow error message indicates this problem, and identifies the line that needs fixing. Peeks to &H4016 and 7 are the culprits. The final result is a very powerful word processor capable of fully communicating with another of its ilk in full REFLEX, of working alone, or of working into a large IBM mainframe system. This combination is the essence of a communicating micro! Page 14 Installing the LDOS keyboard driver somewhat alters the controls for NEWSCRIPT. The key, which was used for control, now becomes , with the pushed slightly ahead of the key. Only the toggle mode of control character entry remains, the continuous mode having been lost. It doesn't use the system keyboard call, apparently. If the keys are depressed, with the key being a bit ahead of the key, then REFLEX and MINIDOS are addressed. Finally, where the key was previously used to break a line, now does this. The key returns control to LBASIC. Although it might seem that the controls are a bit more awkward, only the delete a bunch of characters is significantly slowed. Other techniques, such as breaking the line, and deleting to the end of the line make up for it. At the time of writing, a bug was noted in the printer driver portion of NS that becomes active when any keyboard driver other than NS/CMD is used. This bug persists even when the DCB path is "bent" so it loops into NS and then into either the regular or the LDOS keyboard drivers. The REFLEX filter allows the TRS-80 to run in three modes, the conventional LOCAL mode, the REFLEX mode, and a simple terminal mode. These modes are chosen by selecting "I","U" or "Y" respectively, while the combination is depressed. The more logical "R" and "T" keys are used by LDOS's MINIDOS, and so were not available. REFLEX needs an eight bit data word as the LDOS keyboard driver can generate codes that need this longer word length. Consequently, to use REFLEX, it is necessary to first install the LDOS keyboard driver with the SET command, and then to install the proper RS232 driver with the 8 bit word option. The REFLEX filter can then be installed. The LDOS filter MINIDOS can then be installed, and the machine's configuration captured. The assembler listing for REFLEX/FLT for the TRS-80, Model III is in Appendix 1 with the changes noted for Model I. The Simultaneous Voice and Data, Shared Space way of working together increases the need for easy ways to toss files back and forth between the communicants. Most application packages, of the word processing and broadsheet class, do not cater to sending or receiving the current work space. Two notable exceptions are VISICALC for the TRS-80 Model I, and Prosoft's NEWSCRIPT. Because the LDOS operating system, in SYS2, recognizes devspecs, like *SI, *KI etc., and substitutes the appropriate device for the usual disk drives and a filespec, NEWSCRIPT achieves this desirable feature, with effort on Prosoft's part. SCRIPSIT, unfortunately, clobbers the * in the Special Command area, and so can't send the contents of its work space in this easy fashion. This shouldn't be too hard to fix, and perhaps someone will locate this constraint and remove it. VISICALC is rather special with regard to sending and receiving its work space. The feature is mentioned on the summary card, not in the instruction book. However, substituting :R for a filename, as is indicated on the instruction card, fails to produce the desired results. The code is simply incorrect in the Model I version. With a few fixes, however, it can be made to work. This feature even further enhances the value of VISICALC. Details of the fix are in Appendix II. If the principal utility of the serious microcomputer is in the broadsheet and word processing areas, then Prosoft's NEWSCRIPT and the LDOS patched version of Model I VISICALC provide a means of doing these important things in a fully reflexive way. The Model III machine, because of its interrupt driven RS232 interface, does a somewhat better job than the older Model I. Also, the Model I seems constrained to booting in single density if NS/CMD is to be at the top of memory. Interactive games, played in simultaneous voice and data in ways that are perhaps more complex than simple REFLEX, is a whole new area of possibility. A tic-tac-toe game, in BASIC, is shown in Appendix III. Page 15 This game uses the computers to handle the displays while the two players, connected via telephone and a data line, supply the logic. The computers act as referees and accept only legal moves. This game requires LDOS with the keyboard driver active, *SI active, and the REFLEX filter operating on *KI. This is a trivial game, but it does illustrate the notion of games in silmultaneous voice and data by using two communicating' micros in REFLEX. One very popular current management theory suggests that the levels of mutual trust that exist in North America may be too low for effective human interaction. Enlarging the size of the common information space that communicants share is one way of encouraging the building of mutual trust. The trust level and the ease with which we adapt to more sharing of our information are likely quite symbiotic. Increases in one feed the other. As the technology gets more and more complex, perhaps we need to develop means of increasing the intellectual synergy between managers rather than increasing the competition. Learning to handle simultaneous voice and data shared space communications with our Communicating Micros is one giant step towards such an objective. EDITOR'S NOTE: The EQUate listings below contain the differences between the Model I and III. Use whichever version is appropriate. APPENDIX I 00100 ;RELOCATABLE REFLEX. 00110 ;By Jim and Gordon Thompson.June, 1982. 00120 ; 00130 ; MOD 3 MOD 1 00140 ; 00150 @ABORT EQU 4030H 00160 DODCB$ EQU 401DH 00170 @DSPLY EQU 4467H 00180 @EXIT EQU 402DH 00190 @GET EQU 0013H 00200 HIGH$ EQU 4411H 00210 KIDCB$ EQU 4015H 00220 KIJCL$ EQU 42BEH ;43BEH 00230 @PUT EQU 001BH 00240 RFLAG EQU 4413H ;401AH 00250 SFLAG$ EQU 442BH ;430FH 00260 SIDCB$ EQU 42C8H ;43C8H 00270 ; 00275 ORG 5200H 00280 ENTRY: PUSH DE ;SAVE DCB 00290 LD A,(SIDCB$) ;*SI DCB ADRESS 00300 BIT 03H,A ;CHECK OFF/ON 00310 JR Z,GOOD ;*SI HAS DRIVER 00320 LD HL,NOSI ;"DUMMY!" 00330 CALL @DSPLY ;NO *SI MSG TO *DO 00340 JP @ABORT ;BACK TO SYSTEM 00350 GOOD: LD HL,BANNER ;REFLEX TITLE 00360 CALL @DSPLY ;DISPLAY IT. 00370 LD BC,LAST-START ;PROPER LENGTH 00380 LD HL,(HIGH$) ;PUT INTO MOD III 00390 INC BC ;HIGH$. 00400 XOR A 00410 SBC HL,BC 00420 LD (HIGH$),HL ;NEW HIGH$ FOR MOD3 00430 POP IX ;RECALL DCB ADDRESS 00440 INC HL 00450 LD A,(SFLAG$) ;SFLAG$ 00460 BIT 5,A ;DO in effect? Page 16 00470 JR Z,NODO 00480 LD IX,KIJCL$ ;KIJCL$ 00490 NODO: LD A,(IX+1) 00500 LD (START+1),A ;ADDRESS LOADING 00510 LD (RESTRT+1),A 00520 LD A,(IX+2) 00530 LD (START+2),A 00540 LD (RESTRT+2),A 00550 LD (IX+1),L 00560 LD (IX+2),H 00570 EX DE,HL 00580 LD HL,START ;COPY UP UNDER NEW 00590 LDIR ;TOP OF MEMORY 00600 XOR A 00610 LD (RFLAG),A ;SET REFLEX BYTE TO 00620 JP @EXIT ;ZERO.GO TO SYS. 00630 ;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 00640 ;XX ACTUAL FILTER 00650 ;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 00660 ; 00670 START: CALL 0H ;CALL TO DRIVER 00680 INIT: PUSH AF 00690 OR A ;KEY PUSHED? 00700 JR Z,ABORT ;NO, GO AWAY! 00710 CP 080H ;CHARACTER GTR 80H? 00720 JR C,ABORT ;PASS CHAR CALLER 00730 AND 0FFH 00740 RTEST: CP 0F5H ;TEST FOR "U" 00750 JR NZ,LTEST ; SHTF & CLR. 00760 POP AF 00770 LD A,01H 00780 LD (RFLAG),A ;IN REFLEX,SET FLAG 00790 LD A,52H 00800 LD (3C38H),A ;PUT "R" TO SCREEN 00810 XOR A 00820 JR INIT 00830 LTEST: CP 0E9H ;TEST FOR "I" 00840 JR NZ,TTEST ; SHFT & CLR. 00850 POP AF ;IN LOCAL, SO 00860 LD A,4CH ;WRITE "L" TO 00870 LD (3C38H),A ; SCREEN. 00880 XOR A ;SET A REG TO ZERO. 00890 LD (RFLAG),A ;SET REFLEX FLAG 00900 JR INIT ; TO ZERO 00910 TTEST: CP 0F9H ;TEST FOR "T" 00920 JR NZ,ABORT ;PASS CHAR TO CALLER 00930 POP AF 00940 PUSH DE 00950 PUSH IX 00960 LD A,54H ;WRITE "T" TO 00970 LD (3C38H),A ; SCREEN 00980 REINIT: LD IX,KIDCB$ 00990 LD DE,KIDCB$ 01000 RESTRT: CALL 0H 01010 OR A 01020 JR Z,SI 01030 CP 0E9H ;IS IT CLR SHFT I? 01040 JR Z,REPAIR 01050 CP 0F5H ;IS IT CLR SHFT U? 01060 JR Z,REPAIR 01070 CP 0F9H ;IS IT CLR SHFT T? 01080 JR NZ,CONT ;YES. Page 17 01090 JR RESTRT ; GO BACK. 01100 CONT: PUSH AF 01110 LD DE,SIDCB$ ;*SI DCB ADDRESS 01120 CALL @PUT ;OUTPUT TO SI 01130 POP AF 01140 PUSH AF 01150 LD DE,DODCB$ ;*DO DCB ADDRESS. 01160 CALL @PUT ;WRITE CHAR TO *DO 01170 POP AF 01180 SI: LD DE,SIDCB$ ;*SI DCB ADDRESS 01190 CALL @GET ;INPUT FROM *SI 01200 OR A 01210 JR Z,REINIT 01220 LD DE,DODCB$ ;*DO DCB ADDRESS 01230 CALL @PUT ;WRITE TO *00 01240 JR REINIT ;END OF "T" LOOP 01250 REPAIR: POP IX 01260 POP DE 01270 JR INIT 01280 ABORT: LD A,(RFLAG) ;SEE WHAT MODE WE IN 01290 OR A ; 1 FOR REFLX, 0 LOC. 01300 JR Z,LEAVE ;IT'S LOCAL 01310 POP AF ;IT'S REFLEX 01320 PUSH AF 01330 OR A 01340 JR NZ,TALK ;KEY, GO TO *SI 01350 POP AF ;NO CHARACTER. 01360 LD DE,SIDCB$ ;*SI DCB ADDRESS. 01370 JP @GET ;GET IT. 01380 TALK: PUSH DE 01390 LD DE,SIDCB$ ;*SI DCB ADDRESS 01400 CALL @PUT ;OUTPUT *SI. 01410 POP DE 01420 LEAVE: POP AF 01430 LAST: RET ;RETURN TO CALLER WITH CHAR. 01440 NOSI: DB ' (((((( SI DRIVER NOT ACTIVE ))))))' 01450 DB 0DH 01460 BANNER: DB '*** REFLEX FILTER *** ',0AH,0AH 01470 OB 'June 1982 Version.',0AH 01480 DB ' I LOCAL',0AH 01490 DB ' U REFLEX',0AH 01500 DB ' Y TERMINAL' 01510 DB 0DH 01520 END ENTRY This is the BINHEX listing for the REFLEX filter. The checksum is C6. D5 3A C8 42 CB 5F 28 09 21 F0 52 CD 67 44 C3 30 40 21 14 53 CD 67 44 01 98 00 2A 11 44 03 AF ED 42 22 11 44 DD E1 23 3A 2B 44 CB 6F 28 04 DD 21 BE 42 DD 7E 01 32 58 52 32 9B 52 DD 7E 02 32 59 52 32 9C 52 DD 75 01 DD 74 02 EB 21 57 52 ED B0 AF 32 13 44 C3 2D 40 CD 00 00 F5 B7 28 76 FE 80 38 72 E6 FF FE F5 20 0E F1 3E 01 32 13 44 3E 52 32 38 3C AF 18 E4 FE E9 20 0C F1 3E 4C 32 38 3C AF 32 13 44 18 D4 FE F9 20 4A F1 D5 DD E5 3E 54 32 38 3C DD 21 15 40 11 15 40 CD 00 00 B7 28 1E FE E9 28 2B FE F5 28 27 FE F9 20 02 18 EC F5 11 C8 42 CD 1B 00 F1 F5 11 1D 40 CD 1B 00 F1 11 C8 42 CD 13 00 B7 28 CC 11 1D 40 CD 1B 00 18 C4 DD E1 D1 18 86 3A 13 44 B7 28 14 F1 F5 B7 20 07 F1 11 C8 42 C3 13 00 D5 11 C8 42 CD 1B 00 D1 F1 C9 20 28 28 28 28 28 28 20 53 49 20 44 52 49 56 45 52 20 4E 4F 54 20 41 43 54 49 56 45 20 29 29 29 29 29 29 0D 2A 2A 2A 20 52 45 46 4C 45 58 20 46 49 4C 54 45 52 20 2A 2A 2A 20 0A 0A 4A 75 6E 65 20 31 39 38 32 20 20 56 65 72 73 69 6F 6E 2E 0A 3C 43 4C 45 41 52 20 53 48 49 46 54 3E 20 49 20 4C 4F 43 41 4C 0A 3C 43 4C 45 41 52 20 53 48 49 46 54 3E 20 55 20 52 45 46 4C 45 58 0A 3C 43 4C 45 41 52 20 53 48 49 46 54 3E 20 59 20 54 45 52 4D 49 4E 41 4C 0D Page 18 APPENDIX II. ** VISICALC PATCH TO FIX RS232C FUNCTIONS ** MODIFICATIONS TO LDOS PATCHED VISICALC. .Hardware differences between MODEL I & III force .the use of calls to 1B & 13 for RS232C in and out. .RS232C Interface MUST BE PRESET TO DESIRED STATUS. . .Code at following address previously set the RS232C .hardware when a ":R" was detected. This is now much . reduced as a consequence of using the system calls. X'9B3C'= 28 05 FE 50 CA 8B 9B B7 C9 . .This code senses MODEL I OR III and loads DE with .*SI DCB address. It will be called during both SEND and .RECEIVE operations. X'9B45'= F5 3A 25 01 FE 49 28 05 11 C8 43 18 03 11 C8 42 F1 C9 . .OUTPUT A BYTE TO *SI X'9B7C'= CD C0 9B D5 CD 45 9B CD 1B 00 D1 B7 C9 00 00 . .KEYBD SCAN, REPAIRED HANDSHAKE AND RECEIVE A BYTE X'9751'= FA D5 CD 45 9B CD 13 00 D1 C2 57 9B CD 2B 00 28 F0 3E 60 37 C9 B7 C9 00 00 . .CHECKS INCOMING BYTE FOR HANSHAKE X'9B57'= FE 5B 28 02 B7 C9 3E 60 37 C9 . ** NOTICE ** .Although VISICALC expects a &H5B to terminate the RECEIVE .state, the transmit mode never sends it. Code at 9BC0 is .never triggered into doing it, as the required &H60 is .never there, so it never sends the &H5B. . .Incidently, in the original code, the send handshake was .&H5B and the expected receive one &H5E! We chose the &H5B .for both. They are located at 9BC5, and 9B58 as a result .of the patch. .Because the transmit mode doesn't automatically trigger .the termination of the receive mode, the RECEIVE code has .been altered to also accept any keyboard entry as a .request to terminate the reception of incoming data, and .return to normal VC. . .Should someone else be more successful at making the .transmit send the proper termination signal, the receive .routine, as it now stands, will terminate properly, as .it contains the requisite code to terminate the receive .function upon the receipt of &H5B. . APPENDIX III EDITOR'S NOTE: Due to the length (3 pages) of the Tic Tac Toe listing, it was not printed in this issue. A copy of the listing may be obtained by sending a large, self addressed stamped envelope (postage will be approximately 37 cents.) Page 19 BASIC and File Structure - A Beginner's View by Wes Goodnough This article is written by Wes Goodnough, a relatively new "microcomputer" user, although he has experience on larger machines. It covers the subjects of file structure and business use of a microcomputer. Since for a long time microcomputers were marketed principally as a hobby and personal product, software production had tended to focus on entertainment. More recently, however, the business world has begun to recognize the advantages of "a computer on my own desk that will give me the information I need to have." More and more micros are appearing on management desks, and sometimes in spite of the wishes of professional people in the "Department of Data Processing". In response to this growth, software offerings for business usage are also burgeoning. If the TRS-80 Model III is to have a place in business usage, it is operating systems software of the quality and scope of LDOS that will make it a contender in this market. While entertainment programs have tended to focus on getting the most out of a computer in terms of manipulating its displays and in terms of interacting creatively with the hobbyist-operator, business oriented software must have other concerns. Indeed, when you come right down to it, the reasons for the proliferation of computers in our society in the first place have been business directed. The traditional rational for computer usage in business organizations is that they contribute to reducing the "cost of doing business", that they help an organization grow strong by providing more timely and accurate reports, and that they assist in insuring the basic satisfaction of customers doing business with the firm. As such, it is the DATA to be processed itself that is of concern to a business, not the creativity of the display nor the "elegance" of the programming. Happily, LDOS stands out as providing many enhancements that complement this concern. Without a doubt, the VERSATILITY provided by LDOS is a major asset for business usage of the Model III. The availability and flexibility of drivers and filters as well as the JCL features within LDOS hold great opportunity for business application as well. And the device independence features of LDOS allow the use of high capacity storage devices. Above all, however, business data processing applications must be able to organize, store, retrieve, and manipulate literally millions of bytes of information, and an operating system that lends itself to this task is a must. For those who contemplate using a Model III in their business or for those who are intent on producing productive business software for the Model III, LDOS with its file friendly features stands out as a major resource. It is my intent in this article to outline the basic file structures used in business data applications and to note some possible ways they may be implemented using the features of LDOS and LBASIC. SEQUENTIAL FILE ORGANIZATION The sequential file structure is the native structure of files on magn0 ic tape where processing must start at the beginning of the tape and proceed throuqh one record after another to completion. It is fundamental therefore, that with sequential file structure, even on direct access media, that the only sure entry point is at the beginning of the file. In addition, it is not hard to visualize that because new data cannot be inserted between records already written on the media, it is necessary in updating sequential files to re-write the entire file. Preferably this will be done on a separate drive in order to maintain at least two versions of the file. The term "Father-Son Processing" refers to the practice of maintaining a rotation of separate disks (usually three) to accomodate the update and security back-up of sequential files. It is inherent in sequential updating that the processing be batch oriented, for it is most efficient to make as many changes to the file as possible on any pass through it. Page 20 While sequential file structure does not readily lend itself to interactive applications, it should not be assumed that there is no place for sequential files in Model III applications. Indeed certain cases are actually improved with sequential access methods. In the case where all or nearly all of the records on file are used during processing, it is both efficient and orderly to proceed through the file from beginning to end. Such is the case in payroll applications where every record is examined and processing ought to proceed in an orderly fashion so as to provide adequate controls over the results. The strict order of records in a sequential file can also serve to control the order of other processing. Such was the case in an Election Returns System with which I am familiar. In order to produce a periodic printed report of the progress of precinct returns on election night, a file of candidates and proposals was prepared. Each pass through this file presented in fixed order the pertinent information to enable access to other files and tables where the vote tabulation was stored, and to format and print the desired report. LBASIC supports the Disk BASIC of TRSDOS and uses the same structure and nomenclature for sequential files. Output to files is through the PRINT# instruction while input is through the INPUT# and LINE INPUT# instructions. Using these instructions, record formatting must be handled entirely by the programmer by the construction of the string variable argument used with these instructions. Concatenation of separate strings is one method of building the string arguement. If the programmer is careful to provide for a constant field length as well as for left or right justification and zero or space filling in each field, he will be able to extract the information accurately from the record when it is read from the magnetic file at a later date. To do this he will use the string functions LEFT$, RIGHT$, and MID$ as in the following example. 100 A$ = "TRAN" 110 INPUT B$: IF LEN(B$) > 15 THEN 110 ' a real 115 IF LEN(B$) = 15 THEN 130 ' hassle to 120 B$ = B$ + STRING$(15 - LEN(B$)," ") ' get record 130 INPUT C: IF C > 999 THEN 130 ' set up for 140 C$=STR$(C):C$=RIGHT$(C$,LEN(C$) - 1) ' output to 150 C$=RIGHT$("000" + C$,4 - LEN(C$)) ' media 160 R$ = A$ + B$ + C$ 170 PRINT #1, R$ 180 ................................. ..................................... ..................................... 790 ................................. 800 INPUT #1, R$ ' also a hassle 810 AS = LEFT$(R$,4) ' to retrieve 820 B$ = MID$(R$,5,15) ' data on file 830 CS = RIGHT$(R$,4): C = VAL(C$) ' via string 840 '................................ ' functions By far the outstanding feature of LDOS as it pertains to sequential file handling is the expanded file OPEN Modes provided by LBASIC. In business data processing the data filed on magnetic media represents an almost priceless asset to an organization. The loss of a siqnificant file could be disastrous for even a healthy firm. By providing for "ON" (open new file at beginning ), "OO" (open existing file at beginning ), "EN" (open new file for extension), and "EO" (open existing file for extension), the programmer and the systems analyst can help prevent data loss due to operator errors. In updating sequential files, the "Father" file should be opened as "OO" insuring that the file is present where it is expected before processing begins, and that the file pointer is located at the beginning of the file. Then the "Son" file should be opened as "EN" or as "ON", likewise insuring that no other version of the file is pre- sent. An error returned on these entries would alert the operator to the possibility that a wrong disk was mounted and that data was about to be over-written. Page 21 SEQUENTIAL PROCESSING UNDER RANDOM MODE For practical purposes, distinctions should be made between the term "Sequential" as a file mode and "Sequential" as an access method. On the one hand, the term is used to signify the file mode as distinguished from "Random", (viz; OPEN "O", 1, "FILE"). On the other hand, "Sequential file access method" may reasonably refer merely to the procedure of working through a file from beginning to end. Once this distinction is understood, new doors are opened to the programmer for he will understand also that by opening his files as "Random" mode files, ("RO", "R", "RN"), he may preserve the advantages of sequential access processing and still take advantage of the "Random" instruction set, (LSET, RSET, FIELD, MKI$/CVI, etc.). Sequential processing under the "Random" mode is simple enough to be quite obvious. A FOR-NEXT loop is designed with the FOR-NEXT variable as the LRN of the GET instruction. Foremost among the advantages of the "Random" mode is the simplicity of constructing and interpreting the data record. The FIELD statement allows for identifying fields within the file buffer itself, both in terms of field tags and field lengths. Using the blocked file mode of LBASIC, logical records can be defined with sizes from 1 to 256 characters without the programmer having to distinguish between the various logical records within one physical record. Only one record is defined by the FIELD statement, and LBASIC extends that through the file buffer as needed. Once a record is accessed, any part of the record may be referenced by simple use of the string variable tag assigned by the FIELD statement. Maximum flexibility is provided by the ability to "re-define" the record through succesive FIELD statements. Likewise in formatting the record for output or in making changes to a part of the record, the FIELD string variables simplify access to the part of the record under immediate consideration. The LSET and RSET instructions not only assign values to the FIELD variables, but they also right or left justify the string within the "field", (including space filling). As for "zero filling" of numeric fields, the process is not required at all since numeric values are converted to strings representing the Binary configuration of the numeric value by the MKI$, MKS$, and MKD$ functions. Re-conversion is done with CVI, CVS, and CVD functions. The following is an example of the use of these "Random" features in sequential processing. Compared to the string manipulation in the previous example this is straightforward. 50 OPEN "RO", 1, "FILE",21 ' Open as Random 60 FIELD 1, 4 AS A$, 15 AS B$, 2 AS C$ 70 ................... 90 ................... 100 FOR R 1 TO LOF(1) ' Get one after another 110 GET 1, R ' from begining to end ....................... 260 NEXT R 270 ................... ....................... 540 ................... 550 LSET AS = "TRAN" ' No fuss assignment of 560 LSET B$ = B1$ ' of fields - Correct 570 LSET C$ = MKI$(C) ' lengths and justified 580 PUT 1, LOC(1) ' Only one disk needed 590 ................... While the sequential file mode may not be frequently used in business applications for the Model III, it is certain that "sequential access methods" are important tools to be understood and used, even under "Random" mode. Page 22 DIRECT ACCESS FILE ORGANIZATION Once the programmer understands the use of the "Random" mode instruction set he will see the facility it offers in manipulating data in files. However, the subject of "Random" files is much broader than consideration of the FIELD and LSET instructions. Disk storage devices are considered as "Random" or "Direct" access devices, meaning that there is the ability to go directly to the record you want and read it without having to search sequentially from the beginning of the file. We know that LBASIC will allow us to specify the LRN of any record on file and, using the GET instruction, to pick out that specific record from the file. But how can WE know what LRN to specify unless we have the file organized in a way that will allow us to determine what it ought to be? This is the matter of file organization for direct access. It may already be apparent to the reader that there is great confusion of terms in this subject. It seems that different manufacturers delight in using words in ways intended to distinguish their products rather than to communicate with a standard nomenclature. For purposes of this discussion "Random" will refer only to the LBASIC file mode as specified in OPEN "RO", or "R", or "RN". "Direct access" will refer to the general ability to go directly into a file and retrieve a specified record. Where any other meanings are intended for these terms, it will be clearly expressed. THE RELATIVE FILE There are basically only TWO ways to organize a file for direct access, though certainly there are many variations within each. The first to be considered is the RELATIVE file, ( also sometimes referred to as a "direct" file. ) The Relative file structure is made up of records which are stored in relative locations within the file. For instance, a file of the states of the Union would contain 50 records and each state could be assigned a key number between 1 and 50 to represent both its order of statehood and its relative position on the file. Thus the 18th record on the file would also be the 18th state admitted to the Union. This plan is simple only so long as the key value does not exceed the maximum number of records in the file. Where the range of key values does exceed the number of records allocated, there must be some way to convert the key into a relative position number. One method for randomizing record placement is to divide the key by a prime number and use the remainder as the LRN. In the above example 47 would be the largest prime less than the file size of 50. For a key of 321, the calculation would be: 321 / 47 = 6 plus a remainder of 39 Hence the record with key 321 would be placed in relative position 39. There are many such algorithms, each with its own properties and characteristics when used with a specific file. No matter what algorithm is chosen, it should ideally result in deriving LRNs evenly distributed over the range of the file and with a minimum of duplications. (In the example, key numbers 274 and 368 would also derive the LRN of 39.) In case of a duplicate LRN being derived by the randomizing algorithm, there must be a way to determine an alternate location for the record. Very often it is to simply begin searching subsequent locations on the file until an open spot is found. Since the derivation of duplicate LRNs is more likely to happen as the file approaches being full, it is helpful to allocate extra positions to minimize the amount of sequential searching that needs to be done. The main advantage of the relative file structure and the randomizing algorithms is that it provides the very fastest access times. Usually only a simple calculation and one I/O to the storage media are needed to retrieve a record. Therefore this is the method to choose when speed of access is very important. However, trade-offs are necessary to maintain this speed. If there are many duplicate Page 23 LRN derivations, then access time will be slowed and the advantages lost. Therefore it is important to be sure that the algorithm used is adequate for the application. Leaving extra room on the file may be a necessary overhead, for even though the extra space will never actually be used, access times will be minimized. The coding to implement the search in relative files is very simple. Whether it is to find a place to insert a new record or to find a record on file, the process is the same, a simple calculation and a GET instruction. 100 R = KEY - 47 * INT(KEY/47) ' The calculation 110 GET 1, R ' The file access 120 IF U$ = "1" THEN GET 1: ' Check if duplicate GOTO 120 ' If so get another 130 LSET ALL$ = REC$ ' New rec into buffer 140 PUT 1, LOC(1) ' Write to file 150 PRINT "RECORD IS FILED" ....................... ....................... 200 R = KEY - 47 * INT(KEY/47) ' The calculation 210 GET 1, R ' The access 230 PRINT "RECORD IS FOUND" INDEXED SEQUENTIAL FILES The second method of file organization for direct access is the Indexed file. The Indexed Sequential Access Method or ISAM file organization is the most common example of the structure. With ISAM, records may be ordered in the file in an ascending or descending sequence by whatever key is specified. In addition there is an index to the file containing the LRN of every record along with its key. Much the same as a book index indicates the page where a subject is mentioned in the book, this index indicates where in the file a specific record will be found. 8y first looking in the index for the key being sought, the LRN is found and with only one GET, the record is in hand. The idea is that searching through the index is much quicker than searching through the file on the disk. Indeed using a "Binary Search", a specific item can be found in an index of 1000 items in an average of only 6 looks, while for an index of 10,000 items it will take an average of 7 looks. If the index is in memory (as in a matrix), this will provide fast access, although not as fast as relative file access. In updating the ISAM file, it is only necessary to add new records at the end of the data file, and insert the appropriate entry into the index. For deletions it is enough to remove the appropriate item from the index, and for changes no alteration to the index file is necessary. While it is easy to understand ISAM file updating, putting it together is not quite so simple, for there are many considerations to complicate it. First is data file management. If the data file will be maintained in strict sequential order, then it is necessary to determine how this is to be done. How will new records be added between existing ones? Or should new records be added to the end of the file, relying upon the index to give the ordering? Should deletions be removed altogether from the file or only flagged as being deleted? Each of these questions must be considered from standpoint of the programming required as well as of the needs and requirements of the specific application. Secondly, it must be determined just how to handle the index itself. No matter how the data file is managed, it is paramount that the index be kept in good order. After making alterations to the index it may be necessary to resort it. For this the CMD "O" feature of LBASIC is an asset in that an index contained in a string matrix can be sorted reliably, and quickly. Even a part of the matrix can be sorted if necessary. Other questions involve the management of the index. Should it be a file itself, or a part of the Data file, (maybe the first few sectors)? Page 24 Should it be read into memory for use, or should it be manipulated on disk? Or should the index be "hard wired" into the program? The alternatives here are all dependent at least in part by the size of the index file and the requirements of the application. A small index could be "hard wired" if the data file contents do not change. Regardless of the variations resulting from these considerations, there are certain basics to coding the file access. The Binary search is the key to it and might be like this example. 100 A=1 ' Lowest LRN 110 Z=50 ' Highest LRN 120 H=50 ' Current high LRN 130 L=1 ' Current low LRN 140 M=0 ' Middle point 150 ' KY$ is the key being sought. 160 ' K$(x) is the matrix containing the index. ...................... 200 H=Z : L=A 210 IF LEFT$(K$(H),2) = KYS THEN 500 ' Found if true 220 IF LEFT$(K$(L),2) = KYS THEN 600 ' Found if true 230 M = INT((H-L)/2): ' Mid point IF N = L OR M = H THEN 600 ' Doesn't exist 240 IF LEFT$(K$(M),2) = KY$ THEN 500 ' Found if true 250 IF LEFT$(K$(M),2) > LEFT$(K$(L),2) ' Make M into THEN H = M ELSE L = M ' the next H or L 260 GOTO 230 ' Try again 270 .................. ...................... 500 PRINT "KEY IS FOUND": STOP 600 PRINT "RECORD DOES NOT EXIST": STOP FROM FILES TO DATA BASES Once the use of indices is mastered, it is only a short step from matters of file organization to matters more resembling data base structure. By using the same principals of indexing by keys and LRNs it is possible to create multiple indices for one or more files, (these indices are referred to as "inverted lists"). Each index is based on a key from a separate field or fields of the record. As the various indices are sorted in appropriate sequences, several paths through the file are available. By one it might be possible to read through in alphabetic order on salesmen's names, on another by monthly sales totals. With a little imagination and the application to make it meaningful, it would not be difficult to combine characteristics of more than one file in a single index and relate data of one file to data in another. Another technique that does not qualify as a file organization but that is useable for relating one record and file to another is that of the linked list, (the use of pointers). With just two characters (using the MKI$ function on a given LRL) it is possible to include in one record the information for access to another record on the same file or even a different file. Chained files incorporate two such fields, one to point to the prior logical record and one to point to the next logical record. With such a file, all new records are added to the end of the file, but the chaining pointers are set to locate the record in its proper file sequence according to keys. Likewise, deletions are executed by changing the appropriate pointers to bypass the deleted record. Both linked lists and inverted lists offer advantages that are important in maintaining and accessing data files. In business applications, where the storage and retrieval of large amounts of data is the heart of the processing concern, the success of application programming will be largely determined by the effective and knowledgeable use of appropriate data structures. Whether using Relative files or Inverted lists or Sequential access methods, the Model III with LDOS as an operating system has a good potential in business applications. Page 25 LISP IMPLEMENTATIONS FOR THE Z80 by Lee C. Rice & Daniel J. Lofy Lee Rice is an Associate Professor of Philosophy at Marquette University in Milwaukee, Wis., and Dan Lofy is a former student of his with a degree in computer science. I. LISP AS A PROGRAMMING LANGUAGE LISP is a LISt Processing language which is based upon John McCarthy's work on nonnumeric computation, first published in 1960. The first LISP system was implemented at M.I.T. and described in the LISP 1.5 PROGRAMMER'S MANUAL. Since that time LISP has become the language of choice for virtually all work in artificial intelligence, and has been implemented on a variety of mainframes. The host computer for LISP at M.I.T. was the DEC PDP-10, but research work there soon led to the production of a new minicomputer, "The Lisp Machine", whose hardware took full advantage of LISP's computational advantages. The LISP Machine provides a complete LISP environment: operating system, interpreter, editor, compiler, and utilities, as well as a machine-LISP implementation of other programming languages such as FORTRAN --> all written in, and managed by, LISP. To a considerable extent, LISP remains unique among programming languages, possessing a flavor and feel all of its own. In 1973 during an invited talk at the University of Texas at Austin, Jean Sammett said, "Programming languages can be divided into two categories. In one category there is LISP; in the second category, all the other programming languages!" Today experienced programmers would probably want to add APL to this first rather exclusive category. Many programmers argue that both APL and LISP provide ideal operating environments for the microcomputer. In the past two years no fewer than two versions of each have become available for the TRS80. This transition from mainframe to mini/micro mentality is just beginning. In the old days, machines were expensive, CPU time was equally costly, and disk space was a precious commodity. Programming languages like FORTRAN and COBOL were designed to minimize on-line programming. Programmers would spend hours coding flowcharts and pseudo-code, then compile their source code, pick up a long list of error messages, and return to their desks for debugging. But minis and micros have turned these priorities upside down: computer hardware, CPU time, and disk space are now among the cheapest of commodities in data processing, and programmer time among the most expensive. The use of interpretive and highly user-interactive languages is a first step in the right direction. More and more enhancements are being made to BASIC, and other interpretive languages such as LISP and APL are also coming into their own. There are still two frequently heard myths about LISP in the computer industry: that it is hard to learn, and slow with mathematical calculations. Both have a grain of truth. For those who are used to programming in highly rigid programming languages such as FORTRAN or PASCAL, LISP takes a lot of getting used to. While it is also true that LISP was originally devoted to nonnumeric symbol manipulation, and handled math only haltingly, it is also true that modern implementations of LISP have a number-crunching ability second only to APL (APL, after all, was created to do with numbers just what LISP was created to do with symbols in general). In terms of the microcomputer environment itself, LISP can't be beat. It is oriented toward programming at a terminal with rapid response. An extensive literature of utility programs is currently available. LISP uniformity also provides a very powerful programming tool for the micro user, once you become acclimated to it. LISP functions and LISP data have the same form. One LISP function can analyze another, or even use another. Indeed, thanks to its use of recursion rather than iteration, and its dynamic allocation of variables, LISP functions or programs can be used to alter themselves. Most LISP implementations, for instance, come equipped with a LISP editor (usually called EDIT, and written in LISP). If the user wishes to enhance the editor with new operations, this can be done simply by typing "EDIT EDIT" - i.e., one can use the editor to edit the editor! Page 26 All of these powerful features are bought at a price: the user has to learn some new habits, and unlearn some old ones. For LISP users, the gains are well worth the price. In the next section, we'll provide a very brief overview of LISP structures; and, in the following two, we'll describe the two implementations of LISP available for the TRS80 (both compatible with LDOS). II. ELEMENTS OF LISP PROGRAMMING English structures are made up of words, and so are LISP structures, except that there are two kinds of words in LISP: atoms and lists. Atoms and lists are called, generically, S-expressions (SEXes). Atoms can be English or nonsense words, but should not BEGIN with a number; since most LISP interpreters take any atom beginning with a number as a number-atom. A list is formed by enclosing any number of atoms, separated by spaces, with parentheses. The null list - "()" - containing no atoms is also identified with the atom NIL. Unless told otherwise, the LISP interpreter accepts the first atom in a list as a FUNCTION, and proceeds to evaluate it in the environment specified by the rest of the list. Some examples of obvious LISP numeric functions follow. LISP's responses are indented two spaces to distinguish them from user input: (DIFFERENCE 3.874 2.161) 1.713 (TIMES 9 3) 27 (PLUS (QUOTIENT 6 3) (TIMES 2 (MAX 2 4 3))) 10 (QUOTIENT 3 2) 1.333333 As the last example makes clear, LISP interpreters capable of handling floating point arithmetic do all of the conversions for the user. All functions are prefixed to their arguments, and the interpreter evaluates innermost parentheses first; so there are no rules of precedence to remember. The most important LISP nonnumeric functions are CAR (which delivers the first element of a list), CDR (which delivers the list without its first element), and QUOTE (which tells LISP NOT to evaluate a list). So: (CAR (QUOTE(APPLE PIE))) APPLE (CDR (QUOTE(APPLE PIE))) (PIE) The function CONS takes two arguments to make a new list: (CONS (QUOTE LISP)(QUOTE (TAKES SOME GETTING USED TO))) (LISP TAKES SOME GETTING USED TO) The LAMBDA operator is a means of binding variables locally to a function, and new functions may be introduced using the LISP function DEFINE. So we could define the functions FIRST, SECOND, and THIRD to pick out elements of a list as follows: (DEFINE (( '(SECOND (LAMBDA (LIST) (FIRST (CDR LIST)))) '(THIRD (LAMBDA (LIST) (SECOND (CDR LIST)))) '(FIRST (LAMBDA (LIST) (CAR LIST))) ))) SECOND THIRD FIRST (THIRD '(KEEP UP WITH YESTERDAY)) WITH Page 27 (SECOND '(POP GOES THE WEASEL)) GOES (FIRST '(LISP IS FUN)) LISP As this example also makes clear the single quote is a means of avoiding too many parentheses in most versions of LISP. To bring out the power of LISP's recursive techniques, we now define the function FACTORIAL, which delivers the factorial of a given number. To do this we also need the LISP function COND, which is just the ordinary "IF" function of BASIC or FORTRAN. COND simply takes a list of SEXes, evaluates them from the beginning until it finds a True SEX, and then returns the current value of that SEX. We add two additional LISP functions: ZEROP returns T (for "true") if a number is zero, otherwise NIL (for "false"); and SUBi merely subtracts one from a number. Now here is our definition: (DEFINE 'FACTORIAL (LAMBDA (NUMBER) (COND ((ZEROP NUMBER) 1) (T (TIMES NUMBER (FACTORIAL (SUB1 NUMBER))))) To create this definition, all we needed to know was that, for any number N, the value of FACTORIAL (N+1) is just (N+1) times the value of FACTORIAL (N). So we define the value of FACTORIAL (0), and then the value of FACTORIAL (N) in terms of FACTORIAL (N-1); and let LISP take care of the bookkeeping: (FACTORIAL (4)) 24 (FACTORIAL (PLUS (QUOTIENT 6 3) (DIFFERENCE 5 1))) 6 If we want to save the value of an operation we can use the LISP function SETQ, which stores the evaluated second argument as the value of the first (nonevaluated) atom: (SETQ CHARLIE (FACTORIAL (PLUS (QUOTIENT 6 3) (PLUS 1 0)))) CHARLIE CHARLIE 6 Notice that, unlike LAMBDA (which binds locally), SETQ is a global binder: CHARLIE is now available for later use. For situations where iteration is simpler or more easily readable than recursion (or where the beginning user needs to rely on techniques learned from FORTRAN or BASIC), LISP will also provide full iteration facilities via its GO and PROG features. GO, like the BASIC "GOTO", transfers control to another program segment (which is a character atom rather than a number in LISP). PROG is the LISP program generator, which enables the creation of a sequertial series of functions, and passing of values from earlier to later segments. For programmers who have worked in ALGOL, it is worth noting that the syntax of LISP PROGrams is the same as that of ALGOL. PROG variables are initialized to NIL, evaluation proceeds from left to right and top to bottom, and transfer is accomplished via GO and the insertion of labels (which are not evaluated). The function RETURN of one argument forces exit from PROG with the value being the value of PROG, or (if none exists) NIL. Finally, since LISP itself is a LISP structure, it can be used to describe and evaluate itself. The standard LISP debugger TRACE is written in LISP, and used to debug user-created LISP PROGs or functions; and similarly for the LISP editor. Lest it be concluded that LISP is all sweetness and light, a few weak points should be noted. First, LISP is traditionally quite weak in disk I/O; and it is typically only capable of accessing LISP-created data files or workspaces. Mainframe enhancements to micro versions of LISP have only begun to appear. Page 28 Secondly, the abundance of parentheses and the freeform syntax (no line numbers, and LISP ignores blanks) make some form of formatting desirable for the CRT (in order for the user to read and edit longer programs), and an absolute necessity for printed output. Here again, mainframe versions of LISP are very strong, and micro versions are typically quite weak. For the experienced LISP programmer, these weaknesses are not so serious: a prettyprinter for LISP can be written in LISP. But, for the LISP novice, these shortcomings are often painful. We have only touched upon the bare bones of LISP programming here. A typical LISP implementation for micros will offer fifty or sixty built-in functions (including PRINT, READ, and a host of mathematical tools), debugger, editor, and a variety of separate utilities. LISP, like APL, is also much more economical on memory usage than BASIC or FORTRAN. On a 48K TRS80 I have never needed to chain programs because of failure to fit them into a workspace. Further, since LISP makes no distinction between data and programs, tape or disk access is usually quite rapid. III. SUPERSOFT LISP Supersoft LISP (available from Supersoft Associates, P.O. Box 1628, Champaign, Illinois 61820) is designed to be a standard LISP interpreter. Essentially it uses the original (and now somewhat dated) M.I.T. version LISP 1.05, with the following enhancements: full floating point math, disk or tape I/O, and generous numbers of PROG features for the novice programmer. Updated most recently in 1982, it is now known as LISP 3.71, and is available for TRS80 Model I (tape or disk versions) and TRS80 Model III (tape or disk versions), as well as CP/M. The Model III version is not the same as the Model I version; and the disk versions of each contain many disk enhancements over their tape counterparts. The Model III version is fully compatible with LDOS, and the Model I version is supposed to be also (the authors have not verified this). In Supersoft LISP each SEX is evaluated as input, which results in a genuinely interactive environment, and a pleasant atmosphere for computing. The implementation uses an association list (ALIST) to keep track of variable bindings, and an object list (OBLIST) to keep track of functions currently in the workspace. The user has full access to the OBLIST (delete or add functions), but the interpreter also does bookkeeping; and an efficient garbage collection routine is also implemented. To prevent catastrophe, there is no user access to the ALIST, which is continuously updated by the interpreter. Enhancements to LISP 1.05 are worth noting. CHR, PEEK, and POKE (same as the BASIC functions) are fully implemented. PRINT, PRIN1 (same as PRINT without carriage return), LPRINT, LPRIN1, READ (for user input at terminal: same as BASIC INPUT), and TERPRI (which outputs a single carriage return to CRT or printer) are also provided. The disk versions (Model I and Model III) contain a BREAKpoint function for debugging, standard disk SAVE and LOAD functions, and a special disk-save function (SAVFNS) for saving multiple functions together in a single disk file. SAVFNS is of particular use where the user has created many short functions, since saving these together in a single disk file saves disk space and disk access time. The author has also generously provided a LISP library of sixty additional functions. These include such niceties as EXPT (exponentiation), RADIX (to change a number from base 10 to any other base), and GENSYM (which enables the user to generate new atoms). Three larger programs are also included on the disk. TRACE is a LISP debugging aid which enables the user to step through the execution of any user-created function or program. EDIT is a LISP editor (with full breakpoint facilities). The program DERIV is a mathematical one which takes the derivative of an argument with respect to a single variable, and (optionally) allows the user to generate a Taylor series for a given function. All of these are written in LISP, and full source code is provided in the manual. The manual also provides a complete explanation of the sixty-five error messages generated by the interpreter, and (for the advanced programmer) details of the machine representation of LISP. Page 29 The manual is NOT an introduction to LISP, so it assumes that the user does have some introductory materials or text on hand. Also a weakness is that the manual is not well organized. Apparently, following each update of LISP, the author simply added appendices. The result, for instance, is that there are no less than three versions of disk SAVE given, and only the last is correct. This fact, coupled with a complete lack of index, means that Supersoft would be well advised to prepare a completely new manual from scratch. The interpreter lacks any provision for prettyprinting output, so lineprinter output is almost unreadable. The editor is also quite modest and limited. For the novice these are serious shortcomings, but the manual does indicate procedures for editing the editor, and a prettyprinter can be written. On the positive side for the novice programmer, the interpreter is generally tolerant if too few parentheses are added; and, while only the error numbers are generated by the interpreter, the error messages listed in the manual are clear and explicit. The OBLIST is also unaffected by an error condition; and, after such a condition occurs, the interpreter returns at once to input level. High memory cannot be protected when entering LISP, so the use of the LDOS drivers and filters is also inhibited. Supersoft LISP is as powerful a micro implementation of LISP as we are likely to have for a long time. Full use of it does require homework for the novice LISP programmer, but one or two introductory books on LISP, coupled with some patience when confronted with many error messages, will open up a new world of programming power. IV. UOLISP UOLISP is a recent implementation of LISP, originating in 1980 and updated three times since (most recently in April of 1982), first created at the University of Oregon. Unlike Supersoft LISP, UOLISP is a subset only of Standard LISP, and does NOT include provision for floating point math. Its support utilities are, however, much more extensive than its Supersoft counterpart. These include the interpreter, a compiler for generating fast-load files or directly executable code, a program to load fast-load files, an optimizing phase for the compiler, a function TRACE feature, a structure editor and prettyprinter, another version of LISP called RLISP, and many support packages. First, the interpreter. It supports integers (range -4096 to +4095), strings of up to 255 characters in length, fixed point numbers, and several additional LISP features not supported by Supersoft LISP (dotted pairs, code pointers). A supporting package (BIGNUM) implements arbitrarily large integers, and yet another package supports vectors of arbitrary size (including vectors whose components are vectors, i.e., matrices). In addition to the standard LISP functions and predicates, the UOLISP interpreter comes equipped with compiler support functions; and these are of particular use to experienced assembler programmers. Unlike Supersoft LISP, UOLISP provides a complete compilation process, which is accomplished in two passes. The first of these translates LISP into a pseudo-assembly code called LAP ("LISP Assembly Program"), and the second translates LAP into absolute machine code, placing it into storage (for execution) or into a fast-load file for later reloading. Optionally, a third pass optimizes the LAP before assembling it. Fast-load files are both relocatable and implementation independent. They can also be executed directly from LDOS as standard /CMD files. The debugging process takes place at the interpretive level, which makes the LISP compilation procedure faster and more efficient than FORTRAN, COBOL, and most implementations of PASCAL. The LISP compiler is superior to most other compilers because of the ability of LISP to manipulate LISP: the compiler is written in LISP, and compiled LISP functions run from 10 to 50 times faster than the same functions in the LISP interpreter (which already run at about 5 times the speed of BASIC). The LAP assembler is accessible to the user, so fast assembly language routines and output to nonstandard devices can be implemented. An adjunct package for the optimizer also displays LAP code in assembler format. Page 30 For new LISP programmers, the Structure Editor and Prettyprinter will be welcome additions. The former is a LISP program which permits entry of functions, execution, and then saving as a disk file. This disk file can be accessed by all LDOS utilities, and even read by BASIC programs. The Prettyprinter interfaces to the Structure Editor so that LISP structures are automatically displayed in indented and easily readable format. There is an added bonus for the non-LISP programmer. The language RLISP (which is written in LISP, as if you didn't know already!) provides a palatable alternative to LISP which looks something like PASCAL. The language features WHILE loops, REPEAT loops, several different FOR loops, and infix operators for math. For example, in LISP the function NTH would be defined: (DEFINE 'NTH (LAMBDA (LIST N) (COND ((EQUAL N 0)(CAR L)) (T (NTH (COR L) (DIFFERENCE N 1))))) ) whereas in RLISP we have: EXPR PROCEDURE NTH (LIST, N); IF N=0 THEN CAR L ELSE NTH (CDR L, N-1); PASCAL users, or devotees of structured programming, will follow the RLISP program flow easily. For those of us (authors included) who are LISP fanatics, the suggestion that LISP could profit from the clumsy structuring of PASCAL amounts to little less than heresy. Since structured programming is, however, the current fad, RLISP meets one possible market demand. If the programmer does not like PASCAL or structured programming, there is yet another alternative to LISP included as a utility. The little META translator is a very big LISP program which permits you to create your own programming language, specify its syntax and how it is to be interpreted, and (optionally) convert it into assembly code. The manual contains a short example in META of a program which simulates a pocket calculator, but there is in fact no limit to what META can do. Experienced programmers can even write their own FORTRAN compilers in LISP using META (if this sounds fantastic, we should note that it has already been done, and the results mark a considerable improvement over the outdated Microsoft implementation of FORTRAN IV!). On the negative side, the absence of floating point math makes UOLISP seriously deficient. Unlike its Supersoft counterpart, the UOLISP manual is well organized and very concise. It too assumes considerable familiarity with LISP structures; and it contains many sections devoted to assembler programming. It should be noted that UOLISP files are NOT compatible with Supersoft LISP files. Because of the great command over file formatting provided by LDOS, the LDOS user may reformat many Supersoft LISP files for UOLISP input (provided they do not utilize floating point math!); but the path from Supersoft LISP to UOLISP is a one way street. The UOLISP package offers a solid implementation of LISP for any programmer. Its compilation options will appeal to the serious programmer, while its prettyprinter and utilities will be attractive to anyone. UOLISP runs under Model I or Model III LDOS, with a minimum of 32K (48K recommended), and requires at least one disk drive (two are recommended). It is available from Far West Systems and Software, Box 3301, Eugene, Oregon 97403. V. CONCLUDING NOTES LISP is an exciting language to learn, and a powerful language to use. It has the potential for offering a complete programming environment, and both versions take full advantage of both the Z80 and the TRS80. Page 31 Four books dealing with LISP are particularly noteworthy for the beginning "LISPer". LET'S TALK LISP, by Laurent Siklossy (NJ: Prentice-Hall, 1976), offers an easy-to-read introduction to the distinctive and most powerful features of LISP programming. LISP, by P. H. Winston and B. Horn (MA: Addison-Wesley, 1981), is a much longer book which provides both an introduction to LISP programming and information on the implementation of LISP on many computers. Ken Tracton's PROGRAMMER'S GUIDE TO LISP (PA: Tab Books, 1980) is just what it claims to be, and has many useful LISP programs (as well as many typographical errors). Finally, THE LITTLE LISPER, by Daniel Friedman (Chicago: Science Research Associates, 1974) provides the most light-hearted and fun-filled tutorial on LISP programming imaginable. FORTRAN, COBOL and LDOS JCL The following article by Glen Rathke demonstrates how to simplify the compiling of FORTRAN and COBOL programs through the use of LDOS's JCL. Working with Radio Shack's or Microsoft's Fortran can be less painful if used in conjunction with the JOB CONTROL LANGUAGE found in LDOS. First use the EDIT/CMD module to produce a working program such as the TEMP/FOR example that is in the front of Radio Shack's manual. Next use the LDOS command BUILD to create a JCL file by issuing a BUILD FORTRAN command at the LDOS Ready prompt. Then, type in each line and press . %1F. 1 = COMPILE and check for ERRORS . 2 = COMPILE, generate code, EXECUTE . //KEYIN - PLEASE INDICATE YOUR CHOICE //1 F80 =#FILE# %1F. 3 = QUIT . 4 = RECOMPILE generate code EXECUTE . 5 = EDIT //KEYIN - PLEASE INDICATE YOUR CHOICE //3 //EXIT //4 F80 #FILE#,#FILE#=#FILE# L80 #FILE#-G L80 #FILE#-N,#FILE#-E //EXIT //5 //EDIT //EXIT //2 F80 #FILE#,#FILE#=#FILE# L80 #FILE#-G L80 #FILE#-N,#FILE#-E //EXIT /// %1F. JOB aborted NOT A VALID CHOICE. //EXIT Then use the DO command; DO FORTRAN (FILE=TEMP) A KEYIN response of 1 will check for errors while compiling the program TEMP/FOR which was created using the EDIT/CMD module. If any errors are found at this point you can still go back and make any necessary corrections when prompted at the second KEYIN prompt. If the program is error free, RECOMPILING and EXECUTION are still available as well as a QUIT command. Page 32 A keyin response of 2 will then take control of the three remaining modules (F80/CMD, L80/CMD, and FORLIB/CMD) and process the file TEMP/FOR that was created under the EDIT/CMD. The token in the JCL files #FILE# has to be set equal to TEMP, which is done in the DO command where (FILE=TEMP). Then anytime the token "FILE" is encountered it will be replaced with the program name TEMP. The important part here is that whatever the name of the Fortran program is given, that same name will have to appear in the DO command line. In order to get a complete listing of the TEMP program including the code generated by the compiler you can BUILD another JCL file which I call "PRINT". LBASIC CLS LPRINT CHR$(140) CLS CMD"S" LIST #FILE#/FOR (P) LBASIC CLS LPRINT CHR$(140) CLS CMD"S" LIST #FILE#/LST (P) LBASIC CLS LPRINT CHR$(140) CLS CMD"S" //EXIT Once again use the DO command but this time execute it as DO PRINT (FILE=TEMP). Although the JCL file may be a bit cumbersome, the end result will have a complete listing as well as each listing starting on its own sheet due to the LPRINT CHR$(140) embedded under LBASIC. One more use for the JCL file can be found when you are sure that your program is bug free and when you want to clean up your work diskette, a multiple KILL file could be activated. KILL #FILE#/LST KILL #FILE#/REL DO KILL (FILE=TEMP) This file will only leave you with the original TEMP/FOR and the TEMP/CMD, so be sure that you don't need the other two files (especially TEMP/LST which gives you the code listing generated by the compiler.) These JCL files and commands were created using the 5.1.3 revision. As shown in a previous example with FORTRAN, the JCL function can be used with great ease when performing multiple or related functions. In the next example a JCL file is used to control the COBOL compiler marketed by Radio Shack, written by Ryan McFarland. The purpose of this application is to let the operator "take control" of the various options that affect compiling of a Cobol program. Notice the use of a non numeric character "E" in answer to a KEYIN (actually any non numeric character or a numeral >5 will obtain the same result.) This response will bypass all other options or KEYIN(s) and will directly start EXECUTing. Page 33 %1F............................................................. . 1 Compile (list to Video) . 2 Compile (list to Video & Printer) . 3 Compile (list Errors only to Printer) . 4 Compile (X reference to Printer) . 5 Compile "Debug" source lines . E EXECUTE ............................................................. . //KEYIN - YOUR CHOICE //1 RSCOBOL #FILE# (T) %1F. 1 QUIT . E EXECUTE //KEYIN - YOUR CHOICE //1 //EXIT //2 RSCOBOL #FILE# (T P) %1F. 1 QUIT . E EXECUTE //KEYIN - YOUR CHOICE //1 //EXIT //3 RSCOBOL #FILE# (P E) %1F. 1 QUIT . E EXECUTE //KEYIN - YOUR CHOICE //1 //EXIT //4 RSCOBOL #FILE# (P X) %1F. 1 QUIT . E EXECUTE //KEYIN - YOUR CHOICE //1 //EXIT //5 RSCOBOL #FILE# (D) %1F. 1 QUIT . E EXECUTE //KEYIN - YOUR CHOICE //1 //EXIT /// RUNCOBOL #FILE# //EXIT Use the DO command to execute the above JCL program. DO COBOL (FILE=CALCXMPL) LDOS and a HAYES SMART MODEM John Mullins talks about the Hayes Smart Modem and LDOS. From the number of calls we get, it appears that the Hayes modem is pretty popular. LDOS and a HAYES SMART MODEM make a very good pair, and with a program to issue commands from DOS and a device filter to disable output to the modem until a carrier is received, and a small amount of linking, a host system is in operation. The modem will detect the presence of an incomming call, and if it finds a carrier signal on the other end - will set the carrier detect input of the RS-232. Page 34 Then if the *DO and *KI have been linked to the Comm Line (*CL), the caller (from miles away) can issue keyboard commands and see display output. This simple system begins with a command sending program, MODCMD. All it will do is allow you to give the modem a line of commands. It is assumed at this point that the RS232 driver is in place at the time MODCMD is used. For example, MODCMD AT T D 555-3344 will tell the modem to dial (using tones) 555-3344. The format of the line is as follows (the "'" characters are used to mark the separate fields within the command): MODCMD '*device name ''digit delay ' command '*device name' will default to *CL, and the 'digit delay' will default to 3. The delay will allow the user to see the modem's responses to the commands. The second program is a filter so the RS232 driver will be ignored until a carrier is detected. Without this filter, the display will be slowed down to the speed of the driver (probably 300 baud) even if no one is online. The modem will think that anything it receives when not online is a command, if it receives other characters it can lead to unpredictable results. The next listing is a small JCL file to implement these commands in the correct order. The modem commands can be any you wish, but they must be issued before the online filter, and the online filter must be in place before the links. .reset modem to power-up configuration MODCMD AT Z .set up to dial with tones, ignore backspaces