User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

magazines:chacking14 [2015-04-17 04:34] (current)
Line 1: Line 1:
 +                   ########
 +             ##################
 +         ######            ######
 +      #####
 +    #####  ####  ####      ##      #####   ####  ####  ####  ####  ####   #####
 +  #####    ##    ##      ####    ##   ##   ##  ###     ##    ####  ##   ##   ##
 + #####    ########     ##  ##   ##        #####       ##    ## ## ##   ##
 +#####    ##    ##    ########  ##   ##   ##  ###     ##    ##  ####   ##   ##
 +#####  ####  ####  ####  ####  #####   ####  ####  ####  ####  ####   ######
 +#####                                                                     ##
 + ######            ######            Issue #14
 +   ##################               Version 1.0
 +       ########                    November 1996
 +@(#)contents: Table of Contents
 +   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.
 +   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.
 +   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 
 +(, as well as via FTP 
 +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:
 +Subject: MAILSERV
 +Body of Message:
 +send c=hacking13.txt 
 +To retrieve a PKZIP 1.01 archive of the individual articles in Commodore
 +Hacking, request the file
 +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)
 +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
 +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
 +( 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
 +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 (
 +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 (
 +@(#)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 (Internet) 
 +@(A)c: Hey! You Characters! Sit Down!
 +From: Adam Vardy (
 +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'
 +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?
 +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
 +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.
 +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
 +@(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!
 +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.
 +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.
 +(  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 (
 +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
 +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!
 +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
 +@(A)c: A Bit of Their Own Medicine
 +From: (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, <best viewed using a Commodore 8 Bit Computer> This
 +would please quite a few people (besides me of course).  Who says we have
 +to be able to see 256 colors! 
 +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 
 +"<IMG>" 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:  <IMG SRC="junk.gif" CBMSRC=""> 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:
 +<IMG CBMSRC=...> 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 <IMG SRC="">.  
 +@(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
 +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
 +Then you should be able to uudecode multiple part files with this program.
 +@(A)c: Comfortable Reading
 +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'
 +handle it. 
 +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
 +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'
 +    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:
 +More complete information is available at:
 +@(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  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)
 + (Internet Contact)
 + (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:
 +or contact Mr. Strinic at: 
 +@(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 ( 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: 
 +@(A): Video Interface Computer (VIC) Software Available
 +Ghislain deBlois ( 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:
 +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 
 +with a subject of:
 +and a body of:
 +   subscribe 64EUROPE
 +   END
 +The list address is:
 +@(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: or 
 +contact Mr. Rossi via email at:
 +@(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:
 +@(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  If you
 +need to consult an index first, there is one located at:
 +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:
 +@(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:
 +@(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:
 +@(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:
 +Wraptorized and ARCed versions are available for 1541 and 1581, while
 +Compression Kit, .d64 images, and PKZip version are available in 1541 
 +Screen shots of the issue are available at:
 +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. 
 +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 
 +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:
 +@(#)trick: HEAVY MATH - Part  1: Introduction to Linear Programming (LP)
 +           by Alan Jones (        
 +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'
 +     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'
 +    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'
 +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 
 +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. 
 +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'
 +    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. 
 +have not seen any numerical analyses indicating how to set the 
 +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: 
 +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 
 +@(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 (
 +   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 (
 +   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 (
 +   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 (
 +   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
 +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 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 (
 +@(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 and then modified for a standard 9 pin female COM port on a  
 +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 -|---+                /  |                                  |   |  
 +                /    | 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:  
 +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 ""  
 +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  
 +This file can also be downloaded from in the "lib" 
 +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  
 +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:  
 +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  
 +   (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:  
 +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 ( 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'
 +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'
 +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 (
 +             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 
 +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
 +              ldy >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$=" 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)
 +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
 +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
 +              BLACK
 +              WHITE
 +              RED
 +              CYAN
 +              PURPLE
 +              GREEN
 +              BLUE
 +              YELLOW
 +              ORANGE
 +              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
 +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
 +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
 +   ldy >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
 +   ldy >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
 +   ldy >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
 +@(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
 +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
 +   ldy >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
 +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
 +   ldy >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
 +   ldy >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,
 +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
 +            ldy >parameters
 +            jsr 32768+141
 + parameters .byt x1,x2,y1,y2,,r,c,h,s
 +            .word o,l
 +            .byt m  
 +@(A): Set Mode: SYS32768+48,
 +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
 +@(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
 +>From ML: 
 +              ldx <parameters
 +              ldy >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
 +>From ML: 
 +   ldx <location
 +   ldy >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
 +>From ML: 
 +              ldx <parameters
 +              ldy >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 $22
 +   lda >string'loc
 +   sta $23
 +   lda string'length
 +   ldx <start
 +   ldy >start
 +   jsr 32768+156 
 +   lda <string'loc
 +   sta $22
 +   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
 +              ldy >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
 +              ldy >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
 +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
 +   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
 +          ldy >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
 +   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
 +   ldy >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
 +          ldy >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
 +CHAR is the screen code of the character you want replaced with the tile. 
 +>From ML: 
 +         ldx <parms
 +         ldy >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
 +         ldy >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
 +   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 $22
 +   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 $22
 +   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 $22
 +   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 $22
 +   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
 +         ldy >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
 +>From ML: 
 +         ldx <parms
 +         ldy >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
 +   ldy >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 (
 +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 
 +@(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 
 +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 (
 +@(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 Thanks also go to 
 +Max Cottrell, who did the scans of the photographs, courtesy of MC 
 +Photography, 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'
 +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'
 +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'
 +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'
 +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'
 +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'
 +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 
 +@(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_.
 +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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   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:
 +   Geoff Sullivan' 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 (
 +@(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  
 +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  
 +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  
 +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  
 +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  
 +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  
 +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  
 +@(#)trivia: Commodore Trivia
 +            by Jim Brain (
 +@(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:
 +Subject: MAILSERV
 +subscribe trivia Firstname Lastname
 +@(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       (X means either 1 or 0)
 +        HIRAM     0
 +        GAME    1   X
 +        EXROM     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'
 +        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 ( 
 +@(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  
 +   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  
 +   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  
 +   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 (
 +@(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  
 +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  
 +@(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  
 +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  
 +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  
 +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  
 +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  
 +@(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 
 +           $a000-bfff      x = 0       x = 160      x = 0      x = 192 
 +           $6000-7fff      x = 0       x = 96       x = 0      x = 128 
 +           $4000-5fff      x = 0       x = 64       x = 0      x = 96 
 +           $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",     (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,  (B) NEW   (C) LOAD"file2",8,
 +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
 +To retrieve "dim4.lnx", simply access the URL: 
 +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:
 +Subject: MAILSERV
 +Body of Message:
 +send dim4.lnx
 +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
 +@(A)menucode2: Menu Toolbox at $8000 (32768)
 +begin 644 mbox8000.bin
 +@(#): bottom
magazines/chacking14.txt · Last modified: 2015-04-17 04:34 (external edit)