THE LDOS QUARTERLY January 1,1982 Volume 1, Number 3 ------------------------------------------------------------------------------ Table of Contents ================= VIEW FROM THE BOTTOM FLOOR ........................................ Page 2 WHAT'S NEW ? - LDOS compatible software .......................... Page 8 UDATE NEWS 5.0.3 Model I ................................................ Page 12 5.1.0 Model III .............................................. Page 13 5.1.1 Model I ................................................ Page 15 I WAS AN LDOS BETA TESTER ......................................... Page 16 ITEMS OF GENERAL INTEREST ......................................... Page 17 FILTER DISK UPDATED MENU .......................................... Page 18 FED - A file editor ............................................... Page 20 ELSIE - The LDOS "C" language compiler ............................ Page 21 PARTITIONED DATA SETS ............................................. Page 23 UPDATED 5.1.1 FEATURES ............................................ Page 33 T-TIMER CLOCK/CALENDAR PATCHES .................................... Page 37 DEVICE I/O AND INDEPENDENCE - Technical topic ..................... Page 38 RELOCATING CODE FOR LBASIC USR ROUTINES ........................... Page 47 THE JCL CORNER .................................................... Page 51 LATE BREAKING NOTES AND PATCHES ................................... Page 55 Copyright (C) 1981 By Logical Systems, Incorporated 11520 N. Port Washington Rd. Mequon WI 53092 (414) 241-3066 Page - 1 VIEW FROM THE BOTTOM FLOOR by Bill Schroeder -------------------------------------------- We are very pleased to announce that LDOS 5.1.1 MOD I was released to hundreds of users on November 30th and hundreds more are now awaiting homes on dealer shelves around the world. You will find an expanded list of new features that 5.1.1 offers elsewhere in this newsletter. We feel that 5.1.1 is without doubt the best thing to ever happen to the TRS-80 world and we are sure you will agree. Any 5.0.x user can still "trade-in" a 5.0.x for a 5.1.x as stated in the last LDOS newsletter. 5.0.1 Service Renewal The fee to extend your LDOS support for an additional year has been tentatively set at $50.00. This fee will be subject to change without notice!! We have made every effort to set this fee based on the cost of providing support, but we had to guess at what percentage of our users will renew their support. If we are close with our estimate, this amount will stand. If not, it will have to be adjusted. All renewal notices will contain a "Extended Support Agreement" which will clearly state the services to be received and the total cost for the user to subscribe to those services. This will be an extension of the current support being provided to new LDOS purchasers. If a user does NOT extend his support agreement, he will not be allowed use of the $5.00 update service, the toll-free 800 line, the MicroNET bulletin board and will stop receiving the LDOS quarterly Newsletter. When your warranty expires you will be unsupported, as with any other warranty. This means that LSI will provide NO services to you. This is the purpose of the Extended Agreement. We will provide services to those who wish them but not for free. Each user will be offered the extended support agreement as his warranty expires. There will be a 30 day grace period after warranty expiration, during which time the user may execute his Extended Support Agreement. After that grace period, the user's registration will be totally removed from our support and customer service system. If at some later date the user wishes to re-establish his support, a fee somewhat higher than the extension agreement fee will be charged. Updates, upgrades, and ordering Please note that all upgrades or updates to LDOS products are handled through LSI directly at 11520 N. Port Washington Rd., Mequon, Wisc. 53092. A very long delay could occur if you send to a dealer or a distributor. In the Common Market you should send your LDOS to MOLIMERX at 1 Buckhurst Rd., Bexhill, Sussex, England. LSI does NOT accept credit cards or purchase orders. All upgrades of any sort must be accompanied by a check or money order in U.S. FUNDS. Molimerx, of course, should be sent funds in English pounds. There has been some confusion regarding what is meant by LSI, LSI Distributor and LDOS Dealer. All upgrades and updates come from LSI directly and must be accompanied with a check for the exact amount (LSI does not honor credit cards). LSI DOES NOT SELL ANY OF ITS PRODUCTS RETAIL!! There are four official LSI Distributors; LOBO Drives in California, Galactic Software in Wisconsin, MISOSYS in Virginia and MOLIMERX in England. PAGE - 2 These distributors wholesale to dealers in their areas and handle retail sales. All distributors honor COD, CASH, CHECK and CREDIT CARD retail orders for all LSI products. LDOS Dealers are retail sellers of LDOS and certain other LSI products, but SOME LSI PRODUCTS ARE AVAILABLE FROM DISTRIBUTORS ONLY. If you have any questions about where and how to obtain any LSI product, call LSl at (414) 241-3066. A $5.00 update to 5.1.1 will be available for owners of 5.1.0 MOD III LDOS in the near future, at which time the MOD I & MOD III Systems will contain the identical set of features throughout. Watch for an announcement of MOD III 5.1.1 availability this coming spring. There are several small patches for each of the LDOS versions in this newsletter. You may apply these to the proper version of LDOS or send in your Master disk with 0 and we will update it. Should you elect to apply the patches yourself, it will be your responsibility to keep track of the status of your system. We feel our update service is very important and any prudent user should send us his Master disk several times a year to make sure of having an official "current" master. The current versions of LDOS are: MODEL # VERSION # FILE MOD DATE ======= ========= ============= MOD I 5.0.3A 11/15/81 MOD I 5.1.1 12/15/81 MOD III 5.1.0A 12/15/81 If you use our updating service to keep your system current, you can determine from the above table if you should send in your disk for updating. To check your Master, look at the label and then do a "DIR (S,I,A)" on that disk. The MOD Date will be shown in the display. The /SYS and LDOS utility files should show MOD dates later than or equal to those shown in the above chart. If not, send in your MASTER with $5.00 and we will take care of it. If you are applying the maintenance patches yourself, you must keep accurate records as to the status of your system. 5.0.3A updates are now being returned with a MINIDOS filter on the the disk. The documentation has been appended in a special way to the end of the filter file. If you have this file on your 5.0.3A disk, you can get instructions for it by using the command "LIST MINIDOS/FLT". Let the list run through to completion. At that point the documentation will be on your screen. In the case of our 5.1.1 MOD I LDOS, there are TWO disks in the system. One is the system disk called LDOS 5.1.1 and the other is LDOSXTRA. When sending in a 5.1.1 system for updating DO NOT SEND THE LDOSXTRA DISK. If we should need to update the LDOSXTRA disk we will let you know. Some of our users are under the impression that they MUST trade up to 5.1.1, or that we are dropping support for 5.0.3A. This is not at all correct. We will continue to support 5.0.x as long as a practical number of users are still using it and are covered by their original warranty or their Extended Support Agreement. Future products from LSI, Galactic or MISOSYS that are designed for LDOS will probably be designed to work under 5.0.x or 5.1.x. This will not be 100% true; some of our future products will require the advanced features of our 5.1.x product line and will not be available to 5.0.x users. PAGE - 3 Customer Service We have been listening to you, our users, and have completely redone and expanded our manual, The MOD I 5.1.1 manual is now nearly 400 pages long. It is sequentially page numbered within sections and contains a complete INDEX, TABLE OF CONTENTS and TAB INDEXES. I believe it is absolutely the best manual in the Micro industry, bar none. Many users have been taking us up on our offer to create LDOS system disks of other than standard configurations. This is fine, but please tell us EXACTLY what you want. We need to know the number of tracks, one or two sided, 5 or 8 inch, and the density. We can make special LDOS system disks in almost any configuration. Each official LDOS master is created in an "OPTIMISED" fashion with controlled placement of files on the disk to increase overall proformance. The charge is still $5.00 if you provide the disk and $10.00 if we provide the disk. We will NOT modify your MASTER LDOS disk under any circumstances. We will also provide the proper version of SCRIPSIT for use with LDOS if an LDOS owner cannot find an original 1.0 SCRIPSIT to patch. The charge again is $5.00 if you provide the disk and $10.00 if you do not. You MUST also send proof that you have purchased some "legal" copy of SCRIPSIT, or you can send an original SCRIPSIT master disk with the Radio Shack label. Without proof of ownership of SCRIPSIT we will not be able to help you. Some Model III users have complained that the only way they can get files off of a Model I TRSDOS type disk with their MOD III and LDOS is to "REPAIR" the disk and then copy the files off. THIS IS NOT SO!!! Once the REPAIR command is used on the MOD III you cannot un-REPAIR (put back the old data address mark) on the MOD III. This is not a flaw in the software as the MOD III is not capable of writing the "OLD" data address mark. If you have a MOD I type disk (35 track, Single Density) and you don't have a MOD I computer that you can use to make a backup before doing the REPAIR, you can proceed as follows: 1> Boot under TRSDOS 1.2 or 1.3 2> Place the MOD I type disk in drive 1 3> Use the TRSDOS "CONVERT" command to move the files to MOD III TRSDOS in drive 0 4> After CONVERT has finished remove both disks 5> Place LDOS in drive 0 6> Place the MOD III TRSDOS that contains the moved files in drive 1 7> Reboot the system 8> Use the LDOS "CONV" command to move the files from the drive 1 TRSDOS disk to the drive 0 LDOS disk This procedure will leave the original MOD I type disk untouched and directly usable by MOD I TRSDOS. We do not understand why some users feel they must have the original MOD I type disk with the "OLD" data address marks, especially if they own only a MODEL III. But this is the procedure to use if you must. PAGE - 4 We are finding some very disturbing statistics regarding our 800 customer service lines. We get over 90% of our calls from LESS THAN 10% of our customers. We find that a vast majority of our calls are handled simply by telling the users the same thing that is in the manual (which they neglected to read). Toll free 800 service is not clearly understood by most people. I have talked with many people who think we pay some FLAT RATE and can then have all the incoming calls we want. This is incorrect. WE PAY FOR EVERY SINGLE CALL THAT COMES IN ON THE 800 LINES BY THE MINUTE. At the present rates we pay over $1500 dollars a month just for our 800 service. So please, call us when you need us, but check your manual first before you call. I can't see throwing away a technician's valuable time plus 35 cents a minute just to read the LDOS manual to a user over the phone. Before calling customer service with a "bug report" please make a simple check yourself. Make a mirror backup of your MASTER LDOS disk and make sure that you can duplicate the problem with that disk. If not, there is something wrong with the files that are on the offending disk. Remember that when we make major changes in the system, you must move ALL related files. This is very important. For example, a 5.0.x version of BACKUP or FORMAT may not work with a 5.1.x system. Also, you should understand that we use our product over 200 hours per week. If a major area of the system did not work we would know about it in short order. So if your keyboard goes dead, or your video goes blank, or LDOS won't boot or your basic program gets scrambled when you save it, the chances are that YOU have a problem with your hardware or the use of the software. We also get calls that have NOTHING TO DO WITH LDOS, such as calls about hardware modifications that we know nothing about. We are not a hardware company! So if you hook up a right handed wigit to your expansion port while holding your RS232 cable at a right angle to the interface and connect your "OH-MY-GOSH" drive to your "YOUGOTTOBEKIDDING" interface and reverse your MASTER disk in your "FLOPPED" drive..........and your system won't boot????.......PLEASE DON'T CALL. We make it very clear what hardware we support. If we don't come out with a support statement then it is safe to assume that we know nothing about it. We also get many calls asking us how to make this or that program run with LDOS. We do not have the time to do this. It is not our responsibility to make other companies software work with LDOS. You should contact the authors of the product and ask them to correct or modify their product. It is also prudent that an LDOS user specify to a vendor that he intends to run a program on LDOS when ordering that program. We now have a sysLem by which any prominent software author can get complimentary copies of LDOS for development purposes. If you know of a software package you want supported, have the author contact us for details. From time to time we will offer patches or procedures to make selected programs run with LDOS, as we have with PENCIL, SCRIPSIT, VISICALC, MAC-80, and several others. We are now looking at MOD I & III PROFILE with the intent of correcting it to work correctly on LDOS (no promises, but we will try). As our product line expands and we have a larger user base, it will become harder and harder for us to find the time to deal with other company's products. We are fortunate that more and more companies are providing LDOS compatible products every day. This is of great benefit to both the LDOS users and LSI. PAGE - 5 Some users have been saying that they have trouble getting through on the 800 lines. I have been monitoring these lines very closely and it is very rare that all the lines are busy. It does happen, but not often. If you get a busy signal, check the time. Remember that the 800 lines are open from 10am to 12 noon and from 4pm to 6pm Central time only. At any other time you will get a busy signal. If you must have assistance outside of these hours you can call (414) 241-3066. This is the main number at LSI. About our mail.... we get many letters every day from satisfied users. Most of these ask questions soliciting our comments or recommendations on products, programming procedures or LSI policies. We just don't have the personnel to answer all of these letters. If the answers to your questions are important to you, then give us a call at (414) 241-3066 and we will try to answer them. It is much less expensive to talk on the phone to you for 5 or 10 minutes then to generate lengthy correspondence. We do try to answer certain technical letters with accurate information and will continue to do so. Please DON'T stop writing. We do like to hear from our users and we do consider all written input when we set policies or design new products. Now I would like to mention a very touchy subject........ SOFTWARE PIRACY. Most anything I could say about this mega-buck theft situation has been said. I would like to make an important point that has NOT been expressed. Those of you who are honest, legitimate owners of software should realize that the condoning of this crime, even without participation, is just as bad as participating. Software of the magnitude of LDOS MUST BE SUPPORTED, and the more sales that are made, the better support and development for that product will be. If you see someone giving away a copy of LDOS, just think of it as ONE LESS NEW FEATURE that will be in the next version of YOUR LDOS. Our development money does come from sales. We could go to elaborate disk protection schemes, but that would be very unfair to the vast majority of LDOS users, the honest ones, who would not give away or sell a copy of our system. But it appears that the 99% may have to suffer at the hands of the 1% of criminals that are out there. We hope this practice will decrease so we will not find it necessary to take protective actions in the future. One more point for the pirates out there; WE ARE ABLE TO IDENTIFY EVERY LDOS and have terminated support for several users, and in one case are contemplating legal action against a user. So beware.... we are not blind. About Hardware and Software and ??? Some LDOS users are actively considering getting into double density. When deciding on a double density modification, you should also consider moving up to the LX-80 interface. The price has been dropped to just $449.00, and at that price it becomes a very attractive alternative. Consider the following. Your interface with ram must be worth $200 to $250 on the used market, and if you spend $150 (for a doubler) or $250 (for a 5" and 8" doubler), you have a $350 to $500 value involved. At just $449.00 for an interface that handles 5", 8", Double and Single density, Double and Single sided, up to 8 total drives, and is capable of BOOTING A DOUBLE DENSITY DISK, the LX-80 begins to sound like a pretty good deal. We at LSI use many of these fine interfaces and would not be without them. So for double density, do yourself a favor and consider selling your interface and getting into the LX-80 from LOBO. PAGE - 6 Whenever you order any product for use with your computer, whether it be hardware or software, you should always include your LDOS registration number. Some products require LDOS, and some companies will give discounts to LDOS users. Your LDOS registration number can save you money and get you the right version of a product. If the vendor doesn't know you have LDOS he will not be certain to send you the LDOS version of his product. A simple statement like LDOS SERIAL NUMBER #########, could gave you a lot of aggravation and may save you some money. If you or your company has a significant product that is LDOS compatible or LDOS specific and it does not compete directly with an LSI product, I will be glad to mention it in the "What's New" section. Just send me a copy of the completed product and a brief letter describing its functions, where it can be purchased, and at what price. I would like to see short reviews of LDOS compatible hardware and software for publication in this newsletter. If you have had experience with a product that would be of interest to other LDOS users, write an article about it and send it to the QUARTERLY EDITOR at LSI. If it is worthwhile we will publish it. Hard Disk Systems are now available featuring LDOS. All LDOS users should understand a few important facts about these systems. First off THEY ARE NOT ALL DONE BY LSI. Many of the Systems being advertised as featuring the LDOS operating system have the needed drivers and support software written and supported by companies other than LSI. We trust that these are competent implementations, but we have no way of knowing. LSI is directly supporting several hard drive systems to date. Two that are available as of now are from LOBO Drives International at 354 S. Fairview Ave. Goleta, Ca. 93117 and from Laredo Systems Inc. at 2264 Calle De Luan, Santa Clara, Ca. 95050. Both offer hard drive sub-systems for the MOD I & III. The above mentioned companies have contracted with LSI to do the software creation and support for their systems. There is a difference in acquiring an OFFICIALLY SUPPORTED system and a partially supported system. If a hard drive vendor elects to feature LDOS as his operating system and does his own software development, he must support the system!! If you should buy a system that is not officially supported by LSI and you have problems or questions about the use of LDOS with the hard drive, don't call us!!! We will simply refer you to the place you bought the drive. When we officially support a hard drive system we must have those drives in our customer service department and in our development department. We will NOT be of any help with systems we did not create. We will of course still handle any problems that have nothing to do with the hard drive. For LSI to author a hard drive implementation costs a vendor from $6,000 to $25,000 (this includes drivers, formatters, utilities, documentation and support). Then the vendor buys special finished LDOS packages directly from LSI and delivers them with each hard drive installation. LSI then handles all system software problems and customer assistance. If a vendor creates his own LDOS hard drive package, he is totally responsible for his portion of the package. This is not to say that other hard drive implementations of LDOS won t work or will have problems. They probably will work just fine, but we don't know that and will not be responsible for work we did not do!! PAGE - 7 Roy Soltoff and myself attended COMDEX in Las Vegas in November. We were in search of the next machine for LDOS to be implemented on. We saw many new, well designed Z-80 systems and were impressed by several. It seems likely that LDOS will appear in 1982 on several all RAM MACHINES, the Z-90 from Zenith and the MODEL II from Tandy are just two of the possibilities. We will keep you posted as to what machines will be supported and when. In the next issue of this newsletter Roy will probably have an article on the basic design structure that we will be using on our ram based systems. Many users have asked what publications we would recommend for LDOS users. We would consider one publication to be of major importance to the TRS-80 user. This is 80-US MAGAZINE. 80-US has just gone monthly and has held its subscription rate at just $16.00 per year. This is a real bargain for the original publication dedicated to the TRS-80 line of computers. The people at 80-US have also come out with a book called "THE CAPTAIN-80 BOOK OF BASIC ADVENTURES". For those interested in the adventure concept this is a must have book. See the ads for this book and 80-US magazine elsewhere in this newsletter or call 80-US at (206) 475-2219. When Roy and I began the LDOS project we decided that our system would have NO SECRETS. We are willing to talk about any part of LDOS. But, this requires costly technician's time so details about the system code will not be given out for free. The charge is $50.00/hour, plus phone expenses, one hour minimum, any part of an hour treated as an hour. Customer service will help with any operational or functional questions, but they do not have the resources to answer questions about the system code. In keeping with our open door policy we have included in your manual a complete technical section and we will be expanding on certain areas of the systems operation in each issue of this newsletter. In the last issue Roy detailed the use of the LDOS parameter scanner. In this issue you will find a detailed article on the BYTE I/O concept and how LDOS deals with it. The LDOS newsletter now contains a few ads for products relating to the TRS-80 and/or LDOS. We hope to have more in the future. The LDOS QUARTERLY is still being delivered third class, as there is no way that the present budget could handle the many thousands of dollars it would cost to send it first class (even though we would like to.) One interesting comment that I have heard from several of our users is that OUR LAST NEWSLETTER WAS AS LARGE AS THE DOSPLUS 3.3 MANUAL. I checked and that is a correct statement, as both are about 48 pages. WHAT'S NEW? =========== New and exciting things are happening in the LDOS world. Many products are now becoming available in LDOS compatible or LDOS specific versions. There is not room to talk about all of them here, but at the risk of sounding like a commercial I would like to touch on a few. PAGE - 8 New from GALACTIC software is a FILE EDITOR called "FED". This product is for the novice user, the serious user and the "real pro". It is simple and easy to use and is also very powerful. We use it constantly to maintain the LDOS system, and our secretaries use it to correct data bases. LDOS patches are now developed and implemented with FED. FED is a screen oriented file editor capable of doing most any type of file modification in both HEX and FULL ASCII. It will locate a HEX or ASCII string in a file or find the byte that loads at a specified address, or even tell you where the byte you have the cursor on (one of three cursors) will load. Advanced printer support is provided as well as two types of sector display modes. Elsewhere in this newsletter is additional information on FED. FED is available now for 5.0.x and 5.1.x from Galactic Software, 11520 N. Port Washington Rd. Mequon, Wi. 53092, for just $40.00 (MOD I & III). Also from Galactic is a special LDOS version of their popular MAIL/FILE system at $159.00. The "FILTER" package is available now from LSI distributors (MISOSYS, GALACTIC & LOBO) for $60.00. This package provides many very useful filters for almost all LDOS users. During development of this package, new ideas were continuously being implemented, and the resultant package contains many more filters than originally announced. The XLATE FILTER, BASIC LISTING FILTER or the CALC FILTER are worth the price of this package by themselves. Do yourself a favor and check this out. Details and a list of the filters in this package can be found elsewhere in this newsletter. Many of our users have asked about Editor/Assemblers. We are proud to recommend one as the most powerful and versatile for the novice as well as the experienced programmer. That, of course, is EDAS. This is the Editor Assembler that LDOS is written and maintained with. There is that old saying about "WHY RE-INVENT THE WHEEL?". Well, this Editor Assembler wouldn't have been created had there been an assembler that was as powerful, flexible and easy to use. There wasn't, and so EDAS was written. EDAS comes complete with a very powerful LABEL CROSS REFERENCING SYSTEM, Editor Assembler and very good documentation. If you need or want an Assembler contact MISOSYS at 5904 Edgehill Dr. Alexandria VA. 20303 for more information. EDAS sells for just $79.00 (MOD I & III). There is now a BASIC compiler written for LDOS by Bill Stockwell, and published by Breeze/Quality Software Distributing. This is (for lack of a better term) a "SEMI-COMPILER". That is, it generates optimized code, replacing most time consuming basic routines with assembler modules. Compared to other compilers, this one is "different" but very cost effective. It is only $69.95. Contact Breeze/Quality Software Distributing at 11500 Stemmons, Suite #125, Dallas, Tx. 75229, for additional information. Also from these same people is a product call "Script Plus 3.0" which adds many enhancements to Radio Shack's Scripsit package, and sells for just $39.95. Speaking of Quality Software, I should tell you that they have made a major change in their company as of late, consummating in a merger of themselves and Breeze Computing (Kim Watt's company). So if any of you are wondering where Kim is, he is now in Dallas sharing an office complex with QSD. Kim moved there from Detroit in November (a nice time to go south). Kim's NEW Super-Utility now supports LDOS completely, including the new LDOS data address marks. There are several music generating systems for the TRS-80, but without a doubt the most popular was the ORCHESTRA-80 and now ORCHESTRA-85. Page - 9 This new product (ORCH-85) will allow you to create beautiful music with your computer in STEREO NO LESS. This system allows for the creation and playing of music in up to five parts. Its like having a band in your TRS-80. ORCH-85 lists for just $129.00 and is LDOS compatible. For additional information contact SOFTWARE AFFAIR, Rubis Dr., Sunnyvale, Ca., 94087 (408) 295-9195. From Walonick Associates comes a product called StatPac. This is a super statistical analysis package that is available in a special LDOS version. For additional information contact Walonick Associates at 5624 Girard Ave. South, Minneapolis, Mn 55419. Now there is a clock-calendar board supported by LDOS. This is the "T-TIMER", detailed in an article later in this newsletter. For a complete TAX PREPARATION system to use with LDOS, you can contact Stenholm & Quint CPA, 129 Concord St., Framingham, Ma. 01701 (617) 879-8330. This CPA firm produces a package for tax preparation used by professionals. Their system is call the "SQ1 Tax Preparation System". MISOSYS has available a CPM to LDOS convert utility which will move files from certain 8 or 5 inch CPM disks to an LDOS type disk. Another product from MISOSYS is their popular DISASSEMBLER which is compatible with LDOS and EDAS. For information contact MISOSYS at 5904 Edgehill Dr. Alexandria, Va. 22303. Aerocomp has now been delivering their doubler for several months and from all reports it seems to be working very well. Their doubler was designed and engineered by Wayne & Skip at Aerocomp. Wayne, one of the designers of the PERCOM Doublers I and II, applied the knowledge he had gained in the creation of those products to build the proverbial "better mousetrap". So if their doubler isn't a great product, it should be. Aerocomp calls their doubler the "DDC". Aerocomp also has a very "trick" product they call the "DDS". This is a piggy back data clock separator which is designed to plug into the PERCOM and LNW doubler boards to make them a lot more reliable in double density. This product will correct most of the problems created by these boards. For more information contact Aerocomp at Hanger #8, Redbird Airport, Dallas, Tx. 75224. Many of our users want a good Disk Catalog program that is designed for LDOS. Earle Robinson, a very competent assembler programer, has written a very extensive catalog program just for LDOS. This catalog program has all the features you could want in this type of utility. Earle has started a new company called "softERware" at 16007 Miami Way, Pacific Palacades, Ca. 90272 just to handle the sale of this and his future LDOS compatible products. This program is called "DISCATER" and comes with documentation for just $39.95. Roy Soltoff, the Systems Analyst on the LDOS product, has come up with a very interesting new package. Many LDOS users have asked for a method of creating their own "LIBRARY" of commands. After some investigation, Roy has come up with a construct for the user to be able to create his own libraries. He calls these Partitioned Data Sets or PDS for short. Roy has put this concept to work in a unique package that allows creation, listing and changing of these library like modules. Now you can have several small programs in just one file, saving disk space and directory entries. This product is detailed by Roy elsewhere in this newsletter and is available through MISOSYS at 5904 Edgehill Dr., Alexandria, Va. 22303 Page - 10 LED is the name of the LDOS TEXT EDITOR. This is a new product from LSI and will be available shortly. This editor will allow the processing of line numbered or unnumbered ASCII text of almost any type. It has most of the functions of a screen oriented word processor but adds several specialized features to deal with certain types of text. It does not provide for printer output from within the editor, as the LDOS LIST command can be used. The Editor does support the entire ASCII character set. This product is available directly from the LSI distributor nearest you (do not order directly from LSI). The price for LED is $30.00. Contact an LSI distributor for more information if you are interested in this package. LSI will release "LC", our integer version of the "C" programming language in early '82. The price for "LC" has been set at $150.00. This package will include the LDOS TEXT EDITOR "LED" for creation and maintenance of LC source files. LC will be available from LSI distributors or from your local LDOS dealer. There is a full description of this package elsewhere in this newsletter. Now for a real "biggy". This is a new super LBASIC enhancement package from the people at SNAPP Inc. This is an LDOS implementation of their famous SNAPPWARE BASIC. Any serious basic programmer should not be without this package. It is not cheap, but is worth every penny you pay for it. It will pay for itself in saved time in short order. I could write a book just on this package, but there will be a review in the next issue of this newsletter. For now, call or write SNAPP Inc. 3719 Mantell, Cincinnati, Ohio 45236 phone: (800) 543-4628. LOBO Drives has made a large change in the pricing of their powerful LX-80 interface. LOBO is now offering this interface for just $449.00 with a full 32K of ram. This is the interface that runs 8", 5", Single density, Double density and double sided drives. With the LX-80 you can even boot a MOD I Double density system disk. This is an excellent bargain on a proven product. We use six of these constantly at LSI and have no problems. LOBO has also announced a FREE upgrade to the LX-80. To make the LX-80 even more reliable they have added a satelite data separation board and are offering to retrofit this board into all earlier LX-80s. If you already have an LX-80 contact LOBO for instructions on how to get this new board installed in your interface. For more information contact LOBO drives at 354 S. Fairview Dr. Goleta, CA. 93117. Now available from HEXAGON SYSTEMS is a powerful, LDOS compatible spelling checker for text files. This is the second version of a successful product and provides many enhancements over the original version. This "proof reader" is available for just $99.00 from HEXAGON SYSTEMS, P.O. Box 397, Station A, Vancouver, B.C. Canada V6C 2N2 (604) 682-7646. See their ad in this newsletter. Another very good spelling checker that is LDOS compatible is MICRO PROOF from CORNUCOPIA SOFTWARE at P.O. Box 5028, Walnut Creek, Ca. 94596. Prices start at just $89.50. Page - 11 UPDATE NEWS - MODEL I, 5.0.3A The following patches are for Model I, Version 5.0.3A. If you have an earlier version, you should send in for an update. If your 5.0.3A dates are 11/15/81 or later, then these patches are already installed. Use the BUILD command to type in the following JCL file and patches. When executing the DO command to compile and execute this JCL, be sure to specify the drivespecs S and D in the DO command line. . FIX503A/JCL update to 5.0.3A . s = source drive . d = destination drive //asign p=RS0LT0FF patch backup/cmd.#p#:#d# backupm/fix:#s# patch ksm/flt.#p#:#d# ksmb/fix:#s# patch twoside/cmd.#p#:#d# twosidea/fix:#s# patch sys2/sys.#p#:#d# sys2a/fix:#s# . BACKUPM/FIX . This patch will cause LDVR$ to be properly loaded at . all times X'5441'=CD C6 55 X'55C6'=E6 07 4F 32 08 43 C9 . EOP ****** . KSMB/FIX . This patch will cause KSM to accept only upper case . letters X'5467'=18 . EOP ***** . TWOSIDEA/FIX . This patch will correct twoside to work with 5.0.3 D00,99=33 X'52E2'=B2 . EOP ***** . SYS2A/FIX . This patch will increase the timer for check drive . to 500ms from 275ms D03,A2=14 . EOP ***** Page - 12 UPDATE NEWS - MODEL III, 5.1.0 A The following patches are for Model III, Version 5.1.0A. If you have an earlier version, you should send in for an update. If your 5.1.0A dates are 11/15/81 or later, then the patches are installed except for the last two, and you should DO the JCL file starting at @NEW. If your dates are 12/15/81 or later, then all patches are installed. Use the BUILD command to type in the following JCL file and patches. When executing the DO command to compile and execute this JCL, be sure to specify the drivespecs S and D in the DO command line. . FIX510A/JCL Update to 5.1.0A . s = source drive . d destination drive //assign p=RS0LT0FF . . The first set of patches are for 5.1.0A with dates earlier . than 11/15/81 patch lbasic/cmd.#p#:#d# lbasicd/fx3:#s# patch lcomm/cmd.#p#:#d# lcommb/fx3:#s# patch sys7/sys.#p#:#d# freea/fx3:#s# patch backup/cmd.#p#:#d# backupc/fx3:#s# patch format/cmd.#p#:#d# formate/fx3:#s# patch pr/flt.#p#:#d# pra/fx3:#s# patch sys0/sys.#p#:#d# sys0f/fx3:#s# patch patch/cmd.#p#:#d# patcha/fx3:#s# patch ki/dvr.#p#:#d# kib/fx3:#s# patch sys2/sys.#p#:#d# sys2b/fx3:#s# . The following patches are for 5.1.0A with dates . earlier than 12/15 @NEW patch sys11/sys.#p#:#d# sys11a/fx3.#s# patch backup/cmd.#p#:#d# backupd/fx3:#s# . LBASICD/FX3 X'5DED'=00 .EOP **** . LCOMMB/FX3 X'543C'=F7 .EOP **** . FREEA/FX3 L22 x'5276'=20 .EOP **** Page - 13 . BACKUPC/FX3 X'545C'=CD E1 55 X'55E1'=E6 07 4F 32 27 44 C9 .EOP **** . FORMATE/FX3 D06,47=F2 00 4E 3D 4E F4 00 0C 18 07 13 02 0E 1A 09 15 D06,57=04 10 1C 0B 17 06 12 01 0D 19 08 14 03 0F 1B 0A D06,67=16 05 11 1D 00 00 00 00 00 .EOP **** . PRA/FX3 .Allows a 0 to be sent to the printer X'5518'=00 00 20 X'5531'=00 20 .EOP **** . SYS0F/FX3 .Allows a 0 to be sent to the printer X'41E5'=38 03 C2 4B 04 C3 C2 03 .EOP **** . PATCHA/FX3 . This patch will allow patch to work without a closing . paren D00,BD=8D 52 . EOP ***** . KIB/FX3 . This patch will prevent the "type" buffer from being . filled by the repeat function. X'546F'=02 X'5476'=02 .EOP **** . SYS2B/FX3 . This patch will cause check drive to allow at least . two passings of the index hole before returning with . a drive unavailable indication. X'4E7A'=0F . EOP **** Page - 14 . SYS11A/FX3 . This patch will correct the // WAIT in JCL . D02,D7=C2 FE 0A C2 5C 4F C5 CD 64 51 71 ED A0 C1 10 F1 D02,EB=7E D02,F6=23 .EOP **** . BACKUPD/FX3 . This patch allows a backup of :1 to :0 (X) . D05,87=B3 . .EOP **** UPDATE NEWS - MODEL 1, 5.1.1 The following patches are for Model I, Version 5.1.1. If your 5.1.1 dates are 12/10/81 or later, then the patches are already installed except for the CMDFILE patch, and you should DO the JCL at @NEW. Dates of 12/15/81 or later have all patches installed. Use the BUILD command to type in the following JCL file and patches. When executing the DO command to compile and execute this JCL, be sure to specify the drivespecs S and D in the DO command line. . FIX511/JCL update to 5.1.1 . s = source drive . d = destination drive //asign p=RS0LT0FF patch lbasic/ov3.#P#:#D# ov3a/fx1 :#s# patch backup/cmd.#P#:#D# backupa/fx1 :#s# patch sys6/sys.#P#:#D# reseta/fx1:#s# . If file dates are earlier than 12/15, also DO the . next patch @NEW patch cmdfile/cmd.#P#:#D# cmdfilea/fx1 :#S# . 0V3A/FX1 . This patch corrects the released LBASIC/0V3 file . to match the LBASIC/CMD file. . D00,7B=7C D04,D9=16 D04,E1=29 D04,FA=1D D05,00=36 D05,06=3C D05,0F=79 . .EOP **** Page - 15 . BACKUPA/FX1 . This patch allows a backup of :1 to :0 (X) . D05,87=B3 . .EOP **** . RESETA/FX1 . This patch will cause global reset to turn off the . @ICNFG vector. . D2B,AC=32 03 43 11 02 00 21 00 42 CD 77 47 C2 F7 53 2E 70 . .EOP . CMDFILEA/FX1 D04,C8=61 D05,2A=C3 73 59 00 E5 CD 14 03 22 6C 5F CD F8 01 E1 CD 27 59 E5 21 74 58 CD 67 44 E1 . .EOP **** I WAS AN LDOS BETA TESTER by Tim Daneliuk This is the story of LDOS 5.1.1, the long awaited upgrade for the TRS-80 Model I. It started rather innocently one fateful day in August. I was to do a product evaluation of LDOS 5.0.2 for a major computer magazine, and had arranged a trip to visit the authors of LDOS who would tell all. LSI Inc. is cleverly concealed on the bottom floor of a building in the scenic Wisconsin countryside north of Milwaukee. After a grueling 2 hour trip from Chicago, I found my desination and proceeded to announce myself. I spent the full day there and was amazed, mystified and agast on the way home. How was I going to describe this product adequately in 40,000 words or less? Clearly, LDOS was a major force in the microcomputer industry and was soon to become the standard of excellence in TRS-80 systems software. I finished the product review and settled down to enjoy my new-found DOS when the phone rang. It was LSI and they wanted to know if I'd be interested in field testing the new 5.1 version of LDOS on the Model I. Would I! Promptly, the software was sent and I was officially a "Beta Test Site". Surrounded by 1 computer, 2 Disk Drives, 1 Printer, 2 Cats, and 1 Wife, I calmly proceeded to boot LDOS 5.1.1 and make a backup. Fire-extinguishers and paramedics were available should the experience prove overpowering to either the CPU or myself. Neither was required and what follows is a brief overview (by no means complete) of this new LDOS. Page - 16 LDOS 5.1.1 is not radically different than 5.0.3. Rather there is a set of subtle enhancements to the system which add to its already appreciable power. These were enumerated in the last LDOS quarterly so I'll only deal with my particular favorites. One of the nicest features of 5.1.1 is the SYSRES command. This SYSTEM feature allows certain /SYS files to be loaded into high memory. This speeds up DOS operation since overlays are not being called as often. Also, certain features are added if SYRES is used. For example, by SYSRESing SYS2, SYS3, SYS8, and SYS10 into memory, you can do BACKUP by Class between two non-system diskettes on a two drive system. Another application of SYSRES is the single drive system user. By residing /SYS files into memory they can be purged from the disk and that space is now available for user files. Several new features have been added which make LDOS even easier to use than before. It is now possible to enter a command with parameters and leave off the closing parenthesis. Directories are alphabetically sorted which makes finding a particular file in a listing a lot easier. As with Model III LDOS, 5.1.1 has a MINIDOS filter which allows the commonly used DOS commands to be entered in one keystroke sequence. Another favorite command of mine is the software write-protect feature. This allows you to prevent the operating system from writing to certain drives without having to put a write-protect tab on the disks. LBASIC has also been enhanced. One of the nicest features here is a CMD function which sorts a string array. Should you upgrade to 5.1.1? In all probability, yes. Though the improvements found in this new release are subtle, they are not trivial. I've found my efficiency using LDOS dramatically improved with 5.1.1 (no mean feat considering how efficient 5.0.3 was to use). In my estimation, 5.1.1 has the single greatest feature of being even more "user-friendly" than previous LDOS releases, and certainly than other so-called "advanced" TRS-80 operating systems. ITEMS OF GENERAL INTEREST Those of you trying to use KSM to set up control sequences to be sent to a lineprinter have need of the semicolon character as other than an imbedded carriage return. Use one of the KSM/FLT patches to change the semicolon to a character of your choice. The patch will be a two part patch; changing the character and character offset value. The value (nn) is the ASCII value of the character to act as the embedded . The offset (oo) is the value (nn-X'0D'). Both (nn) and (oo) should be represented as hex digits. Model I, Version 5.0 - X'5490'=nn:X'5494'=oo Model III, Version 5.1.0 - X'555B'=nn:X'555F'=oo Model I, Version 5.1.1 - X'558E'=nn:X'5592'=oo Those of you who don't have lower case hardware installed may run into a perplexing problem when doing comparisons on keyboard inputs. If KI/DVR is set, the keyboard will automatically be in the lower case mode, even though upper case is displayed on the video. Characters from the keyboard will not match up when compared to upper case characters. Be sure to do a <0> and then sysgen the system to lock yourself in the caps mode. PAGE - 17 Model I owners should be sure NOT to use configuration files created under 5.0.x with version 5.1.x! LDOS provides the key sequence as a means to restart a timed out drive. However, this will only work if the interrupts are on. Since FORMAT and BACKUP both disable the interrupts, a timed out drive during either procedure will hang up the system. Some versions of the Radio Shack interface (both the model with the buffered cable and the one without) have an official Radio Shack modification to increase the drive select time by changing a resistor value from 200k to 270k ohms. Also, as mentioned on page 49 of the December 80-Microcomputing, the capacitor used with the resistor to provide the select timing can go bad and may have to be replaced. The article gives component numbers for the capacitor of C-48 (C-62 in the newer interfaces) and C-12 for the LNW interface. The original value was 33 mF, and the article recommends that a 47mF or a 68 mF, 16 volt, tantalum capacitor be used to replace it. If you are experiencing drive timeout, you should have these two components checked. The new 5.1 manual mentions a version 5.1 ROM for LX-80 owners. Hopefully, this ROM will be available in early 1982. Among other things, this ROM will allow software write protect, correctly pick up the DAM of the directory (eliminating the need to log a drive), and provide more head settling time for 8" drives. For details on upgrading your ROM, contact LOBO Drives directly. Single drive owners of 5.1 can get a directory of visible files on a data disk by using the following procedure. Use the SYSTEM (SYSRES=) command to reside SYS modules 1 and 10. Filter the keyboard with the MiniDOS filter. Then type in the MiniDOS command . When the Q prompt appears on the screen, insert the data disk in drive 0 and press enter. Model I LDOS owners upgrading 5.0 disks to 5.1 may have a problem after doing a BACKUP (OLD) from a 5.1 system disk to a 5.0 system disk. The 5.1 version SYS6 increased in length to 50 sectors. Depending on the location of SYS6 on the 5.0 disk, it is possible that it will get broken into 3 extents by the backup. This will result in certain library commands not working. If this is the case, try killing SYS6 on the 5.0 disk and then backing up (not COPYing) SYS6 from the 5.1 to the 5.0 disk. If this does not work, it will be necessary to make a mirror image backup of the 5.1 disk and then move the necessary files from the 5.0 to the 5.1 disk. LDOS FILTER PACKAGE LSI is proud to announce the first in a series of extension packages for the LDOS product line. This package is FILTER oriented, and will contain many useful modules. This section of the newsletter will detail the filters that will be incorporated into this package. XLATE/FLT........ A complete translation filter system, for input and output. Included are a complete EBCDIC translate system and also a DVORAC keyboard translator. The user can very easily build any other translate tables that are needed for special use. PAGE - 18 LISTBAS/FLT...... A filter which will format the output of a Basic program. All program lines which contain multiple statements (i.e. statements separated by colons) will have their appearance reformatted when displayed. All new statements encountered in a physical program line will be displayed on a new line, and will be indented. Also, special formatting will be done to change the display of PRINT statements and statements involving parentheses. STRIP7/FLT....... Strips bit seven (the high bit) off of each character. STRIPCNT/FLT..... A filter which will replace an output character above X'7F' or below X'20' with a pound sign (#). MONITOR/FLT...... A filter similar to STRIPCNT/FLT, with the exception that characters less than X'20' will be displayed as a percent sign (%) followed by an ASCII representation of the actual character value + X'41'. in addition, characters greater than X'7F' will be displayed as either an or a . TITLE/FLT........ A printer filter that will print a user defined title after each Top-Of-Form character (X'0C') is encountered. UPPER/FLT........ Converts every alphabetic character (a-z) to UPPER case. LOWER/FLT........ Converts every alphabetic character (A-Z) to lower case. SLASH0/FLT....... Will cause a printer that is capable of backspacing to do a backspace and type a "/" over every 0 (numeric zero) that is encountered. TRAP/FLT......... Will trap and throw away a certain character each time that the character tries to go through the filter. Any character (00 - FF) may be "trapped". LINEFEED/FLT..... Either add or remove a linefeed after each carriage return. PAGEPAWS/FLT..... Will pause after each Top-Of-Form character is printed and wait until is pressed to continue. CALC/FLT......... A keyboard filter to perform Hex/Decimal/Binary conversion. Hex addition and subtraction may also be done. REMOVE/CMD....... Removes each occurrence of a specified byte from a file. PAGE - 19 F E D - The Ultimate File Editor - by Doug Kennedy -------------------------------------------------- FED is an all-purpose, screen oriented file editor to be used with the LDOS operating system. Its wide range of capabilities make it excellent for the advanced user, but its simplicity makes it easy to use for the novice user. The editor supports both Model I and III, upper and lower case, single or double density, or anything readable by LDOS. Some things to clarify: This is a file editor, NOT a file copier, text editor, or word processor. It is for displaying, printing, and modifying existing files. Fed works on a file level, not a track/sector level. FED was not designed to repair damaged disks, or recover lost files, but it could be used to do so by the experienced LDOS user. You cannot create or extend files with FED, only modify existing ones. FED is intended to run with the LDOS operating system only. FED is available for $40.00 from Galactic Software, 11520 N. Port Washington Rd, Mequon, WI 53092. Here is a brief description of FED's capabilities: 1) Complete editing capabilities, including Hexadecimal and ASCII modifying. Direct disk patching becomes a simple matter with FED. It is possible to write machine language code directly to disk. Small changes in files can be made instantly. No need to read in a large source file and reassemble just to change one character. 2) Record advancing, backspacing, and positioning. Move through files quickly either forward or backward. The user need not know how the file's directory records are stored, how many sectors per gran are on the disk, or how many granules per cylinder the disk has, or what density is used. Just know the filespec and password (if it has one). 3) Global ASCII and Hex string searching, with a command to position to the next occurrence of that string. FED searches the entire file, not just one record like most editors. It allows searching for 30 character ASCII strings (upper/lower case), and 30 digit (15 byte) Hex strings. FED saves that string and you can go to the next occurrence of that string from the currently displayed position in the file. 4) Locate a Hex address in a load module format file, and calculate the load position of a specified byte. A MUST for assembly language programmers. No more tedious hours spent going through a load module file manually to locate or change a byte at some memory location. Just type in the load address and FED points you at that byte. Another extremely powerful feature is the reverse of the address location command. FED calculates where in memory a specific byte pointed to by the cursor will load. With these two features it is possible to write machine language routines directly to disk. Direct patches are made quickly and easily. Even X-patches are easily installed by the experienced programmer. 5) Listing of a file or individual records to a printer, with many safeguards added to make it difficult to LOCK-UP the system if a printer is deselected, out of paper, etc. PAGE - 20 6) Includes a 256 byte display mode, and an extended 128 byte mode. Editing utilities in the past allowed for 256 byte displays only. By using this format exclusively, the variations of an ASCII/HEX display are limited. But by having a 128 character display mode, the extra space makes it more visually appealing. The filespec, drivespec, record number, input & output can be displayed horizontally instead of vertically. ELSIE - THE CONTENTED COMPILER by Jim Frimel LC, LSI's soon-to-be-released C compiler (nicknamed Elsie), will give LDOS users many new ways to "milk" their system. LC provides a substantial subset of the C programming language of Bell Labs fame, the main language used under the UNIX (TM Western Electric) operating system. LC was written to be compatible with UNIX programs. The C standard library is supplied with the compiler. LC programs which use the standard library can be compiled and run under UNIX. Programs written under UNIX which only use statements implemented by LC are also portable to LC and LDOS. A large amount of existing software, both commercial and public domain, will be directly useable by LC owners. For those of you who are not familiar with the C programming language, here is a brief introduction. C is a structured, portable language. A C program is a collection of functions arranged hierarchically (they call each other). C functions can be recursive and re-entrant, as local variables are created and stored in a stack (in LC, the Z80 machine stack). All machine-dependent features needed, such as I/O, are not implemented in the language; rather, they are placed in the standard library. Thus, only the implementation of the standard library changes from installation to installation, and C programs are written in machine-independent ways. The language itself provides ways of expressing program structure, and of giving arithmetic and logical expressions. C is known for having one of the most powerful expression capabilities available in any language. C statements supply the WHILE, DO-WHILE, FOR, IF, and SWITCH-CASE constructs. C also provides powerful pointer capabilities to enable direct access to memory and variable storage. LC is an integer-only implementation of C, which provides all C statements except "struct", "union", "goto", 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. LC accepts multiple input files, with 4 levels of nesting for "#include'd" files. The compiler generates a Z-80 source file which is then assembled and linked to the standard library to generate the executable program. 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 TRS-80 are supplied in an installation library, and provide access to graphics and LDOS entry points. LC supports separate compilation; programs may be compiled in segments, and frequently used functions can be pre-compiled. External variables are supported with the "extern" statement. PAGE - 21 Optionally, the compiler will generate external declarations automatically without any "extern" statements. Users can create their own libraries of commonly used functions - user libraries - which need not be compiled for each subsequent use. Elsie supports both the Microsoft Macro-80 assembler and the MISOSYS EDAS disk editor-assembler. Under M80, the standard and function libraries are in relocatable format; under EDAS, the standard library is implemented as a partitioned data set composed of relocatable object deck modules which use an LC-supplied linker program while the user function libraries will be in Z-80 source form, to be assembled along with the program using the "*get" file include facility of EDAS. Supplied with LC is a program, "blib", which allows users to create their own relocatable load module libraries under the Microsoft package. To give you an idea of how simple LC programs can perform complex functions, here is a simple example program: #include stdio/csh /* standard I/O definitions */ /* XFER - copy standard input to standard output */ int c, bytes, lines; FILE *fp; main() { while( (c=getchar()) != eof) { putchar(c); ++bytes; if (c == eol) ++lines; } fp = fopen("*do","w"); fprintf(fp, "%d characters , %d lines were copied", bytes, lines); } This program just copies standard input to standard output, then gives a character and line count to the user on the video display. Here is an explanation of the program, going through the program from top to bottom. The standard header file, "stdio/csh", is processed as if it were part of the program source file, and contains system dependent and machine dependent information, such as the constants "eol" and "eof" (end-of-line and file). "FILE", also defined in the standard header file, provides a system-independent way of defining a file pointer variable. "main" is always the name of the main function, which is the top of the hierarchy of the structured C program. The brace characters ( {,} ) group statements into compound statements. Thus, the body of the function is one compound statement. The "while" statement provides looping for the program. The conditional expression in parentheses shows the power of complex C expressions. The innermost expression, "c=getchar()", gets a character from the standard input, and puts it into the variable, "c". [All functions in C designate parameters within the appending parentheses and the parentheses are always required regardless of the absence of any parameter.] PAGE - 22 The value of the character is then compared to the constant, "eof", to determine if end-of-file has been reached. Within the loop the character "c" is output, and the byte counter is incremented. The line counter, "lines", is incremented if an end-of-line character was read. Finally, when the loop is exited, the video display is opened as an output file and "fprintf" is used to print statistics on the display. This normally trivial program becomes a powerful utility when LC's standard I/O redirection feature is invoked. Standard I/o redirection allows the user to specify at execution time where standard input and output are to be read and written. Once XFER is compiled, assembled and linked, typing the following line into LDOS: XFER will copy the keyboard to the video display, the defaults for standard input and output. However, both input and output may be redirected, using the > (for output), and < (for input) characters. Thus, the command: XFER *PR will let you type directly from the keyboard to the printer. The command: XFER >*pr TEST/BAK LC will probably find its niche most readily among those who would like to program at the "systems" and utilities level, but really don't relish assembly language programming. Those LDOS users who already write assembly language programs will find that LC increases their productivity for system tasks, and executes fast enough for most system work. LC readily interfaces with assembly language for critical portions of code. However, users will find that this is usually not necessary. LC will be available for shipment in February of 1982, if all goes well, for a cost of $150.00. Orders may be placed with the domestic US LSI distributor nearest you. MISOSYS ANNOUNCES PARTITIONED DATA SETS by Roy Soltoff Partitioned Data Sets (PDS) are not new to LDOS. The two library files, SYS6/SYS and SYS7/SYS, are PDS structures. Katzan, in OPERATING SYSTEMS, A PAGE - 23 PRAGMATIC APPROACH, defines a partitioned data set as "a data file that is divided into sequentially organized members." Katzan further states, "Each PDS includes a directory that points to the beginning of each member. Data sets of this type are most frequently used to store object programs - each member corresponds to a single object program. The PDS as a whole is referred to as a library. Operating system libraries and user libraries are stored in this fashion." This definition describes exactly the two LIB files in LDOS. Some LDOS users have already explained how to find the member "number" corresponding to a LIB command by searching through the PARM table of SYS1/SYS. This table is used by the LDOS Command Interpreter, which parses the command line and checks if the "filename" entered by the user matches up with a LIB command listed in the table. When a match is found, linkage is established with the system loader in SYSRES to denote the LIB file and the specific member entry satisfying the LDOS command entered. The system loader, in reading the LIB file, discovers that it is a PDS and reads through the member map table stored in the LIB file. This map table is a directory containing information relevant to each member in the file. Once the system loader finds the appropriate entry, it positions the file to the starting point of the member, and then loads and executes the module. The PDS structure has provided a technique for combining separately executable object programs into one file, thereby saving directory slots. It also saves time by not having to load an entire 10K-15K file just to get a few hundred bytes or a few thousand bytes of program loaded if all LIB commands were just one big file. The overhead of having to read and search the member directory is minimal. This technique has been used for years on mainframe and mini computers. LDOS is the only known DOS supporting PDS structures on the TRS-80. Up until now, only the system library has been blessed with this support. However, MISOSYS has now implemented User PDS structures. The PDS command can be used to create custom user libraries. A library could be a collection of a dozen utility programs - all stored under one name but directly executable by specifying the library name followed by the member name. Consider for a moment, that I have built a library containing CMDFILE, DSMBLR, FED, BINHEX, EDAS, and XREF. The library name MYLIB was chosen. I can then execute EDAS by entering: MYLIB(EDAS) at the LDOS ready prompt. If I wanted to build a custom LDOS command library, I could use CMDFILE to extract DIR, COPY, KILL, DEBUG, ROUTE, and RESET from SYS6/SYS and SYS7/SYS and build them into a user SYSLIB. Then I could kill off SYS6 and SYS7 which would save about 15K from my "custom" SYSTEM disk. When I wanted to do a directory, I would only need to type: SYSLIB(DIR) :2 (A,I) to achieve the same result as if I had typed DIR :2 (A,I) on a regular SYSTEM disk. Albeit I could have named my user library, "S" and save the entering of five characters each time I wanted to execute a member of the library. That would let me use "S(DIR)"! How's that for you BASIC/S fans? ... cont. page 33 PAGE - 24 [ Pages 25 through 32 contain graphics/advertisements ] Okay, what capabilities are included with PDS? The PDS command will itself be a PDS. Members provided will implement the following functions: o ALIAS - Will provide the capability of defining more than one reference name to a PDS member. o APPEND - Will append a new member to the existing PUS and update the member directory and map tables accordingly. o CREATE - Will provide the capability of creating a new partitioned data set with a maximum number of members. The PDS is composed of a front end loader program, a MEMBER directory, a MAP table, and one or more executable object deck files as specified by the user. The object deck (/CMD files) list can be entered either by on-line prompts or via a listing in a data file. The capability of multiple entry points to a single module (separate member names just like COPY and APPEND or SET and FILTER) is implemented only when the data file list option is specified. o DIR - Will provide a directory of members listing the member name, date of entry, location in the PDS, transfer address, and file space occupied. o EXTRACT - Will transfer a copy of a PDS member from the PDS to a target diskette as a standard /CMD file. The member will not be deleted from the PDS. o KILL - Will remove a member from the PDS and compress the file to delete the space previously occupied by the deleted member. o LIST - Will list a specific member in standard hex format. PDS is available from MISOSYS, 5904 Edgehill Drive, Alexandria, VA 22303. PDS is priced at $50. Orders received prior to March 1, 1982 may take advantage of an introductory offering at $40. LDOS 5.1 - Enhancements and New Features - by Dick Konov The following pages of the newsletter will describe the differences between LDOS-5.0 and LDOS-5.1. In the last issue of the newsletter, a similar article was written. Since that time, additional features have been added to LDOS-5.1. This article will highlight the most significant changes which have been made to the operating system. 1.> Any LDOS command parameters which requires parentheses may be entered without the closing parenthesis. 2.> The CONV utility has been added to the system. This command will allow you to transfer files created on the Model III under TRSDOS 1.2 or 1.3 to an LDOS diskette. Note that Model I owners who wish to utilize CONV must be capable of reading double density with their system. PAGE - 33 3.> Some LDOS drivers, filters and Library commands will reuse their original memory allocations if they are established, turned off, and re-established. They are the SPOOLer, the Keyboard driver (KI/DVR), the MiniDOS Filter, the Printer filter (PR/FLT), and the KSM Filter. In addition, drivers such as PDUBL, TWOSIDE and the above mentioned will only be allowed to be initiated once. 4.> The Keyboard (*KI) now has its own driver. This driver activates the use of the key, and must be established if advanced keyboard features are to be utilized (e.g. KSM). In addition, the KI/DVR allows you to enter all ASCII characters (0-127) directly from the keyboard. Also, the KI/DVR allows you to establish an extended character set. 5.> The MiniDOS filter has been added. This is an additional keyboard filter which allows the keyboard driver to intercept certain keyboard inputs and immediately act on them. MiniDOS commands are issued by depressing , and an alphabetic key. The following functions are available when using the MiniDOS filter: toggle the CLOCK display on or off, enter the system DEBUGger (if activated), display FREE space for all active drives, KILL a file, display a disk's DIRECTORY, send a hex character to the printer, REPEAT the last DOS command, and issue a Top of Form to the lineprinter. 6.> A SuperVisory Call (SVC) table can now be loaded into high memory for use by assembly language programmers. It contains most documented system entry points and routines. It is established using the SYSTEM library command. 7.> Some SYStem modules may be resided in high memory by using the SYSTEM library command. This will allow you to perform certain functions that normally require these SYStem modules to be on a disk. For instance, the user of a two drive system will be allowed to perform a BACKUP by class using non-system diskettes, provided the proper SYStem modules have been made resident. Residing system modules also increases the speed of the system. 8.> Any Physical drive in your system may be established as Logical drive 0. This can be accomplished by using the SYSTEM library command. 9.> For Radio Shack interface owners only, drives may be software write protected. This is accomplished using the SYSTEM Library command. 10.> The parameters BSTEP and CYL have been added to the SYSTEM library command. BSTEP is global in nature, while CYL is used with the DRIVE= parameter. These parameters will allow you to set your own default values for the FORMAT utility regarding the bootstrap step rate and number of cylinders to be formatted. 11.> The SYSTEM library command will also have added to it the parameters DATE= and TIME=. These parameters are used to enable or disable the DATE and TIME prompts on power up or reboot. If not altered, you will be prompted only for the date on power-up. 12.> The SPOOLer will despool at a faster speed, and will work in conjunction with the LSCRIPT patch for SCRIPSIT. PAGE - 34 13.> APPEND has two additional parameters. The ECHO parameter will echo characters to the screen if a "devspec to -->" APPEND is performed. The STRIP parameter will "strip" off the last character of the file being APPENDed to before the APPEND is performed. This can be useful if you wish to, for instance, APPEND two SCRIPSIT files together. 14.> The COPY Library command has also had the ECHO parameter added to it. 15.> The DEVICE Library command will display additional information. Included in this is whether or not the diskette is write protected (software or physically), options which are currently active (e.g. KI/DVR, MiniDOS, TYPE, etc.) and SYStem modules which have been resided in high memory. 16.> A "Not" partspec may be specified for some Library commands and utilities. For example, by entering the following command: DIR -/CMD:0 you will be shown a Directory of drive 0 of all files that do NOT have the extension "/CMD". This "Not" partspec is available with the DIR and PURGE Library commands and the BACKUP utility. 17.> A specific date, or a range of dates may be specified when utilizing the DIR and PURGE Library commands, as well as the BACKUP utility. The system will use the file's last modification date to determine whether or not that file is to be included in the specified operation. 18.> Along with the above mentioned modifications to DIR, additional enhancements have been made. Unless specified, all files in a directory will be displayed in sorted order. Also, a MOD parameter has been added to allow you to produce a directory of modified files only. 19.> Along with the above mentioned modifications to BACKUP, two additional parameters have been added. The NEW parameter will BACKUP only those files not already on the destination disk. The OLD parameter will BACKUP only those files already existing on the destination disk. In addition, if the (QUERY) parameter is specified, a backup by class will always be the result, whether or not the backup is a mirror image. If the (QUERY) parameter is specified, you will be shown the MOD date and flag of each file. 20.> One enhancement was made to the FREE Library command. If the FREE command is given with a drivespec, a FREE space map will be displayed for that particular drive. 21.> The FORMAT utility has had two parameters added to it. The (QUERY) parameter will query you as to the type of FORMAT you require. If not specified, the (QUERY) parameter will default to ON. The (SYSTEM) parameter has been added, and deals with formatting a hard drive. Also, changes have been made to the prompt questions and how these questions are dealt with. 22.> LCOMM has been modified substantially. The modifications made to LCOMM are too numerous to mention here. Two of the most significant enhancements will be discussed. PAGE - 35 LCOMM will allow you to input from the keyboard all ASCII characters (0-127). Also, a Dump To Disk (DTD) function has been added. This will allow you to receive a file in a RAM buffer and dump it to disk after the transmission has been completed. This feature is important to Radio Shack interface owners, as it will guard against the random dropping of bytes when receiving files. Many other features have also been added. 23.> The PATCH Utility has been enhanced, and will allow you to enter Direct ('D' type) patches from the command line. 24.> There will be two SCRIPSIT patches included with LDOS-5.1. The SCRIPT/FIX patch will be identical to the SCRIPSIT/FIX patch that was included with LDOS-5.0. Many new features have been added to SCRIPSIT if the LDOS-5.1 LSCRIPT/FIX patch file is applied. Operation of SCRIPSIT when using the new patch will differ greatly from operating under the LDOS-5.0 patched version. Many of the enhanced LDOS operations (such as the use of the SPOOLer and MiniDOS) will be accessible from the SCRIPSIT environment. 25.> The RS232/DVR driver has had its name changed to RS232R/DVR. Both RS232 drivers have had enhancements made to them. The parameters BAUD, WORD, STOP and PARITY may be abbreviated to their first characters. As specified by standard RS232 conventions, a TRUE condition means a logic 0, or a positive voltage. A FALSE condition means a logic 1, or a negative voltage. The RS232 driver will now treat the line condition parameters DSR, CD, CTS and RI in the following manner: If specified ON, the driver will observe the lead and wait for a TRUE condition before sending each character. If specified OFF, the driver will observe the lead and wait for a FALSE condition before sending each character. If not specified, the lead will be ignored. In addition, a (BREAK) parameter has been added to the RS232 drivers. This parameter determines whether the driver can set the system BREAK, PAUSE or ENTER bits. 26.> LBASIC has had several enhancements. The time it takes to load or save LBASIC programs has been decreased drastically. Also note that LBASIC does not need to be created by applying patches to Radio Shack Basic; it will be resident on your Master Diskette. A machine language string sort has been added to LBASIC. This will allow you to sort a string array contained in RAM. In the CMD"N" function, the last parameter will now represent the last line number to be renumbered. It used to represent the first line number above those to be renumbered minus one. PAGE - 36 The RESTORE command has had an optional parameter added to it. Entering the command RESTORE nnnn (where nnnn represents a line number in an LBASlC program) will restore all DATA statements in lines whose numbers are greater than or equal to the line number specified in the RESTORE statement. The RUN command has had two parameters added to it. These parameters come into play when using the RUN command as an LBASIC program statement which will chain programs together. The (V) parameter will allow you to save any variables which may have been established in one program, and utilize them in another program. The (line number) parameter will allow you to specify a line number dealing with where execution of the program is to begin. A new command has been introduced into LBASIC. This command is SET EOF# (where # refers to the buffer # associated with an open disk file). This command may be used to reset the End Of File (EOF) marker of a random file. This is a very convenient way of shortening a random file that may contain unwanted records at the end. 27.> The file MOD1/EQU is included on your Master Diskette. It is an equate file, and may be used by assembly language programmers. 28.> The file VC/FIX is also included on your Master Diskette, and is a patch file to be used with VISICALC. LDOS Supports the T-TIMER (tm) by Roy Soltoff The T-TIMER, a bus-connected circuit board that provides a calendar and clock in real time, is now supported by LDOS. This board is manufactured by the BAR-W-HARDWARE-RANCH. The T-TIMER keeps the time and date via a MSM-5832 real time clock/calendar chip. It uses a power backup supply of 2-AA size batteries used for when the CPU is turned off. The T-TIMER is currently available for the Model I and plugs into either the expansion port (screen printer port) or the bus connecting the CPU to the expansion interface. It has a bus extender socket. My test version is connected to my LX-80 development system on the CPU. The LX-80 is then plugged into the T-TIMER. This timer has been in use for over two months without any problem. The pleasure of accurate date and time without having to enter date and time on each powerup is great. The only thing I have found wrong with this unit is that when plugged into the CPU bus, my little finger scrapes the edge of the T-TIMER circuit board when I press the TRS-80's RESET button. Perhaps I should just plug it into the expansion port and be done with it. The only bad thing about this device is that now I am spoiled. The office has four machines but only one T-TIMER. Come on BAR-W, get me a Model III version! The Model I T-TIMER is priced at $89 and is available from BAR-W at Box 1631, Hurst, TX 76053. Herewith are the LDOS patches: . TTIMER Model I Version 5.0.1 patch . Copyright (C) 1981 by Roy Soltoff, All rights reserved . PATCH SYS0/SYS.WOLVES D04,72=D8 45 ED 78 0D CD A1 47 ED 78 0D E6 0F 85 12 1B D04,82=C9 11 43 40 01 C5 03 CD C9 45 10 FB D0D,D3=21 46 40 01 CA 01 CD AA 4E 06 03 CD AA 4E 01 CC D0D,E3=0F CD AA 4E EB 13 DB CB E6 03 21 9E 50 20 01 34 PAGE - 37 D0D,F3=18 39 ED 78 0D A0 07 57 07 07 82 57 ED D0E,00=78 0D E6 0F 82 77 2B C9 . end of patch . TTIMER Model I Version 5.0.2 & 5.0.3 patch . Copyright (C) 1981 by Roy Soltoff, All rights reserved . PATCH SYS0/SYS.WOLVES D04,65=D8 45 ED 78 0D CD A1 47 ED 78 0D E6 0F 85 12 1B D04,82=C9 11 43 40 01 C5 03 CD C9 45 10 FB D0D,C0=21 46 40 01 CA 01 CD AA 4E 06 03 CD AA 4E 01 CC D0D,D0=0F CD AA 4E EB 13 DB CB E6 03 21 92 50 20 01 34 D0D,E0=18 34 ED 78 0D A0 07 57 07 07 82 57 ED 78 0D E6 D0D,F0=0F 82 77 2B C9 . end of patch . TTIMER Model I Version 5.1.1 patch . Copyright (C) 1981 by Roy Soltoff, All rights reserved . PATCH SYS0/SYS.SYSTEM D04,05=D2 45 ED 78 0D CD A6 47 ED 78 0D E6 0F 85 12 1B D04,82=C9 11 43 40 01 C5 03 CD C3 45 10 FB D0D,4E=21 46 40 01 CA 01 CD B8 4E 06 03 CD B8 4E 01 CC D0D,5E=0F CD B8 4E EB 13 DB CB E6 03 21 B9 50 20 01 34 D0D,6E=18 21 ED 78 0D A0 07 57 07 07 82 57 ED 78 0D E6 D0E,7E=0F 82 77 2B C9 . end of patch LDOS Device I/O and Independence by Roy Soltoff A very powerful and frequently used feature of LDOS is its relatively complete device independence. This feature is available through the FILTER, LINK, RESET, ROUTE, and SET commands. It is also available to the Assembly Language programmer due to the correlated structuring of the Device Control Blocks (DCB) as used for byte I/O devices {*KI, *DO, *PR, *CL, etc.} and the File Control Blocks (FCB) as used for all disk files. Any system that supports total device independent structures should be realized as an OS with possible channel input/output for each distinct device {such as console, error output, data sets, etc.} on the machine side. On the device side, there should exist no discernable transmission difference among all the peripherals attached to the machine. Furthermore, you should be able to easily interconnect any machine channel to any peripheral, possibly to multiple peripherals. The system should also be capable of installing filters (massaging functions) anywhere in the I/O channel. The operating system running on a TRS-80 most resembling this structure is LDOS. Functions lacking from this "total device independent structure" are its inability to filter a channel connected to a data set (disk file) as occuring from the command, "ROUTE *DD TO FILESPEC" and a somewhat simplified scheme in eliminating filters and channel connections once made (i.e. via RESET). These limitations generally stem from the lack of adequate memory available to the operating system in a 48K environment. Consider, for a moment, that UNIX - a most device independent system - takes upwards of 100K for its system implementation. PAGE - 38 Enough of the philosophical. Let's begin to examine the methods used in LDOS to implement device independence and reflect on how this ties in with the programming of drivers and filters. You will first need a basic understanding of the data fields associated with the DCB and FCB. Adequate explanations are covered in the technical section of the LDOS manual and will not be repeated here. I will expand on the information where applicable. Device independence has its roots in what I will call "byte I/O". The term shall apply to any I/O passed through a channel, one byte at a time. You get one byte when you scan the keyboard (albeit early TRS-80s were afflicted with kkeyyboouncce but that was not multiple byte input). One byte is passed to a printer. A data set generally has I/O data blocks of 256 bytes; however, we can certainly characterize a blocked file with a record length of one - that provides byte I/O with a data set channel. Three primitive routines are available at the assembly language level for byte I/O. Primitive is not used here to imply rudimentary but rather elementary. Just as the atom is considered a basic building block of molecules, these byte I/O primitives can be used to build larger routines. The three are called @GET, @PUT, and @CTL. Their vector entry points are in the Level II ROM. @GET is used to input a byte from a device or file. @PUT is used to output a byte to a device or file. @CTL is used to communicate with the driver routine servicing the device or file. A reasonable illustration of these routines is: ;*=*=* ; Example ROM Byte I/o Routines ;*=*=* @GET PUSH BC ;Save this register LD B,00000001B ;Set the mask code JR GO2DVR @PUT PUSH BC ;Save this register LD B,00000010B ;Set the mask code JR GO2DVR @CTL PUSH BC ;Save this register LD B,00000100B ;Set the mask code JR GO2DVR . . GO2DVR JP DVRBGN Observe the similarity of these routines. They are each identical except for the value loaded into register B which establishes a mask code. If we examine a few routines that use these primitives as building blocks, the illustration will become more clear. Three other routines are in the ROM having vectors labeled @KEY (scan the keyboard and return the value of any depressed key), @DSP (display a character on the video screen), and @PRT (output a character to the line printer. These appear as follows: @KBD LD DE,KIDCB$ ;P/u keyboard DCB JR @GET ;Go to input @DSP LD DE,DODCB$ ;P/u the video DCB JR @PUT ;Go to output @PRT LD DE,PRDCB$ ;P/u the printer DCB JR @PUT ;Go to output PAGE 39 Again we discover some interesting similarities among these three routines. First, each loads register pair DE with a pointer to a specific Device Control Block - the DCB assigned for use by the device. Second, where we expect to input a byte, we go to the @GET routine but where we want to output a byte, we go to the @PUT routine. These are not just whimsical procedures. The rule is that to input a byte from a device, we load register pair DE with the pointer to that device's control block then go to the @GET routine. If we want to output a byte to a device, we point DE to the control block and go to the @PUT routine. Similarly, if we want to "talk" to the driver routine servicing the device (i.e. RS232/DVR), we can use the @CTL vector. Later on I will show exactly how a driver routine can be written to sort out these primitives. If we go back and examine the three primitives, we notice that each one collects into an instruction that jumps to some common driver beginning. Again, this is a routine that exists in the TRS-80 ROM. Since the Model III routine is different from the Model I routine, both will be shown here. For one reason, it is important to see how Tandy screwed up the Model III device independence and made it more difficult for such an implementation in LDOS. For another reason, it is what forced the limitation of a maximum of four active ROUTES in the Model III. First the Model I routine: ;*=*=* ; Model I Driver Initialization for hooks ;*=*=* DVRBGN PUSH HL ;Save register HL PUSH IX ;Save register IX PUSH DE ;Transfer the DCB or 0CB POP IX ; address to IX PUSH DE ;Save register DE LD HL,DVRRET ;Set up return restoral PUSH HL ; onto stack LD C,A ;Xfer char to output LD A,(DE) ;P/u DCB/FCB "type" byte AND B ;Mask with primitive code CP B ;Can DCB handle the call? JP NZ,IOHOOK ;Go to DOS hook if not CP 2 ;Set flags for direction LD L,(IX+1) ;P/u lo-order vector LD H,(IX+2) ;P/u hi-order vector JP (HL) ;Go to device driver DVRRET POP DE ;Reg restoral routine POP IX POP HL POP BC RET The most important lines of code are: LD A,(DE) ;P/u DCB/FCB "type" byte AND B ;Mask with primitive code CP B ;Can DCB handle the call? JP NZ,IOHOOK ;Go to DOS hook if not PAGE - 40 This piece of code masks the TYPE byte with the primitive mask and checks for a match. For example, if you peek at address X'4015', the TYPE byte for the keyboard, you will see a value of X'01' or 00000001B. If the @GET primitive was entered by the @KBD vector, the mask value would be 00000001B. Thus the comparison would be a match and the jump to IOHOOK would not take place. What if the @PUT primitive was entered with register pair DE pointing to the *KI DCB? The TYPE value of 00000001B would be ANDed with the mask value of 00000010B with a resultant value of 0. The zero value would not match the mask value causing a jump to the IOHOOK routine. Obviously, an output request to the keyboard makes no sense! In fact, the keyboard driver could not even handle such a request!! We thus see that the first three TYPE bits (0, 1, and 2) are used by the three primitives to identify whether the device driver has any code to deal with each specific primitive. If you examine the TYPE codes in the *KI, *DO, and *PR device control blocks, you will see that *KI supports @GET, *DO supports @GET, @PUT, and @CTL, while the *PR device supports only @PUT and @CTL. Where a conflict occurs, the IOHOOK routine is supposed to deal with the error. In Level II, this will generate an illegal function call error. What would happen if the bits 0-2 each contained a zero but one of the bits 3-7 contained a one? If this were the case, then the comparison would never match the primitive mask and the jump to IOHOOK would always happen. Notice that the technical documentation states a ROUTED device has its TYPE byte bit 4 set to a one. A NIL device has its TYPE byte bit 3 set to a one. Therefore, any device which is ROUTED or NIL, will have all three primitive byte I/O calls directed to the IOHOOK routine. Also, if you examine the technical information on file control blocks, you will see that an FCB for an OPEN file, will have FCB+0 bit 7 set. This was not arbitrary. If register pair DE contains an FCB pointer for the primitive call (@GET or @PUT), then the DVRBGN routine will likewise vector to IOHOOK. This little feat enables us to get out of the ROM into a routine that we control in the operating system for any primitive call with a ROUTED or NIL device or an open file. More on that later. Before we go on to the Model III DVRBGN routine, let's take a peek at one last compare. After the masking is performed, if we don't jump to IOHOOK, we see a "CP 2" instruction. What's the purpose of this? The masked value will be either 1 for @GET, 2 for @PUT, or 4 for @CTL. The following table illustrates the FLAG register conditions prevailing after the compare for each primitive: TABLE I - FLAG SETUP -------------------- 1 CP 2 C,NZ = @GET primitive 2 CP 2 Z,NC = @PUT primitive 4 CP 2 NZ,NC = @CTL primitive After the compare, the DVRBGN routine picks up the vector pointing to the driver routine's entry point, places it into register pair HL, and performs an indirect jump instruction (this causes a jump to the address contained in register pair HL). PAGE - 41 We then see that when the DVRBGN routine passes control over to the device driver routine, the flag conditions are unique for each different primitive. This provides a method that the drivers can use to establish what primitive was used to access the routine - and the primitive established the direction of the request - input, output, or control! Now, the corresponding routine in the Model III will be shown. Prepare for the pain. The horrible instructions are preceded by triple asterisks: ;*=*=* ; Model III Driver Initialization for hooks ;*=*=* DVRBGN PUSH HL ;Save register HL PUSH IX ;Save register IX PUSH DE ;Transfer the DCB or FCB POP IX ; address to IX PUSH DE ;Save register DE LD HL,DVRRET ;Set up return restoral PUSH HL ; onto stack LD C,A ;Xfer char to output LD A,(DE) ;P/u DCB/FCB "type" byte *** BIT 7,A ;If not a file, don't *** JR Z,DVRB1 ; permit the IOHOOK AND B ;Mask with primitive code CP B ;Can DCB handle the call? JP NZ,IOHOOK ;Go to DOS hook if not DVRBl AND B ;Mask with primitive code CP 2 ;Set flags for direction LD L,(IX+1) ;P/u lo-order vector LD H,(IX+2) ;P/u hi-order vector JP (HL) ;Go to device driver DVRRET POP DE ;Reg restoral routine POP IX POP HL POP BC RET Tandy got their sticky little fingers into the ROM and created two lines of code that kept us from exiting through IOHOOK anytime bit 7 was reset. Ugh! Double ugh! Thus, neither the ROUTE bit nor the NIL bit could be used to force control to IOHOOK. This forced us to either implement a route driver in high memory (which would have eliminated device routes from LBASIC under the current scheme of memory management) or a route table in SYSRES (which would limit the number of active routes to some maximum number). The latter method was chosen as the lesser of two evils with four being arbitrarily set as the route table maximum. Four popped out due to space limitations. Since so much has been stated about the IOHOOK jump, let's take a look at a representative sample of such a routine. This one originates from the Model I LDOS: PAGE - 42 ;*=*=* ; LDOS Model I IOHOOK routine ;*=*=* IOHOOK0 PUSH HL ;Xfer pointer to IX POP IX IOHOOK LD L,(IX+1) ;P/u lo-order vector LD H,(IX+2) ;P/u hi-order vector LD A,(IX+0) ;P/u DCB/FCB type CP 00010000B ;Is this DCB routed? JR Z,IOHOOK$ ;Vector points to new DCB JP NC,BYTEIO ;Disk I/O on bits 7,6,5 AND 00001000B ;Is this DCB NILed? XOR 00001000B ;Set Z-flag if so RET Z ;Ignore CALL if NIL LD A,B ;Xfer the mask code CP 2 ;Set up the flags JP (HL) ; and go to vector addr ;*=*=* ; Byte I/O routine ;*=*=* BYTEIO EQU $ ;Tests for direction to ; read or write 1 byte Consider what would happen if we performed the command: ROUTE *PR *DO The *PR TYPE byte would contain the value X'10' indicating a routed device. Also, the ROUTE library command would replace the vector address in the *PR DCB with a pointer to the *DO device control block. That is, the first three bytes of the *PR DCB would be [10 1D 40]. If you trace through a call to @PRT (request to output a byte to the printer), you will discover that a jump to IOHOOK is performed. Trace through the IOHOOK routine. We first pick up the vector to *DO's DCB from (IX+1) and (IX+2) and put it into register pair HL. We then pick up the TYPE byte, compare it to 00010000B (X'10') and discover that the device is routed. The match causes a jump to IOHOOK$ which transfers the vector in HL (remember HL contained the *DO DCB address) This then falls through to IOHOOK which grabs the *DO vector and TYPE byte. If you examine the remaining code of IOHOOK, you will discover that in this case, the last three instructions get executed which are essentially identical to the ROM DVRBGN exit discussed earlier. Notice that if *DO was itself routed, IOHOOK would again loop to IOHOOK$ and continue the loop until it got to a device in the "chain" that was not routed. With the NIL bit set, it is easy to observe that the code in IOHOOK that appears as: AND 8 XOR 8 RET Z will perform an immediate return with the Z-flag set on a NIL device. This function constitutes the bit-bucket. PAGE - 43 If we performed the command: ROUTE *PR to filespec the TYPE byte of the *PR DCB would be set to X'10' indicating a route. However, the vector bytes would be set to the file control block in high memory established by the ROUTE command. The file would have been opened so the FCB would be in an open state (remember, bit 7 is set). What happens if we @PRT a character? The DVRBGN routine will again vector to IOHOOK. IOHOOK will discover that *PR is routed as previously shown. When IOHOOK$ does its job, it will now point IX to the FCB of the file *PR was routed to. The TYPE byte of the FCB (the FCB+1 byte) will have bit 7 set causing the jump to the BYTEIO routine. This routine is not going to be detailed here. It essentially ascertains from the mask byte whether the request was @PUT or @GET and performs the appropriate byte transfer for the file. Now that we have examined how LDOS directs I/O to either drivers or file access routines, let's take a peek at how we can establish control blocks for device independence. That's the real easy part. When you are requested to enter a specification, you generally can provide a device specification or a file specification. If a program is written to always provide for a 32-byte FCB, you will always have enough space for an 8-byte DCB. The system @OPEN and @CLOSE routines (@INIT included) detect the specification of device or file via the presence or absence of the asterisk prefix required in device specifications. If a file specification is given, @OPEN opens the file and constructs the open FCB. If a device specification is given, @OPEN copies the DCB into the FCB space (in the Model III we also must establish a pseudo-route table within the FCB space so that IOHOOK can gain control. Thus a standard linkage such as: LD HL,BUFFER LD DE,FCB LD B,0 CALL @OPEN doesn't care if FCB contained a true file specification or a device specification. At the conclusion of the @OPEN statement, the FCB contents are filled with data needed to support calls for byte I/O such as: LD DE,FCB CALL @GET or LD DE,FCB ;Point to control block LD A,CHAR ;P/u the char to output CALL @PUT ;Issue the PUT call CALL NZ,TSTERR ;Test if valid error JP NZ,IOERR ;Go service the error TSTERR EX DE,HL ;If a file, its an error BIT 7,(HL) ;Test for FCB EX DE,HL ;Z=DCB, NZ=FCB RET PAGE - 44 The byte I/O vector is independent of the device type provided the device can support that direction of I/O. The error testing procedure is needed if any output requests are made in an environment that is subject to either device or file specifications (independence). Since the TRS-80 ROM driver routines do not complete their output function and return unilaterally with the ZERO FLAG get, a @PUT to a device could be interpreted as an error. However, it is most important to test for an error return if the @PUT was to a disk file! It is for this reason that program authors who do not take this into consideration when writing their application software will cause havoc to those LDOS users that ROUTE *PR TO FILESPEC and lockup the system when "printer" output is re-directed to a disk file on a diskette that becomes FULL. Want to have some fun? Try going into LBASIC and running the following mini-program: 5 FO$="*PR" 10 OPEN"O",1,FO$ 20 PRINT#1,"This is a test" 30 CLOSE1 Find a use for that? Okay, let's say you have a program that writes data to a sequential file. You want to test the program and ascertain what is being written without actually having to generate the file and list it back out. You could of course duplicate your PRINT#1 statements as LPRINT statements. You could also have substituted the *PR device name in lieu of the file name in the OPEN statement. If your program contained numerous PRINT#1 statements, which would be easier? How about this one? ROUTE *D0 NIL ROUTE *D1 FILE1 ROUTE *D2 FILE2 ROUTE *D3 FILE3 LBASIC 10 CMD"ROUTE *D0 *D1 20 GOSUB180 30 PRINT#1,"Bunch of data" 40 CLOSE1 50 CMD"ROUTE *D0 *D2 60 GOSUB180 70 PRINT#2,"Another bunch of data" 80 CLOSE1 90 CMD"ROUTE *D0 *D3 110 GOSUB180 110 PRINT#1,"The last bunch of data" 120 CLOSE1 130 CMD"S 140 CMD"RESET *D1 150 CMD"RESET *D2 160 CMD"RESET *D3 170 END 180 OPEN"0",1,"*D0":RETURN PAGE - 45 And they said I didn't know BASIC! Ingenuity will find a use for this procedure. One such use could be to segregate output for different kinds of preprinted forms - such as tax forms. Now we will move on to the device driver linkage used to separate out the @PUT, @GET, and @CTL calls. It is extremely important to remember the FLAG register direction conditions that were set according to the primitive byte I/O routine that got us to the driver. These conditions were presented in TABLE I. Consider the following protocol for the "front end" of a driver: ENTRY JR BEGIN ;Branch around linkage DW $-$ ;Last byte used by driver DB BEGIN-ENTRY-5,'MODNAME' BEGIN JR C,WASGET ;Go if @GET request JR Z,WASPUT ;Go if @PUT request . ;Must have been @CTL request At the entry of the driver, an absolute jump instruction executes which causes a branch around some data. Ignore, for a moment, the data area which will be discussed shortly. At the label, BEGIN, a test is made on the CARRY FLAG. If the CARRY was set, then it only could have gotten itself into that condition if the disk primitive was an input request (@GET). Thus, an input request could be directed to a part of the driver which only handles INPUT from the device. If the request was not from the @GET primitive, the CARRY will not be set. The next test is if the ZERO FLAG is set. The ZERO condition prevailed when a @PUT primitive was the initial request. Thus the jump to WASPUT can go to a part of the driver that deals specifically with OUTPUT to the device. If neither the ZERO or CARRY flags are set, the routine falls through to the next instruction (which is not shown). What would follow would be a part of the driver that would handle @CTL calls. For instance, you may want to have an RS-232 driver handle a BREAK by issuing a @CTL call 80 that the RS-232 driver emits a true modem break, but a CONTROL-A (SHIFT+DOWNARROW+A) would @PUT a X'01'. You might ask why we don't check for a "NOCARRY" flag? Well if we just ascertained that the CARRY is not set, then it must be the other condition - there is only one CARRY flag - it is either SET or RESET. Thus the only other case could be a @CTL request. Some drivers are written to assume that @CTL requests are to be handled exactly like @PUT requests. This is entirely up to the function of the driver and the author thereof. If the driver is the LDOS byte I/O disk driver, a @CTL call is output to the disk file just as if the byte I/O primitive was a @PUT. Now, the front end linkage shown above has been implemented in LDOS supplied drivers and filters starting with release 5.1.1. This was to provide a uniform way of identifying the name of a driver when it was resident in memory as well as the last memory address used by the driver. The PDUBL/CMD double density disk driver released with 5.1.1 also has this linkage. PDUBL itself uses it to search through all drivers vectored from the Drive Code Table (DCT) prior to relocating itself into high memory in case PDUBL was already resident from a previous PDUBL command. PAGE - 46 Under LDOS 5.0.x, if you entered PDUBL twice, two copies of PDUBL would be in high memory - one just wasting away. This will not happen under 5.1.1. TWOSIDE also uses this technique. Although LDOS 5.1.0 had all of its filters and drivers implemented with a technique for determining system residency, they have been revised to also use this front end linkage for the sake of uniformity at the expense of a few extra bytes taken up in RAM. It will be interesting to observe that if every module using space in high memory used this technique, then one could check a device chain and locate the starting and ending point of each filter, driver, and whatnot. In fact, a memory management routine could be written to start from (HIGH$+1) and search through all of high memory presenting a directory of space utilization. Have I raised a few eyebrows? If you write drivers and filters, you can use this technique as easily as I can within the system. One last topic needs to be discussed relating to filters. A filter is inserted between the DCB and driver routine (or between the DCB and the current filter when applied to a DCB already filtered). The usual linkage for a filter is to access the chained module by calling the address that was in the DCB at the time of the filter installation. However, since the driver expected the FLAG register contents to designate the I/O direction of the request, it is ABSOLUTELY ESSENTIAL that each filter maintain the integrity of those flags when issuing that CALL instruction. If you check out the TRAP filter described in the technical section of your LDOS manual, that is the purpose of the PUSH AF - POP AF sequence. Another pitfall to watch out for is that routines handling output requests expect the output character stored in the C register when the routine takes over. At the conclusion of the routine, the character is generally placed in the A register. If your filter is going to massage output, adhere to those specifications. This will ensure compatibility amongst all filters and drivers. Questions and/or comments concerning this article may be addressed to me at LSI corporate headquarters. RELOCATING CODE FOR LBASIC USR ROUTINES by Chuck One of the most useful features of LDOS is the capability for a user to insert blocks of code in high memory and have them protected from the system. The FILTER and SET library commands operate in this manner. It is also possible to put blocks of code into memory to be called as USR routines from LBASIC. However, since the high memory location of the code can vary, any absolute references in the code to be moved will be incorrect after the relocation. Also, if the code is to be called as a USR routine, a method must be used to store the entry point for LBASIC to recover and assign with a DEFUSR statement. This article will describe three steps - how to relocate the code and set the new high memory protect, how to relocate absolute addresses in the code, and how to access this code from LBASIC. Normally, a front end program module is used to relocate the user code into high memory. This module normally can be ORGed at X'5200'. However, if the program is to be executed with the RUN (X) command, it should be ORGed at X'5300'. The normal order of code in the program will be as follows: PAGE - 4? 1) * The memory protect routine. 2) * The address relocater. 3) * The block move relocation. 4) * The table of relocation addresses. 5) * The actual code to be moved. The first thing you should do is to find the current HIGH$ value and the length of the code you wish to move. You can then calculate the new HIGH$ value, and the location in high memory where your code will reside. The next example assumes the label LENGTH is equated to the length of your code (a method to do this is shown in a later example). * The memory protect routine 00200 LD HL,(HIGH$) ;get current memory protect 00210 LD BC,LENGTH ;length of relocatable code 00220 OR A ;clear Carry flag 00230 SBC HL,BC ,calculate new HIGHS 00240 LD (HIGH$),HL ;store this value 00250 INC HL ;pt to 1st memory location Now that HIGH$ has the correct value to protect the code to be moved and the HL register is pointed at the start of the relocation area, you can see about fixing up all absolute addresses in the code. The method described here was chosen because it fulfils two requirements - it is very easy to use and modify, and it adds no extra code in high memory. This method requires the construction of a table containing the absolute instruction addresses. The easiest way to do this is to label all absolute instructions with common labels, such as REL1, REL2, etc. For example, suppose you had the following routine assembled at X'5500': 5500 C30655 00000 JP Z,OUT 5503 3E0A 00000 LD A,10 5505 C9 00000 RET 5506 E5 00000 OUT PUSH HL The first line of code assembles as an absolute jump on zero to address X'5506'. When this block of code is moved to high memory, a jump to X'5506' is not what the user really wants. This same problem occurs with CALL statements, a LD of registers from memory locations, or a LD of a memory location from a register. Of course, jumps, calls, or loads outside of the relocatable code will not be a problem. There are many different ways to get around this problem when writing your own code. Relative jumps can be used instead of absolute jumps, alternate registers can be used instead of memory locations, etc. However, there will be times when you will have to use absolute instructions. The following block of code will be used as an example to show how to label the instructions and construct the table. This code serves no actual purpose other than as an example. * The actual code to be moved PAGE - 48 5500 02000 ORG 5500H 5500 CD7F0A 02010 START CALL 0A7FH 5503 ED5B1755 02020 REL1 LD DE,(STOR1) 5507 CDC901 02030 CALL 01C9H 550A CD1355 02040 REL2 CALL LOOP1 550D CA1455 02050 REL3 JP Z,ENDIT 5510 221855 02060 REL4 LD (STOR2),HL 5513 C9 02070 LOOP1 RET 5514 C3C901 02080 ENDIT JP 01C9H 5517 00 02090 STOR1 DEFB 00 5518 00 02100 STOR2 DEFB 00 0018 02110 LENGTH EQU $-START 5500 02110 END 5500H As you can see, only those instructions that reference addresses inside the user's block of code need to be relocated. Calls or Jumps to ROM or LDOS system addresses outside of the relocatable code should not be altered! The relocating table will be a series of addresses. The label RELTBL should be placed on the first entry in the table. Also, a terminating pair of 0 bytes should be the last entry in the table. * The table of relocation addresses 01000 RELTBL DEFW REL1+2 DEFW REL2+1 DEFW REL3+1 DEFW REL4+1 DEFW 0 ;end of table indicator The table entries point to the locations in memory where the absolute addresses reside. Notice that the REL1 label entry is +2 from the start of the instruction. This is because the LD DE,(STOR1) instruction is a 4 byte instruction with the address being the last two bytes. All other of the example addresses follow single byte instructions and therefore are offset by only 1 byte. If you are unsure of the instruction length, it would be advisable to run an assembled listing and check the offsets used in the table. The next block of code will make the adjustments of the necessary addresses before the code is moved into high memory. It should immediately follow the block of code that calculates the new HIGH$. At that point, register pair HL contains the address where the relocatable code will start in high memory, and BC contains the byte count of the code to relocate. The address in HL will also be the entry point when the code is called as a USR routine from LBASIC. It is assumed that the label START is used on the first line of the code to actually be moved into high memory. * The address relocater PAGE - 49 00500 ;**** Relocate hard Jumps, Calls, and Addresses 00510 ; 00510 PUSH HL ;save entry point 00520 PUSH BC ;save byte count 00530 LD BC,START ;reloc. code start 00550 OR A ;clear CARRY flag 00560 SBC HL,BC ;calc. offset for reloc. 00561 ; 00562 ; Register HL now contains the offset difference 00563 ; between the current location and the location 00564 ; in high memory. 00565 ; 00570 LD C,L 00580 LD B,H ;offset into BC 00590 LD IX,RELTBL ;table of labels to adj. 00600 RELOOP LD L,(IX) ;pre-move address 00610 LD HL,(IX+1) 00620 LD A,H ;msb of table entry 00630 OR A ;see if it is a Zero 00640 JR Z,DUNREL ;end of reloc. on Zero 00650 PUSH HL ;save loc. of address 00660 LD E,(HL) ;now get the CONTENTS 00670 INC HL ;of the memory location 00680 LD D,(HL) 00690 EX DE,HL ;current absolute address 00700 ADD HL,BC ;add in the offset 00710 EX DE,HL ;new address into DE 00720 POP HL ;loc of address 00730 LD (HL),E ;store the offset address 00740 INC HL ;in the current instruction 00750 LD (HL),D 00760 INC IX ;next table location 00770 INC IX 00780 JR RELOOP ;reloc. next label Now that all of the necessary adjustments are made, you can move the code into high memory. Remember that the entry point and byte count were pushed onto the stack at the start of the previous routine. * The block move relocation 00800 DUNREL POP BC ;recover byte count 00810 POP DE ;recover entry point 00820 LD HL,START ;start of user code 00830 LDIR ;move it 00840 JP @EXIT ;EXIT, all done At this point everything is complete. The routine is loaded in high memory, the HIGH$ value is set to protect it, and all absolute addresses have be relocated. However, nothing has been done to make this routine available as a USR call from LBASIC. To do this, the location of the entry point in high memory must be stored in a fixed location so that the LBASIC program can pick it up. PAGE - 50 There is an 8 byte user storage area provide in LDOS just for this purpose. This area is pointed to by the address in USTOR$, memory locations X'4DFE' and X'4DFF'. Consider the rewrite of the previous five lines: 00800 DUNREL POP BC ;recover byte count 00810 LD HL,USTOR$ ;get pointer to user area 00820 LD E,(HL) ;now point DE at 00830 INC HL 00840 LD D,(HL) ;user storage location 00850 EX DE,HL ;0nto HL for load 00860 POP DE ;recover entry point 00870 LD (HL),E ;and store entry point 00880 INC HL 00890 LD (HL),D ;for recovery by LBASlC 00900 ; 00910 ; Now we continue the relocation move 00920 ; 00930 LD HL,START ;start of user code 00940 LDIR ;move it into high memory 00950 JP @EXIT ;EXIT, all done This routine will work for USR programs with a single entry point. If more than one USR call will be made to the same block of code, the entry points can be stored sequentially in the user storage area. Since there are 8 bytes of storage space, up to four entry points can be used with this method. However, storing four entry points would require a slightly different routine to replace lines 860 to 890 in the previous example. The LBASIC program can pick up the entry point as follows: 100 DEFINT X 110 X=PEEK(&H4DFE)+256*(PEEK(&H4DFF)) 120 REM ** It will be necessary to use the negative value 130 REM ** when the entry point is above 32767. 140 DEFUSR1= -1*(65536-(peek(X)+256*(peek(X+1)))) If more than one entry point is needed, addition lines similar to line 140 can be used, indexing off of the value in the variable X. THE JCL CORNER by Chuck A survey of all the customer support people revealed an interesting fact. Only one of them recalled ever being asked a question dealing with JCL compiling or the compilation macros. "Plenty of questions about the execution phase", they said, "but nothing about compiling". This tends to suggest one of two things - either everyone knows everything about the compiling phase of JCL, or no one is using it because they don't understand it. Assuming a point midway between these two conclusions, the next issues of the quarterly will try and explain the function of the compilation phase of JCL, and give some practical examples of its use. PAGE - 51 The first question that comes to mind is "Why compile a JCL file ?" Basically, the compilation phase allows a single JCL file to be used for many different functions, and to have these functions selected at runtime. There are three terms that will be used throughout this discussion. They are LABEL, TOKEN, and MACRO. Labels are probably the easiest to understand. They are merely used to combine many smaller JCL files into one larger file to save disk and disk directory space. A token can be considered a variable. It will have either a logical true or logical false value. It may also have a string value assigned to it. A macro is a special JCL command statement. It is always in the format of two slashes (//) followed by the appropriate word. So how can you construct a JCL file to make practical use of the compilation feature? A good place to start will be by gaining an understanding of the logical decision capabilities of JCL. This will include the three logical operator symbols and the three decision macros. Of course, the all important tokens will also be discussed. Logical operators Decision macros ----------------- --------------- AND & //IF OR + //ELSE NOT - //END The decision macros can be used with or without the logical operators. The //IF macro is used to test the logical value of the statement following it. For example: //IF a ;Tests to see if the token "a" is true //IF -a ;Tests to see if the token "a" is false A token can be declared to be true by specifying it on the DO command line. It does not have to be assigned a value. All of the following examples will assign a true value to the token "a". DO TEST/JCL (a) DO TEST/JCL (a=testfile) DO TEST/JCL (A) You will notice that upper and lower case are evaluated identically, and there is no real difference between the first and third examples. Now that we know one method of assigning a true value to a token, we can determine how to assign it a false value. There is literally nothing to assigning a false value to a token - simply do not specify it on the DO command line. Also, the //SET, //ASSIGN, and //RESET macros can assign or reset a token's logical value. They will be discussed later. The //END macro is used to mark the end of a corresponding //IF block. There must be one //END used for every //IF. The //ELSE macro is used to provide an alternative course of action in case an //IF statement evaluates false. As you will see later, //IF conditional blocks can also be nested inside of //ELSE blocks. Now for some examples: Example #1 . TEST/JCL PAGE - 52 //if a . print this comment //end Example #2 . TEST/JCL //if a . print this comment //else . print nothing entered! //end Example #3 . TEST/JCL //if a . print this comment //else //if b . print it was b, not a //else . print neither a or b //end //end Example #1 is easy to understand, If the token "a" was true, the comment line would be printed. Example #2 gives an alternate course of action in case the token "a" is false. Example #3 does the same thing, except that the alternate action also is a conditional test. Notice that there are two end statements in this example - the first //END ends the second //IF, and the second //END ends the first //IF. The logical operators can be used with the //IF macro to do more complex testing. Logical operators all have the same precedence, and will be evaluated from right to left. Refer to the following: //IF a+b ;if either a OR b is true //IF -a&-b&-c ;if NOT a AND NOT b AND NOT c (if none is true) //IF a&-b ;if a AND NOT b (if a is true and b is false) //IF b+-a ;if b OR NOT a (if either b is true or a is not true) As you can see, almost any combination of tokens and logical operators can be used with an //IF macro to determine the logical condition, and therefore the inclusion or exclusion of the following lines in the file up to the corresponding //END macro. As was mentioned earlier, the //SET and //RESET macros can change the logical value of a token. //SET will assign a true value, and //RESET will assign a false value. //ASSIGN will assign a true value, as well as a character string value, to a token. One very powerful use for these macros is to allow a single control token to adjust the values of numerous other tokens for use by the rest of the JCL. This will reduce the number of characters needed on the DO command line to. For example: .TEST/JCL //if a //set b //set c PAGE - 53 //assign d=testfile //reset ex //else . a was not entered //exit //end By entering a DO command "DO TEST/JCL (a)", you will assign the tokens "b" and "c" a logical true value, assign the token "d" a true value as well as the string value "testfile", and assign the token "ex" a logical false value, even if "ex" was entered on the DO command line. You could now have a series of //IF lines to do procedures based on the value of the tokens. Perhaps you're wondering why a token can be assigned a string value since we have only discussed logical evaluations. They answer is that token values can be used as substitution fields, and can also be concatenated to build larger strings - probably the most powerful feature of the entire JCL language! Token substitution and concatenation is easy. Simply use the pound sign (#) to enclose the token name in the proper places. For example: COPY #f1#:1 to #f2#:2 COPY #f1#:#s# to #f2#:#d# BACKUP GEN/#ex#:#s# :#d# The first two examples have substitution fields for the filespec in the COPY command. Additionally, the source and destination drivespecs are substituted in the second example. The third example substitutes the file extension for a BACKUP command, as well as the drivespecs. Consider the following JCL examples: Example #1 . TEST/JCL //if a //assign ex=ASM //end //if -a //assign ex=CMD //end //if -s //assign s=1 //end //if -d //assign d=2 //end BACKUP GEN/#ex#:#s# :#d# //exit Suppose you had two sets of files named GEN1 through GEN8, with one set having the extension /ASM and the other set having the extension /CMD. This file would allow you to backup these files sets and assign the source and destination drives. It also provides default drivespecs in case they are not entered on the DO command line. The JCL files in the Update section of the newsletter even use a substitution field for the password in the filespec to apply the patches. Refer to the following DO command line examples and the resultant line generated by the JCL compiler: PAGE - 54 DO TEST (a,d=3) =>BACKUP GEN/ASM:1 :3 DO TEST =>BACKUP GEN/CMD:1 :2 DO TEST (s=0,d=4) =>BACKUP GEN/CMD:0 :4 One final point to end this month's JCL corner. IF you are going to experiment with JCL compilation, you may wish to use the special character $ in the DO command. This will do the compilation without actually executing the file. You can list the SYSTEM/JCL file to see the results of the compilation. If everything is satisfactory, you can then execute the SYSTEM/JCL file with the command DO *. Also, any compilation process should produce at least one line of executable code. Otherwise, the existing SYSTEM/JCL file may be executed. One way to avoid this problem is to start every JCL file with an execution comment listing the name of the file. LATE BREAKING NOTES AND PATCHES =============================== There are a few notes and extra patches that apply to the Model I, 5.1.1 version. If the file dates on your master is 12/15/81 or later, these patches have already been installed. On page 5-5 of the 5.1.1 LScript addendum, there is an error in the MICROPROOF patch. The byte 22F in the second line of code should be a 2F. There is a small patch for LBASIC/0V2 that correctly exits to LBASIC if the key is pressed. . LBASIC/0V2A . This patch will cause the break key to work correctly . during a CMU"X" . X'5682'=62 58 X'5694'=6B 21 00 X'5862'=CD 73 56 C3 F6 55 . . EOP Here is a short patch for the KI/DVR program, Model I, 5.1.1 only. It allows a zero character to be generated by a <@> as stated in the manual. . KIA/FX1 . This patch will allow CNT<@> to send a null properly . D00,FD=FE FF . . EOP Both the Model I and III versions allow system overlays to be resided in memory, thereby freeing up disk space. When creating a minimum system disk, the only SYS files that normally need to be on the disk to boot the system are SYS0 and SYS2. However, if the CONFIG/SYS file has more than 4 extents, SYS8 must also be on the disk. PAGE - 55 It is not advisable to ROUTE or LINK the printer to a disk file when using LCOMM or the printer SPOOLer. The results will vary depending on the particular hardware you are using. The most common result is a constant stream of zeros written to the file. As explained in Roy's article on Device I/O, the @CTL call can be used to check the status of a device. When the @CTL call is made to a device that is connected to a file, a zero character actually gets written to a file. In LCOMM, the status of the printer is checked as a high priority interrupt task. That means approximately 40 zeros per second will be written to the file! Here is a short patch to KI/DVR for Model I, 5.1.1 owners who are using the LSCRIPT patch with Scripsit. It will increase the repeat rate of the keyboard, and thereby speed up the cursor movement in Scripsit. . PATCH FOR KI/DVR to increase the keyboard repeat rate . D01,22=01 D02,F9=01 D03,00=01 One final note on double sided drives.... We have just re-tested TWOSIDE and PDUBL with double sided drives. We could find no problems in double or single density. However, one of our dealers who is also a hardware dealer has discovered that some Radio Shack interfaces had pins 32 and 34 connected together. Also, some disk drives have pin 34 grounded internally. When these two hardware elements come together in the same system, trouble results, especially with double sided drives. lf you are having difficulty, check the expansion interface and separate pins 32 and 34 if necessary. The patch file VC/FIX on the 5.1.1 LDOSXTRA disk had extra carriage returns in the three longest lines in the file. These must be removed to keep from getting an error when applying the patch. NOTE: This patch is identical to the patch on the MicroNET board, and the one in the last newsletter. When doing a backup from a source disk of larger capacity than the destination disk, it will be necessary to have multiple destination disks. BE SURE TREY ARE ALL FORMATTED THE SAME. Switching the number of tracks or sides can cause the backup to abort with a "Directory Read Error". For those of you looking for an LDOS compatible data base, the MAXI MANAGER data base program should now be LDOS compatible. Instructions on converting the programs to LDOS will be supplied when purchased. TRS-80 and TRSDOS are trademarks of Tandy Corporation. The LDOS QUARTERLY is copyrighted in it's entirety. No material contained herein may be duplicated for any purpose without the written permission of Logical Systems, Inc. PAGE - 56