@(#)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 á, and the fractions &188;, &189;, and &190; were put in their proper order. * Typing a shift-space now sends a space, rather than the á 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. If T1, T2, C1 and C2 are all the same, then what you have is a block. There's a simpler way to get a block. >From ML: ldx params jsr 32768+102 rts params .byt x1,x2,y1,y1,t1,t2,c1,c2 @(A): Block: SYS 32768+3,x1,x2,y1,y2,code,color This routine will draw a block of characters on the screen. It will also paint an area of the screen without changing the characters if you use a CODE of 255. It can erase portions of the screen if you use spaces, and it can draw single lines or rows of characters if you like. It is a mainstay of my programming. Can't do without it. X1 is the leftmost column of the block, 0-39. X2 is the rightmost column of the screen, 0-39 > X1. Y1 is the top row of the block, 0-24. Y2 is the bottom of the block, 0-24 > Y1. Note that if Y2 is greater than 24, the block can overwrite your BASIC program at $0801 (+2049). CODE is the screen code of the tile in your block, 0-254. You can find the screen code of any character by printing it at HOME and then issuing the command: print peek(1024) When a CODE of 255 is issued, the BLOCK program will not alter the screen at all, only the color. This allows you to change (PAINT) colors of portions of the screen without having to re-print them. If you must use character #255 on the screen, use LATTICE with both screen codes set to 255. With both codes and both colors set the same, LATTICE becomes BLOCK. COLOR is the color of CODE, 0-15. >From ML: ldx params jsr 32768+105 rts params .byt x1,x2,y1,y2,code,color @(A): Outline Box: SYS 32768+6,x1,x2,y1,y2,color This routine will pop up a box on the screen using the CMDR-A,S,Z,X, SHIFT-ASTERISK and SHIFT-MINUS characters. The area inside the box will not be affected. X1 is the leftmost column of the box, 0-39. X2 is the rightmost column of the screen, 0-39 > X1. Y1 is the top row of the box, 0-24. Y2 is the bottom of the box, 0-24 > Y1. Note that if Y2 is greater than 24, the box can overwrite your BASIC program at $0801 (+2049). COLOR is the color of the box, 0-15. >From ML: ldx params jsr 32768+108 rts params .byt x1,x2,y1,y2,color @(A): Copy Tile: SYS32768+9,FONT LOCATION,TILE,CHAR This is a magic command. Within the ML are 60 tiles, lifted from TILE STYLIST. This command will copy any of those tiles to any character in your font. All you have to do is tell the command where your font is. FONT LOCATION is the location of your font in memory. TILE is the built in tile 0-9, that you want to have copied into your font. CHAR is the screen code of the character you want replaced with the tile. >From ML: ldx parms jsr 32768+111 rts parms .word font'location .byt tile,char @(A): More Than Sixty Tiles?: SYS32768+12 If you use this command, you must be a tile fanatic. You can use values greater than 99 for TILE if you BLOAD a tile font into the proper location. This will only work with the $9000 and $0800 versions of TILE TOOLBOX. It can work with the $C000 version, but under normal circumstances, you can't BLOAD to the $D000 area, which is where the VIC chip and I/O are. To get the proper BLOAD location, SYS32768+12. The address will be returned in the .X and .Y registers. For BASIC users, the address will be returned in locations 781 and 782. ML users would simply insert the JSR before a LOAD: jsr 32768+12 jsr LOAD BASIC users would BLOAD their font into place this way: 20 sys57812"tiles",8,0:poke780,0: sys32768+12:sys65493 This would give you a total of 266 tiles in memory if your tile font is 9 blocks long, but you will only be able to access the first 256, including the ten already in the ML. @(A): Animation You can use the COPY TILE command for animation by copying a series of tiles into the same CHAR. This will be much faster than drawing new characters or re-drawing an entire lattice or block. Of course if you're changing just one character, you can poke one byte on the screen, but the advantage of copying is that you have information [outside] of your font so your font isn't crowded and barely usable for text. @(A): Shade: SYS 32768+96,x1,x2,y1,y2 SHADE paints with intelligence. I have always used BLOCK to shade an area with a uniform color just beneath and to the left of a box I'm about to draw. This gives a nice 3-D effect. SHADE does one better. If there are multiple colors in the area, each color is assigned a darker shade. So your overlapping windows will have a consistent shading effect. SHADE can have a flash-type cycling effect when used repeatedly on the same section of a screen. Eventually it will only cycle between blacks and all the shades of white. >From ML: ldx parms jsr 32768+192 rts parms .byt x1,x2,y1,y2 @(A): Screen Stash: SYS 32768+66,page @(A): Screen Restore: SYS 32768+69,page @(A): Screen Merge: SYS 32768+87,page Without screen swapping, pop-up help screens and menus would be cumbersome. These two routines will store a screen at any page (256 byte section) in memory. To store the current screen at $d000 (53248), you would: SYS 32768+66,53248/256 To get the screen back: SYS 32768+99,53248/256 $D000 is at page 208. Note that each screen takes up 8 pages, and should be kept 8 pages apart. Note that screen stash stores the current border and background colors, as well as cursor position per imperial order of Maurice Jones. Screen restore will bring back the border and background colors of the stored screen. SCREEN MERGE will restore a screen "under" an existing screen, meaning that every place where there's a SPACE can be written to by the screen being merged. Background and border colors aren't changed by MERGE. In case you're confused about what screen merge does, MERGE would be a simple screen restore on a blank screen. On a screen with something, anything that's not a SPACE or SHIFT SPACE, MERGE allows restored screen to bleed through without wiping out the current screen. You can use MERGE in games like Concentration, where you only want to reveal part of the screen at a time. STASH From ML: lda page jsr32768+165 RESTORE From ML: lda page jsr32768+168 MERGE From ML: lda page jsr32768+183 @(A): Link: SYS 32768+72 Though all TOOLBOX routines that affect the screen use LINX and keep line links clear, you can call LINX directly with a SYS 32768+72. Same from ML. @(A): Print At: SYS32768+75,x,y,string$ This will print text anywhere on the screen. X and Y are your screen parameters. STRING can be a literal or a string variable. >From ML: lda string'loc sta $23 ldx row ldy column jsr 32768+171 >From ML the string must terminate in a zero. @(A): Center: SYS 32768+78,row,string$ Centers a string (fewer than 41 bytes) on a specified line. >From ML: lda string'loc sta $23 ldx row jsr 32768+174 String must terminate in zero. @(A): UPcase: SYS 32768+81,variable$ Converts all characters in a string to upper case. "We, The People" becomes "WE, THE PEOPLE" Note UPCASE will not print the string for you. >From ML: lda string'loc sta $23 jsr 32768+177 String must terminate in zero. @(A): LCase: SYS 32768+84,variable$ Converts all characters in a string to lowercase. "We, The People" becomes "we, the people". Great for use before a test of input like Y and y or N and n to consistently lowercase input. >From ML: lda string'loc sta $23 jsr 32768+180 String must terminate in zero. @(A): CHARACTER SWAP: SYS32768+90,a,b,c CHAR SWAP will search the screen for parameter A and change it to parameter B with the color, C. Here A and B are screen codes as revealed in LOADSTAR LETTER #34 or page 376 of your Programmer's Reference Guide. But the quickest way to find out a screen code is to print the character in the HOME position and then: print peek(1024) or if your screen is moved: print peek(peek(648)*256) In a flash, you can change every instance of a character to another character, or you can leave the character the same and just change its color. This is good for font animation where absolute speed isn't a factor. Note: if you want to change characters, but not their colors, send a color code of 128. >From ML: ldx parms jsr 32768+186 parms .byt a,b,c @(A): COLOR SWAP:SYS32768+93,c1,c2 This changes every instance of a target color on the screen to another color. >From ML: ldx parms jsr 32768+189 parms .byt a,b,c @(A): BRANCHER:SYS32768+99,"string" BRANCHER adds very quick flow control to BASIC programs. Send this routine a string and it will wait until a key, included in that string, is pressed. The string can be up to 207 bytes long. Imagine the BASIC code necessary to check 207 hot keys! This call will handle it in one command -- and much, MUCH faster. When a valid key is pressed, BRANCHER will inform you which key was pressed by passing its instring position to the F% variable 1000 SYS 32768+99,"mdvc":on f% goto100,200,300,400 Here's the BASIC equivalent: 1000 geta$:if a$<>"m"anda$<>"d" anda$<>"v"anda$ <>"c"then1000 1010 ifa$="m"then100 1020 ifa$="d"then200 1030 ifa$="v"then300 1040 ifa$="c"then400 Not only is this code more bulky, but imagine how clunky it would be if you had 25 active keys. >From ML: ldx string'loc stx $22 sty $23 jsr 32768+195 String must terminate in a zero. @(A): License Agreement As with all LOADSTAR tools, we encourage you to use them in your programming endeavors. You can do so without a licensing fee as long as you mention somewhere briefly in the docs that you got the routines from LOADSTAR. If you'd prefer not to mention us, write for permission. LOADSTAR's tools may be used in commercial products, and programs published in other magazines under the same provisions. ======================================================================== @(#)fido: FIDO's Nuggets by Geoff Sullivan (sunfish@gis.net) Summer slows things down everywhere, except perhaps in Zone 3, and the Commodore FIDO Echos are no different. I like to think we Commodore users have other interests beside our computers, and that we pursue them at this time of year. Message flow was slow, and at times sporadic. There was some discussion of a hitch in the system, and even now, I've been over a week without one new message arriving at my node. There is also concern that the Internet has absorbed some of the Echo traffic too. More of us have access to it, and there is no doubt that it's faster. @(A): Warning: Killer App. Movie at 11. The C128 killer application with a life of it's own, QWKRR, by Rod Gasson, is in version 5.0b at this writing. There are known bugs in it and Rod has posted the symptoms and cautions frequently on the Echos. Users are able to respond and help Rod work out the bugs from his Australian lab, while most of us in the Northern Hemisphere are enjoying a warm summer! @(A): The Canon Is of Little Use, Sir. Traffic has been light in the Geos Echo, but a major topic has been the use of Canon InkJet printers with Geos. Manufacturers are now catering more and more to Microsoft's Plug-n-Play concept, while we plug-n-pray. Only the older InkJet printers, such as the BJ-200 and 600 series, have actual DIP switches for manual configuration. Until software is available for us to configure the newer printers, their use will be limited. @(A): Catch What WAVE? Discussion of Maurice Randall's Wave for Geos 128 has been centered around speculation as to what it will end up being. Will it be a SLIP/PPP connection to the Web, or a high speed terminal program? Only Maurice knows for sure, and lately he's been busy tweaking software for CMD's Super CPU, the C64 version of which has begun shipping. @(A): Speed Thrills.... Speaking of the Super CPU, the few users that have them by now are raving. I expect the message base to have more information as more SCPU's are put into service. We have all read the hype before, but actual user experiences posted on the Echos are confirming the awesome speed of this accelerator cartridge. @(A): Ingenious Commodore Usage Finally, an often asked question is, "What do you DO with a Commodore computer?". There is much to do, and recently a thread addressing that subject was begun. John Davis' story of how he and his VIC-20 increased his Union participation by using a mail-merge program to personalize meeting announcements brought a smile. He also has used his SX-64 to do sing-alongs for kids at a local campground. SID is his only instrument! So, that's a glimpse into the world of FIDO, the wonder dog of networks, for this time. Here, boy.... ========================================================================= @(#)review: The Hacking Review by Tom Warnes @(A): The Compleat Crossword, published by J and F Publishing. This is a collection of crossword games which are made a little simpler because the computer is watching to make sure you don't cheat. To start, simply load the disk just like any LOADSTAR offering: LOAD"!",8,1 (substitute 8 with whatever device you are accessing). You'll find most of the actions and key mappings identical to those found on the LOADSTAR menu program. The start up screen gives you the option of finding out about the people are who created the puzzles in "All About This Disk". The other choices are "Change Title", "Change Music" and "Exit to Basic". The Change Title only allows you to change the background screen. The Change Music becomes a heaven sent option after you've been playing this game for a few hours, or even minutes. You may find yourself really hating the background music; therefore, I'll give a few tips on turning the music off completely. The music doesn't come on until you've loaded a puzzle into your computer off of the disk. To turn the music off completely hold down the CNTR key while pressing the S key or press the CLR/HOME key. The CLR/HOME key acts as a toggle as does the CNTR-S combination. There were a few minor bugs on the disk that I found annoying. In the option "All About This Disk" only a summary of the creators of the puzzles is given. They don't attempt to explain the different functions or how to access them. My suggestion would be to add an extra subgroup called something like "Credit to the Creators" to put their names in, and in the "All About This Disk" put a more complete description of the choices available to the user. The "Change Title" had me stumped for a short while until I discovered it only changes the texture of the background screen, not the color to help someone who has been staring at the screen trying to solve these puzzles. The puzzles themselves are interesting even if sometimes they don't stick to the theme of the puzzle. There is a small hiccup in the music presenter, as it had a small problem playing the last song on the list available to the user. It acted like a cassette player playing a cassette that has the tape wound to tight on the spools. Except for these minor problems it was interesting having the computer keeping me honest. One big thing that has bothered me for years is the fact no one has found a way to reward the player for successfully completing a game on the computer. I've seen a simple message flashed on the screen or even a colorful display. This is not for everyone. A possible reward would be to have a timed series of puzzles so the player could compete against time. A feature I liked was the fact that you could mark a puzzle as having been completed, or if you're like me, one that you've worked on and still have to complete. You are given this option each time you go from a puzzle to the start-up screen. Most of these puzzles seem to have come from the mind of Barbara Schulak, a name you will recognize from the Loadstar 128 collection. @(A): The Compleat Lee O., distributed by J and F Publishing. Speaking of the Loadstar 128 collection the next group of programs came from those disks. It is called the complete Lee O. This is a collection of programs submitted to Loadstar to be put out on their 128 Loadstar disks. The programmer, Leo O. Clinton, tried to help fill the barren field of 80 column programming. They are all utility programs. Their titles are "Mutual Funds", "Resumes", "Genealogy", "Auto Expense Tracking", "Kitchen Upkeep" (Recipes), and "Home Finances". All of these programs come on one disk and it is highly recommended that you copy each onto a dedicated disk. To explain the working of the programs, I sometimes borrowed heavily from the text that Leo O. Clinton typed in to explain the workings of his programs. @(A)subapp: Mutual Funds Works with drive 8 only. Keeps 253 transactions in each of 16 Mutual Fund Accounts. Computes profit/loss, investment and total returns and investment and fund performers. Output can be to screen, disk or printer if you have included all the recommended files on your disk. Escape will take you one level back from the level you’re working on. You can add accounts, delete accounts, modify accounts, or add transactions. This program works on the trade date of your accounts and must be entered in the request for date. @(A)subapp: Resume Writer This program is important in today's shifting job market. It works with a wide range of disk drives. It can create a resume after you type in the answers to a range of questions. It creates a resume to your personal preference. The chronological option lists last job first, or you can go with most important job first and on down to the least important. All information can be saved to disk and then recalled and printed when you need it. @(A)subapp: Pedigree 128 Keeps track of 5 generations of your family. Gives you the option of creating a full page of information for each member. If you get stuck and don't know how to answer a question, the help screens will steer you in the right direction. After the title screen is displayed a chart will show you the relationship of the people you are entering. Drives 8 through 11 are supported. This is really a fine program for someone interested in his or her family relations. @(A)subapp: Auto Expense If you're one of the people you see at the gas pumps jotting down mileage, cost and quantity of gas in a little book, this program is for you. This program keeps a record of 18 cars with the possibility of 252 entries for each car per disk. The program is menu driven. After you enter data you can use what you have entered to create graphs or print a record for the car you pick. The graphs will show you Actual mileage, Cumulative mileage, or a Cents per mile Pie Chart. @(A)subapp: Cook's Helper This program is a electronic recipe box with a lot of extra features thrown in. It allows you to make up a weekly menu and will help make up a shopping list so you can get all the ingredients you will need. There is a conversion calculator to help you go from metric to American Standard, and also an option to convert to different quantities. Entering the recipes into this program is a little different, as you must use various buttons to access certain menus. For example, you press the F1 key whenever you want to print quantities. A list will appear and you use the cursor keys to select the proper quantity. I have used this program since it first came out on Loadstar 128 and it saves on the number of piles of paper I have laying around. @(A)subapp: Fiduciary The closest program that I can relate to this program is Sylvia Porter's Personal Finance 128 series put out by Timeworks. Sylvia Porter's has a few more small functions this program doesn't have. This program allows you to know what your transactions have been, balance your checkbook, create a budget and show you how close you are to staying within that budget. It shows you what Assets/Liabilities you have, and allows you to see in a chart where your money is going. A 30+ page manual that explains what functions this program is capable of is available for you to print out. ========================================================================= @(#)hw: The CMD Nirvana: The Guts and Glory by Todd Elliott (telliott@ubmail.ubalt.edu) http://ubmail.ubalt.edu/~telliott/commodore.html @(A): Introduction Before you begin, download the CMD Nirvana picture off of my WWW site! Take a good look at the picture, and if it doesn't whet your appetite, this article will! This is the computer that I use at home for my various programming projects and good old fashioned entertainment. It consists of a C128DCR with three built-in foreign components: a 12 VDC fan, CMD HD 85 megabyte drive and a FD 4000 3.5 disk drive. The case is painted obsidian black. It does have a 4MB RAMLink hooked up with a 1750 REU and a Swiftlink or Action Replay cartridge. Other peripherals circling the CMD Nirvana's universe are an 1541, 1571, a SlikStik, MW350 printer interface, in addition to a host of books and magazines dedicated solely to the c64/128 line. (Soon, it will have a SuperCPU 20!) It is a very powerful computer, but it doesn't cure my malady of starting programming projects, but only to leave them unfinished to do the next one. All of this power is corrupting, indeed! @(A): Disclaimer: This article, while resembling a how-to-do-it-yourself article, is only meant for entertainment and informational purposes and is to be used at the reader's own risk. Mr Elliott, Commodore Hacking, nor Brain Innovations, Inc. can be held responsible for any damages and/or injuries occurring as a result of following this information contained in this document. Electronic circuitry is fragile and can be damaged easily. Users must use ground strips or some other means of protecting their circuitry from accidental discharges of static electricity. Also, soldering equipment, electronic outlets, etc. pose a significant danger to self, and extreme care should be used in operating these items or working on electronic circuitry. Be sure to unplug the electronic circuitry before commencing work. I also disclaim any and all warranties, both express or implied. Tremendous thanks goes to Al Anger, who, with his substantial assistance, made this CMD Nirvana computer a reality. Thanks, Al Anger! For those who don't know him, take a peek at Commodore World's Issue Ten cover, and you'll see his C128T (Tower) computer, plus a host of other hardware projects. But, Mr. Anger did not write this article and is not responsible for its contents, in which the disclaimer above still applies. You can reach Al Anger at coyote@bridge.net. Thanks also go to Max Cottrell, who did the scans of the photographs, courtesy of MC Photography, mcphoto@izzy.net. The standard disclaimer also applies to Max Cottrell and MC Photography. @(A): A Verbal Tour Let's begin with a visual inspection of the front panel: The plastic panel contains a sticker overlay for the CMD HD, which is located on the left side of the panel. The HD sticker overlay is located next to the C128D's POWER-ON LED on its right. The FD 4000 occupies the right side of the plastic panel. The right side of the plastic front panel is used to house a receptacle for the C128D's built-in 1571 disk drive, with a swinging gate. But, the built-in 1571 drive was removed, and the left side panel was cut and filed smoothly with the correct dimensions to fit a FD 4000 disk drive snugly. (Well,almost.) Continuing with the visual inspection, we turn to the left side of the C128D. The metal casing was cut to allow for the fan, power cord and off/on switch to be accessible. If you note the picture carefully, the cuts on the case aren't in perfect sync with the interior. I guess the design won't be winning any art awards anytime soon. ;) The main thing is that I can access the off/on switch, and be able to plug/unplug the power cord without any difficulty. As for the fan opening, a circular opening as shown in the picture is not needed. In fact, a wave of lines cut on the case would be sufficient to allow air circulation. Going to the back end of the C128D, you will see wires snaking out of the receptacle in which the power cord formerly went through. @(A): Opening the Hood Let's dispense with the visual inspection and actually open the 'hood' of the CMD Nirvana computer! Yes, I know it's not a pretty sight and may look daunting to you, but it can be done! From the top view, it looks like the power supply for the C128D has been moved from its original position 90 degrees counterclockwise. The CMD HD motherboard now occupies the lower left corner of the C128D case. The FD 4000 juts across the lower right corner of the C128D front panel and the C128D case. As you can see, the internal 1571 disk drive has been ripped out. Wires are everywhere, but most of them settle down in the blank area in the upper right corner of the C128D case. @(A): Digging In Ah, where will we start? Let's take a closer look at the plastic front panel of the C128D. The CMD HD front panel was inserted and attached to the plastic front panel of the C128D, and is not attached to the metal case of the C128D. The marriage of the CMD HD front panel and the C128D's plastic front panel was accomplished by four screws and three pieces of plastic. First, I used masking tape to cover the CMD HD's metal case on the front side. This front side already has holes drilled on it by CMD or some OEM manufacturer. I used an X-Acto® knife to cut holes in the masking tape, popping through the holes in the metal case. When finished with the poking of the holes in the masking tape, I have a 'drill image', so I peel off the tape from the CMD HD's metal case, and affix it to the C128D's plastic front panel on the left side. Making sure that everything's aligned, I proceeded to drill holes, following the 'drill image', in the plastic front panel. After peeling off the masking tape, and then doing a test fit with the CMD HD's front panel with its protruding LEDs, and swap buttons, it was a perfect fit! I then made the connection more solid with four screws and pieces of plastic, by attaching the CMD HD's front panel to the left side of the C128D's plastic front panel. Then, I superimposed the sticker overlay for the CMD HD perfectly with the LED's and the push-buttons, and used spray-on glue to make the overlay a permanent part of the C128D's plastic front panel. @(A): Preparing the FD-4000 As for the FD 4000, I used a saw to cut off portions of the plastic front panel of the C128D where the internal 1571 disk enclosure used to be, cut in correct dimensions to fit the FD 4000. It was still rough, so I used a file to smooth the edges, on a gradual basis, until the FD 4000 made a snug fit. I measured the front cavity of the FD 4000 and used those same measurements to make the cut on the C128D's plastic front panel on the right side. As you can see from the picture, there is little room for error, especially at the top of the plastic front panel. Generally, the cut was made as far as to the right side of the C128D's plastic front panel as possible. @(A): Preparing for the CMD Hard Drive Now, to the internals of the C128D. I had to move the power supply counterclockwise 90 degrees to make room for the CMD HD. I quickly ran into a snag, as the power connector between the PCB and the power supply was too short. I had to cut off all the wires on the power connector, then enlarged it by soldering all wiring to a cannibalized wiring from a power supply wire to both ends of the power connectors. For further clarification, a close-up of both ends is supplied. The cannibalized power wiring was very convenient, as they were color marked, and it was easy for me to make sure that the wiring corresponded with each end of the power supply connectors. Next, I spliced the +-12 VDC wires on the power supply connector to supply continuous power to the fan. Usually a fan comes with black and red wires. Splice the black wire of the fan to the black wire of the power supply. Splice the red wire of the fan to the yellow wire of the power supply. Next, the fan was attached to the power supply with screws, to the right of the power cord connector. The structural improvements to the PCB was made by bending the PCB power connector end at a 45 degree angle, for it would collide with the position of the CMD HD's PCB. Last, I connected one end of the entire power supply to the back edge of the C128D's metal case. This was accomplished by bending the end of the power supply at a 90 degree angle and screwing it together to the metal case of the C128D. However, one end of the power supply remained unsupported and would tip over onto the PCB, causing possible malfunctions for the C128D. So, a makeshift support was propped upon the C128D's PCB to support the remaining end of the power supply. This support, like all other supports used, were fitted with black electrical tape at the bottom to prevent shorts on the PCB. The massive heat sink covering the VIC - II chip and the 80 column display chip supported the other end of the power supply. @(A): Installing the HD With the power supply situated 90 degrees counterclockwise, we now have room to insert the PCB for the CMD HD 85 megger. I took the CMD HD's PCB out of its original metallic case that CMD supplied. (NOTE: If you do that, you may void CMD's warranty on the unit.) But the CMD HD's PCB could not just sit atop the C128D's motherboard, for there may be accidental electrical shorts or other problems. So, the CMD HD's PCB just hovered above the C128D's motherboard by approximately 1/4 of an inch. This was accomplished by erecting two support beams above the C128D's motherboard. The beams were obtained at a hardware store. They are aluminum and are easily malleable with pliers. I screwed down one end of the beam to the middle edge of the motherboard, leaving the other end of the beam covered with electrical tape. I could have screwed down the other end, but might have cut the motherboard in a way that Commodore never intended and screwed up the whole thing. All supports listed in this article are screwed down on existing 'drilled holes' in the c128d's PCB. Please note that the support beam is nearly aligned with the motherboard's power connector. I put electrical tape on top of the support beam, as this top will support the CMD HD's PCB. This is to ensure a smooth operation of the unit without any electrical shorts or other problems. Also, look at the rear view of the support beam in the picture, for it can give you a clear idea of how tall it is in relation to the C128D's motherboard. As for the other support beam, it is screwed down on both ends to the C128D's motherboard on the far left side. This support beam is taller than the one explained earlier. The reason is that the CMD HD's PCB will be screwed on that support beam, so this support beam would have to be aligned parallel to the top of the first support beam. Then the second support beam is covered with electrical tape and two holes are drilled at both ends, which align perfectly with the CMD's HD PCB's drilled holes. (See photo for further clarification.) Finally, to attach the CMD HD's PCB to the two support beams, I made sure that both beams were in alignment and supported the PCB in a level fashion, almost parallel to the C128D's motherboard. I attached one end of the CMD HD's PCB, which has no cable connectors, to the second support beam on the far left of the C128D's motherboard. Two screws were used to make a secure connection to the support beam. The other end of the CMD HD's PCB, the one with all the cable connectors, rested on the first support beam, but was not screwed down. It could be done, but as the PCB was already secured, I didn't bother. The cables running out of the CMD HD's PCB are in a tight space, due to the FD 4000. As you may note from the picture, there is no room for the internal 1571. If you decide to do an internal CMD HD operation on your C128D, you must sacrifice your internal 1571 drive. @(A): Installing the FD With the CMD HD PCB out of the way, I began work on the FD 4000. Before the FD 4000 was inserted, I cut off pin one of the C128D's chip U113. This pin gives a signal that the internal 1571 drive is in existence. With that pin cut, the C128D no longer recognizes the existence of the internal 1571 drive. It will, however, recognize any peripherals using the serial bus, as I use a external 1571 as Drive #8 in my system. I took the FD 4000 mechanism and the motherboard (it's built as a single unit) out of its original case that CMD supplied. (NOTE: Doing so may void CMD's warranty on the FD x000 unit.) I used trial and error to position the FD 4000 drive in the C128D's metal casing. This is to ensure that the FD 4000 would not protrude too far out of the C128D's plastic front panel, or intrude too far inside the C128D's plastic front panel. As you can see from the following picture, the FD 4000 unit protrudes from the C128D's metal case by approximately 1 1/2 inches. Lastly, I attached a support beam to the bottom right in front of the C128D's metal case. This involved some cutting on the edge of the bottom of the C128D's metal case in order to make the FD 4000 fit the C128D's metal case. The bottom edge of the C128D's metal case was not cut out completely, rather, it was bent inwards with pliers, creating a small surface for the FD 4000 to rest upon. Again, trial and error was used to determine how much to cut and bend the bottom edge, so that the FD 4000 unit would fit the C128D's metal case and the plastic front panel. Finally, the FD 4000 unit was screwed upon the support beam. This FD 4000 also rests upon the bent in bottom edge. This creates a stable surface for the FD 4000 unit to operate without having to insert a second support beam onto the C128D's motherboard to support the other edge of the FD 4000 unit. Finally, I connected the cables to the CMD HD's PCB and the FD 4000, and attached the ribbon cables to the CMD HD's PCB, including that of the hard disk drive and the front panel controls. I extended the length of the power-on LED wire for the C128D's power supply. This extension was made by adding more wire and resoldering the connections. This was necessitated because the 90 degree turn of the power supply made all the wiring too short. :( Ah, the wisdom of CBM to cut costs by making everything short and sweet! I made sure that the CMD HD and the FD 4000's on/off switches were already in the ON position. Last, I bought Velcro® from an art supply store, and liberally applied it to the CMD HD 85 MB drive mechanism. The opposite end of the Velcro® attachment was pasted on the inside of the top metallic case of the C128D. This was positioned roughly 3 inches from the front edge of the top metallic case. Trial and error was used here to determine the optimum measurements. The CMD HD 85 mechanism was then attached to the inside of the top metallic case of the C128D unit by Velcro®. This is a safe method, for the CMD HD has been running for almost a year without any glitches. Close the case carefully (The HD is on the case, after all!), and attach all the power to a power control center with individual switches. The individual switches then can be used to control a specific peripheral such as the internal FD 4000 or the CMD HD 85, without having to open the unit to access the off/on switches, or drilling holes in the case of the C128D to attach these same switches. Convenient, isn’t it? @(A): Lessons Learned Before concluding the article, it seems possible that one could put a 1581 drive in lieu of the FD x000 drives. It's possible, but I do not own a 1581, so I really cannot comment. I would guess that the general guidelines for the FD x000 drives would apply to the 1581. Granted, all of this looks quick and dirty. But when I first started out with this project with Al Anger, we didn't have step-by-step manuals, or other references. It was truly a new territory for me. (Al has already done such hacks for his C= computers before me, and his experience was invaluable.) However, there were some bloopers. One, the c128d died upon powering up. It turned out that the fan +- 12 VDC wiring was connected to the wrong wire, and shut down the system. With that fixed, the c128d powered up okay, but now, the CMD HD died. If that wasn't frustrating enough, it was difficult to find out what went wrong, and I was wondering if the FD 4000 would be next. The culprit was a break on the CMD HD PCB. I accidentally drilled a cut on the PCB. With some soldering, I fixed it by building a bridge between the break in the CMD HD PCB. Whew! Everything now worked, and has worked since. Consider those bloopers invaluable lessons learned in dealing with sensitive electronic circuitry. @(A): Conclusion These are just general guidelines and are meant for entertainment purposes only. It serves as an inspiration to those who always dreamed of building their own C= beasts. I'm sure that there are countless users that have customized their computers, and with these general guidelines, undoubtedly, some users will want to create such a monster with rich C= 8 bit computing power! @(A): Postscript For those Commodore users who do not have access to graphical browsers, you can contact the author for a Word v7.0 document printout with pictures. The cost is $3 dollars for people living in the U.S. Canadian readers will have to pay slightly more in U.S. dollars. ========================================================================= @(#)surf: Hack Surfing For those who can access that great expanse of area called the World Wide Web, here are some new places to visit that are of interest to the Commodore community. In early 1994, when the US Commodore WWW Site started, the number of sites online that catered to Commodore numbered in the 10's. Now, the number is in the 100's. What a change. If you know of a site that is not listed here, please feel free to send it to the magazine. The following links have been gleaned from those recently changed or added to _CaBooM! - Your One Stop Commodore Links Site_. (http://www.msen.com/~brain/cbmlinks/). To encourage these sites to strive to continually enhance their creations, and because we like to gripe :-), we'll point out improvements that could be made at each site. @(A): Companies o Centsible Software URL: http://home.sprynet.com/sprynet/cents/ Centsible Software has been a common name in Used Software Distribution for a while now. their WWW Site contains catalogs for the different platforms they support. C=Hacking gripe: Although the site is very informative and works well for either text or graphical browsers, it is rather plain. A bit of text here and some judicious use of HTML 1.0 tags would spice it up immensely. Text Browser compatibility shouldn't force WWW sites to be dull. o Arkanix Labs, Inc. URL: http://www.arkanixlabs.com/ Arkanix Labs recently purchased Threshold Productions International in order to expand their presence in the Commodore Market. They have a stocked WWW Site, complete with a catalog and recent news press releases. C=H gripe: For the graphical set, the site is heavy on graphics, although it does offer text link alternatives. o Herne Data Systems, Inc. URL: http://ourworld.compuserve.com/homepages/herne_data/cpm.htm In the 1980's, HDS created some utilities for the C128's CP/M mode. Jugg'ler 128 allowed the CP/M user to read over 140 different disk formats, while Scramb'ler 128 encrypted files and disks. Although HDS doesn't support these products anymore, they do provide them and numerous reference works on their WWW Site. C=H gripe: text based browsers might not handle the HTML TABLE very well. @(A): Demo Groups o Demolition URL: http://www.cei.net/~rreed/ As the Webmaster puts it, " Demolition is currently more of a concept than anything." Demolition is slated to become a disk based demo programming resource magazine. However, at present, the site contains a few articles on topics like boolean logic and VIC internals. In addition, the site contains a comprehensive bibliography of basic and demo related programming articles. C=H gripe: The bibliography is on the main page, making it a lengthy piece of text. @(A): Reference Works o The Commodore Web Ring URL: http://www.ncf.carleton.ca/~ag090/HomePage.ringpage.html Although not a WWW site per se, this site starts you off on a journey through various Commodore WWW sites. It's entertaining and will undoubtedly take you somewhere you wouldn't have been before. C=H gripe: Graphical surfers might find the large "buttons" annoying. o Info and Files for Commodore GEOS URL: http://www.radiks.net/irv_cobb/geos2.html This, a sub page under Irv Cobb's home page, offers various GEOS utilities that were either programmed by Irv or that he finds useful. GEOS users should bookmark this page. C=H gripe: As above. A bit of HTML 1.0 would spice this page right up. o The History of Commodore URL: http://www.geocities.com/SiliconValley/Heights/8329/History.html A sub page of "The Commodore Haven", this sites gives the low-down on Commodore, from its inception to its demise. C=H gripe: well done page. o Commodore Pictures URL: http://www.swt.edu/~ez13942/commie/cbmpics.htm Although the author of the page is not mentioned, he takes us on a tour of his various Commodore computer systems. It's always interesting to see how folks use their machine. C=H gripe: The graphics and the captions are all on one page, which makes the page a bit lengthy. o The KIM-1 page URL: http://www.magic.ca/~yhpun/ianpun.html For anyone who doesn't know what a KIM is or how it relates to Commodore, this page is for you. Featuring pictures and explanations of both the KIM-1 and the author's home-made expansion board, this site offers a glimpse of the life of the 6502 pre-CBM. C=H gripe: The KIM-1 stuff is on the same page as the author's personal and business information. o CBMSearch - a search engine for searching Commodore related software. URL: http://www.ts.umu.se/~yak/cccc/cbmsearch/ Bookmark this site. Now. Offering a concise way to find Commodore software quickly and easily, CBMSearch can relieve the headache of trying to find CBM titles on the Internet. C=H gripe: Can't really say there is a gripe. The page is concise and could be spruced up a bit, but in this case, function overrules form. @(A): User Groups o Bronx User's Group (BUG) URL: http://www.mediaworks.com/bug/ As Commodore Authorized User Group #0065, BUG's WWW site contains links to mail each of the officers and some links to other sites. A phone number is given for information. C=H gripe: The site's a bit low on content. We applaud the presence, but a map or some info about the group would be nice. o Stone Mountain User's Group - Contains information on when and where we meet. URL: http://www.cris.com/~Derektp/ Although supporting all orphaned computer systems, SMUG (love the acronym) appears to focus on the CBM systems and contains information on meeting places and times. C=H gripe: As above, the content is a bit low, but at least directions and times are given. o ICPUG Independent Commodore Products User Group URL: http://www.icpug.org.uk/ Although not devoted exclusively to the CBM 8-bit line, ICPUG does support them. A wealth of information, including the ability to join and club news is available. C=H gripe: For the graphical set, the site is a bit heavy on graphics. (For these sites, viewing with Lynx offers faster response.) @(A): Individual Commodore Users o Commie web page -- Better red than IBM URL: http://www.swt.edu/~ez13942/commie/ Bo Zimmerman titles his page this peculiar way. He offers some history on his use of Commodore systems and offers some pictures of his various equipment. He also presents the Commodore Pictures page, detailed above. C=H gripe: the background makes for hard reading on some graphical browsers. o Don's Page URL: http://people.delphi.com/novan/ In an effort to offer people with text browsers some picture content, Don has included ASCII art in his page. We are impressed. Basically, the site details Don's hobbies and how the Commodore fits in. C=H gripe: We really think the ASCII is great, but there's no reason to make all the text in the document mono-spaced. o Dave's Commodore 64 page URL: http://www.csun.edu/~hbbuse08/c64.html This page is for those looking for game information, SID tunes, and emulators. (Note: some of the files on this site are copyrighted.) C=H gripe: The top says "This page looks best when viewed with Microsoft's Internet Explorer or Netscape!" o John Elliott's Home Page URL: http://www.nsis.com/~prof/ John has a very extensive site detailing computers in education, including a piece on using "obsolete computers" in the classroom. A number of pieces available on the site include education conference highlights, and a discussion of how he finally hooked up to the Internet. The site is best viewed with Lynx, as it is enhanced for Lynx! (that's a switch) C=H gripe: The layout of the pages seems a bit haphazard, but maybe it's just us. o Irv Cobb's home page URL: http://www.radiks.net/irv_cobb/ If you want to know about Irv or where he grew up, it's all here. Hyperlinks are spread throughout the text to direct you to different topics. C=H gripe: none. Although it isn't as "splashy" as some pages, it is laid out well, and looks fine, although simplistic, on a graphical browser. o Commodore 64 Online URL: http://www.geocities.com/SiliconValley/Park/4645/ Tim Plelp's site is brimming with links to his favorite utilities and applications. Also included is a comprehensive list of PD/Shareware titles. C=H gripe: use unordered lists instead of "*" for the various items. o Commodore Connection URL: http://www.gis.net/~sunfish/crcbm.html Geoff Sullivan's personal site offers articles and software to make using a C64 or 128 more enjoyable. Besides links to other sites, he also offers up Perfect Print fonts and articles on how to expand your REU to 2MB and how to build a simple RS-232 converter. Of special interest is a collection of customized GEOS mouse pointer icons and a program called QWIKSTASH that will copy files in GEOS on bootup. C=H gripe: Great resource, but little information about Geoff and how he uses his CBM. ========================================================================= @(#)jb: Jim Butterfield: The Commodore Guru - An Interview by Jim Lawless (jimbos@radiks.net) @(A): Introduction My initial interest in the Commodore 64 computer began in 1983. At the time, my primary source of information pertaining to the C64 came from Compute! and Compute!'s Gazette publications. One author's name stood from the rest; Jim Butterfield. I used to turn to Jim's articles immediately when I managed to get my hands on a new magazine. Mr. Butterfield has the rare ability to describe complex subjects in simple terms. I'm certain that I'm not alone when I credit Jim with having taught me a lot about the inner workings of the Commodore 64. As important as the specifics of writing code for the C64 was Jim's style. He would often write code that was readily portable to multiple CBM machines. His code had longevity and purpose. The solidity of his programs left me with a lasting impression pertaining to how software should be developed. The following interview with Jim was conducted via e-mail. Q: What was the first programming language that you learned? A: In about 1963, an assembly language called COGENT for a computer that few people have ever heard of: a Collins Radio C-8401. That was shortly followed by work on an IBM 1401, which had a machine language that was alphanumeric. (Honest! You could keypunch M/L directly!) Q: Were numbers expressed in Base-36? A: No. Decimal. The basic machine had 1000 bytes (not 1K) of (7-bit) memory (core, not RAM!) so addresses ranged from 000 to 999 (and were given in decimal, of course). Expanded machines had 4K, then 16K ... the addresses were slightly more complex in that case. Thus, to move bytes from an area at, say address 123 to address 456 the instruction would be M123456. I AM NOT MAKING THIS UP!!!! Q: Did you guys have contests to spell out goofy words as part of a program? (I know of a programmer who used to regularly use the return code $0BAD to indicate a problem...) A: No (the addresses mixed in with the op codes ruled that out), but you could do fun things on a 1401 if the system manager wasn't looking .. such as play music. Q: What was the first computer that you owned? A: Not counting the TUTAC-1, which was powered by rubber bands and was more correctly a logic machine: The KIM-1, a single-board microcomputer made by MOS Technologies, Inc., of Norristown PA. MOS Technologies was subsequently acquired by Commodore. Q: When did you first encounter a Commodore computer? A: When Commodore acquired MOS Technologies, the computer that I had owned for over a year became a Commodore computer. Subsequently, an employee of MOS Technologies, Chuck Peddle, convinced Jack Tramiel of Commodore that they should launch a personal computer called "The PET". I got one of those not long after they started production. Q: Did you have formal training in computer programming? A: Yes, on that long-ago Collins C-8401. But this was more a process- control machine; it didn't use of any the newfangled (at the time) languages such as Fortran and Cobol. So my training was in machine language/assembler. Q: What was the first book that you wrote? A: A couple of enthusiasts and I collaborated on a volume called "The First Book of KIM", a book describing how to do things with the KIM-1 single board computer. That computer was powered by a 6502,by the way; in fact the KIM-1 board itself was designed as a engineering prototype for people who wanted to try out the chip. Q: Was it similar to the Altair where you had to manually increment an address-counter before you could throw the switches to set the byte at that address? A: No, the KIM-1 had an operating system in ROM. That's one of the things that made all KIM users "equal" and able to share programs, while the other early micro owners had quite a scattering of stuff. Q: What COULD you do with a KIM-1? A: Hey, watch it! That's like saying, "What could you do with a Commodore 64"? Although the KIM-1 came with a hexadecimal keypad rather than a keyboard, and output to a six-digit LED display, you could use those to good advantage AND hook up extra stuff. Play music? Play Blackjack? Hunt the Wumpus? Skeet shoot? Unless you had the budget for a printer, you'd have a hard time doing an accounts receivable, of course. But this is the 6502 we're talking about! And we all know it can do ANYTHING! Q: What was the last book that you wrote? A: It's probably the revised version of "Machine Language For the Commodore 64, 128, and Other Commodore Computers". In 1985 and 1986, however, I did produce a "pocket diary" reference guide for Commodore 8- bit computers. Q: Have you ever written articles or books on subjects that are not computer-related? A: My first writing experience was a treatise on transistor theory, published by Popular Electronics in August of 1959. Not much else. Q: Did you write commercial software for any of the Commodore computers? A: As a general rule, no. All my stuff is public domain. At one time, I had written a simple spell-checking engine that was incorporated into a word processing package for a while. Q: SuperMon was a tool that I used daily when developing ML routines or exploring the C64. What prompted you to write SuperMon? A: In the early days of Commodore personal computers, there were quite a few machine language monitors around. They were partly based on some publicly published code by Steve Wozniak (of Apple!), and partly based on the MOS Technology TIM monitor, from KIM-1 days. Two variants of the basic monitor caught my eye: NewMon, which added several useful features to the basic Machine Language Monitor; and HiMon, which sited the monitor in upper memory where it wouldn't conflict with BASIC programs. I decided to put the two together and generate a self-relocating MLM. That was desirable in early PET/CBM days, where some computers would come with 8K RAM, some with 16K, and others with 32K; you couldn't assume where the top of memory would be. In those days, almost every Commodore computer came with a small built- in MLM, and the first Supermon was an add-on. Later, as Commodore changed the style of the MLM packages they built into newer machines such as the 128, I went back and modified those earlier versions so that they would work the same across all platforms. Q: Did you ever expand the mini-assembler in SuperMon into a full-blown assembler development package? A: No. I hustled Brad Templeton into writing PAL, so that there would be an assembler available for those who needed it. There had been a few assemblers around before that - Commodore had one, and another was the MAE system - but I was sure that somebody like Brad could do better. Q: Even Superman had to put up with Kryptonite. Describe your worst experience as a software developer / technical writer. A: My first publication of SuperMon in Compute! magazine had the wrong end-of-address supplied (my fault). I got a LOT of mail and phone calls on that one. Q: I had heard a rumor pertaining to your software development habits that indicated you would approach a given project with full force. You would focus your undivided attention on it until it was complete. Is this rumor accurate? A: Possibly. If I have a project under way, it "follows me around" until it's complete; I fret over it and can't put it away until all the pieces are in place. Q: If so, did you ever change this methodology? A: Not to any great extent. A half-written program bugs me, and I won't rest until it's finished. I might, however, decide that I'm taking the wrong track, and scrap a program completely in order to start over. This isn't a loss: the first attempt can show you what's really wanted. Q: Your articles made you seem a bit omniscient. You always had the inside info on the newest CBM computers and always seemed to be able to explain their complexities in a manner that would suggest that you had a lot of time to study them. I don't know a whole lot about your employment during the mid/late 80's. Were you affiliated with CBM? A beta-tester? A: I had many friends in Commodore Canada, but I never worked for the company, although I did contract work for them on occasion. The big problem was not getting information from Commodore; it was learning to ignore most of it. Commodore was bubbling over with ideas and plans that never came to fruition. There was no point in writing about projects that never happened (the Commodore music box? the cash register? the videotape/disk storage device?). I took the position: "Don't tell me about it until it's a real product!". Commodore Canada was an excellent source of information, and I relied on them to keep me from straying too far into technical speculation. Q: Did you use any high-level languages on CBM computers? A: BASIC, of course. COMAL, a BASIC derivative language from Denmark, was nicely constructed. Played around a little with C, but that language doesn't fit comfortably into an 8-bit environment. Q: What was your favorite computer that CBM produced? A: I don't know that I have a single favorite. The early PET/CBM machines were great "discovery" platforms, where we could investigate these wonderful new computers. The advent of the VIC-20 and the Commodore 64 brought color and sound, which added to the charm of these home computers; but they paid a penalty in slow disk access and screen width limitations. Today, perhaps the Commodore 128 ranks as the best, or at least the computer with most general usability. But it wasn't produced in quantities as great as some of the earlier machines, and so the user community hasn't been quite as furious. Q: What kind of home computer do you currently use? A: C128 .. Amiga .. Pentium system. All three. Q: Who were your influences as related to writing? A: Nobody specific. Just tried to write it as I would say it. Q: Who were your influences as related to programming? A: I've worked with a lot of sharp programmers over the years. Not one I can pick out especially. Q: If you could relive the CBM glory years, would you do anything differently? A: I don't think so. On another path, I could have gone for big bucks; but making money carries a responsibility to support and service, and that would have taken the fun out of it. Q: Is your current job computer-related? A: I'm currently more or less retired. Q: If you had not chosen a career in computing, what field of endeavor would you most likely have pursued? A: Before computers, I worked in electronics and telecommunications. Q: What are your current hobbies? A: Reading; travel; films; raising my daughter. (That's a hobby???) Q: What sort of technical literature do you currently read? A: Mostly reference material. Current magazines are heavy on the "what's for sale" stream; to my mind, that's not the fun part of computing. Q: Are you surprised that a sort of "CBM renaissance" has been taking place the last few years ( ...availability of C64 emulators on multiple platforms and such...the SuperCPU from CMD...). A: It's a shame that Commodore wasn't able to/interested in keeping the 8-bit line going. It's good to see that is happening. Surprised? A little. But enthusiasts and user groups have always had a stronger effect than manufacturers are willing to admit. Q: What is your opinion on the way consumer computing has evolved since the inception of the early PET machines? A: The average computer user today has a lot less fun than we still have with the early machines. The industry message today is "Buy it and use it, and then turn it off .. don't worry or think about how it all works". That's sure a lot less fun for tinkerers. Q: What words of wisdom would you care to impart on a new (or revitalized) generation of CBM hackers? A: Enjoy what you're doing! If it becomes drudgery, you're doing it wrong! ========================================================================= @(#)trivia: Commodore Trivia by Jim Brain (j.brain@ieee.org) @(A): Introduction As some may know, these questions are part of a contest held each month on the Internet, in which the winner receives a donated prize. I encourage those who can received the newest editions of trivia to enter the contest. This article contains the questions and answers for trivia editions #29-32, with questions for edition #33. If you wish, you can subscribe to the trivia mailing list and receive the newest editions of the trivia via Internet email. To add your name to the list, please mail a message: To: brain@mail.msen.com Subject: MAILSERV Body: subscribe trivia Firstname Lastname help quit @(A): Trivia Questions and Answers This edition should be sub-titled "Programmer's Trivia". Q $1C0) What are the two configurations for the LORAM, HIRAM, GAME, and EXROM pins that will allow the use of a full 64kB of RAM in the C64? A $1C0) There are actually 4 configurations, in two categories: LORAM 0 0 (X means either 1 or 0) HIRAM 0 0 GAME 1 X EXROM X 0 Q $1C1) What is the first thing that the C64 (and VIC) KERNAL does upon powerup? A $1C1) The first thing each does is reset the stack pointer to $ff. Q $1C2) What KERNAL routine is used to set a DOS channel to input? A $1C2) CHKIN ($ffc6) Q $1C3) What KERNAL routine is used to set a DOS channel to output? A $1C3) CHKOUT ($ffc9) Q $1C4) Before calling the routines in $1C2 and $1C3, what register must you load? A $1C4) You must load .X with the logical file number. Q $1C5) What 3 devices can the KERNAL NOT load from? A $1C5) keyboard (0), RS-232 (2), or screen (3). The first and last are somewhat obvious, but allowing RS-232 loads would have made loading from a remote machine possible. Incidentally, you can't save to any of these devices, either. Q $1C6) In the Commodore KERNAL, there are "high" and "low" level routines. To which class of routines does "SECOND" belong? A $1C6) low. It is used to specify the secondary address, as the '7' in open 4,4,7. Q $1C7) If a programmer calls the KERNAL routine "STOP" and the RUN/STOP key is NOT pressed, what is returned in the .A register? A $1C7) .A will contain a byte representing the last row of the keyboard scan. Q $1C8) The Commodore KERNAL routines are all accessed via a jump table. What routine is used to change the values in the KERNAL jump table? A $1C8) The appropriately named VECTOR ($ff8d) call, which few programmers actually use. Q $1C9) A call is made to a KERNAL routine, the call returns with the C bit set and the .A register holds $02. What error does this indicate? A $1C9) "File already open" Q $1CA) If a call to READST is made, and a $40 is returned in .A, what does this indicate? A $1CA) End of File. Q $1CB) What routine can be called to determine the physical format of the Commodore 64 screen in characters? A $1CB) The also appropriately named SCREEN ($ffed) call. Q $1CC) The Commodore 64 starts a non-destructive RAM test at what location? A $1CC) $0300. Q $1CD) Which way does the RAM test proceed: up or down? A $1CD) up. Q $1CE) Which KERNAL routine is used ONLY in conjunction with a Commodore IEEE card? A $1CE) SETTMO ($ffa2), which sets the IEEE bus card timeout flag. I infer that Commodore thought many people would use the IEEE interface. (Anyone know any more about this?) Q $1CF) Many hybrid BASIC/ML programs use SYS to transfer control from BASIC to ML. However, a few use USR(X). When using the latter function, where does BASIC fetch the ML routine's starting address from? A $1CF) 785 and 786, in classic LO:HI format. The "BASIC" Trivia Set Q $1D0) To load a program from the current location on a cassette tape, what two key combination must a user press on a VIC-20 or C64. A $1D0) SHIFT and the RUN/STOP key. Note that the same key sequence loads a file from disk on the SX-64 or C128 in 128 mode. Q $1D1) If I issue the BASIC statement OPEN "JIM,S,W", What type of file am I opening? A $1D1) A sequential file. Q $1D2) Is BASIC in the Commodore computer systems an "interpreted" or "compiled" language A $1D2) interpreted. When a program has been "Blitzed!", it is then compiled. Q $1D3) What type of variable is A%? A $1D3) An integer variable. Q $1D4) If I issue the BASIC line PRINT:PRINT "A","B" what column does the "B" show up on when run on a C64? A $1D4) Column 11, if we number columns from 1. Q $1D5) What column does "B" show up on if I run the BASIC line in $1D4 on a VIC-20? A $1D5) Column 12. Since the VIC has 22 columns, the natural column spacing was 11 positions, instead of 10 on 40 and 80 column CBMs. Q $1D6) Alphebetically, what is the first BASIC 2.0 command to have a 3 letter abbreviation? A $1D6) CLOSE. Q $1D7) How many times does the statement FOR T=1TO0 execute? A $1D7) once. A BASIC for loop always executes at least once. This is different from languages like 'C', which would not execute the loop at all. Feature or bug, who knows... Q $1D8) What base does the BASIC LOG command use for its logarithm function? A $1D8) base e. (2.7....) (one of the entrants claims that "e" in the 64 isn't quite as accurate as we think. He was quoting 2.85.... Q $1D9) A = NOT B can be written as which expression: a) A = -B b) A = -(B+1) A $1D9) b. NOT computes the twos-complement of the number, not the simple ones-complement negation. This feature simpleifies subtraction in a CPU, since subtractions can be performed as additions. Q $1DA) What does INT(-15.43) return? A $1DA) -16. INT returns the next LOWER integer. Q $1DB) What does ASC$("JIM") return? A $1DB) ASC$ returns an error. That's what I get for writing these late at night. What I menat was "ASC", returns the value of the first character of a string, in this case 'J'. Since I didn't specify if this was a uppercase 'j' or lowercase 'J' in graphics mode, the result could either be 74 or 202. Q $1DC) What is the abbreviation for GET#? A $1DC) Technically, there is none. However, on the C128 at least, GET# shares the same token as GET, so typing gE# will indeed work. This is different from PRINT and PRINT#, which have different tokens. Q $1DD) What is the largest integer value that Commodore BASIC can handle? A $1DD) Again, this was a little ambiguous. I was looking for the maximum value that an integer variable can hold, which is 32767, but line numbers (which are integers) can be up to 63999. Q $1DE) What is the ONLY Commodore Editor key not affected by "quote mode" A $1DE) The DEL key. I would have answered return, but the 64 PRG spells it out that only this key is unaffected. Q $1DF) What is the range of RND? A $1DF) 0.0 <= RND < 1.0, or [0,1). Both mean that the range is from 0 to 1, including 0, but not 1.0. The "VIC Chip" Trivia Set Q $1E0) We all know that VIC stands for Video Interface Chip. However, in what computer was a VIC chip first used? A $1E0) The VIC-I was used in the VIC-20. Q $1E1) What is the difference between the 6566 and 6567 VIC chips? A $1E1) The 6566 has fully decoded address lines. The '67 has multiplexed address lines for connection to DRAM. Q $1E2) On what computer would one find a VIC-II chip? A $1E2) C64, C64C, 64SX. Q $1E3) On what computer would one find a VIC-IIe chip? A $1E3) C128, C128D Q $1E4) On what computer would one find a VIC-III chip? A $1E4) C65 (64DX) Q $1E5) Versions of each VIC chip exist for each computer model/video standard combinations suppoerted by Commodore. What model/video standard would the 6569 work with? A $1E5) C64 type machine using the PAL-B standard. Note that there are also PAL-N and PAL-M standards, which required different VIC-II models. Q $1E6) How much memory could be directly addressed by a VIC-II chip? A $1E6) 16 kilobytes. Q $1E7) How many control registers does the VIC-I contain? A $1E7) 16 control registers. Q $1E8) How many control registers does the VIC-II contain? A $1E8) 47 control registers. Q $1E9) The VIC-II series introduced Movable Object Blocks to the Commodore programmer. By what common name are MOBs known? A $1E9) "sprites" Q $1EA) What are the dimensions of a MOB? A $1EA) 24 dots wide by 21 tall. Q $1EB) What difference between the VIC-I and VIC-II causes VIC-II equipped systems to potentially operate slightly slower than VIC-I equipped systems, all other items held constant? A $1EB) Even with all of the fancy features of the VIC-II (like sprites) turned off, the VIC-II doesn't have quite enough time to do all of its work, which includes refreshing the DRAM ICs in addition to the work of drawing the screen and reading the Paddle inputs. So, every 8th rasterline, the VIC has to "steal cycles" from the CPU to fetch character data from RAM. Since this time is not available to the CPU to execute programs, a simple program written on each machine will execute faster on the VIC because its CPU doesn't have to fight the video IC for cycles. Q $1EC) In addition to supporting graphical output to an external display, what other vitally important function do the VIC chips (starting with the VIC-II) perform? A $1EC) They refresh the Dynamic RAM of the computer periodically. If the DRAM is not refreshed, it would lose its contents. Q $1ED) Many people know that the VIC-II can deliver up to 320x200 resolution without much trouble. What is the maximum resolution of the VIC-III chip? A $1ED) According to the specifications, it is supposed to handle 1280H by 400V interlaced and non-interlaced. Q $1EE) Between the development of the VIC-II and the VIC-IIe, there was a related, though not very similar video IC developed for CBM machines. Name its TLA (three letter acronym). A $1EE) TED (Text Editting Device). It was developed for the 264 series (Plus/4, C16). Q $1EF) How many pins does a VIC-II chip contain? A $1EF) Every VIC-II has 40 pins. The "BASIC Tokens" Trivia Set The following questions refer to the way Commodore "crunched" BASIC programs by substituting one of more bytes called "tokens" for BASIC keywords in a BASIC program. The resulting code was smaller, since multiple character keywords were internally replaced with smaller length tokens. (All the answers were taken from _Commodore Magazine_, April 1987, pp 82-85.) Q $1F0) Commodore BASIC tokens start at what number? A $1F0) $80, or 128. Q $1F1) BASIC 2.0 defines tokens without gaps up to $ca. What keyword is represented by $cb? A $1F1) GO. Q $1F2) Why is the token for PI strange? A $1F2) It is token $ff, or 255. Q $1F3) All versions of Commodore BASIC contain at least a subset of tokens. At what number does this subset end? A $1F3) $ca. Q $1F4) BASIC 4.0 defines tokens beyond $cb. What is the last token included in BASIC 4.0? A $1F4) $da. Q $1F5) There was a BASIC 4.0+ included in the B series. It extends the BASIC with some new commands not in 4.0. What token range are these new commands at? A $1F5) $db-$e8. Q $1F6) When a user plugs a Super Expander into a Commodore 64, he or she gains access to 25 new BASIC commands. The tokens for these commands are defined differently from the previous tokens. What is the difference? A $1F6) They are two byte tokens of the form: $fe XX, where XX ranges from $80 to $9e. Q $1F7) When the Plus/4 and C-16 was developed, new commands were added to BASIC. In addition, many commands from BASIC 4.0 were also included. Unfortunately, the tokens for BASIC 4.0 commands included in these new machines differed from those in the older BASIC 4.0. If a user lists a program written in BASIC 4.0 on a Plus/4, what will the BASIC 4.0 CONCAT command show up as? A $1F7) CONCAT is $cc in BASIC 4.0, and is RGR in BASIC 3.5. Q $1F8) What is the last token used in the Plus/4 line? A $1F8) $fd. Q $1F9) If you list a program written on the Plus/4 with the keyword SCALE on a BASIC 4.0/4.0+ machine, what happens? A $1F9) SCALE on BASIC 3.5 is token $e9, which is not in the BASIC 4.0(+) list. The PET will crash. Interstingly, tokens above $e9 do not crash the PET. Q $1FA) When the C128 was released, it shared many tokens with the Plus/4. However, at $ce, the 128 differs from the Plus/4. The Plus/4 token $ce corresponds to RLUM, but the C128 uses the token another way. What is peculiar about the C128 usage? A $1FA) The C128 uses $ce as a prefix byte for a range of two-byte tokens that range from $02 to $0a. Q $1FB) The C128 shares many keywords with the Super Expander cartridge for the C64. As with the Plus/4, though, keywords don't map to the same token. To what token does the C128 keyword SPRITE (token: $fe $07) correspond to on the Super Expander equipped 64? A $1FB) $fe $93. Q $1FC) What keyword was not included in BASIC v1, but was included in BASIC v2? A $1FC) GO, token $cb. Q $1FD) The C128 defines all the tokens from $fe $02 to $fe $26, with the exception of two tokens. Name one of them. A $1FD) $fe $20 and $fe $22. Q $1FE) The Plus/4 line had the ability to add keywords dynamically when running cartridges. At what point in the token list do these "added" keywords show up in the Plus/4 line? A $1FE) They use $fe as a prefix byte for two-byte tokens. Q $1FF) If a programmer want to write a single program to run on a B128, a plus/4, and a C128, what version of BASIC is the lowest common denominator? A $1FF) Unfortunately, BASIC 2.0 is it. The C128 Set: Q $200) How many general purpose central processin units does a C128 contain? Q $201) The Commodore 128 contains a MMU IC. What does MMU stand for? Q $202) What Commodore produced cartridge is specifically mentioned in the 128 PRG as being incompatible with the 128? Q $203) The C128 introduces the concepts of "banks" How many such banks are recognized by the C128 BASIC? Q $204) What version is the BASIC included in the C128 in native mode? Q $205) Can any of the BASIC graphics commands be used on the 80 column screen? Q $206) How many high-level graphics commands are available on the C128 in C128 mode? Q $207) In C128 mode, at what location does screen memory start? Q $208) The 80 column IC in the 128 can display how many full character sets of 256 characters each at one time? Q $209) Many have scorned the C128's 80 column video IC. What about this IC makes it so hard to use? Q $20A) What number is the 80 column IC referenced by? Q $20B) What machine language addressing modes cannot be used with the 80 column chip? Q $20C) The C128 contains keyboard keys not present on the C64. What IC is used to read these keys? (besides the CIA, as on the 64) Q $20D) Following the introduction of the C128, a new version of was developed. Name it. Q $20E) Many people refer to C128s as 16k or 64k units. To what does this refer? Q $20F) According to the C128 literature, the C128 can be expanded to use how much memory? ========================================================================= @(#)basic: Hacking BASICs by R. T. Cunningham (wanderer_rtc@usa.pipeline.com) @(A): Introducation Although BASIC is not an "advanced" language, such as Assembly or C, it's been used far more often than any other since the first Commodore computer was introduced. It is not my intent to provide information here that is widely available in user manuals, newsletters, or other forums. What I am going to present is what I have learned from "The School of Hard Knocks" or, in other words, by trial and error. @(A): Detecting Drives Connected If your program attempts to access a device number that is not connected to computer in the serial chain, like fetching a directory, your program will halt with "?device not present error in (line number)". How do we prevent this from happening? The answer is to open the device number, close the device number, and check the status variable: open15,10,15:close15:ifst<>0then (act on device not being present) Any number returned by the status variable other than 0 will indicate that the device is either not connected or not turned on. In my own programs, I like to do this check for all of the drives early in the program by stashing the device numbers in an array. Legal device numbers for disk drives are 8 to 30, with 30 being used as configuration mode for a CMD drive. Since I know of no other drive that can use device #30, I won't include that device number in the loop. The array should be dimensioned to at least 21. I prefer 22 and to use the first variable (0) to hold the number of devices. I keep the "start up" device number in a non-array variable so that I can return to it after the drive checking routine has been completed: 10 dimdv(22):dv(0)=0:rem set number of devices to 0 20 dv=peek(186):rem current device # of last drive accessed 30 ifdv<8thendv=8:rem prevents non-disk device #s 40 fora=1to22:rem device #s 8-29 minus 7 so that array starts at 1 50 open15,a+7,15:close15 60 ifst<>thendv(0)=dv(0)+1:dv(dv(0))=a+7:rem increment number of devices and store device numbers 70 next If I have device number 8, 10, 12 and 14 connected, dv(0) will now contain 4, dv(1) through dv(4) will contain those device numbers. You can now use this array to check for a valid device number prior to an access command: 100 rem d equals the device number selected in this example 110 fl=0:rem set flag to 0 120 fora=1todv(0):rem check total number of drives attached 130 ifd=(dv(a))thenfl=1:rem set flag to 1 if a match is found 140 next 150 rem continue with drive access only if flag is set to 1 @(A): Selective GOTO (GO TO) Routine: When acting on a number the ON/GOTO command set works by either using a numeric variable or the value of a string, if the string contains a number: 10 onagoto100,200,300,400 or 10 onval(a$)goto100,200,300,400 What if we want to use a non-numeric character with ON/GOTO, especially with a list of choices presented to the user? In the C128's native mode the INSTR function can be used: 10 rem keys accessible by user are A,B,C,D and stored in a$ response 20 oninstr("ABCD",a$)goto100,200,300,400 or 20 a=instr("ABCD",a$):onagoto100,200,300,400 On the 64, since INSTR is not an available function, we can emulate the function with a different routine: 20 on-1*(a$="A")-2*(a$="B")-3*(a$="C")-3*(a$="D")goto100,200,300,400 or 20 a=-1*(a$="A")-2*(a$="B")-3*(a$="C")-3*(a$="D"):onagoto100,200,300,400 Note that the first 1* is not necessary but the - is. I've added it for clarity only. In the first example, INSTR returns the place number (sequence) of each character in the string. In the second example, the place number is obtained by multiplying the negative sequence number by the signed value of a$. The signed value of a string is always -1 (I think!). When working with a program that is designed to work in both 64 and 128 modes, the INSTR function should not be used since the other method will also work in 128 mode. More proficient readers might want to demonstrate the machine language equivalents of both drive detection and INSTR routines? I for one would like to add them to my ML arsenal. ========================================================================= @(#)error: ? DS, DS$: rem The Error Channel We are not aware of any errors with issue 13. ========================================================================= @(#)bits: Twiddling the Bits: VIC-20 ROM Cartridge Exploration and Archiving by Ward Shrake (wshrake@aol.com) @(A): Introduction This article's primary purpose is to enable you to understand the basic principles of making an archival backup of a ROM cartridge. However, I do wish to point out the following important points, before I begin: @(A): Disclaimer 1. This is NOT intended for any sort of illegal purposes! The information can be misused, if one wants to badly enough. However, so can virtually every other piece of information on the planet. Fire is a good thing, as are hammers, saws, and other tools, but all of them can be misused. I urge the reader to use this information in a proper fashion and to take the time to reflect on what you are doing, to avoid hurting anyone or anything. 2. I am releasing this information for two basic reasons (besides basic hacker pride in obscure technical knowledge). First, the Vic20 died many years ago. Commodore helped accelerate its death, by pushing the C64 computer onto the market, at a time when all the companies out there had a lot at stake. I don't blame Commodore from a marketing sense; they just wanted to stay alive themselves in a cutthroat market environment. However, this means a lot of people still have the idea that the Vic20 was/is a piece of obsolete junk. This is not true, but the public acts as if it were. The end result is that a lot of perfectly good hardware and software is thrown away on a regular basis. Once it is in a landfill somewhere, it’s rather difficult for anyone to use it! Hence my two-fold concern: to help show the public (and Commodore Guru types) the Vic20 is a very cool gaming machine, and to physically rescue the software for the system before all of it is lost forever. I take little pleasure in thinking that 50,000 years from now some archaeologist will dig up our landfills and think we must have had some really cool stuff! 3. I really like the term "Digital Archaeology." (I wasn't the first to use it, however.) Basically, it means that with the many rapid advances in the computer sciences, lots of stuff gets lost or forgotten in the rush to replace everything every few years. Whereas an entire civilization might take hundreds or even thousands of years to die out and be all but forgotten, the history, lore, and software of computers can be gone in just a few years. If we don't revive it now, who will remember how to use any of this stuff? There are only a few people around now that can do it, and their memories are getting fuzzy with the passage of time. I don't mean to preach; I just think this is as good a time as ever! A small group of concerned individuals, myself included, have begun the task of archiving all the VIC-20 cartridges known to exist. The project also includes documenting every aspect of the VIC-20 hardware and how it operates. @(A): General information about Vic20 cartridge software A Vic20 cartridge is approximately 5.5 inches wide, 3 and 3/8ths inches deep, and 5/8ths inches tall, when viewed as if ready to be installed. Most of the cartridges that were made by Commodore are either a beige or dark brown colored plastic with a tan or metallic all-text label. Some third-party companies had more interesting looking cartridges; most of the plastic cases were black as a general rule, with white also being used at times. In rare cases, oddly-shaped carts existed, for example, carts by UMI. Some of these seem to be more epoxy-based than plastic, with glitter inside it! Only a few companies really had fancy, full- colored labels on their cartridges. The most common memory configuration, inside the casing, is one bank of 8k. ROM was standard for the larger companies, but EPROM's were also used at times, even by Commodore themselves. Four-kilobyte cartridges do exist, as do 8k cartridges made up of two banks of 4k chips. (Memory was expensive then, as you can no doubt imagine, and some companies had to make due with whatever they could get cheap enough.) 16K cartridges do exist as well, although the bulk of these were done by the largest companies. Commodore made a few 16k carts, as did Atari, Sega, Hes, and a few others. If other standard cartridge memory configurations existed in the Vic's day, the author is currently unaware of them. (I would like to hear of any, if they do/did exist, especially if they were once made commercially.) There may be a few exceptions, for instance, for carts that modified the Vic20's own inherent abilities; for example, 40 and 80 column boards. But the rule of thumb here is that 8k was the accepted standard, with 4k and 16k at times. All of these cartridge configurations, by the way, are using 8-bit memory because the Vic20 is an 8-bit computer. Inside a typical Vic20 cartridge is one double-sided, etched circuit board, with some form of memory chip(s) on it. This may be a "standard" IC chip as we are used to seeing (24 or 28 pin ROM, in a DIP package), or it could be a blank circuit board, with a tiny blob of black epoxy material on it, under which are presumably the internal components of a typical, normal ROM chip. The standard circuit board size is approximately 3 and 9/16ths inches wide, and 1 and 3/4 inches deep. A cart fits into a 44-position, double- sided card edge connector, located in the back, left hand side of the Vic20. On the cart circuit board itself, there might be several wire traces or jumpers, which, if there, are meant to configure the cartridge to a certain memory arrangement. These jumpers are meant to connect the BLK or RAM lines to the system ground. These lines, when connected, tell the Vic20 where to place the cartridge within the Vic20's internal memory mapping scheme. While all "normal," autostart game cartridges are located in one fixed area of memory, this is not true with all cartridges. A rare few of the total Vic20 cart collection did not use the autostart procedure; you had to type in a systems number to start the program running after inserting it. These are very rare, however (6 out of 150+ so far). Most cartridges all autostart after insertion and power-up, just as cartridges do in game console systems. All this memory banking may seem confusing. If it does, remember this: Every cartridge that autostarts must have at least one bank of memory in Block 5, or the autostart procedure will not function. If it autostarts, there has to be some memory in Block 5. That may help relieve some confusion. There may be additional memory installed as well, in some cases, for more storage space. The location of this additional memory is less important than the location of the autostart bank. However, there are only three additional 8k banks left, for a total of four banks of user-added RAM or ROM memory. The Vic20 was built when memory was expensive, and computers were designed to be bare-bones memory-wise with the capability to expand on later. This may take some getting used to at first, but understanding it gets easier in time. Take it in stride for now. @(A): The Cartridge Auto-Starting Feature Please note that if you already understand the autostarting system used in the Commodore 64, this is nearly identical in procedure. Only certain codes and memory locations differ; the rest applies to both machines. The "normal" spot for an 8K cartridge to be located in memory is in "Block 5"(which is located at $A000 to $BFFF). Again, this is not the only possible spot in memory for a cartridge to be located, but it is the only spot where the Vic20 will look for a cartridge that automatically starts on power-up. This is because (at power up) the Vic20 looks for a precise code in a precise spot to see if it should autostart a cartridge or not. If the Vic20 finds this EXACT five-byte code, EXACTLY where it is supposed to be located in memory, the Vic20 turns control over to the cartridge. If not, it gives over control to the user, via the normal, power-up Basic READY prompt screen. This 8K autostart sequence code is shown below: Address Hex value Decimal value ASCII values $A004 $41 65 Capitol "A" $A005 $30 48 Digit "zero" $A006 $C3 195 Reverse "C" character $A007 $C2 194 Reverse "B" character $A008 $CD 205 Reverse "M" character (You may note that the code above is symbolically saying $A000, and Commodore Business Machines. In other words, that this is the right software, for the right machine. The C64 uses $8000 instead.) If the computer finds this five-byte sequence exactly as shown, it turns its control over to the machine language program in the cartridge. To do so, it needs to know where the program begins. There are four bytes which determine this, as shown in the chart below. Note that this is in the cart, not the Vic20. Address What this byte of information contains $A000 Low-byte of 16-bit "cold start" address (power-up) $A001 High-byte of 16-bit "cold start" address $A002 Low-byte of 16-bit "warm start" address (restore key) $A003 High-byte of 16-bit "warm start" address Let's do a quick summary of this before we go on. You plug a cartridge into the Vic20. You turn the power on. The Vic20 starts its own built-in operating system software. It gets itself ready to be used, either by the user (in BASIC) or by a cartridge's program. One of the last steps in the computer's start-up sequence is to look at a certain spot in memory, to see (A) if there is a cartridge inserted there, and (B) if it is the proper type. It does both these tasks through simple assumptions. Assuming that the existence of an autostart code sequence at a certain memory address implies a cartridge is present, the computer looks for the "A0CBM" code sequence. If it finds it, it then transfers control to the locations specified at $A000-$A003, as defined above. (In many cases, this address is $A009 or 40969 ... the next byte possible after all the start-up codes.) @(A): How to Archive Vic20 ROM Cartridges Now that we know how the autostart process works, what can we do with that information? Well, to archive a cartridge's internal ROM memory to either tape or diskette, you have to know how the autostart process works. This is necessary because you have to figure some way around it to be able to get to that "no carts inserted" normal power-up screen. This means that you then have full control of the machine, instead of the cartridge being in full control. Simply put, there are only two steps to archiving a cartridge from its cart to disk or tape. 1. Find some method of defeating the autostart process, so that the Vic20 powers up with the cartridge in memory, but does not start it up. So that you are in control, instead of the cartridge running the show. 2. Copy that area in memory where the cartridge resides, to tape or disk. The resulting program is called an "image" of the cartridge's memory. After that, assuming there is no copy-protection coded into the original, you have a working version of the program stored on disk/tape instead of on ROM. Some problems may arise, but don't worry, they are easy to get around if you know how to do it. A. There may be more than one block of memory to copy. The one found at Block 5 is easy, because if the cart auto-starts, there must be memory that needs to be copied. However, additional memory may be present. You will need to determine where it is, and how much of it there is. B. Depending on how you transferred the image to disk (assume I mean "disk or tape" from now on), was the loading address information stored with the image? If it was you can reload it easily next time. Without those two important address bytes (these are separate from those we discussed earlier), the software won't load properly, and so will not work. OK, so now you're convinced it’s impossible, right? For every problem, there is always a number of solutions. I wrote a small program that eliminates most of the problems inherent in archiving carts, and have figured out ways of eliminating most of the hassles. The program also makes the process more reliable, since archiving rare and cool things is the main idea. I'll make that program publicly available, soon, after a bit of polishing. But you still have to get around that auto-start procedure. Without doing that first, you are dead in the water before you've even started. So, here's how you get around the autostart procedure. After that, its all downhill! There are a number of suggested methods shown below. My suggestion is to pick out the method you like best and stick with it. The rest will just be to satisfy your built-in hacking curiosity, OK? Other methods exist but I didn't feel they warranted the space here. These are some of the best ways. @(A)method1: Inserting a Cartridge Into a Powered Computer Please pay attention to what I am about to say: this is the only method I DO NOT recommend! I mention it mainly because it represents a very real risk of killing your hard-to-replace Vic20 computer system. This is supposed to be an exercise in keeping things alive and usable, not killing more off! If you feel you want to try this, you do it at your own risk! I once knew a guy that wanted to archive Vic20 carts, but wasn't willing to go to a lot of effort to find a good way to get around the autostart feature. When he told me what he was doing, I tried to warn him. He kept on doing it, saying he'd "just be careful." The next thing I know, he is asking me how to repair a computer that died suddenly. I told him the truth: (A) you don't, you go find and buy another one, and (B) you listen to me the next time I tell you that you're risking your almost irreplaceable hardware. If that didn't convince you, well, I tried. There are better methods, by far! If you can't find a better one than this, pay someone to modify your Vic20, or just loan the cart in question to someone who is more used to doing this! @(A)method2: Altering Your Computer's Operating System ROM What this method does is change the copy of the code to check for, inside the Vic20, so that no cartridge's unaltered code ever matches it. So no autostart. No cart will ever match the modified start-up code in your new operating system, so none will ever be seen as a cart. However, having one of these chips installed permanently could be a bad idea, as you cannot test or start your saved images quite as easily. The image won't autostart either, unless you are willing to keep swapping chips back and forth, or unless you know how to decode the starting addresses and type in systems numbers. This is an elegant way to solve the problem, providing you possess tools to read and program EPROM ICs and can obtain replacement ICs that are pin-compatible. Thus, the elegant solution requires a substantial amount of resources. However, one chip does exist, which is expensive if you buy it new, and may be hard to find as well. (Try posting to "comp.sys.cbm.") If you can find a Motorola 68764 chip, you're almost there! Just copy the Kernal rom to disk, modify the "A0CBM" code found there to be anything but that, and burn a new EPROM of your modified Kernal rom. The manual to the Promenade EPROM-writing machine makes programming these chips a snap. And the Promenade is still available today, from it makers, Jason-Ranheim Co. (Phone: 916-878-0785, or 1-800-421-7731.) These same 68764 chips work with C64's internals, too. This does work. It has the advantage of requiring no modifications to your Vic20 which can't be easily reversed. Before I got tired of swapping Kernal chips back and forth, this was my preferred method of archiving cartridges. @(A)method3: Using a Cartridge Port Epander I've come to feel that a plug-in board is the best way to modify things just long enough to get past the start-up process, skip the autoboot phase, and get down to business. If you can find one, buy it! It makes life so much easier and nicer, in more ways than just this one. I highly recommend buying one. Basically, this device lets you plug in lots of carts at once, and with just a button press, decide which one to use at any given time. Well, that switch is all you need! Just (A) turn the computer off and insert a cartridge, (B) make sure all the switches are de-activated, (C) turn the computer on. You should now be looking at a normal, BASIC power-up screen. Now (D) press the button that activates the slot that your cartridge is plugged into, so that the cartridge is now mapped into memory properly, although belatedly, and (E) follow the instructions in the next part of this text, to archive the cart. Note that you can modify your Vic20 to do the same thing if you are handy with a soldering iron. But as I don't want anyone killing their only Vic20, maybe I'll save that for another article ... this one is almost at deadline, and I don't want to rush things and make any mistakes!(Besides, I don't know yet if anyone is interested enough to modify their Vic20's to do this??) @(A): Saving One or More Blocks of cartridge Memory to Disk or Tape Once you've defeated the auto-start feature of the Vic20, the memory contained in the cartridge is just another block of memory as far as the Vic20 is concerned. You have full access privileges, with all that goes with it, including the ability to save it to external storage. You have three basic choices to save the block of memory to tape/disk. You can either (A) wait until I release my program that does it automatically, or (B) use a "memory save" feature of a machine language monitor program (not built in) to save the 8K block of ROM memory, or you can (C) just change four POKE's in the Vic20's memory. With this, your cartridge is seen as if it were in the BASIC program memory area so that the built-in "SAVE" command works. It really works. The beauty of it all is that no additional programs are needed. To save any block of cartridge-usable memory in the Vic20, just type in four easy POKE commands, then tell the Vic to SAVE the program as it would normally save any BASIC program. (You can even copy the system ROMs that way, if you want to.) For those of you already familiar enough with Commodore's style and memory arrangement schemes to make sense of this, bytes 43 and 44 (decimal, not hex) are the pointers to the Start of Basic memory area, and bytes 45 and 46 are the pointers to the Start of Variables, or in other words, the End of Basic. Follow this chart, to save a block of memory from these areas via pokes: Block # Hex Address Poke 43,x Poke 44,x Poke 45,x Poke 46,x 5 $a000-bfff x = 0 x = 160 x = 0 x = 192 3 $6000-7fff x = 0 x = 96 x = 0 x = 128 2 $4000-5fff x = 0 x = 64 x = 0 x = 96 1 $2000-3fff x = 0 x = 32 x = 0 x = 64 Here's an example: to save block 5 (the most commonly used memory block) you do the following steps. 0. Follow the previous instructions, to get to this point. (The cartridge has been inserted, power is now turned on, and the autostart has been defeated. The Vic20 is showing you its normal BASIC power-up screen.) 1. Type the following, hitting RETURN after each line. (Type carefully!) POKE 43,0 (and return) POKE 44,160 (and return) POKE 45,0 (and return) POKE 46,192 (and return) SAVE "FILENAME.EXT",8 (and return) 2. Wait for the disk drive to finish its saving process. (Be patient.) 3. If you have more 8k blocks to copy, repeat all the previous steps, but adjust the POKE statements, according to the information in the chart. Note that the pokes to 43 and 45 are always zero; even page increments. Also, note that the computer will get confused or lock up if you try to copy another block of memory without starting completely over. 4. When the busy light turns off again, turn the Vic20's power back off. Remove the cartridge, and if you have a modified 8k or 16k RAM expander insert it or activate it. If you have a 32k RAM expander, you can use it. 5. Load the disk's directory up, (or rewind the tape), and see if the file has been properly saved to the disk. It should show a file size of 33 blocks, if all has gone well ... 32 blocks x 256 bytes each = 8k, plus one block for the disk drive's overhead and the file loading address. 6. If everything looks fine so far, just load the newly created "image" into RAM memory, to see if it runs. Remember a few tips: as with the C64, you always have to use the ,8,1 loading conventions for any machine language program to reload into memory back where it came from. Also, to properly load up an image that has more than one 8k bank, you will have to type NEW after each load to reset some memory pointers. Otherwise, it moves BASIC to where the cart now is and gets confused. So multi-loads are: (A) LOAD"file1",8,1 (B) NEW (C) LOAD"file2",8,1 7. The last step is starting up the image, to see it in all its new glory! To do this, all you have to do is (A) press the reset button you've installed yourself, or if you don't have one installed, (B) type the following "reset" command into the computer... SYS 64802 (and return). 8. At this point, your image is probably running. If it is not, carefully recheck all the previous instructions. You may have made a mistake or two there, somewhere. (One mistake I have often made is to forget to re-activate the expansion chassis' slot, and essentially save empty air.) @(A): Troubleshooting But if you recheck everything, and it STILL doesn't work, try archiving another cartridge. If the first does not work, but the second one does, you have likely found one of the few protected carts out there. How to "break" the copy protection is way out of the scope of this article, so I can't help you there! Sorry. But usually, everything will be fine by now, if you've followed the instructions carefully, step-by-step. Only about 10% of the VIC-20 cartridges were copy protected. ========================================================================= @(#)next: The Next Hack What? Why are you reading this? Aren't you happy with the issue you have? We walked through the snow with no shoes uphill both ways to deliver this to you and you are still asking for more? Have you even read the issue you have in your hot little hands? Demanding reader, aren't you. OK, here's what's coming up: o We continually receive comments from folks trying to learn ML programming. They have copies of C=Hacking in hand, but lament that the concepts are too advanced for them. Well, next time we'll review some resources for the beginning ML programmer. Two of them, _Coder's World_ and _Bonkers_ are organized in publication format and go over many of the details that every ML programmer must learn. o We're not sure which one will get here first, but Frank Kontros is writing up some of his impressive hardware and software projects as we write. It might be the EPROM programmer, the Digital I/O board, or one of his many software exploits. WE'll spotlight one next time. o For many years, Commodore 64/128 users have been able to purchase stereo SID cartridges like the SID Symphony by CMD. However, there's not an overabundance of games or applications that take advantage of the second SID. Frank Kontros overcomes that problem in a non- obvious way by showing how to build a "pseudo'stereo" adaptor for your C64 or 128. The effect is noticeable and it requires no programming changes. o And, of course, C=Hacking's regular goodies. Now, go back and re-read those articles. We need some sleep.... ========================================================================= @(#)code: Hacking the Code Being a technical, developer oriented magazine, some articles featured in C=H include executables or other binary files as part of the article. All such binary files are included on the soft copy of this issue in this section. In an effort to retain the integrity of such binary files through distribution over various computer networks, the binaries in this section have been encoded using the UUcode format, a popular Internet binary-to-readable text encoding method. In order to execute or otherwise utilize these binary files, one must feed this section of the magazine to a UUdecoding application. Typical examples include UUXFER for the 64, uudecode on the ACE OS for the 64 and 128, and uudecode on most UNIX OS machines. Some encoders can decode multiple files, while others will require the user to manually split this section into individual pieces prior to decoding. In addition to this section, there are other ways to retrieve the binary files featured in this issue. For those with World Wide Web access, the files are available at http://www.msen.com/~brain/pub/ To retrieve "dim4.lnx", simply access the URL: http://www.msen.com/~brain/pub/dim4.lnx For those with electronic mail access only, the Commodore Hacking MAILSERV server also contains a copy of these files. To retrieve a copy of "dim4.lnx", send the following email message: To: brain@mail.msen.com Subject: MAILSERV Body of Message: send dim4.lnx help quit For some articles published in Commodore, the author or authors may also have other methods for accessing files mentioned in the article. These methods are described in the respective article. Commodore Hacking always attempts to provide the reader with as many options as possible to retrieve uncorrupted binary files. Although none of these above methods is foolproof, the added redundancy helps overcome any shortcomings. WARNING: The UUCode format translates files from binary to ASCII, not PETSCII. Therefore, either decode this section before downloading this section to a PETSCII mode computer system, or download this section without translation to PETSCII. Some decoder programs can handle PETSCII converted UUCode files, but the practice is not recommended because conversion is typically done in a telecommunications program and accuracy in translation cannot be guaranteed. @(A)menucode1: Menu Toolbox at $1000 (4096) begin 644 mbox1000.bin M`!!,>1M,]!M,&QU,0!U,$1M,WR9,^1U,;AY,XQY,)R%,%1],0Q],!B=,AB!, M,2%,WR5,=BA,?2A,"2M,%BM,'2M,TQ%,SQ!,3!%,O11,$A-,<1-,.Q-,6!-, ME!-,G!-,^Q-,/11,FQ1,'!M,+1M,/AM,3QM,RQ1,]A1,!Q5,&!5,(15,*!5, M7!5,>!5,B!5,K15,.A9,P!9,Q!9,!Q=,$!=,%Q=,&A=,;A=,@A=,BQ=,EA=, MO1=,PQ=,R1=,TA=,YQ=,]A=,$1A,)AE,3QA,[QHX(/#_CLHLC,DL(-T;A/R8 MP`2P`6`8:02%_JD`A?V%^ZD3(-+_(`4?>*D`A0&B`Z``L=&1^\8!L?/F`9'] MR-#QYM+F_.;TYO[*$.;&_J#IQ@&M(-#F`9']R,8!K2'0Y@&1_%`:D`C:HL6$QLY:D`A?V%_HU0+(W$+"#=&YBL4"R9HRSN4"S` M!=#O(*@=R1F0`JD9C<4LH`"Q(IEF+,C,Q2S0]2"]%*ZC+*``C+LL&"#P_R`% M'ZVH+(V\+"#<$B#D__#[H@"-Q"RNNRR.4"S)$?`0R9'P'R#U$LD-\"_0`$PD M$NZ[+*V[+,VF+-!2J0"-NRQ,I1+.NRRMNRS)__`#3*42K*8LB(R[+$RE$JW$ M+/`&K5`L3(`2K;LL&&VC+*J@`"#P_R`%'ZVG+(V\+"#<$JV[+!AI`87]J0"% M_DPJ(*VC+!AMNRRJH``8(/#_(`4?K:@LC;PL(-P2K:,L&&U0+*J@`!@@\/\@ M!1^MIRR-O"P@W!),)!*LI"RMO"R1\S`&L=%)@)'1R,RE+/#MD.M@JIA(H`"* MV68LT`B,NRRB#8[$+,C,Q2S0[6BHBF`@O10@W1N$TR#=&X36(&SE(*@=C5`L MK5`L\`V@`+$B(-+_R,Q0+-#U8""H'+"#=&XQ?+""]%*762*732*Y>+*`` M&"#P_R`%'\Y<+*Q=++'S*0^JO:LLD?.(S%PLT/"EULU?+/`+YM8@;.4@!1], M;11HA=-HA=9,;.4@J!V%^R#D__#[H`#1(M`+R)B%_:D`A?Y,*B#(Q/O0[/#C MH!BYV0`)@)G9`(@0]6!(J0&-S2QH("D8JJD!H``@NO\@1QB%%"!'&(45IA2D M%:D`(-7_H`"8D:Y@AON$_*`#L?N9!RR($/A,_!V&^X3\H`.Q^YD'+(@0^$QQ M'HX,+(P-+$SO'HX]+(P^+&`@&B".%RR,&"R-&2R&^X3\&&7[A?NI`&7\A?R@ M`+'[C54L($<8C58L($<8C1HL("(@3#`?CE4LC%8LJ0&-S2RI`(T/+(U7+(U8 M+(U9+$Q?'X;[A/RD^Z7\H@&.S2Q,"2=(J0&-S2QH("D8KATLJ0&@`""Z_R!' M&(44($<8A16F%*053*(@J0&-S2R&^X3\H``@&B"I`(T>+(T/++'[C4HLC1\L MC0IWH4BJ2R%(Z[: M+$R6%R"8&*D`C1$MC1(MC1,M(*@=CG\MC(`MC8$MJ0&%QZT_+8V&`JV!+4J- M4"RI%#CM4"RHKCPM&"#P_Z``L2(@TO_(S($MD/6I`8T2+:D`C1$M(-T;C'@M MC",M(*@=CE`LC'HMC7LMK1(M"AAM$BVJK5`LG7\MK7HMG8`MK7LMG8$MS1$M MD`.-$2WN$BW.(RW0R2"H'8U&++8T9+8T5+:UX+1AI`DJ-4"RI M#3CM4"R-'RV-&BV-%BVM>"T8:0%M'RV-("V-&RV-%RVM"2WP'LX8+>X9+X;+:T0+8T<+X5+X7+X6+>X7+:(4H"T@]A>M"2WP M!Z(8H"T@/ANB':`M("T;K!TMR*X?+>@8(/#_K2(MC88"J0&%QZD`C2,MK2,M M"AAM(RVJO8(MA2*]@RV%([V$+8U0+*``L2(@TO_(S%`LT/7FUJX=+>B&TR!L MY>XC+:TC++8Y"+:UX+8U#+:T/+8U$+:T, M+8U%+:)`H"U,'Q<@J!V-4"R@`+$BF=XLR,Q0+)#UJ0"1(F"-#`..#0.,#@-@ MHN^@+XX-`XP.`V"&%(05H`>Q%)DK+(@0^$R7&X84A!6@!;$4F2LLB!#X3`H< MAA2$%:`$L129*RR($/A,5!R&%(05H`6I`)DK+(@0^J``L12-+RS(L12-,"S( ML12-*RS(L12-+2Q,71VI`(74C3WH!BYV0`)@)G9`(@0 M]6"I`(U0+"#=&YBN4"R=*RSN4"S@!=#O(.8;I=9(I=-(KBTLH``8(/#_(`4? MSBLLK"PLK2\LR?_P`I'1K3`LD?.(S"LLT.REULTN+/`&(/X<3"(@`@XM+"XN+(@0]ZTO+!AM+2R-H!VM,"QM+BR-H1VM M*RP8:1>-G1VM+"QI+HV>'2`:(*`'N3DLF0#`B!#W3"(@(/VN()ZM(*.VIB*D M(V"E>DBE>TB&>H1[((NPA4F$2FB%>VB%>F"%9(1E3%*JH$^I`)F_+8@0^F`@ MW1N,!RP@W1N,""P@W1N,"2P@W1N,"BQ@(.`=K`DHA?NETND`A?PXI?/I*(7] MI?3I`(7^K`+/`7K54LC5I28VH*ZU9+!AM5RR%_844 MJ0!M6"R%_H45KLTLT`,@*B"M&BR%_:D`A?ZI1HVH*Z[-+-`P("H@K1DBE>TBI^X5Z MJ0"%>R"+L*``I?Z11\BE_9%':(5[:(5ZH`)HD5_(:)%?8*TK+(U5+*TL+(U6 M+&`@J!T@O?\@W1N,'2R8JJD!H``@NO\@W1NF%*05CALLAJZ,'"R$KZD`(,#_ M(,S_H@$@QO\@Y/\@Y/^@`"#D_R`:()&N("(@YJ[0`N:O(+?_*4+PZ*D!(,/_ M(,S_I:XX[1LLC3\LI:_M'"R-0"R@!$Y`+&X_+(@0]ZT_+#CI`HT_+(7]K4`L MZ0"-0"R%_B`J(*T;+!AI((T;+*T<+&D`C1PL8"#=&XP]+(T^+&"I`(W-+(U! M+(U"+(T>+(T/+"#=&XQ*+(P?+(P'+"#=&XQ++(P(+(P@+"#=&XQ,+(P)+(PA M+"#=&XQ-+(P*+(PB+"#=&XQ&+"#=&XQ'+(PD+(P-+"#=&XQ(+"#=&XQ)+"#= M&XQ7+(U8+"#=&XQ#+(U$+"#=&XQ%+*F@KD8LT`*I((TC+(T,+*(?H"P@+1NM M32PX[4PLC4XLK4LL..U*+(U;+""3):D`(.3_\/O)+=`"J9W)*]`"J1W)(-`" MJ0W)7]`"J87)5-`+KD4L\`8@/RL@^R/)$=`,($HD(+[EQ^M1BR% MQZU'+*X:+/`#K4DLC88"K4PL&&U9+*JL2BS(&"#P_R`%'ZT7+(7[K1@LA?RL M2BRMA@*1\\C,2RR0^/#VK1XLT!F@`"`:(+'[("(@(-+_R,Q;++`%S!DLD.I@ MK1Q^M3"P8;5DLJJQ,+,@8(/#_(`4?K$HLL=%)@)'1K4K3\LS5DLL!:M62R-3BS.3BP8;0DLC0HLC4TL M3-+-`1(/@? M(!H@H`.Q^TF`D?M,(B"M62P8;5X4+.C( MT/`@(B"MS2S05*(1H"P@MAVI%*`L(,X=(-4=J4*-J"NMIBN%_84BK:X4+*T4+,DGD`6I)HT4+*`!L?T@TO_(S!0L\/60\ZT#+!AM!"R%TR!L MY4S:**7]..D!A?FE_ND`A?JL`RS([A0LL?V1^*BXO.CT-%`````````````````````````!7)```ORT````````( M```````````````````````````````````````!`>\O```````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````0$!``````!4```````````````` M`````````0\)#@(&``4)"P(`"P4&#`````````````````````````!?:0$" M#PP")!<7`R46%J`#P]+3TB_2Q=35TLX@U$\@TT5,14-4```````````````` M````````````!P$```$/`P,$`````````````````````*`#```G`!@#`28! M%U]I`PX"(P,%`R0"!`$$(P,#H`$````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````$*))!I8))%"B'-P<(AG!P>!&!AF9A@8@8!D1@@08B8!!Q@@ M,`P$&.`D),,8&,,D)%6J5:I5JE6JS#/,,\PSS#-F@68\9H%F/%K;&.?G&-M: M$1$B(D1$B(@1$2(R3$2(B,`P#`/`,`P#P#`,"]`P#`,1$:JJ1$2JJO5$1$!? M1$0$B%`@4(@```"J5:I5JE6J5:JJJJI55555`@H(*""@@((!`0$"`@49X0$" M'.`!`AS@B!$B1(A$(A$B1(A$(D2(1`000@@A!!``0*1*!"!2)0)!(A2(%")! M"$$JE"*4*D$4@1@89F88&($!)F(0"$9D@(/&;#@8#`8#*!""1((0*`#=$7=$ MW1%W1`Q@`QC`!C"!4HA2`"6()0`4$LDDDT@H*!ADK()J3#``_\#>WL;V]@9T M(A>[<2)'[G6NU;I7ZEVKP]L8?GX8V\.`1`@0($0"`?__________`1$0?!`1 M`<<1$1'^$1$1[_]@9F9F9F8&P_`\#\/P/`\0.$2"`8)$.(1F2!`DS$(!<(@' M`'"(!P`B290B22*42:2DI*1*2DI*$43N1!%$[D0!;6T0;6T![J2DI.1*2DI. @*`!4`"@``0`2"81"0H0)$D2(1(A$B$2(B@4B4*A0(@50 ` end @(A)menucode2: Menu Toolbox at $8000 (32768) begin 644 mbox8000.bin M`(!,>8M,](M,&XU,0(U,$8M,WY9,^8U,;HY,XXY,)Y%,%8],0X],!I=,AI!, M,9%,WY5,=IA,?9A,"9M,%IM,'9M,TX%,SX!,3(%,O81,$H-,<8-,.X-,6(-, ME(-,G(-,^X-,/81,FX1,'(M,+8M,/HM,3XM,RX1,]H1,!X5,&(5,(85,*(5, M7(5,>(5,B(5,K85,.H9,P(9,Q(9,!X=,$(=,%X=,&H=,;H=,@H=,BX=,EH=, MO8=,PX=,R8=,TH=,YX=,]H=,$8A,)HE,3XA,[XHX(/#_CLJ*D`A0&B`Z``L=&1^\8!L?/F`9'] MR-#QYM+F_.;TYO[*$.;&_J#IQ@&M(-#F`9']R,8!K2'0Y@&1_%`:D`C:J<6$QLY:D`A?V%_HU0G(W$G"#=BYBL4)R9HYSN4)S` M!=#O(*B-R1F0`JD9C<6G"#=BXQ?G""]A*762*732*Y>G*`` M&"#P_R`%C\Y(C5:<($>(C1J<("*03#"/CE6(A16F%*053**0J0&-S9R&^X3\H``@&I"I`(T>G(T/G+'[C4J<($>(C4N(C4R(C4V(C4:< M($>(C4>(C4B<($>(C4F<($>(C5>(C5B( MC4.<($>(C42<($>(C46<("*03*B1AON$_"`:D*D!C1Z<&&D=C4N(C4R(C4V( MC4:<($>(C4>(C4B<($>(C4F(C:2<($>(C:6<($>(C::<($>(C:><($>(C:B<($>(C5"<($>(($>( MION&(J;\AB.M4)Q,\X&-4)PX(/#_CLJ(C<><($>(C(C$(""(C5R<($>(C5V<($>(C5Z<($>(C5^<3%6$AB*$ M(ZD!CIWH4BJ9R%(Z[: MG$R6AR"8B*D`C1&=C1*=C1.=(*B-CG^=C("=C8&=J0&%QZT_G8V&`JV!G4J- M4)RI%#CM4)RHKCR=&"#P_Z``L2(@TO_(S(&=D/6I`8T2G:D`C1&=(-V+C'B= MC".=(*B-CE"=R,Q&G9#UK1&=&&D"2HU0 MG*D4..U0G(T=G8T8G8T4G:T1G1AI`6T=G8T>G8T9G8T5G:UXG1AI`DJ-4)RI M#3CM4)R-'YV-&IV-%IVM>)T8:0%M'YV-()V-&YV-%YVM"9WP'LX8G>X9GX;G:T0G8TX5GX7GX6G>X7G:(4H)T@]H>M"9WP M!Z(8H)T@/HNB':"=("V+K!V=R*X?G>@8(/#_K2*=C88"J0&%QZD`C2.=K2.= M"AAM(YVJO8*=A2*]@YV%([V$G8U0G*``L2(@TO_(S%"B&TR!L MY>XCG:TCGG8Y"G:UXG8U#G:T/G8U$G:T, MG8U%G:)`H)U,'X<@J(V-4)R@`+$BF=ZQ%)DKG(@0^$R7BX84A!6@!;$4F2N<(.:+(-V+KC><*0&--YS( MS"RWH!BYV0`)@)G9`(@0 M]6"I`(U0G"#=BYBN4)R=*YSN4)S@!=#O(.:+I=9(I=-(KBV@`@XMG"XNG(@0]ZTOG!AM+9R-H(VM,)QM+IR-H8VM M*YP8:1>-G8VM+)QIGHV>C2`:D*`'N3FDBE>TB&>H1[((NPA4F$2FB%>VB%>F"%9(1E3%*JH$^I`)F_G8@0^F`@ MW8N,!YP@W8N,")P@W8N,"9P@W8N,"IQ@(."-K`>DHA?NETND`A?PXI?/I*(7] MI?3I`(7^K`>G/`7K56I28VHFZU9G!AM5YR%_844 MJ0!M6)R%_H45KLVDBE>TBI^X5Z MJ0"%>R"+L*``I?Z11\BE_9%':(5[:(5ZH`)HD5_(:)%?8*TKG(U5G*TLG(U6 MG&`@J(T@O?\@W8N,'9R8JJD!H``@NO\@W8NF%*05CANG(T/G"#=BXQ*G(P?G(P'G"#=BXQ+G(P(G(P@G"#=BXQ,G(P)G(PA MG"#=BXQ-G(P*G(PBG"#=BXQ&G"#=BXQ'G(PDG(P-G"#=BXQ(G"#=BXQ)G"#= MBXQ7G(U8G"#=BXQ#G(U$G"#=BXQ%G*F@KD:2(/N33->1R9'0#"!* ME"#SDB#[DTS7D1R1W0"2!*E"`G ME4S7D1J0&-#YRM'ISP`TRRER!? MCZU9G!AM5YR%_:D`;5BX^M1IR% MQZU'G*X:G/`#K4FX^M3)P8;5FK3^5K5FG-`1(/B/ M(!J0H`.Q^TF`D?M,(I"M69P8;5>< MC56X4G.C( MT/`@(I"MS9S05*(1H)P@MHVI%*"<(,Z-(-6-J4*-J)NMIIN%_84BK:>;A?Z% M(R`JD*E)C:B;K5F<&&U7G(7]A12I`&U8G(7^A14@*I"I1HVHFZT:G(7]J0"% M_DPJD*U9G!AM5YR%%*D`;5B+(-V+C!Z<8"#=BXRJFXR&`B#=BXRIFR#=BXRKFZ73C02X4G*T4G,DGD`6I)HT4G*`!L?T@TO_(S!2<\/60\ZT#G!AM!)R%TR!L MY4S:F*7]..D!A?FE_ND`A?JL`YS([A2*BXO.CT-%`````````````````````````!7)```OYT````````( M```````````````````````````````````````!`>^?```````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````0$!``````!4```````````````` M`````````0\)#@(&``4)"P(`"P4&#`````````````````````````!?:0$" M#PP")!<7`R46%J`#P]+3TB_2Q=35TLX@U$\@TT5,14-4```````````````` M````````````!P$```$/`P,$`````````````````````*`#```G`!@#`28! M%U]I`PX"(P,%`R0"!`$$(P,#H`$````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````$*))!I8))%"B'-P<(AG!P>!&!AF9A@8@8!D1@@08B8!!Q@@ M,`P$&.`D),,8&,,D)%6J5:I5JE6JS#/,,\PSS#-F@68\9H%F/%K;&.?G&-M: M$1$B(D1$B(@1$2(R3$2(B,`P#`/`,`P#P#`,"]`P#`,1$:JJ1$2JJO5$1$!? M1$0$B%`@4(@```"J5:I5JE6J5:JJJJI55555`@H(*""@@((!`0$"`@49X0$" M'.`!`AS@B!$B1(A$(A$B1(A$(D2(1`000@@A!!``0*1*!"!2)0)!(A2(%")! M"$$JE"*4*D$4@1@89F88&($!)F(0"$9D@(/&;#@8#`8#*!""1((0*`#=$7=$ MW1%W1`Q@`QC`!C"!4HA2`"6()0`4$LDDDT@H*!ADK()J3#``_\#>WL;V]@9T M(A>[<2)'[G6NU;I7ZEVKP]L8?GX8V\.`1`@0($0"`?__________`1$0?!`1 M`<<1$1'^$1$1[_]@9F9F9F8&P_`\#\/P/`\0.$2"`8)$.(1F2!`DS$(!<(@' M`'"(!P`B290B22*42:2DI*1*2DI*$43N1!%$[D0!;6T0;6T![J2DI.1*2DI. @*`!4`"@``0`2"81"0H0)$D2(1(A$B$2(B@4B4*A0(@50 ` end ========================================================================= @(#): bottom