@(#)top: ######## ################## ###### ###### ##### ##### #### #### ## ##### #### #### #### #### #### ##### ##### ## ## #### ## ## ## ### ## #### ## ## ## ##### ######## ## ## ## ##### ## ## ## ## ## ##### ## ## ######## ## ## ## ### ## ## #### ## ## ##### #### #### #### #### ##### #### #### #### #### #### ###### ##### ## ###### ###### Issue #14 ################## Version 1.0 ######## November 1996 ------------------------------------------------------------------------- @(#)contents: Table of Contents Features 6. The Commodore Telnet BBS by Bo Zimmerman (Reference: net) In this age of internetworked computer systems, is the Commodore left out? No way, as Bo Zimmerman describes how to coax your Commodore BBS system to play the networking game. Bo shows how to set up your BBS so that Internet users can "telnet" to your BBS from anywhere on the 'Net. 8. Menu Toolbox III by Jeff Jones (Reference: toolbox) You've got this neat idea for a game, utility, or productivity application. The engine is complete and working, but the user interface is a mess. Do you scrap the project because you're not up to the task of writing a whole UI engine? Nonsense. Jeff presents a rich set of functions and subroutines to tame that killer application. 11. The CMD Nirvana: The Guts and Glory by Todd Elliott (Reference: hw) Has your computer system started looking like the multi-headed beast from a "B" movie? Are you tired of having so many items on your desk? Do you envy IBM PC owners with their all-in-one computer? Well, if you answered YES! to any of the above, let Todd show you his souped up C128DCR. Learn how you, too, can "upgrade" your computer system and refine its image. 13. Jim Butterfield: The Commodore Guru - An Interview by Jim Lawless (Reference: jb) Jim Butterfield has long been associated with the Commodore computer system, from the days of the KIM-1 to the present. Many of us learned machine language through Jim's articles or books, while most have benefitted from his early work on creating memory maps and documenting KERNAL routines for the Commodore line. Jim Lawless talks to the ubiquitous Commodore Guru. Columns 4. Hi Tech Trickery by Alan Jones (Reference: trick) In part II of Alan's "Heavy Math" series, he moves right into Linear Programming and how to accomplish it on the C64. If you're still not sure what LP math is, read on, as you'll be surprised at which everyday problems fall into this category of mathematics. 15. Hacking BASICs by Richard T. Cunningham (Reference: basic) Even as more and more programmers take up the ML flag and wave it proudly, there are many who either use BASIC entirely, or prototype pieces of code in BASIC before converting to ML. Richard outlines some common "gotchas" in the ever-present programming language. 17. Twiddling the Bits by Ward Shrake (Reference: bits) OK, VIC-20 enthusiasts, listen up. Resident VIC-20 cartridge expert Ward Shrake details exactly how the VIC-20 and its cartridges work together to allow the user to play games and use applications on cartridge. Ward details how to archive your collection of VIC carts, as well as how the computer recognizes and executes code on a cartridge. Departments 1. The (cough, cough) Hacking Editor (Reference: editor) 2. Input/Output (Reference: io) 3. Newsfront (Reference: news) 5. Hacking the Mags (Reference: mags) 7. UseNuggets (Reference: usenet) 9. FIDO's Nuggets (Reference: fido) 10. The Hacking Review (Reference: review) 12. Hack Surfing (Reference: surf) 14. Commodore Trivia (Reference: trivia) 16. ? DS, DS$: rem The Error Channel (Reference: error) 18. The Next Hack (Reference: next) 19. Hacking the Code (Reference: code) ------------------------------------------------------------------------- @(#)legal: Commodore Hacking Legal Notice Commodore and the respective Commodore product names are trademarks or registered trademarks of ESCOM GmbH or Visual Information Services Corporation. Commodore Hacking is in no way affiliated with ESCOM GmbH or Visual Information Services Corporation (VISCorp), owners of said trademarks. Commodore Hacking is published 4 times yearly by: Brain Innovations Inc. 10710 Bruhn Avenue Bennington, NE 68007 The magazine is published on on-line networks free of charge, and a nominal fee is charged for alternate mediums of transmission. Permission is granted to re-distribute this "net-magazine" or "e-zine" in its entirety for non-profit use. A charge of no more than US$5.00 may be charged by redistribution parties to cover printed duplication and no more than US$10.00 for other types of duplication to cover duplication and media costs for this publication. If this publications is included in a for-profit compilation, this publication must be alternately available separately or as part of a non-profit compilation. This publication, in regards to its specific ordering and compilations of various elements, is copyright (c) 1995-96 by Brain Innovations, Incorporated, unless otherwise noted. Each work in this publication retains any and all copyrights pertaining to the individual work's contents. For redistribution rights to individual works, please contact the author of said work or Brain Innovations, Inc. Brain Innovations, Inc. assumes no responsibility for errors or omissions in editorial, article, or program listing content. ------------------------------------------------------------------------- @(#)info: Commodore Hacking Information Commodore Hacking is published via the Internet 4 times yearly, and is presented in both ISO-8859-1 and HTML versions. This and previous issues can be found at the Commodore Hacking Home Page (http://www.msen.com/~brain/chacking/), as well as via FTP (ftp://ccnga.uwaterloo.ca/pub/cbm/hacking.mag/) In addition, the Commodore Hacking mail server can be used to retrieve each issue. To request a copy of an issue, please send the following electronic mail message: To: brain@mail.msen.com Subject: MAILSERV Body of Message: help catalog send c=hacking13.txt quit To retrieve a PKZIP 1.01 archive of the individual articles in Commodore Hacking, request the file c=hacking13.zip To subscribe to the Commodore Hacking and receive new issues as they are published, add the following command to you MAILSERV message prior to the quit command: subscribe c=hacking Firstname Lastname msglen (msglen is largest size of email message in line you can receive. Each line is roughly 50 characters, so 600 lines is about 30000 bytes. When in doubt, choose 600) example: subscribe c=hacking Jim Brain 600 Although no fee is charged for this magazine, donations are gladly accepted from corporate and individual concerns. All moneys will be used to defray any administrative costs, subscribe to publications for review, and compensate the individual authors contributing to this issue. As part of a magazine promotion, Commodore Hacking Issue #12 was professionally laid out on printed format. These printed copies are for sale. If you can not obtain Commodore Hacking through any other means and wish to purchase a copy on disk or would like to purchase the professionally printed Issue #12, please address a check or money order to "Jim Brain" and mail to: Jim Brain 10710 Bruhn Avenue Bennington, NE 68007 Disk copies of each issue: USD$5.00 Professionally printed copy of Issue #12: USD$6.00 All prices cover only duplication and materials and include shipping in the United States. For disk copies, please specify format: Computer Disk Size Capacity Notes CBM/PETSCII 5.25 inch 170 kB 1541 format 340 kB 1571 format 3.50 inch 800 kB 1581/FD2000 format 1.6 MB FD2000/FD4000 format IBM/ASCII 3.50 inch 720 kB Double Density 1.4 MB High Density Any persons wishing to author articles for inclusion in Commodore Hacking are encouraged to view the submission guidelines on the WWW (http://www.msen.com/~brain/pub/c-hacking-submit.txt) or via the MAILSERV server (send c-hacking-submit.txt). ========================================================================= @(#)rch: Reading C=Hacking Starting with Issue 11 of Commodore Hacking, the new QuickFind indexing system is utilized to aid readers of the text version in navigating the magazine. At the top of each article or other important place in the magazine, a word prefixed with a special string is present. (See the title of this article for an example.) Throughout the magazine, if an article is mentioned, it will be followed by a reference string. For example, if we mentioned this article, we would add (Reference: rch) after the name. By using your favorite editor's search function and searching for the string after the word "Reference:", prefixed by the magic prefix string, will move you directly to the article of choice. To merely skip to the next article in the magazine, search only for the magic prefix string. Some handy indexing strings possibly not referenced anywhere are: top top of issue bottom bottom of issue contents table of contents legal legal notice For those with access to a UNIX system, the command "what" can be run on the issue, which will result in all the article titles being printed. A slightly different magic prefix string "@(A)" is used to delimit sub-topics or main heading in articles. The text after the magic string differs depending on article content. For the Input/Output column (Reference: io), the text after the magic prefix will either be "c" for comment, or "r" for response. In features and columns, a number after the prefix indicates the ordinal of that heading or sub-topic in the article. If a specific sub-topic is referenced elsewhere in the article, a sub-topic reference will be indicated. A reference to "@(A)r" would be written as "(SubRef: r)". As time goes on, the role of this indexing system will be expanded and changed to ease navigation of the text version, but minimize the clutter added by these extra items. ========================================================================= @(#)editor: The Hacking Editor by Jim Brain (j.brain@ieee.org) Sometimes, it's important to look back and see how far we've come. The following story comes to mind: A young boy sits in the living room and flips earnestly through a Montgomery Wards catalog looking for some item. The year is 1983. At last he finds the item and presents the book to his father, who is reading a periodical in his easy chair. "Dad," the boy begins, "I want to buy one of these with my savings." The father, startled upon hearing of such a prospective purchase, looks up and reaches for the catalog. "What is it you want to buy?" he asks. "That video game on the top of the page is what I want," the boy explains. The father looks at the pertinent page and notices a glossy picture of an Atari VCS2600 console system, complete with options. Frowning, the father raises his head and look in the boy's eyes. "Son," he starts, "I am not going to let you buy one of these video game systems. All they are good for is playing games, and that's too much money to spend to buy a game." The boy protests, stating that "all his friends" own one and that it the "thing" to own today. The father, known for being stubborn, refuses to budge on the issues, but concludes the exchange by handing the catalog back and saying, "If you want to buy a machine that plays games, buy one of those new computer systems. That way, you can play games with it and also use it for other things when the games get old and boring." The boy takes back the book and sulks for a while as he flips through the pages. As the hurt wears off, he notices a section near the video console page that shows off those new computer systems his Dad referred to. At first, the kid's eye is drawn to the shiny silver Texas Instruments TI-99/4 computer system pictured in the catalog. He is about to jump up and again hand the catalog to his Dad when he realizes the "new-fangled" item is priced at $322.00. His heart sinks, for his savings account only holds a bit over $250.00 and the machine looked so impressive. So, beaten again, the young boy flips the page and resigns himself to never owning anything "cool". However, the next page pictures a different computer system and a quick check confirms the price is within budget: $233.00. The computer isn't as impressive looking as the TI, but the boy will not be without a "video game", and this fits the bill. Needless to say, the computer was a Commodore VIC-20, and the boy bought a few games for the unit, including a Space Invaders clone and a Pac-Man clone. As the father predicted, the boy lost interest in the unit after a while and packed the system away. However, as the boy entered 7th grade, he again pulled the unit out when he learned that one of his classrooms was equipped with Commodore VIC machines. His interest in computers as tools started there and grew with the years. As I finish my first year of editorship of Commodore Hacking, I am looking back at the events that have occurred in the last year and those that have occurred over the years since I first learned about Commodore computers. Commodore owners have come from 3.5kB and 22 by 23 screens with the VIC-20 to CBM machines with features like multiple megabytes of RAM, 33.6 kbps FaxModems, gigabyte hard drives, 8-20 MHz operation, and a host of other options. No, I don't think Commodore computers can solve all the world's problems. However, they and their owners should be commended on their loyalty and dedication to the market and to the advances that have kept the machines out of closets and dumpsters. While I won't doubt that there are more IBM PC clones in the world today, I wonder how many PC units are resting under tons of refuse in the city dump. Here at Hacking Headquarters, I am impressded by what we have accomplished with the publication, but I have already outlined improvements that can be made and things I didn't quite get implemented this past year. As always, your letters and comments are always appreciated. The publication depends on reader feedback to ensure that covers subjects of interest to the Commodore enthusiast. Of course, some things, like the technical focus of Commodore Hacking, define the magazine and its place among the various Commodore publications. However, even that can be continually improved. So, as you look back on the past year of Commodore usage, take a look at our progress or lack thereof and send us a note, if only to tell us to change nothing. Remember, we can't increase the publication's usefulness to you if we don't know where it currently falls short. As for the boy in the above story, I think he's come a long way since that fateful day in 1983. He no longer thinks TI's look better than CBM's. In fact, I think he has earned an impressive reputation as a Commodore advocate. Then again, I might be a bit biased, so you be the judge. The boy in the story was a youngster named Jimmy. Jimmy Brain. Enjoy YOUR magazine, Jim Brain (j.brain@ieee.org) editor ========================================================================= @(#)io: Input/Output Obviously, Commodore Hacking depends on the comments and article submissions from the Commodore community to flourish. Everyone sees the articles, but let's not forget those comments. They are very helpful, and every attempt is made to address concerns in them. Address any comments, concerns, or suggestions to: Commodore Hacking 10710 Bruhn Avenue Bennington, NE 68007 j.brain@ieee.org (Internet) @(A)c: Hey! You Characters! Sit Down! From: Adam Vardy (abe0084@InfoNET.st-johns.nf.ca) Dear C=Hacking, In the last issue there was some source code for printing very big numbers. This source code is all in uppercase. This seems to be true whenever source code is included in the magazine. I am wondering why that is. This makes it rather difficult for me to extract the source and put it into a form that my assembler can deal with. I can't load the source right into Power Assembler. It only accepts lowercase code. It is puzzling to me why you do this, because I would think any assembler that accepts plain text would work this way too. Another thing is this. In the last issue one of the uuencoded files in the magazine was dim4. The source code for the included files is for the Merlin Assembler. OK. So I try to read these files. I'm having problems with this. If I try to More them in ACE, I can't. It's unreadable. They seem to be text, but however I try to read them, I get weird characters or other stuff. Loading them into a word processor or into ZED, or anything doesn't work. I don't have Merlin. But I would think it must have some way to save plain text source. That way, everyone can at least read it, right? @(A)r: Code is printed in the magazine as it is received by Commodore Hacking. The only formatting done to source code in articles and columns is to indent each line 3 spaces. The source code to which you refer above was in a USENET posting and was captured from the comp.sys.cbm newsgroup in uppercase. Our theory is that some folks who upload code to the Internet do not do an PETSCII-ASCII translation, which would cause the effect of switching all lowercase characters to uppercase. However, we are not certain that there all assemblers expect lowercase, which is why we do not try to alter case of source code. As for your second problem, we accept part of the blame. We are attempting to obtain allof the source code used in the publciation in ASCII or PETSCII format. However, a number of assemblers, including Turbo-Assembler, do have an internal format that is neither ASCII nor PETSCII. Merlin may also have such a format. However, we are unfamiliar with Merlin, so it may not have an option to output code in ASCII or PETSCII, as Turbo- Assembler does. Our suggestion is to contact the author of the article directly and ask for an ASCII copy of the source and accept our apologies. @(A)c: A Plea for Information From: MICHAEL I DEMING Dear C=Hacking, An article or series of articles on the 80 column chip would be very helpful e.g. how to use sprites, a screen dump and other things like that. If I knew how to do this I would write the articles but I don't so I am begging for any info on this chip. @(A)r: Always check back issues of Commodore Hacking for prior articles on topics. See Commodore Hacking Information (Reference: info) for directions on how to access back issues. VDC information is included in Issue 1 as part of Craig Bruce's "Simple Hires Line Drawing Package for the C128" and as part of Craig Taylor's "An In-Depth Look at the 8563 Video Chip on the C= 128" in issue 2. As for the other topics, other articles in Commodore Hacking touch on those issues, but we always appreciate new articles dealing with these topics. @(A)c: All I Can Say is Wow! From: George Szaszvari In Commodore Hacking #13 Preface: >Whew! Folks, here is the long awaited Issue #13 of Commodore Hacking. >Hacking Headquarters has produced an issue overflowing with technical >articles sure to satisfy even the most discerning Commodore enthusiast. >In fact, this issue is OVERFLOWING with 384 kB of material, so empty out >that mailbox. Here it comes... Yeah, a real BUMPER issue, thanks! @(A)r: Well, the size is a both a blessing and a curse. While we are happy about the number and diversity of articles, we know there are those who can't handle a large issue like #13, so we are trimming the size a bit from #14. However, thanks for the comments. @(A)c: Speaking of Kudos! From: Brett Tabke Dear C=Hacking, Thank you! One of, if not THE, best issues yet! I can't thank you enough for all the work you've done here Jim. Between Hacking, The FAQ, and the CBM product documetation, you have put out more valuable information in 6 months than most of the pay magazines to in their lifetime. The CBM products listing is a rare treasure that every CBM owner should take time to read. @(A)r: We don't know what to say. We're just happy that everyone stood by us during the move and the delay in getting #13 out. By th way, for those who have not seen. The CBM Products List to which Brett Tabke refers is available as "cbmmodel.txt" on the MAILSERV and through the WWW. (http://www.msen.com/~brain/pub/cbmmodel.txt) If you prefer to wait, an updated copy will be presented in Commodore Hacking #15. @(A)c: Who's Got the Right Copyright? From: Ruth Hackley (fgm@rosenet.net) Dear C=Hacking, I am Ruth Hackley, Ron's wife, and newsletter editor for the L.C.C.U.G. in Eugene. Are there any portions of C=Hacking that can be used in the newsletter. We plan to provide the magazine on disk to our library as well. @(A)r: The entire publication can be redistributable as a complete work, as explained in the Commodore Hacking Legal Notice (Reference: legal). As well, individual articles can be reprinted with permission from the author of the article. Commodore Trivia is a special case. Permission has been given by the author to reprint Commodore Trivia in newsletters and publications, just as _Commodore World_ and this publication do. @(A)c: A Little Lacking From: Scott Brockway Dear C=Hacking, I thought the magazine was sort of a transactor replacement. When I downloaded issue 12 of C=Hacking I was not just a bit disappointed. I like all the technical stuff and now I fear the mag is no longer for me. Hey C=H, Put the code back in! @(A)r: We are sorry you felt this way. It was not, nor is it currently, our intention to leave technical readers without articles of interest. We ask that you take a good look at the magazine. Others have initially thought the magazine lacked technical content, but later determined that the style of some articles had changed and the technical articles were separated by a few less technical offerings. However, be aware that due to the time and space constraints we are trying to fit Commodore hacking in will reduce the number of technical articles by 1 or possibly 2 each issue over the old issues. Also, some technical articles do not contain any code pieces. In the case of Issue 12, we were forced to redo the issue after an important technical article from a semi-regular writer did not appear. The resulting rework might have shown through. We hope Issue 13 provided enough technical content. Our most technical readers might find the current issue a bit light on content, due to problems associated with Commodore Hacking's recent relocation efforts. We ask that the technical readers bear with us as we ramp up in our new location. One of our continual problems, and one of Craig Taylor's (the previous editor) as well was finding quality technical articles to publish. One way to solve the problem is to delay the publication date, a tactic Craig might have used. However, we are trying to get back on a stable schedule. So, if you are up to it, write up a technical piece for inclusion in the next issue. @(A)c: A Bit of Their Own Medicine From: wanderer_rtc@usa.pipeline.com (R. T. Cunningham) Dear C=Hacking, I just read CHacking #13 and was very impressed with the amount of work put into it. While I was reading the HTML tutorial, I came to a not quite brilliant idea. While working on an HTML viewer, take time to see if you can work standard C/G viewing. I would love to do up a bunch of web pages using C/G with the familiar disclaimer up on top, previously posted by someone else and plagiarized by me, . This would please quite a few people (besides me of course). Who says we have to be able to see 256 colors! @(A)r: Oh, do we detect a bit of revenge here? I am sure Jim Brain can arrange C/G graphics in the HTML viewer he is working on, but we can see a problem: The eventual goal of the HTML viewer is to grow the application into a full fledge WWW Browser. If a site uses C/G graphics exclusively, the large number of Commodore enthusiasts that view WWW sites with non-CBM graphical browsers will not see the C/G graphics. In addition, some would-be Commodore enthusiasts who explore these C/G graphics enabled sites might leave thinking we are snobs and never return. We don't need that. We think a slightly altered suggestion is better. When designing the "" tag in he HTML viewer, allow it to understand the optional attribute "CBMSRC". That way, a Commodore site can safely display graphics to non-CBM browsers and still put the "Best Viewed with a C64" on the page. All the graphics on the page would then be specified by an image tag looking like: . The CBMSRC attribute could then be used on a CBM browser to display the alternate C/G graphic. A non=CBM browser would ignore the CBMSRC attribute, and a tag like: would be ignored by the browser as well, since it contains no SRC attribute. And, best of all, if you really wanted to keep the Netscape browsers out, simply put . @(A)c: UU what? From: Cameron Kaiser Dear C=Hacking, I noticed that the last C-Hacking had a number of uuencoded files concatenated to each other. This presents a problem in unix because a number of crufty uudecoders don't recognize them together (only the first one). I have made a PERL script that folks can use to fix this. I'll leave it in ftp.armory.com/pub/user/spectre/UNIX/multiuu.pl @(A)r: We appreciate the utility. If someone wants to take advantage of this helpful utility, simply FTP the file to your local UNIX account and execute: chmod u+x multiuu.pl Then you should be able to uudecode multiple part files with this program. @(A)c: Comfortable Reading From: rbthomas@freenet.edmonton.ab.ca I have d-loaded a few issues of C= Hacking and converted them to GEOS and looked at them with geoWrite but that is a clumsy process. Also, I understand some of the issues have program files in them and these need to be extracted for use. How does a person go about this? Thanks in advance for any help you can offer. I have a 1581 and an FD-2000 drive so the space isn't a problem with storing the file. I would like to read it in comfort also. TWS won't handle it. @(A)r: To help people who can't handle the large size of Commodore Hacking, each issue is now available as an archive of individual articles and already decoded executable files. Commodore Hacking Information (Reference: info) has information on how to obtain and dowload the archive files. ========================================================================= @(#)news: Newsfront @(A): Commodore Hacking CANCELED! As many know, one of the distribution mediums for Commodore Hacking is USENET, which is a services that operates primarily on the Internet. After dutifully "posting" Issue #13, Hacking Headquarters was informed that the posting had been "canceled". Since normally only the original poster can delete or "cancel" a posting, we were alarmed. The culprit turned out to be a automated program that had been installed on USENET since Issue #12 was published. The program, called a "cancel robot" or "cancelbot" for short, had been created by an individual and installed on one USENET node. This specific cancelbot watches for large postings to non-binary newsgroups (newsgroups that do not have "binary" or "binaries" in their names) that contain large UUencoded binary files. It then "forges" a cancel message by masquerading as the original poster. Since USENET contains very little security, this notion of "forging" postings can be done quite easily. Without detailing the technical side of USENET, suffice it to say that a posting from one site immediately begins its journey to all other sites on USENET, being replicated along the way. The cancelbot canceled the posting immediately after it showed up on its server. The cancel message then began its journey to each server, canceling the article at each site. Given the propogation delay of USENET, the posting was up long enough for some readers to acquire it, but not everyone. Therefore, a pointer to the location of the issue was posted later. Along with the pointer posting, Commodore Hacking asked the USENET newgroup comp.sys.cbm how it should ahndle the situation. We offered three suggestions and asked for comment. They were: 1. Request an exclusion for the publication from the cancelbot 2. Publish only a pointer to the location of the new issue. 3. Publish the issue stripped of UUencoded binary files. Suggestions 1 and 2 received an equal number of votes, with suggestion 3 receiving a couple of votes and 1 person voting to split the issue into multiple parts. Needless to say, the issue is still undecided. Therefore, for the current issue, we have requested an exclusion from the USENET cancelbot. However, since most readers can now access the publication via the World Wide Web, Electronic Mail, and FTP, we are considering publishing only an announcement in the future. The announcement will highlight the newest issue and detail where to obtain it. Some of the survey respondents mentioned that a few readers may only have access to USENET as a means of receiving the magazine. If you are one of those folks, PLEASE WRITE US! We are continuing to post the entire issue on USENET for your benefit and may not continue to do so if we don't hear from you. The postal mail address is located in this issue (Reference: legal). If Commodore Hacking does not receive any aformentioned letters or objections, we will consider posting only new issue announcements in the future. Doing so would relieve some burden on the USENET system, which was really not designed to handle a posting of C=Hacking's size. If you have any questions about the potential impact of this change, please mail us at Hacking Headquarters. @(A): The The Underground Went South! Shortly after the release of Commodore Hacking #13, Underground Magazine editor Scott Eggleston informed his subscribers that changes in his life had forced him to cut back on the time devoted to publishing, and that he was merging The Underground with the newly announced LOADSTAR LETTER commercial publication. As reported in the last issue, Scott will co- edit the new expanded LOADSTAR LETTER with Jeff Jones and unfilled Underground subscriptions will be filled with LOADSTAR LETTER subscriptions on a 1 for 1 basis. @(A): Get Yer QWKRR128 5.0! Read All About It! In Commodore Hacking #13, Gaelyne Gasson (formerly Gaelyne Moranec), described how to read Internet electronic mail offline by using an offline mail reader like QWKRR128. Hot on the heels of that article,Rod Gasson has announced the availability of a beta of version 5.0 of the QWKRR128 software. Available to all registered users of QWKRR128, the beta includes a number of enhancements and bug fixes, including: 1. Supports full 255byte character sets. 2. Reads messages of ANY length (including the ability to print, export, or small.dat them). 3. Separate VIP & TWIT lists. 4. UUdecodes messages of any length as long as the UUencode is in a single message. (It won't decode if the file is split over several messages). 5. Decodes MIME messages (Base64). Same restriction as UUdecodes. 6. Added keyboard tables so it can be configured to 'international standards'. 7. Updated the 'auto-netmail' routines to include Internet Email as well as fido netmail. 8. Improved the address book so it will handle both the fidonet format addresses and email style addresses. 9. Added the ability to ATTACH files to a message or reply. These attaches are limited in length to about 8megs (the max that the QWK format can handle). 10. Improved the routines to detect a valid Q.NDX file (the name of the new QWKRR index file). This means these no longer have to be manually scratched prior to reading a new mail packet. 11. Added code so that you no longer have to quit QWKRR in order to read a different mail packet. 12. Improved the macros so that whole words can be used as a 'trigger'. This can be used as a 'simple' spell corrector. (eg, a macro such as "Ismeal=Ismael" will ensure that you'll never transpose the "a" and "e" in Ismael again. 13. Added a 'scrap macro' that can be defined and used while in the editor itself, without the need to add it to your macro file). 14. Added code so that quote initials can be changed 'on the fly' (This is useful when quoting from Email messages where the default initials are often meaningless). 15. Added time/date stamping to the zipped REP packets. (Some BBS's didn't like having the same date/time stamp on all mail packets). 16. Improved access speed by about 3 times for Ramlink users. 17. Improved tagline handling. You can have up to 10,000 taglines in one category. Tagline files are now numbered from .000 to 999. 18. Several cosmetic changes and bug fixes. The new beta version is available from the 221b Baker Street BBS in the US and GEOZ BBS in Australia and at: ftp://ccnga.uwaterloo.ca/pub/cbm/INCOMING/telecomm/qwkrrv5b.lzh ftp://hal9000.net.au/pub/cbm/qwkrr/qwkrrv5b.lzh More complete information is available at: http://www.hal9000.net.au/~moranec/qwkrr10.html @(A): Centsible Software Address Update (And Some Bad News) The folks at Centsible Software have moved! Well, they are still at the same location, but they have "electronically moved", to sprynet.com. The new information appears below: Centsible Software PO Box 930 St. Joseph, MI 49085 616-428-9096 (Orders and Information 12-6pm EST) 616-429-7211 (Bulleting Board System and Facsimile) Cents@sprynet.com (Internet Contact) http://home.sprynet.com/sprynet/cents (WWW URL) On a sad note, Centsible contacted Hacking Headquarters later to note that they will soon be closing down Centsible Software. All outstanding orders will be completed, and the closure won't happen immediately, but soon Centsible will be all but a memory. @(A): Brace Yourself, There's More Software Support International (SSI), has recently decided that they will start focusing more on IBM compatible sales. In an initial announcement, SSI indicated that they would no longer carry Commodore products after January 1, 1997, but later announced that they would continue to sell products as long as existing stock holds up. However, they will no longer promote the CBM or Amiga product lines. The latest catalog from SSI will be the last to carry CBM and Amiga merchandise. @(A): And Now for Some Good News Arkanix Labs, a West Coast hardware and software developer, recently announced that they had acquired Threshold Productions International. Petar Strinic (note the 'a' in Petar) announced that the acquisition would expand their presence in the market. Arkanix Labs develops for the MS-DOS and C64/128 systems, and is working on SuperCPU products. To find out more about the company, visit their WWW Site at: www.arkanixlabs.com or contact Mr. Strinic at: petars@arkanixlabs.com @(A): The Underground To Live on in LOADSTAR LETTER Scott Eggleston, editor of The Underground, has recently sent notice to all Underground readers that recent changes in his life have prompted him to discontinue publishing of The Underground. Determined that Underground subscribers would not be left in the lurch, Scott has arranged for each subscriber to receive issues of the newly launched commercial LOADSTAR LETTER publication (See Newsfront in C=H #13). While the size of each issue will be smaller, the issues will arrive monthly, as opposed to The Underground's bimonthly schedule. Scott, not bowing out of publishing entirely, will be brought on as Associate Editor of LOADSTAR LETTER. Subscribers should expect to receive their first issue of the merged publication at the same time The Underground #15 would have arrived. As well, Scott will continue to offer back issues of The Underground for US$2.50 per issue. The Underware disk will no longer be available from Eggleston, although reader Tom Adams (tom.adams@neteast.com) has agreed to copy the disks as long as he is able to do so. If you need to contact Scott Eggleston, you may do so at: egglest1@cougarnet.byu.edu @(A): Video Interface Computer (VIC) Software Available Ghislain deBlois (dh374@freenet.carleton.ca) is currently releasing a number of games and utilities for the avid Commodore VIC-20 user community. Intending to release them in "cassette/disk of the month" fashion, deBlois' first installment contains: o Meteor Zone o Mini Assembler o Vicfall! o Ringside Future installments promise titles like: Realms of Quest, Ice Hockey, Bosing, and Screen Magic (a multi-color hi-res drawing program). All programs are written for the unexpanded VIC-20 computer system (VC-20 in Europe) to better serve VIC enthusiasts. For more information, contact deBlois at his electronic mail address. @(A): Get on the Super CPU list! Brett Tabke, of PHD Software, has created a mailing list for owners of the CMD SuperCPU accelerator cartridge. To subscribe to the list, send a message to: listserve@giga.or.at with a message body of: subscribe super-cpu firstname lastname @(A): Mailing Lists, Take Two! For those who live in on the OTHER side of that little pond from the US, or if you just want to keep up on the developments there, there is a new electronic mailing list for European 64 enthusiasts. Simply send email to: listserv@lentil.demon.co.uk with a subject of: MAILSERV and a body of: subscribe 64EUROPE END The list address is: 64europe@lentil.demon.co.uk @(A): It's Better than Novaterm 9.6! Nick Rossi has recently announced that patch "A" for the latest version of Novaterm (9.6) is now available. Citing the help of early purchasers of the product, Nick noted a list of bug fixes that have been incorporated in the new release, including: * Estimated file length omitted from Zmodem upload, to avoid confusing BBS's. * The "funny ASCII" problem when capturing to the buffer in ANSI or VT102 mode has been fixed. * Due to the above, you should remove the ".opt ansi" line from all your scripts and recompile them. * A bug in the script function that checks for incoming strings was fixed. * The "Save buffer when full" option now works properly with hardware flow control. * A bug in the recovery function of the BBGRam driver was fixed. * A bug in one ANSI screen clearing function was fixed. * Several errors in the font81.ANSI character set were fixed: ASCII 160 was changed to a, and the fractions &188;, &189;, and &190; were put in their proper order. * Typing a shift-space now sends a space, rather than the a character. * Color was added to the VT102 terminal emulation. * A real-time clock driver was added to read from the CMD SmartMouse and SmartTrak. * Functions in the text editor were fixed: loading/saving in the buffer and changing the device number. If you have already purchased Novaterm 9.6, you can receive a free upgrade by making a backup of your master disk and sending the master disk back to: Nick Rossi 10002 Aurora Ave. N. #3353 Seattle, WA 98133 U.S.A. Copies of the latest release are available in either 1541 or 1581 disk formats for USD$29.95 plus USD$1.50 for shipping and handling. The software is accompanied by a 90 page user manual. For more information on the upgrade or Novaterm in general, visit the Novaterm 9.6 WWW Site: http://www.eskimo.com/~voyager/novaterm.html or contact Mr. Rossi via email at: voyager@eskimo.com. @(A): Who's Got the Rights to the Commodore 8-bit line? That is a very good question. Ever since Commodore was sold to ESCOM GmbH, Commodore 8-bit users have wondered who owns the intellectual rights to the Commodore 8-bit line of computers. Now that ESCOM has declared bankruptcy and initiated the sale of the Amiga line to US based Visual Information Service Corporation (VISCorp), CBM enthusiasts are even more curious. The sale, evidently drawn up before the bankruptcy declaration, would place Amiga technology into the hands of VISCorp, which was started by several ex-Commodore engineers. However, even if or when the deal is finalized, who owns the rights to the CBM 8-bit line may still be a mystery. @(A): New Address for Meeting 64/128 Users Through the Mail Tom Adams, president of the mail correspondence club called Meeting 64/128 Users Through the Mail, asks that all electronic correspondence for either him or the club be addressed to: tom.adams@neteast.com @(A): Complete you Transactor Collection! Karl Hildon, one of the producers of the now-defunct _Transactor_ publication, has announced that he is now able to provide electronic copies of any issue of the technical magazine for USD$5.00. Issues can be scanned in the format of your choice, and will be electronically mailed to the purchaser. To order, mail Karl Hildon your Visa Card account number (visa only) and expiration date and issue number request to karl@inforamp.net. If you need to consult an index first, there is one located at: http://vanbc.wimsey.com/~danf/cbm/transactor.idx Mr. Hildon also mentioned that if demand warrants, he will also make available the _Transactor_ companion disks. Also, Mr. Hildon has announced that he can also make available copies of _The Inner Space Anthology_ for USD$20.00 or CAN$20.00. Follow the above directions to obtain copies of this out of print resource. @(A): "Ultimate" Demonstration Contest Announced Commodore Zone and Tim Wright have announced the Commodore 64 Golden Fleece Award 1997 contest. An award of $100.00 will be presented to the author of a demo program that represents the best in demo construction and captures the spirit that have made demos a staple of Commodore history. The deadline for entry is February 1, 1997, and entries should be sent to "Binary Zone P.D. Entries must fit on a single side of a 1541 disk, and will be judged as complete works. Authors can enter as many works as they wish. Entries will be judged on programming ability, graphics expertise, and musical content as well as overall presentation. All entries must be previously unreleased material. Entries should be accompanied by contact details, and the winner will be featured in Binary Zone P.D. For further information, or to enter the contest, contact: Jason 'Kenz' Mackenzie Binary Zone P.D. 34 Portland Road Droitwich Worcestershire England WR9 7QW @(A): Possible Products for SuperCPU 'Puter PROTOVISION, a game development company, is currently working on compression tools for the SuperCPU, as well as some utilities for the new unit that are designed to take full advantage of the 16 bit processing power of the 65C816. In addition, the company is investigating the possibility of developing a new graphical operating system for the unit that will run in 16 bit mode and take advantage of the 16 megabytes of addressing and the new opcodes available in the accelerator. The new system will be able to multitask and offer several graphics modes and capabilities. @(A): New OS Version Available For those who enjoyed reading about Andre Fachat's OS/A65 operating system in the last issue of Commodore Hacking (Issue 13, Section: os), Andre has updated his multitasking OS to version 1.3.10b. New in this version is: * MORE AVAILABLE TASKS and STACK SPACE for systems w/o MMU (C64): New compile option STACKCOPY for systems without MMU. Allows more tasks and gives each task more stack space. * new 9600 baud RS232 driver for C64! (see comp.sys.cbm FAQ) * new 6551 ACIA driver for the C64 (connected to IRQ line) * new 16550A UART driver for all supported machines! * New GETB and PUTB kernel calls, to get and put a whole data block from and to a stream. It is used by the FSIEC filesystem currently. * Better NMI handling: New CTRLNMI kernel call, and modified SETNMI call. SETNMI now sets the NMI routine address, and enables NMI routine chaining. There also must be a link to a control routine that can enable and disable the NMI line. Therefore FSIEC and FSIBM now call CTRLNMI to switch the NMI on and off around their time critical regions. * Introduced return code to device IRQ routines. This allows to return from the IRQ routines prematurely, if one IRQ routine signals that it has removed an IRQ source (if SYSINPORT is not available). It is available on the World Wide Web at: http://www.tu-chemnitz.de/~fachat/csa/ @(A): Current Releases for the Commodore from CWI Computer Workshops, Inc., is currently distributing NewView, an image effects generato, and HyperLink, a hypermedia authoring system. More information on these titles and their upcoming 3D Game, "Nether", are available at: http://www.armory.com/~spectre/ @(A): Commodore Hacking Selected for Inclusion in PC Webopaedia Sandy Bay Software, Incorporated has selected Commodore Hacking's World Root WWW Site to be included in a virtual encyclopedia of WWW sites. Visit the PC Webopaedia at: Dear Webmaster: http://www.sandybay.com/pc-web @(A): LOADSTAR's Pass Around Issue is Available J and F Publishing has announced that LOADSTAR Issue #148 has been selected to be a "pass-around" issue. This issue is available for free and is intended to allow non-subscribers a chance to see what is in the disk-based monthly magazine. Issue #148 is available at: http://www.loadstar.com/pass.html Wraptorized and ARCed versions are available for 1541 and 1581, while Compression Kit, .d64 images, and PKZip version are available in 1541 format. Screen shots of the issue are available at: http://www.loadstar.com/148contents.html The issue is packed, filling over 700 kB, and includes articles like: * How to Copy Files * Super Snapshot Bypass Switch Installation * 'Lectronic Formulator * Directomeister II Directory Editor * Menu Toolbox III, as published in C=Hacking #14 (Reference: toolbox) * GEOS Fonts (Ronda and Triana) Download the issue today, and share it with your friends and user groups. @(A): Hey! It's the Commodore Man! If you're in the market for some used equipment or require some service on your CBM system, contact: Jon Searle, The Commodore Man Service and Software 1307 Golfview Drive Grain Valley, MO 64029 Jon offers over 1000 titles, documentation, books, magazines, and hardware. A catalog can be requested for a nominal fee. Until December 31, 1996, Jon is offering a "Buy 3, Get 1 Free" offer on software titles. Write for details and restrictions. @(A): GEOS III, Revenge of the 8-bit GUI! Maurice Randall, creator of such GEOS offerings as GeoFAX and many utilities for CMD, has announced that he is formally working on GEOS 3.0. He has successfully reverse engineered GEOS 2.0 and is now working to incorporate changes into the OS that will provide more seamless support for peripherals announced since the release of GEOS 2.0. Among the changes is a number of bug fixes to the original GEOS OS code and some enhancements to allow shortening of the OS code or faster execution. A time or formal name for the project has not been determined, but the new version will require some type of RAM expansion. At a recent Lansing Area Commodore Club meeting, Maurice demonstrated some of the changes that may show up in the final GEOS 3.0 system. They include: o Removal of 15 file limit in file lists. o Ability to use CMD devices in Native Mode. o Ability to read CMD FD DD disks in a 1581 drive. o Ability to create CMD Native partitions on a RAMDisk. o Ability to read/write MS-DOS floppies as native files on 1571,81, or FD. o Ability to read single bytes from drives. o Ability to utilize 4 separate disk drives simultaneously These changes are incorporated in new disk driver code that can be used by any existing GEOS application. The new drivers utilize a radically different Configure program with more options than the current setup application of the same name. Maurice stated that he will likely take a half-written desktop replacement he has written titled "Dashboard" and develop it into what will become the replacement for DeskTop in GEOS 2.0. Although the new system will require the use of RAM expansion, the system will not require a SuperCPU or other speed enhancement unit to operate. @(A): Explosive Commodore Surfing Power Brain Innovations, Inc., recently announced that they had revamped the popular WWW Links pages on Jim Brain's Commodore home Page. The new site, completely automated, offers many advantages over the older set of pages. The new site, called CaBooM!, can display links in either HTML TABLE or UNORDERED LIST format, include or exclude graphics, and include or exclude link descriptions. The site is organized into categories and sub-categories. Surfers can automatically add new sites to the system and specify which categories fit the site. Users can also update sites at a later date by specifying their user ID and password used to create the site. New and updated entries are identified with appropriate comments, and sites can be listed in multiple categories. Check out the new system at: http://www.msen.com/~brain/cbmlinks/index.html ========================================================================= @(#)trick: HEAVY MATH - Part 1: Introduction to Linear Programming (LP) by Alan Jones (alan.jones@qcs.org) This article describes the Linear Programming problem. LP software is being developed for the C64 to emphasize that the C64 is capable of solving HEAVY MATH problems. It describes some of the C64 program design issues and gives readers an opportunity it influence the development of the software. @(A): Introduction Linear Programming, LP, is the simplest type of constrained numerical optimization problem. It's simplest (standard) form is: max P = c'x s.t. Ax = b x >= 0 That is, we want to find the solution vector x which maximizes the function P, which is a linear combination of elements of x, while satisfying the linear equation Ax = b, and with each element of x >= 0. A is a matrix with typically more columns than rows. The maximization problem itself is easy, except for the inequalities and determining which elements of x are fixed at a bound and which are free. Assume x is a vector of 20 variables and we have 10 equality constraints making A a 10 by 20 matrix. Solving the problem involves choosing 10 of the variables to be bound (at zero), eliminating those 10 columns from A and solving the reduced linear system, say B*xb = b, for the other 10 elements of x, xb. Then sort through the solutions to find the feasible solutions that satisfy all of the constraints, x >= 0, and chose from them the solution that will maximize the function P. Taking 20 columns of A 10 at a time we will have 184,756 solutions to solve and evaluate! @(A): LP Development LP is an important problem that requires a computer and clever algorithms to solve non-trivial problems. The development of LP algorithms parallels the early development of computers. George Dantzig published his first paper on his simplex method in 1947. LP problems have long been studied in mathematics, economics, and business fields, but the simplex method and the computer were the big breakthroughs. Just imagine the problem of allocating and distributing limited resources to millions of soldiers in WW II. There are many types of problems that can be solved as LP problems, and some have specialized algorithms for their efficient solution. @(A): LP Examples The inequality constraint occurs naturally. Many processes are irreversible. For example you can burn fuel in rocket at a positive fuel flow rate to produce thrust, but you can't unburn the exhaust to refill the tanks. A table leg can push on the floor but not pull (unless bolted). A rope, cable, or chain can pull but not push. You can't buy or sell negative quantities of a new item. You can't start assembling a machine before the parts arrive. LP problems can also be written in more general forms. Perhaps the most general is: max P = c'x s.t. bl <= Ax <= bu xl <= x <= xu Where bl an xl are vectors of lower bounds and bu and xu are vectors of upper bounds. The LP forms can be manipulated with simple algebraic operations and by adding constraints and "slack" variables. Most numerical optimization problems are set up to minimize a cost function. Historically, LP problems are set up as maximization problems. If your function P is a total cost to be minimized, simply multiply the vector c by -1 and maximize instead. Multiplying the i'th constraint equation by -1 will change the sign of all the elements of the i'th row of A, bl, bu, and change the direction of the inequalities, but not change x(i). The i'th constraint above is actually two equations and can be written (neglecting the subscripts): Ax <= bu Ax >= bl To convert them to equality constraints: Ax + y1 = bu Ax + -y2 = bl y1 and y2 are additional variables both >= 0 added to take up the "slack" in the inequality equations. When the constraint is free (i.e. could be ignored) the slack variable is >0. When the constraint is active, the slack variable is constrained to zero. The slack variables are simply appended to the vector x and treated as normal variables. Lower bounds on x can be removed with a change of variable, x = y - xl, without adding more rows or variables. xl <= x <= xu, becomes 0 <= y <= xu - xl Upper bounds on x can be handled by adding slack variables. The expanded problem could look like: Ax = b x + xs = xu x >= 0, xs >= 0 This can double the length of the x vector and add an equal number of equality constraints. A fair amount of algebraic manipulation is possible to get a LP into the form required by the solution software. This can significantly increase the problem size. Good software will use the more general forms of the LP program and use a more sophisticated solution logic instead of increasing the problem size. Mixture problems are probably the easiest to describe for illustrating the importance of LP. Suppose you are producing cans of mixed nuts. You want to find the percentage of each nut to mix and package at the lowest cost, or maximum profit. You check the commodities prices of the various nuts available at different times and places. c(i) could be the price per pound of each nut, i, and x(i) would be the percent of that nut to be mixed. One constraint is that the percentages total 100. The Marketing Department may demand no more than 25% peanuts and no less than 5% of Cashews, pecans, and almonds. Each nut may be scored for crunchiness, and other aspects of taste to meet other constraints. Of course no x(i) can be less than zero. You can do the same thing with "real fruit juice" drinks. Mix the cheapest available fruit juices while balancing sweetness, acidity, color, taste, and other factors. Another type of problem is project scheduling. Suppose you are going to design and build a bridge, or spacecraft. You identify all of the tasks that must be accomplished, and then estimate their completion time and constraints. E.g. task 43 can't begin until tasks 16, 17, and 41 have been completed. You could then set up a LP problem to schedule each task so as to complete the project in the minimum time. Various other performance criteria can be embedded in a LP problem. @(A): Non Linear Programming (NLP) LP is also a special case of Non Linear Programming, NLP. The NLP problem is similar to the LP problem except that the objective function P and constraint equations can be nonlinear functions. NLP is a much more expensive problem to solve. An approach to solving a NLP is to linearize the problem at a point to get a LP subproblem. Solving the LP gives a search direction for the NLP problem. You then advance in the search direction until you have made sufficient improvement in the objective function or diverged too far from the constraints. You then correct back to the constraints and linearize again. The sequence is repeated until the solution is found. @(A): C64 Software? Computers were not created by secretaries and typesetters. Although computers can do a lot of things, they were created to do Heavy Math. The first electronic computer, the Attanasoff-Berry Computer, ABC, was built to solve systems of up to 29 linear equations, although it could be adapted to solve other problems as well. The second and third, ENIAC and EDVAC, were intended to solve ODEs (Ordinary Differential Equations, i.e. computing artillery range tables), as well as more general usage.(ENIAC's first operational use was solving a 25 by 25 set of linear equations from Los Alamos to see if an atomic bomb might be feasible. The ABC could have solved this problem, but it had a read/write reliability problem and Attanasoff was called up for other war related work instead of perfecting the ABC.) And I have already discussed the LP problem. Software for the C64 has been readily available and published in the C64 related literature for solving systems of linear equations and numerically integrating differential equations (4th order Runge-Kutta being typical). However nothing is available or published for solving LP problems on a C64. I do recall seeing a one inch ad in some Commodore magazines trying to sell software to solve small LP problems on a C64, maybe 15-20 equations, but I never read any reviews of it and I always suspected it to be poor software. I intend to plug this hole by writing a good LP program for the C64. This is Part 1 of at least a two part series on LP for the C64. Part 2 will include the presentation of the C64 LP program. I usually hate multi-part articles that could have been published as one large article. However, in this case Part 2, and indeed the C64 LP computer program, has not been written yet. Part 2 will be dependent on reader feedback! No feedback means no reader or user interest and I won't bother to submit Part 2. I have not written a LP program before, or even used one much on other systems. There is a very good chance that some readers will have experience with LP software and can offer practical suggestions for writing C64 LP software. I would also like to hear from any reader who may have some type of LP problem that they would like to be able to solve, perhaps something related to a hobby or home computing application. Also, someone may be able to point me to an ideal LP reference book or even provide suitable source code to examine. Choosing a LP solution method for the C64 is not an easy task. Appropriate reference books and papers are hard to come by. There is nothing in the CBM literature that I am aware of. Many books have been published on the LP subject. However, most are old books written for business students or for training clerks to solve small problems by hand, and they use outdated methods. These are easily found in local libraries and at small colleges. LP is still an active research area and many new journal articles are still being written, as well as new books. However, the focus in on solving VERY large LP problems using sparse matrix algebra techniques, and newer methods such as Karmarker or interior-point methods. There is even a LP FAQ available. Two of the best references that I have found so far are: "Computer Solution of Linear Programs", J. L. Nazareth (1987), and "Advanced Linear Programming", B. A. Murtagh (1981). The LP source codes that I have looked at were either too crude, suitable only for small problems, too poorly documented, or suited only for large problems on large computers. This gives you some idea of where I am at, should you want to provide helpful feedback. Our C64 (and 128) does arithmetic slowly, but reliably, and has limited memory. We would not want to solve a large LP problem with thousands of constraints and variables on a C64 even if we could. Still, we want to be able solve problems as large as practical using efficient methods. At the heart of the solution algorithm we must be able to solve an n by n system of equations, where n is the number of constraint equations. For, say n = 70, we will need 24,500 bytes to store the full matrix, leaving the rest for the OS/language/LP program. The simplex type solutions typically require computation time = K * n~3, so we will not likely want to solve any LP problems on the C64 with more than 70 constraints. The desire to solve huge LP problems also motivated the development of sparse matrix algebra techniques. Matrices associated with LP tend be very sparse. The idea is to be able to store only the non-zero elements, to store them in data structures that can be used effectively by linear equation solvers, and to use larger but often slower external memory efficiently. These codes have a higher overhead in terms of code size and computation/FP multiply. However, these codes can compute the same results with substantially fewer multiplies than simpler code for dense or full matrices. They often perform faster overall, at least on scalar computers. Our 6502 can zip through complicated data structures and ML code fairly fast compared to the cost of a FP multiply. Using sparse matrix techniques is possible with the C64, but not required. I think the complications of using sparse matrix methods is not warranted in this case. Users wanting to solve large sparse problems are free to disagree. @(A): Types of LP Problems There are several LP solution methods: (primal) simplex, revised simplex, dual simplex, primal-dual simplex, Karmarker, and others. There are also many variations among these. I have chosen the revised simplex method for the C64 program. Some other choices might be better for some types of LP problems, and I may also write a primal-dual simplex program. In the revised simplex method, the constraint matrix A can be stored outside of main memory (on disk or REU) and brought in a column at a time. The matrix A can be stored in a sparse matrix form. This is probably a good idea for our slow disk storage, but unnecessary for our REU storage. A square matrix B will be based on a set of n columns of A. At each iteration a new column of A is chosen to enter B and an old column is re moved. Each column represents an element of x and the objective is to get the unbound variables selected into B with the remaining variables set to their limits. At each iteration we have to solve many linear systems using B with different right hand side vectors and then update B to account for the column addition and removal. There are several ways to work with the matrix B. B can be explicitly inverted. The inverse can then be explicitly updated using the Sherman- Morrison-Woodburry formula, or updated in product form by storing a sparse matrix factor that accounts for the update. The later is preferred for sparse implementations, but the storage used grows with each iteration and eventually a new explicit inverse of B will have to be computed. Both methods are numerically unstable and can have excessive growth of roundoff errors, necessitating error checks and occasional reinversion. B can also be efficiently used in an LU factored form. B = LU where L is lower triangular and U is upper triangular. The updating is difficult, especially when exploiting sparcity and external storage. Bartels and Golub (1969) developed a numerically stable way of updating the L and U factors that enabled L to be stored externally, with U stored in main memory. Forrest and Tomlin (1972) developed a method that allows both L and U to use external storage. This is the method used in most commercial codes for solving large LP problems. However, it is not numerically stable and needs to be monitored and refactored. Sanders (1976) developed a variation of the Bartels-Golub method that is stable and allows most of U to be stored externally. Fletcher and Matthews (1984) developed a stable method for updating the LU factors explicitly in main memory. In the Fletcher-Matthews update we have: PBQ = LU. B is the unfactored matrix, P is a row permutation matrix, Q is a column permutation matrix, L is a unit lower triangular matrix, and U is an upper triangular matrix. L and U are stored explicitly (not in a factored form) in a square matrix B. L and U are first formed using a normal LU factorization (Gaussian elimination). P is a row permutation matrix that represents the partial pivoting normally used to stabilize Gaussian elimination. Q is an optional column permutation that represents the full pivoting that could be done with Gaussian elimination to get better numerical stability. P and Q are completely defined by integer arrays. In the update, one column of B is removed, the rest of the vectors are shifted left to fill the gap, and the entering vector placed in the right most column of B. L, U, and P are then updated to a stable factorization of the new B matrix. Pivoting is still required for stability, but only two adjacent rows can be exchanged. This is a weaker form of stability than Gaussian elimination with partial pivoting. It may be advisable to use some more extreme measures to assure greater accuracy, such as preliminary scaling of the problem (equilibration), full pivoting in the initial factorization, or doing a final refactorization. Q is not changed during the update (no column pivoting for stability), but we will have to keep track of where each column of A is located in B (or the LU factorization of B). The update is also cheaper when the column of B removed is farther to the right. I have chosen to use the Fletcher-Matthews update. This choice is ideal for dense LP problems, but less so for sparse problems. It limits the number of constraints that we can handle. It also has consequences for other program design choices that must be made for the C64 LP program. Using the simple standard form keeps the program logic simple, but converting problems with inequality constraints and upper and lower bounds to standard form will make the problem size bigger. This will be more expensive to solve when not taking advantage of sparcity, and make our size limit more significant. I am leaning toward solving LP problems in the form: Max P = c'x s.t. Ax = b xl <= x <= xu There are many more program design choices to make. There are different strategies for selecting the entering and leaving variables (columns). There are different ways to pick a starting B matrix. There are different ways to perform "Phase 1" of the revised simplex algorithm. Many of the internal tests of floating point results involve tolerances. These tolerances do affect the performance of the program. However, I have only seen arbitrary suggested tolerances. These tolerances should be determined by the floating point precision used, the problems size, matrix condition number, and perhaps some problem specific parameters. I have not seen any numerical analyses indicating how to set the tolerances. I have completed the subroutines to perform the Fletcher-Matthews update, matrix factorization, and solving linear systems. Your interest and feedback can influence other major parts of the program, or even convince me to use a different updating method. Or perhaps everyone would rather not see the sequel? You can reach me via e-mail at: alan.jones@qcs.org Since I am writing this software it will be developed in the COMAL 2.0 language, which is fast and very readable (and thus easily translated to other languages). A typical commercial LP code represents about 10 man years of development. The C64 software will represent perhaps 10 days, plus past research, or 10 weeks of part time effort, and be submitted for the next issue of C=Hacking. It won't be the best software, but it will be good. Over a period of perhaps a year, we can incorporate and publish changes (hopefully not actual bugs). Then it can be translated be to ACE assembly or some other language to make it available to more C64/128 users. @(A): Conclusion The C64 LP software is being developed simply to fill an empty slot in C64 software. It is also to emphasize that the C64 can indeed be used for HEAVY MATH, subject only to constraints of limited speed, memory, and software. There is little demand for solving LP problems on a C64, otherwise it would have been done many times already. This article will not interest many C64/128 users. It does not even come close to describing how to write a working LP program. It does describe what LP is and some of the issues involved in designing a LP program for the C64. I do thank those that read this far. Don't forget to write. ========================================================================= @(#)mags: Hacking the Mags Not everything good and/or technical comes from Commodore Hacking, which is as it should be. (We still think we have the most, though...) Thus, let's spotlight some good and/or technical reading from the other Commodore publications. If you know of a magazine that you would like to see summarized here, let C=Hacking know about it. These summaries are only limited by Commodore Hacking's inability to purchase subscriptions to all the Commodore publications available. We are very grateful to those publications that send complimentary copies of their publications for review. @(A): Commodore World (http://www.the-spa.com/cmd/cwhome.html) Although a bit late, Issue 15 made its way to our mailbox and opened with an apology from VP Charles Christianson detailing why the current issue took so long to reach subscribers. As we suspected, it was due to SuperCPU shipments and general bug-swatting. However, another factor that wasn't as obvious was some personnel changes in the publication. Gaelyne Gasson goes over the various graphics formats and how to convert them to viewable formats on the Commodore. The GEOS programmers will appreciate Maurice Randall's article on VLIR files, and Doug Cotton presents Part 2 of his discussion on file transfer utilities. The demo scene gets a little press with Sherry Freedline's piece on demos, including a section on _Driven_, reviewed below. Commodore Hacking even got a mention or two in Max Cottrell's report on the Lansing Area Commodore Club Expo '96. @(A): DisC=overy (http://www.eskimo.com/~drray/discovery.html) Arriving on the Internet October 1st, Issue 2 of this new publication maintains the level of content started in Issue 1. We suppose it's too early to tell, but it looks like one will show up every 4 months. The issue starts with three detailed pieces on VIC video techniques, including a discussion of the Super Hires FLI technique by Roland Toegal and 'Count Zero', a starter article on using raster interrupts by Mike Gordillo and 'Dokken', and how to use simple text scroll routines in programs by Mike Gordillo. Steve Judd details the basics of using the SID chip, and Andreas Varga steals the issue with an interview with SID creator Bob Yannes. The article is a must read. The highlights of the hardware section is a Atari 2600 cartridge reader for the VIC-20 by Ravid Noam and how to upgrade a Commodore 16 to 64 kB by Martin Gierich. @(A): Driven (http://soho.ios.com/~coolhnd/) In addition to the funky banner on Driven #15, the issue mentions the resurgence of the Demo Scene and congratulates all the recent Driven 4kB Competition entrants. If you are interested in demos and what effects are possible, be sure to check out the recent entries. #15 details the CMD Swiftlink in an article by Perry Eidelbus. Users undecided on purchasing a SL, or programmers unsure of whether to develop for the unit should read this piece. In a look back, 'The Hobbitt' runs through the history of the NTSC demo scene. Also, if you didn't get a chance to take a look at DisC=overy yet, there's an interview with editor Mike Gordillo in this issue. In between #15 and #16, Driven published the "Driven 4K Compo Edition", containing reviews and comments on the entries submitted for the recent Driven competition. Driven #16 contains a look into the world of Computer Workshops, Inc. (CWI) by Cameron Kaiser, as well as a detailed description of Craig Bruce's ACE OS, available on the Internet. As well, there are the usual notices of new demo releases and groups. The editors remark that they feel #16 is the best Driven yet. @(A): LOADSTAR (http://www.loadstar.com) Sometimes, we read LOADSTAR purely for the entertainment factor. And I don't mean the games on the disk. In Issue 145, Jeff Jones outlines his top ten email pet peeves. #145 delves into a rare topic in C64 circles: Musical Instrument Digital Interface (MIDI). Fender goes over the protocol and how it can be used with a 64/128. On the heels of that article is a piece by John Serafino that creates MIDI tracks for your own enjoyment. Bo Zimmerman presents a "Presenter" for LOADSTAR that utilizes GEOS. In addition, Bo gives GEOS users a handy utility that archives files and can even create .d64 images. To supplement Maurice Randall's _Commodore World_ article on VLIR files, Roger Detaille details the revisions in the directory that GEOS disks dictate. As a bonus, Issue #145 contains Driven 12, reviewed in C=Hacking Issue 13 (Reference: mags) as well as DisC=overy #1, also reviewed last time. Issue 146 starts off on an apologetic note, as Jeff repents for redistributing DisC=overy #1 not in its entirety. It brings up an important point that compilations like DisC=overy and C=Hacking can only be freely redistributed in their entirety. Diving into the issue, developers looking to design their own fonts might find use in Anthony Rose's Font Studio, Bob Markland's Font Viewer II, or Bob's Font Studio Printer. Jeff presents his entry in the Directory Editor arena: DirectoMeister I. Demo Scene folks will enjoy "Omni's First Demo" on Issue 147. Continuing with the video theme, Andrew Martin present Hires Sketch II, an art creation application. Of interest to GEOS DTP (Desktop Publishing) folks is a set of two GEOPaint documents containing some clip-art. As mentioned in Newsfront (Reference: news), Issue 148 has been released to the Commodore community as a "pass-around" issue. Distribution is encouraged. Although not technical in nature, everyone should read the piece describing this issue. It gives some insight into the workings of LOADSTAR and its ex-parent company, SOFTDISK. Fender Tucker shows how to add a bypass switch to a Super Snapshot cartridge, while Jeff revamps his Directomeister I into version II. As well, Menu Toolbox III, included in this issue (Reference: toolbox) is available on LS148. As well, Commodore Hacking #13 is included on the 3.5" disk version. @(A): The Underground Issue #14 is the last issue for this publication. It has merged with LOADSTAR LETTER. See Newsfront (Reference: news) for more information. We were hoping to get the last issue in to review it, but C=Hacking's recent relocation sent the issue off into never-never land. Anyway, we wish Scott Eggleston and his family the best. He will continue to edit LOADSTAR LETTER. Other magazines not covered in this rundown include: * _64'er_ * _Atta Bitar_ (_8 bitter_) * _COIN!_ o _Commodore 64/128 Power User Newsletter (CPU) o _COMMODORE CEE_ o _Commodore Gazette_ * _Commodore Network_ * _Commodore Zone_ o _LOADSTAR 128_ o _LOADSTAR LETTER_ (We received an electronic copy, but couldn't print it) * _Gatekeeper_ o _Vision_ Notes on Legend: * = We have never received an issue of this publication. o = We have not received a new issue of this publication to review. + = We will begin reviewing this magazine in the next issue. In addition, others exist that C=Hacking is simply not aware of. As soon as we can snag a copy of any of these, or get the foreign language ones in English :-), we will give you the scoop on them. ============================================================================ @(#)net: The Commodore Telnet BBS by Bo Zimmerman (ez13942@swt.edu) @(A): Overview The following are instructions for setting up a Commodore computer as a telnet-able BBS. It relies on a modem connection with a PC running LINUX with a telnet daemon. The Commodore is connected to the PC via a null modem cable. The LINUX box has a modified version of minicom, which comes with the slackware distribution (and others I would imagine), and a shell script, all described in greater detail below. The essential goal is this: when a user telnets to the LINUX machine and logs in as the BBS user, the PC will run the modified minicom, which is set up to communicate with the COM port connected to the Commodore. When minicom starts up, it will signal the Commodore that a connection has been made by setting the modem port's DTR signal. The Commodore BBS program goes online because the DTR line is attached to the DCD line in the cable. So long as the user is still in minicom, the connection remains, and wa-la! A Commodore on the net! Part I : Required Components (SubRef: 1) Part II : RS232 Adapter Instructions (SubRef: 2) Part III: Setting up the LINUX box (SubRef: 3) Part IV : Setting up the Commodore BBS program (SubRef: 4) Part V : What's missing (SubRef: 5) Part VI : Credits (SubRef: 6) @(A)1: Part I: Required Components 1) Commodore 64/128/VIC-20 2) Sufficient Commodore drives for your BBS software. 3) Commodore BBS software with DCD initiation capabilities (see part IV) 4) Standard RS232 null modem cable adaptor for the Commodore 5) PC 386 or better running Linux 6) Network capabilities for the Linux machine (ethernet card, PPP connection, or other connection) @(A)2: Part II: RS232 Adaptor Instructions (This is cut and pasted from some instructions I downloaded off of ftp.funet.fi and then modified for a standard 9 pin female COM port on a PC). USER PORT STD. DB9 COM NULL DB9 COM CABLE CABLE | +------\ | | | 2 | \ 3 | | M -|------------------| U1-A O-------|- 2 TX ----------|- 3 RX | | / | | | +------/ | | | \ | | | | \ | | | 3| \ 4 4+------\ | | D -|---|U3-B O----+---| \ 6 | | | | / | 5| U1-B O-------|- 7 RTS ----------|- 8 CTS | | / +---| / | | | / +------/ | | | | | | \ | | | | \ | | | 5| \ 6 9+------\ | | E -|---|U3-C O----+---| \ 8 | | | | / | 10| U1-C O-------|- 4 DTR ------+---|- 6 DSR | | / +---| / | | | | / +------/ | | | | | | | | | | | | / | | | B -|---+ / | | | | | | 3 / | 1 | | | C -|-----------------O U2-A -----------|- 2 RX ------|---|- 3 TX | \ | | | | | \ | | | | | \ | | | | | | | | | | | | | | | | / / | | | | / | / | | | | | 10 / |11 6 / | 4 | | | L -|----O U3-E ------O U2-B -----------|- 6 DSR ---+ +---|- 1 DCD | \ | \ | | | | | \ | \ | | | | | \ \ | | | | | | | | | | | | / / | | | | / | / | | | | | 12 / |13 8 / | 10 | | | K -|----O U3-F ------O U2-C -----------|- 8 CTS ---|------|- 7 RTS | \ | \ | | | | | \ | \ | | | | | \ \ | | | | | | | | | | | | / / | | | | / | / | | | | | 8 / | 9 11 / | 13 | | | H -|----O U3-D ------O U2-D -----------|- 1 DCD ---+------|- 4 DTR | \ | \ | | | | \ | \ | | | | \ \ | | | | | | | | N -|-----------------------------------|- 5 SIG GND ----------|- 5 | | | | +5V | | 2 -|----+------------+ +------|- PROTECTIVE GND --------|- | | | | | | | | | | | | | --+-- 0.1uF | ------- | | | --+-- 10V | --- | | | | | - | ********************************* A -|----+ | | * * | | | | * U-1 1488 RS-232 XMTR * | ------- | 14 +----+ 7 | * * | --- +----| U2 |--+ | * U-2 1489 RS-232 RCVR * | - | +----+ \ | * * | | \ | * U-3 7404 HEX INVERTER * | | 14 +----+ 7\ | * * | +----| U3 |--+ | * DIODES SIGNAL DIODES * | |\ | +----+ | | * WILL WORK HERE * | | \| | | * * 10-|----| |---+--------+ | | * NOTE: THE RS-232 VOLTAGE * | | /| + | | ------- | * BE APPX +/- 10 VOLTS * | |/ | --+-- | --- | * WHICH IS OK TO USE * | 100uF --+-- 14 | - | * PER RS-232 STANDARD * | 15V | +--|--+ | * * | | | | 7 | * * | ------- | U1 +----+ | ********************************* | --- | | | | | - +--|--+ | | | 1 | ------- | | | --- | | 120uF | - | | 15V | /| | | ********************************* | +|| |/ | | | * * 11-|--||----+---| |----+----+ | * Commodore User Port to RS-232 * | || | |\ | | | * Adaptor designed by Stephen * | | | \| | | * Coan, Version 2, 03-NOV-83. * | | | | * * | -------- 100uF ---+--- | * This general design has also * | \ / 15V ---+--- | * been used in other devices * | \/ + | | * where a negative voltage was * | -------- | | * not available for the RS-232 * | | | | * * | | | | * The user port is a 44 pin * | +-------+----------+ | * edge connector and the PC COM * | | | * port is a female DB 9 (as on * | | | * on a joystick) * | ------- | * * --- | * * - | * * | * * | ********************************* | | You'll want to follow the instructions for the NULL modem cable for the sake of this project, so use the pin settings on the right hand side. @(A)3: Part III: Setting up the LINUX box You should know now that if you don't have root access to the LINUX machine, you should give up now. Secondly, you need to have the machine already configured with respect to its network hardware and the telnet daemon. The popular slackware distribution sets all this up during its installation process. The first step will be to create the above shell "new_minicom" and its accompanying configuration "cua0". 1. Log on as root, and enter the /usr/bin directory. 2. Run minicom by entering its name followed by the name of the port you'll be using. For instance, enter: "minicom -l -o cua0" for com port 1. "minicom -l -o cua1" for com port 2. 3. Enter CTRL-A followed by 'z' to view a menu of options. 4. Enter CTRL-A,P for communication parameters. You'll want the parameters to be: 2400 baud, 8 bits, no parity, 1 stop bit. Exit this menu when done. 5. Enter CTRL-A,T for terminal parameters. ANSI, Backspace, and enabled are fine settings. 6. Enter CTRL-A,O for configuration parameters. Select the third option- communication port setup. Make sure the serial device reads "/dev/cua0" for com port 1 or "/dev/cua1" for com port 2. Baud/parity/bits should read as you set them above. Hardware and software flow control should BOTH be turned OFF! 7. Exit back to the parameters menu and select "modem and dialing." The reset and initialization strings should be blank. Auto baud detect, hang-up drops DTR, and modem has DCD line should all read YES. 8. Exit back to the parameters menu again and hit the option "save configuration as cua0" (or cua1 if you are using com 2). 9. Exit minicom altogether by entering CTRL-A,X. 10.We will make this our TEMPORARY new_minicom by entering from the shell: cp minicom new_minicom If you want to test the RS232 cable, now would be a good time. Run minicom with the following options: new_minicom -l -o cua0 (or cua1 for com port 2) The next step is to create the BBS "user." 1. Log on as root and run the program "adduser." Call your account "bbs" and give it the name "bbs." After the user is created, you should have a directory called "/home/bbs." 2. Now load the file "/etc/passwd" into emacs and find the line containing the information about your BBS. The characters between the first and second colons in the line are the encrypted password. Delete these characters. Next change the default shell (the part following the last colon) to point to the file /usr/bin/new_minicom -l -o cua0. 3. When complete, excepting the ID number (504), your line should look identical to this one: bbs::504:100:bbs:/home/bbs:/usr/bin/new_minicom -l -o cua0 If you are using com 2, change the shell command to read "cua1" instead of cua0. The next step is a little tricky. You'll need to make some changes to minicom to make it much more secure against abuse by users. Without changes, the user can enter all the commands you did above! It will be necessary to have extensive knowledge of C and knowledge of compiling in LINUX to perform these changes. ;) Now that you're frightened, you'll be glad to know that the necessary files are available at: 147.26.162.107 in the "lib" subdirectory. The only files you'll really need are "new_minicom", which must be copied to your /usr/bin directory, and the file "wb.rc" (discussed below), which must be copied to /home/bbs. Also available is the file "newminicom.zip" which contains all the modified source code. The following changes, to the best of my memory, were made: 1. All CTRL-A commands have been disabled, with the exception of CTRL- A,X. 2. Minicom will automatically exit on the reception of the sequence CTRL- A,CTRL-B,CTRL-C,CTRL-D from the modem. 3. Spawning out has been disabled. 4. The status windows have been removed. 5. ANSI has been made permanent. 6. A "busy" message for already connected processes has been added. 7. A "cleaning up" message for the com port has been added in the event of an abnormal exit. After new_minicom is set up in the /usr/bin directory, you may think you're done. Well, you almost are! You may need to make sure there are no protections on the com port, on minicom, or on other necessary files. Do this with the "chmod" command. You'll want to turn on read and write for the com port as follows: chmod +r /dev/cau0 (or cua1) chmod +w /dev/cau0 (or cua1) Read and execute abilities can be added to minicom similarly: chmod +x /usr/bin/new_minicom Now you're done, right? No, but the last step requires a bit of explanation. Our telnet session is maintained because we have an actual user logged on and running a program. Should this user disconnect themselves from their telnet session without logging off, we are actually left with an open session of new_minicom still running in LINUX. Normally we wouldn't care, except that so long as new_minicom is running, the com port is protected from use, such that the system will be eternally busy! What we need to do then is to have a shell script, with root privileges, that will keep an eye on copies of new_minicom running without a telnet daemon connection. The following shell script will do that. >From the /home/bbs directory, create the file "wb.rc" (I call it the watch-boy) and enter the following lines: set temp=1 while (temp=1) do pid=`ps -auxg | grep 'new_minicom' | grep -v 'grep' | grep 'bbs' \ | grep '?'| awk '{print $2}'` tty=`ps -auxg | grep 'new_minicom' | grep -v 'grep' | grep 'bbs' \ | grep '?' | awk '{print $7}' | grep '?'` if [ 'expr $tty : "?"' ] then kill -9 $pid fi sleep 60 done [!NOTE!: The two lines with the backslash (\) are extensions of the prior lines. For instance, the characters "| awk '{print $2}'`" should immediately follow the end of the line that reads "...grep '?'". Do not include the backslashes!] What this actually does is to look for occurrences of "new_minicom" being run by a user called "bbs" in which there is no terminal connection. It then kills those processes and goes to sleep for awhile before checking again. This file can also be downloaded from 147.26.162.107 in the "lib" subdirectory. Last thing to do then is to activate the watchboy by adding the following line to the file /etc/rc.d/rc.local /home/bbs/wb.rc & You can start up the watch boy as root without rebooting the machine, but the above will make sure it is started up whenever the LINUX box is restarted. Now on to the Commodore side. @(A)4: Part IV: Setting up the Commodore BBS program Thankfully, doing this is MUCH easier than setting up the LINUX box. The requirements on the Commodore end are actually very few, since what we end up doing is have the LINUX machine act as our modem and phone connection. As far as the BBS program is concerned (with few exceptions), it is acting completely as normal. You'll first want to select the BBS program to work with. Make sure it is one that is written in BASIC so that you can modify it easily. The BBS should also support ASCII, and preferably ANSI as well. For the time being, ANSI is the only way we'll get any color at all out of LINUX. The BBS program should support 2400 baud through the modem port. If not, you'll need to lower the set baud rate in minicom above. Detecting a connection is accomplished by simply watching the Data Carrier Detect line on the modem port. That will be bit 4 in location 56577. When the following BASIC condition becomes true, the BBS should go online: (peek(56577)and16)=16 The BBS program should go online by swinging its Data Terminal Ready signal high. This can be done with the following: poke56577,6:poke56579,6 The BBS program should hang up whenever it detects the Data Carrier Detect line go low. That's done with something similar to the peek above: (peek(56577)and16)=0 Lastly, the program will hang-up by doing two things. The first thing is to tell minicom to terminate. This is done by the following: print#2,chr$(1);chr$(2);chr$(3);chr$(4); Where print#2 is above you should substitute the proper modem channel for the number 2. The second is to drop the Data Terminal ready signal by entering: poke56577,0:poke56579,32 If the BBS program does all these things, it will perform admirably. @(A)5: Part V: What's to Come There are two current problems with this configuration for a telnet Commodore BBS. One is that Commodore graphics do not work. For a long time this baffled me, and I looked all over the minicom source for the solution. It wasn't there. Now I'm thinking it has something to do with the telnet daemon itself, which is the next place to check. When it's solved, I'll let you know. The other problem concerns time lag. Normally, lag is unimportant, but some transfer protocols are now especially sensitive to lag time. For this reason, along with translation problems mentioned above and the sensitivity of minicom to its termination codes, make the operation of the stream transfer protocols on the telnet BBS impossible. Perhaps some modified uuencoding packet based protocol could be written and patched in to the BBS program. If any such solution presents itself, it will be pursued. @(A)6: Part VI: Credits Very few of these are my original ideas. Special thanks to Matt Beall of California (mathew@cinenet.net) for most of the modifications done to minicom. The project itself is the brain child of Henry Knoepfle of Arizona, who helped me through all the linux changes. Early in August, as soon as I get my own BBS program properly configured, I'll be putting it back up on the same machine that the ftp files are on. Telnet to it and log on as user "bbs" with no password. Good luck! ========================================================================= @(#)usenet: UseNuggets COMP.SYS.CBM: The breeding ground of programmers and users alike. Let's see what topics are showing up this month: @(A): To C or Not To C, That Is The Question Over the past few months, there has been some discussion of the C programming language, a common language used in the development of many UNIX, Windows, and Macintosh applications. We're not exactly sure what sparked the discussion, but GNU C came up very early. For those who don't know, the Free Software Foundation (FSF) is an organization that sponsors the creation and maintenance of many fine applications and utilities. One such group of applications are known as the GNU (GNU's Not UNIX) applications. Many people use the GNU utilities because they can be compiled and run on many different machines. One of the more popular apps is GNU C, which can be run on many computer systems as well as create object code for all the supported environments. The system is highly customizable, which explains why there was talk of both porting GNU C to the Commodore 64, and/or using a DOS or UNIX version of the compiler to create object code that would run on the C64. The thread has drug on for quite a while, but seems to be winding down. We're not sure there was a general consensus, but many remarked that GNU C is simply too large to run on a C64. In addition, the assumptions it makes about the supported hardware architectures makes cross-compilation a near impossibility. Still, many are searching for a way to bring ANSI C to the Commodore system. Success may come from CMD, as Doug Cotton mentioned that they were looking into a 65C816 cross compiler with the hopes of porting a small free C compiler to the 64 environment. @(A): The SuperCPU this and the SuperCPU that.... Now that the SuperCPU has started shipping from CMD, the newsgroup has been abuzz with questions and thoughts about the units. However, it seems the group is always one step ahead of CMD. Now that the units have started appearing on user's doorsteps, questions about the planned 128 unit and the SCPU RamCard have dominated the topics. The fact that the 64 unit actually contains 128 kB or RAM confused some folks, who wanted to know why they were paying for this extra RAM, and how they could take advantage of it now that they have it. Then, as fast as folks described that the extra RAM was actually used to "shadow" the ROM so that the KERNAL could run at full speed, the topic switched from present RAM to planned RAM. Questions ranging from how much RAM would be available on the RamCard, to how fast the RAM could be accessed, to what style of modules could be used have been debated. CMD, the developers of the RamCard, acknowledged that the full address space of 16 megabytes would be available on the unit and that they would try to provide speeds as fast as economically possible. CMD has also stated that they will be utilizing the same 30 pin SIMM technology that is used in the company's RamLink product. Some Usenetters debated that 72 pin SIMMs were becoming more cost effective, but CMD countered that only those that upgrade to the full capacity of the unit would realize any cost savings. The substantial increase in power the SuperCPU provides the programmer brought many questions and comments on planned or potential new operating systems for the unit. As of yet, none have surfaced, but only time will tell. For its part, CMD has made GEOS compatibility a staple of the new unit, so that OS will run correctly. At least one commercial venture, PROTOVISION, is allegedly planning an all GUI OS for the unit. See Newsfront (Section: news) for more information. Brett Tabke, of PHD Software Systems, announced that he is busy upgrading his Karma assembler for the 128 to run on the new unit and praised the virtues of the new opcodes, modes, and options available when operating the unit in "Native mode." This started some discussion on writing code that only runs on the new processor. The sides were split almost immediately, as all noted that while the new applications would run very well on the SCPU, they would not run at all on a stock 64. Proponents noted that new software demands the purchase of the SCPU, while purists maintained that that would limit the software to a small market segment. @(A): The "Virtual 1541"! Now, before you start thinking of 3-dimensional plastic cases and track 0 head knocking in quadrophonic sound, let's explain the topic. Many users have expressed a desire to virtualize the IBM PC as a glorified 1541 drive with full emulation. The closest thing as yet is the 64NET package, which allows you to load and save programs to the IBM PC hard drive like it was a regular CBM drive. The drawback to 64NET is its non- standard access method. Before you can access the emulated CBM drive, you have to load special software on the 64 and use a special user port cable. So, for users who demand perfect emulation, no choices exist yet. The lack of options haven't dented the dreams of many who outlined the "technical specifications" of such a virtual disk drive. ========================================================================= @(#)toolbox: Menu Toolbox III by Jeff Jones (jeff@loadstar.com) Copyright 1996: J and F Publishing @(A): Introduction This toolbox has the most versatile menu commands I've ever coded, and will make your BASIC and ML programs scream with speedy scrolling menus and file selectors with multi- item selectability. That's right. I said scrolling! Because of its size, there are only two versions of MENU TOOLBOX III: Filename SYS Location Notes MENUTOOLS 1000 4096 (Reference: code, SubRef: menucode1) MENUTOOLS 8000 32768 (Reference: code, SubRef: menucode2) These are the optimal locations for BASIC. It's 8K (33 blocks) in length, but your programs will be much smaller, and have access to RAM under ROM for array, screen and menu storage. You won't suffer for memory. There are four types of menus: o Custom Item Menus o File Requestors o Screen Menus o Instant Pages (from BASIC only) @(A): ML and Compiler Users You usually can't use SYS 32768,1,2,3,4,5 from ML or compiled programs so you'll have to POKE the parameters into a location and then tell the toolbox where to get the parameters. You tell MENU TOOLBOX II where to find the parameters by loading the .X and .Y registers with the low and high bytes of the location and then SYSing. From BASIC, the .X register is location 781 and the .Y register is 782. Here I'll use $033C (+828) as an example. The high/low bytes for location 828 are 3 high and 60 low. The following BASIC example of the lattice command works equally well as BASIC or compiled. poke828,x1 poke829,x2 poke830,y1 poke831,y2 poke832,t1 poke833,t2 poke834,c1 poke835,c2 poke781,60 poke782,3 sys32768+102 This may look slow, but in compiled programs, POKE commands are executed at near ML speeds. If there is a chance that you're going to compile your program, you may want to use the ML/compiler protocols from the start. It's heck converting a program. I know (Directomeister). ML programmers can embed parameters within their programs. It's actually easier from ML than compiled: background ldx b'lattice jsr 32768+102 rts b'lattice .byt 0,39,0,24,9,10,15,12 @(A): Instant Pages SYS 32768+198,PAGENAME$, items,list$..., hotkeys$ Since it's by far the easiest to use, we'll discuss instant pages first. A page is a computer screen with a user interface setup. Instant page allows you to create with one SYS a screen with a tiled background, a title bar, and a centered working menu complete with hotkeys. Consider the following code: 10 T$="M Y D A T A B A S E" 20 A$(1)="OPEN DATABASE (O)" 30 A$(2)="DEFINE FIELDS (D)" 40 A$(3)="ADD RECORD (A)" 50 A$(4)="SEARCH RECORDS (S) 60 A$(5)="PRINT RECORDS (P)" 70 A$(6)="RETURN TO LOADSTAR (Q)" 80 A$(7)="odaspq" 90 sys32768+198,T$,6,A$(1),A$(2),A$(3),A$(4),A$(5),A$(6),a$(7) 100 onf%gosub200,300,400,500,600,700 110 goto 10 Make sure the number of items in your list$ matches the number declared with ITEMS. If you RUN this program, a typical LOADSTAR type program will pop up on the screen: M Y D A T A B A S E OPEN DATABASE (O) DEFINE FIELDS (D) ADD RECORD (A) SEARCH RECORDS (S) PRINT RECORDS (P) RETURN TO LOADSTAR (Q) CRSR/RETURN TO SELECT You'll have a CRSR/RETURN menu with hotkeys for each menu item, and more hotkeys if you simply include them. The menu is automatically centered left to right and top to bottom. CRSRing to ADD RECORD or pressing [A] will exit the menu and the variable, F%, will be 3. This is how you know which item or hotkey was selected by the user. There can be up to 40 hotkeys defined so that your page goes beyond the items presented on the menu. If hotkey #20 is pressed, the menu is exited, and F%'s value is 20. It's not mandatory for your menu to have alternative hotkeys, but if you do, list the menu's hotkeys first, and in the same order that they appear in the menu so that F% is always the same as the menu choices and the hotkeys. Lines 10-80 set up the data for the menu into variables since you can see that there's no way all this text could fit on one line. Just imagine it with 20 hotkeys. Line 90 calls the routine. Program flow is transferred to MENU TOOLBOX II until a menu item or hotkey is pressed. Line 100 is one way of dispatching flow of the program based on the user input. Ironically, this feature will only work from BASIC. I wrote the INSTANT PAGE feature as a simple driver to test MENU TOOLBOX II's ability to take commands from ML. I liked the routine I ended up with and decided it should be added to the package. Adding links for ML for this routine could be done -- but since I wrote the routine with many parameters intending for it to be called from BASIC, it becomes more difficult, even convoluted, to write ML links for a program which is essentially a series of ML links. Plus there's no time left this month. @(A): Instant Page Setup: SYS 32768+201, tilea, tileb, colora, colorb, title color, highlight color, menu color, message color, frame color, frame on, background, border You can use my bland default colors or you can use your own. This command simply changes the presets. Your background is made up of a mesh of two characters, A & B, in two colors. TILE A is one of the characters in the tiled background (0-255) TILE B is the other tile in the background COLOR A is the color of TILE A, 0-15 where COLOR A has the following effect: COLOR A VALUE COLOR 0 BLACK 1 WHITE 2 RED 3 CYAN 4 PURPLE 5 GREEN 6 BLUE 7 YELLOW 8 ORANGE 9 BROWN 10 LIGHT RED 11 DARK GRAY 12 MED GRAY 13 LIGHT GREEN 14 LIGHT BLUE 15 LIGHT GRAY This chart applies to all subsequent color values mentioned in the documentation. COLOR B is the color of TILE B TITLE COLOR is the color of the title of the page. HIGHLIGHT COLOR is the color of the highlight bar of the menu MENU COLOR is the color of the menu MESSAGE COLOR is the color of the message at the bottom of the screen, "CRSR/RETURN To Select." FRAME COLOR is the color of the frames surrounding the title and menu. FRAME ON turns the frame around the menu on with a nonzero value. You might need to turn off the frame to squeeze in extra menu items. Maybe you don't like frames, either. BACKGROUND is the background color BORDER is the border color @(A): Change Message: SYS 32768+204,New Message$ In case your page needs a custom message at the bottom of the screen, change it here. Keep it less than 38 characters. @(A): Screen To Menu: SYS 32768+63,y,x1,x2,n,t,h,"keys" Screen To Menu is an easy way to create a CRSR/RETURN menu from a vertical list of options that you've previously printed on the screen. So any list on your screen can be made to "spring to life" as a CRSR/RETURN menu. There may be up to 24 items, as wide as the entire screen. It's up to you to write the subroutines that correspond to each menu item. After an item is selected, the variable, F%, tells you which item was selected. It will hold a value between 1 and the number of items in the menu. Here it is in use: 150 sysaddr,y,x1,x2,n,t,h,"hotkeys" 160 on f% goto200,300,400,500,600... "f%" is the nth item selected. Y is the starting row on the screen. X1 is the left extreme of the highlight bar. X2 is the right extreme of the highlight bar. N is the number of items in the menu. T is the text color of the unhighlighted items in the menu. H is the highlight bar color. NOTE: If you don't want the highlight bar to reverse items, add 128 to the color codes (0-15) of parameters T and H. The MENU command has been extended per imperial order of Maurice Jones. Maurice likes to press one key instead of using CRSR/RETURN menus, which force you to press more than one key. The new "keys" field allows you to define hotkeys for each menu item, and also for flow control beyond the CRSR/RETURN menu. For instance, you have five items on your menu, but "keys" is defined as "12345qlprt". 1-5 happen to be hotkeys for the menu in this example. You can use mnemonic keys if you like. If the user CRSRs to item 4 and presses RETURN, F% will become 4. If they press 4, f% becomes 4. But as a bonus, if the user presses "l", which is seventh in the KEYS string, F% becomes 7. If they press "r", F% becomes 9, and so on. MENU now has the power of BRANCHER. You can have up to 40 hotkeys in the string. What would you use these hotkeys for? Well you might have a CRSR/RETURN menu, but also "q" to quit and SPACE to go to another menu. The only new requirement is that you now have to define hotkeys for each of your menus. It's a good idea to let your users know about the hotkeys. To use screen menus from ML: ldx parameters jsr 32768+162 User input is returned in 253 Parameters is a stream of legal parameter bytes followed by the length of the hotkey string, followed by the hotkey string. @(A): Introduction to Scrolling Menus These menus are more involved to implement, but well worth the setup time. The multi-file selector in DISKMEISTER is an example of a quirky BASIC/ML slow POKE (pardon the pun). You need self-contained ML to handle your menus, especially scrolling ones. MENU TOOLBOX will create its own pointers for the menu items you define. Normally these pointers will be right at the end of the ML. Each item in your menu will take up 4 bytes. The pointers can extend under ROM and IO with no problem. If you don't want the pointers to be at their default location, you can change the array location with the following SYS. @(A): Change Location: SYS 32768+27,location >From ML ldx location jsr 32768+126 Since the default pointers will begin around $a000, you will want to change the location if you have data such as a screen stored there. Typically you'll want the pointers somewhere where they won't cost you anything, which is usually under some ROM. You'll also want to use this command if you want to switch between pointers for different menus. @(A): Declaring Menu Items Before MENU TOOLBOX can create a menu for you, you must either BLOAD a directory, an EDSTAR PRG text file with a list of menu items in it, or declare items from DATA statements. I've included tools to make this process easy. Since directories are so structured, they don't need pointers so all you have to do is tell MENU TOOLBOX where to BLOAD the directory: @(A): Bload Directory: SYS 32768+39,"$:*",device,location Before you can show a file requestor, you must first have a directory in memory. You can BLOAD a directory anywhere in RAM, even under IO at $D000-$DFFF. There is NO NEED to use the CHANGE LOCATION command after BLOADing a directory. F% holds the number of files, but keep in mind that counting starts from 0, not 1. >From ML: ldx filename lda namelength jsr 32768+138 the directory filename, usually "$:*" must be followed immediately in memory by the device number byte and then the low/high bytes of the load address. @(A): File Requestor: SYS 32768+45,x,y1,y2,r,c,h,s,m This command will pop up a scrolling (if necessary) menu on your screen. Your users will be able to CRSR up and down or page with the + and - keys. You should print this somewhere on the screen so that your users will know. Lotta parameters? Here's what they mean: X is the upper left hand corner of the requestor box. Since directories are always going to be about 32 columns across, you would never have a number more than 6 here. Y1 is the top row of the menu, 0- 20. Y2 is the bottom row in the menu. Y2 determines how much of your screen will be taken up by the file requestor. R stands for REVERSE mode. If you want all the items in the menu to be printed in reverse, put a 1 here. Highlighted items will appear unreversed. C is the color of the menu and all unhighlighted menu items. H is the color of the highlighted (current) item. S is the color of selected files (if the menu is in multi-file select mode. M is for MULTI MODE. It allows the user to select more than one file. Make this a 0 for a normal single file and 1 for multi-file selection ability. Files are selected with SPACE or RETURN. To exit the requestor you must press F1. Your program should inform the user of this if they are in the multi file mode. When in single mode the file name is returned in W$, the position in the directory is in I% and the block size of the selected file is in B%. >From ML: ldx location jsr 32768+144 Have parameters as a stream of bytes in the order and extremes presented above. When in single mode, .X and .Y point to the filename and .A holds the file length. Compiler users, .A is location 780, .X is 781 and .Y is 782. You can find F% at 253, I% at $14 and b% at $22 @(A): Index Items: SYS32768+33,item This command works best with bloaded directories, but can be used on normal scrolling menu data. It returns the filename or menu item string of ITEM into w$. When f% <> 0, it means the item or file has been selected. So when you have a multi file menu, do a loop to check each file. If f% <> 0, act on that file. [Big note:] if you're hurting for string array space or suffering from garbage collection blues, why not store/load lists into menu item slots in high memory? You can use INDEX to check your hidden pseudo arrays, and DEFINE MENU ITEM (below) to store/flag items. Such arrays won't be dynamic, but they can come in handy. >From ML: ldx item jsr 32768+132 .X and .Y point to the returned string and .A holds the string length. F% is in locations 253 and 254 always. @(A): Menus from BASIC Strings Menu items can also exist in BASIC, but preferably in DATA lines and not in dynamic strings since some dynamic strings can change location after a garbage collection. MENU TOOLBOX has to know a few things about your menu items before it can make a menu out of them. It has to know each item's place in the menu. Is it item number one or three hundred? If you have many items, you can tell MENU TOOLBOX all about your menu in a FOR loop with the following command. This isn't difficult to do. All you have to do is: @(A): Define Menu Item: SYS32768+30,item$,index,selected Here you're telling the system the place of a certain string in your menu. If you're doing this from an array, you can use a FOR loop. ITEM$ will always be a string variable, probably from an array or from DATA read into a string. If your menu items are in DATA statements, you don't need to DIMension an array to hold the strings. You can READ the data into a throwaway variable like a$ and then sys32768+42,a$,index,selected in a FOR loop. If you will want to print the menu item somewhere outside of the menu, you will probably want and need an array. In any case, string DATA in arrays doesn't take up any memory except for pointers. INDEX is just the item's place in the menu. SELECTED is whether or not the item should be considered selected when the menu pops up. You can use this even when not in multi-select mode to show that some items are not available or to highlight items to show that some pending action is needed. >From ML: ldx parameters lda string'length jsr 32768+129 parameters .asc "item name" .word index .byt selected @(A): Menu COmmand: SYSaddr+42,x1,x2,y1,y2,r,c,h,s,o,l,m This command will pop up a scrolling (if necessary) menu on your screen. Your users will be able to CRSR up and down or page with the + and - keys. You should print this somewhere on the screen so that your users will know. Here's what the parameters mean: X1 is the upper left hand corner of the requestor box. X2 is the right extreme of the menu. Any menu item that exceeds the width defined by X1 and X2 will be truncated. Y1 is the top row of the menu, 0- 20. Y2 is the bottom row in the menu. Y2 determines how much of your screen will be taken up by the menu. R stands for REVERSE mode. If you want all the items in the menu to be printed in reverse, put a 1 here. Highlighted items will appear unreversed. C is the color of the menu and all unhighlighted menu items. H is the color of the highlighted (current) item. S is the color of selected menu items. O is the offset, in case you've sectioned off your menu items, generally zero. If you want to pop into the menu at a particular point (say at the last item selected which you've preserved), use offset to do so. The rest of the menu is still accessible. L is the limit or the highest menu item allowed. Note that this will usually be one less than f% when you use the Rack Em Up command. M is for MULTI MODE, which allows the user to be able to select more than one item. Outside of a file requestor, there are few uses for this. Make this a 0 for a normal single item and 1 for multi-item selection ability. Items are selected with RETURN or SPACE. To exit a multi-select menu you must press F1. Your program should inform the user of this if they are in the multi item mode. When RETURN is pressed in single mode, the item number is returned in F%. >From ML: ldx parameters jsr 32768+141 parameters .byt x1,x2,y1,y2,,r,c,h,s .word o,l .byt m @(A): Set Mode: SYS32768+48,n Sometimes you may have a regular menu and a directory set up in memory. You may want to set the proper mode for FIND AND CLEAR with this command before using it. N is 0 for normal retrieval and 1 for file requestor retrieval. @(A): BLOADT Text File: SYS32768+15,file$,device,location This command will BLOAD a standard EDSTAR text file into memory and place a zero at the end of the file to mark the end. It can also be used as a regular BLOAD. FILE$ is the filename of the file you want to BLOAD. DEVICE is any legal device number. LOCATION is anywhere in RAM except the IO area $D000-$DFFF. Again, you really should take advantage of areas outside of BASIC and beneath ROM. You can indeed use packed text if you BLOAD it with DTEXT, published on LOADSTAR #122 and the COMPLEAT PROGRAMMER. >From ML: ldx parameters lda filename'length jsr 32768+114 parameters .asc "filename" .byt device .word location @(A): Rack 'em Up: SYS32768+36,location This command simply itemizes every line in a text file that you've BLOADed so that it can be used as a menu. Pointers for each line in the text file will be located starting from the end of the file. So don't BLOAD a file that ends too close to $FFFF or the beginning of important data. F% tells you the number of lines it has itemized. Save this into another variable because you will need the value to set a limit (bottom) to any menu made with the BLOADed data. The longest length of a line is stored in $14 (decimal 20). If you want your resulting menu properly centered, check out this location immediately after the call as this location is heavily trafficked by Menu Toolbox and BASIC. >From ML: ldx location jsr 32768+135 @(A): Text File Reader You would simply BLOAD a text file using the aformentioned command, and then RACK IT UP. Next just define a regular menu wide enough to accommodate the text anywhere on the screen. Don't forget to prompt your users to press RETURN to exit the reader (which is really a big menu). @(A): Report Location: SYS32768+54 If you don't want to rack up a text file again, you can find out and store exactly where the menu pointers begin with this command. The location will be reported in F%. Remember that F% is an integer variable, and has a max of 32767. So if F% is negative, subtract it from 32768: SYSAD+69:ad=f%:iff%<0thenad=32768- f % >From ML: jsr 32768+153 Location returned in .X and .Y @(A): Get Word: SYS32768+51,color,cursor,limit,text$ Your program will probably need input from the user. Here you have the best input routine I've ever done. It allows you to cursor through already-typed text, and it allows you to predefine the text from a variable or static string, allowing the user to just hit RETURN if they don't want to change the text as it appears at the blinking cursor. The results of editing (or non-editing) is returned in W$. COLOR is the color of text that is typed by the user. CURSOR is the color of the flashing cursor. LIMIT is the maximum length of the input. TEXT$ will usually be null. If not, the contents of the variable will be printed at the current location of the cursor, respecting the COLOR parameter. The length of TEXT$ overrides LIMIT only if it's longer than LIMIT. >From ML: ldx parameters jsr 32768+150 rts parameters .byt color,cursor,limit .byt length of default string .asc "default string" Returns location of edited string in .X and .Y. .A holds the length of the string. @(A): Start Memory Print: SYS32768+60,location,string$ @(A): Continue Memory Print: SYS32768+63,string$ Use START MEMORY print to start a list of text in memory. This command allows you to print to memory in case you want to build a menu from software instead of a table or file. You can print a list in memory, RACK it up, and make a scrolling menu out of it. Works beneath ROMs, too. A carriage return is appended to the string in memory. Once you've started memory printing, just keep sending strings with continue memory print. The updated address of the end of your menu is kept in locations 251 and 252. USE NO OTHER COMMANDS while building your list with memory print! You might corrupt 251 and 252. The final item in your menu should end with a character string 0 so that RACK IT UP knows where the end of your list is. sys32768+63,final$+chr$(0). START From ML: lda string'loc sta $23 lda string'length ldx start jsr 32768+156 CONTINUE From ML: lda string'loc sta $23 lda string'length jsr 32768+159 @(A): Scroll Up: SYS32768+18,x1,x2,y1,y1 This scrolls a section of the screen defined by the extremes above. Scroll need not be used with menus. That's done automatically, but since the code exists for the MENU command, I thought I'd give you direct access to it if you want. The cursor is placed right where new screen text would appear according to the parameters of the scroll. >From ML: ldx parameters jsr 32768+117 rts parameters .byt x1,x2,y1,y2 @(A): Scroll Down: SYS32768+21,x1,x2,y1,y1 This scrolls a section of the screen defined by the extremes above. >From ML: ldx parameters jsr 32768+120 rts parameters .byt x1,x2,y1,y2 @(A): Clear Row: SYS32768+24,code,color In case you have to blank a duplicated line in the scroll area, this command will do it using the screen code and color you specify. Cursor position isn't changed. >From ML: ldx code ldy color jsr 32768+123 @(A): Titles In order to make use of the internal tiles, you MUST use a custom font in your program. The use of fonts in programs is beyond the scope of this article. FOr information on fonts, please see LOADSTAR's Compleat Programmer or Font Finale on LOADSTAR #92. Here is the command structure of the tile functions. Since I made three versions of the program, I'll refer to only the $C000 version. Replace 32768 with the other addresses if you will be using other versions. @(A): Lattice: SYS 32768,x1,x2,y1,y2,t1,t2,c1,c2 This command will create a colorful pattern on the screen. If T1 and T2 were 1 and 2, the grid would consist of As and Bs in the following fashion: abababababababa bababababababab ababababbababab These lattices can be any dimension, as thin as a column or row and as large as the entire screen. They can be very colorful and eye-catching as you will see in DIRECTOMEISTER on our pass-around issue, available from our web page at http://www.loadstar.com/ X1 is the leftmost column of the lattice, 0-39. X2 is the rightmost column of the screen, 0-39 > X1. Y1 is the top row of the lattice, 0-24. Y2 is the bottom of the lattice, 0-24 > Y1. Note that if Y2 is greater than 24, the lattice can overwrite your BASIC program at $0801 (+2049). T1 is the screen code of the tile in your lattice, 0-255. You can find the screen code of any character by printing it at HOME and then issuing the command: print peek(1024) T2 is the screen code of the other tile in your lattice. It can be the same as T1 if you like. You can still get a lattice effect by using the same tile with a lattice of color only. C1 is the color of T1, 0-15. C2 is the color value of T2 in your lattice. As with tile selection, C1 and C2 can have identical values with T1 and T2 having different values, creating a lattice of tiles and not color.