User Tools

Site Tools

         ######            ######
    #####  ####  ####      ##      #####   ####  ####  ####  ####  ####   #####
  #####    ##    ##      ####    ##   ##   ##  ###     ##    ####  ##   ##   ##
 #####    ########     ##  ##   ##        #####       ##    ## ## ##   ##
#####    ##    ##    ########  ##   ##   ##  ###     ##    ##  ####   ##   ##
#####  ####  ####  ####  ####  #####   ####  ####  ####  ####  ####   ######
#####                                                                     ##
 ######            ######            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

   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:

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's 
unreadable.  They seem to be text, but however I try to read them, I get 
weird characters or other stuff.  Loading them into a word processor or 
into ZED, or anything doesn't work.

I don't have Merlin.  But I would think it must have some way to save 
plain text source.  That way, everyone can at least read it, right?

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't 
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 
5.  Decodes MIME messages  (Base64).   Same restriction as UUdecodes.
6.  Added keyboard tables so it can be configured to 'international 
7.  Updated the 'auto-netmail' routines to include Internet Email as well 
    as fido netmail.
8.  Improved the address book so it will handle both the fidonet format 
    addresses and email style addresses.
9.  Added the ability to ATTACH files to a message or reply. These 
    attaches are limited in length to about 8megs (the max that the QWK 
    format can handle).
10. Improved the routines to detect a valid Q.NDX file (the name of the 
    new QWKRR index file).  This means these no longer have to be manually 
    scratched prior to reading a new mail packet.
11. Added code so that you no longer have to quit QWKRR in order to read 
    a different mail packet.
12. Improved the macros so that whole words can be used as a 'trigger'. 
    This can be used as a 'simple' spell corrector. (eg, a macro such as 
    "Ismeal=Ismael" will ensure that you'll never transpose the "a" and "e" 
    in Ismael again.
13. Added a 'scrap macro' that can be defined and used while in the 
    editor itself, without the need to add it to your macro file).
14. Added code so that quote initials can be changed 'on the fly' (This 
    is useful when quoting from Email messages where the default initials are 
    often meaningless).
15. Added time/date stamping to the zipped REP packets. (Some BBS's 
    didn't like having the same date/time stamp on all mail packets).
16. Improved access speed by about 3 times for Ramlink users.
17. Improved tagline handling. You can have up to 10,000 taglines in one 
    category. Tagline files are now numbered from .000 to 999.
18. Several cosmetic changes and bug fixes.

The new beta version is available from the 221b Baker Street BBS in the 
US and GEOZ BBS in Australia and at:

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
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 
* 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 
* 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
   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.  A 
time or formal name for the project has not been determined, but the new 
version will require some type of RAM expansion.

At a recent Lansing Area Commodore Club meeting, Maurice demonstrated 
some of the changes that may show up in the final GEOS 3.0 system.  They 
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 
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'x 
     s.t. Ax  = b 
           x >= 0 
That is, we want to find the solution vector x which maximizes the 
function P, which is a linear combination of elements of x, while 
satisfying the linear equation Ax = b, and with each element of x >= 0.  
A is a matrix with typically more columns than rows.  The maximization 
problem itself is easy, except for the inequalities and determining which 
elements of x are fixed at a bound and which are free. 
Assume x is a vector of 20 variables and we have 10 equality constraints 
making A a 10 by 20 matrix.  Solving the problem involves choosing 10 of 
the variables to be bound (at zero), eliminating those 10 columns from A 
and solving the reduced linear system, say B*xb = b, for the other 10 
elements of x, xb.  Then sort through the solutions to find the feasible 
solutions that satisfy all of the constraints, x >= 0, and chose from  
them the solution that will maximize the function P.  Taking 20 columns 
of A 10 at a time we will have 184,756 solutions to solve and evaluate! 

@(A): LP Development
LP is an important problem that requires a computer and clever algorithms 
to solve non-trivial problems.  The development of LP algorithms 
parallels the early development of computers.  George Dantzig published 
his first paper on his simplex method in 1947.  LP problems have long 
been studied in mathematics, economics, and business fields, but the 
simplex method and the computer were the big breakthroughs.  Just imagine 
the problem of allocating and distributing limited resources to millions 
of soldiers in WW II.  There are many types of problems that can be 
solved as LP problems, and some have specialized algorithms for their 
efficient solution. 

@(A): LP Examples
The inequality constraint occurs naturally. Many processes are 
irreversible. For example you can burn fuel in rocket at a positive fuel 
flow rate to produce thrust, but you can't unburn the exhaust to refill 
the tanks. A table leg can push on the floor but not pull (unless 
bolted). A rope, cable, or chain can pull but not push. You can't buy or 
sell negative quantities of a new item. You can't start assembling a 
machine before the parts arrive. 
LP problems can also be written in more general forms.  Perhaps the most 
general is: 
    max P = c'x 
    s.t. bl <= Ax <= bu 
         xl <= x  <= xu 
Where bl an xl are vectors of lower bounds and bu and xu are vectors of 
upper bounds. 
The LP forms can be manipulated with simple algebraic operations and by 
adding constraints and "slack" variables.  Most numerical optimization 
problems are set up to minimize a cost function.  Historically, LP 
problems are set up as maximization problems.  If your function P is a 
total cost to be minimized, simply multiply the vector c by -1 and 
maximize instead.  Multiplying the i'th constraint equation by -1 will 
change the sign of all the elements of the i'th row of A, bl, bu, and 
change the direction of the inequalities, but not change x(i).  The i'th 
constraint above is actually two equations and can be written (neglecting 
the subscripts): 
     Ax <= bu 
     Ax >= bl 
To convert them to equality constraints: 
     Ax +  y1 = bu 
     Ax + -y2 = bl 
y1 and y2 are additional variables both >= 0 added to take up the "slack" 
in the inequality equations.  When the constraint is free (i.e. could be 
ignored) the slack variable is >0.  When the constraint is active, the 
slack variable is constrained to zero.  The slack variables are simply 
appended to the vector x and treated as normal variables. 
Lower bounds on x can be removed with a change of variable, x = y - xl, 
without adding more rows or variables. 
    xl <= x <= xu,  becomes  0 <= y <= xu - xl 
Upper bounds on x can be handled by adding slack variables.  The expanded 
problem could look like: 
    Ax = b 
    x + xs = xu 
    x >= 0, xs >= 0 
This can double the length of the x vector and add an equal number of 
equality constraints.  A fair amount of algebraic manipulation is 
possible to get a LP into the form required by the solution software.  
This can significantly increase the problem size.  Good software will use 
the more general forms of the LP program and use a more sophisticated 
solution logic instead of increasing the problem size. 
Mixture problems are probably the easiest to describe for illustrating 
the importance of LP.  Suppose you are producing cans of mixed nuts.  You 
want to find the percentage of each nut to mix and package at the lowest 
cost, or maximum profit.  You check the commodities prices of the various 
nuts available at different times and places.  c(i) could be the price 
per pound of each nut, i, and x(i) would be the percent of that nut to be 
mixed.  One constraint is that the percentages total 100.  The Marketing 
Department may demand no more than 25% peanuts and no less than 5% of 
Cashews, pecans, and almonds.  Each nut may be scored for crunchiness, 
and other aspects of taste to meet other constraints.  Of course no x(i) 
can be less than zero.  You can do the same thing with "real fruit juice" 
drinks.  Mix the cheapest available fruit juices while balancing 
sweetness, acidity, color, taste, and other factors. 
Another type of problem is project scheduling.  Suppose you are going to 
design and build a bridge, or spacecraft. You identify all of the 
tasks that must be accomplished, and then estimate their completion time 
and constraints.  E.g. task 43 can't begin until tasks 16, 17, and 41 
have been completed.  You could then set up a LP problem to schedule each 
task so as to complete the project in the minimum time.  Various other 
performance criteria can be embedded in a LP problem. 

@(A): Non Linear Programming (NLP)
LP is also a special case of Non Linear Programming, NLP.  The NLP 
problem is similar to the LP problem except that the objective function P 
and constraint equations can be nonlinear functions.  NLP is a much more 
expensive problem to solve.  An approach to solving a NLP is to linearize 
the problem at a point to get a LP subproblem.  Solving the LP gives a 
search direction for the NLP problem.  You then advance in the search 
direction until you have made sufficient improvement in the objective 
function or diverged too far from the constraints.  You then correct back 
to the constraints and linearize again.  The sequence is repeated until 
the solution is found. 
@(A): C64 Software?
Computers were not created by secretaries and typesetters.  Although 
computers can do a lot of things, they were created to do Heavy Math.  
The first electronic computer, the Attanasoff-Berry Computer, ABC, was 
built to solve systems of up to 29 linear equations, although it could be 
adapted to solve other problems as well.  The second and third, ENIAC and 
EDVAC, were intended to solve ODEs (Ordinary Differential Equations, i.e. 
computing artillery range tables), as well as more general usage.(ENIAC's 
first operational use was solving a 25 by 25 set of linear equations from 
Los Alamos to see if an atomic bomb might be feasible.  The ABC could 
have solved this problem, but it had a read/write reliability problem and 
Attanasoff was called up for other war related work instead of perfecting 
the ABC.)  And I have already discussed the LP problem. 
Software for the C64 has been readily available and published in the C64 
related literature for solving systems of linear equations and 
numerically integrating differential equations (4th order Runge-Kutta 
being typical).  However nothing is available or published for solving LP 
problems on a C64.  I do recall seeing a one inch ad in some Commodore 
magazines trying to sell software to solve small LP problems on a C64, 
maybe 15-20 equations, but I never read any reviews of it and I always 
suspected it to be poor software.  I intend to plug this hole by writing 
a good LP program for the C64. 
This is Part 1 of at least a two part series on LP for the C64.  Part 2  
will include the presentation of the C64 LP program.  I usually hate 
multi-part articles that could have been published as one large article.  
However, in this case Part 2, and indeed the C64 LP computer program, has 
not been written yet.  Part 2 will be dependent on reader feedback!
No feedback means no reader or user interest and I won't bother to submit 
Part 2.  I have not written a LP program before, or even used one much 
on other systems.  There is a very good chance that some readers will 
have experience with LP software and can offer practical suggestions 
for writing C64 LP software.  I would also like to hear from any reader 
who may have some type of LP problem that they would like to be able to 
solve, perhaps something related to a hobby or home computing application.
Also, someone may be able to point me to an ideal LP reference book or 
even provide suitable source code to examine. 
Choosing a LP solution method for the C64 is not an easy task. 
Appropriate reference books and papers are hard to come by.  There is 
nothing in the CBM literature that I am aware of.  Many books have been 
published on the LP subject.  However, most are old books written for 
business students or for training clerks to solve small problems by hand, 
and they use outdated methods.  These are easily found in local libraries 
and at small colleges.  LP is still an active research area and many new 
journal articles are still being written, as well as new books.  However, 
the focus in on solving VERY large LP problems using sparse matrix 
algebra techniques, and newer methods such as Karmarker or interior-point 
methods.  There is even a LP FAQ available.  Two of the best references 
that I have found so far are: "Computer Solution of Linear Programs", J. 
L. Nazareth (1987), and "Advanced Linear Programming", B. A. Murtagh 
(1981).  The LP source codes that I have looked at were either too crude, 
suitable only for small problems, too poorly documented, or suited only 
for large problems on large computers.  This gives you some idea of where 
I am at, should you want to provide helpful feedback. 
Our C64 (and 128) does arithmetic slowly, but reliably, and has limited 
memory. We would not want to solve a large LP problem with thousands of 
constraints and variables on a C64 even if we could.  Still, we want to 
be able solve problems as large as practical using efficient methods.  At 
the heart of the solution algorithm we must be able to solve an n by n 
system of equations, where n is the number of constraint equations.  For, 
say n = 70, we will need 24,500 bytes to store the full matrix, leaving 
the rest for the OS/language/LP program.  The simplex type solutions 
typically require computation time = K * n~3, so we will not likely want 
to solve any LP problems on the C64 with more than 70 constraints. 
The desire to solve huge LP problems also motivated the development of 
sparse matrix algebra techniques.  Matrices associated with LP tend be 
very sparse.  The idea is to be able to store only the non-zero elements, 
to store them in data structures that can be used effectively by linear 
equation solvers, and  to use larger but often slower external memory 
efficiently.  These codes have a higher overhead in terms of code size 
and computation/FP multiply.  However, these codes can compute the same 
results with substantially fewer multiplies than simpler code for dense 
or full matrices.  They often perform faster overall, at least on scalar 
computers.  Our 6502 can zip through complicated data structures and ML 
code fairly fast compared to the cost of a FP multiply.  Using sparse 
matrix techniques is possible with the C64, but not required.  I think 
the complications of using sparse matrix methods is not warranted in this 
case.  Users wanting to solve large sparse problems are free to disagree. 

@(A): Types of LP Problems
There are several LP solution methods: (primal) simplex, revised simplex, 
dual simplex, primal-dual simplex, Karmarker, and others.  There are also 
many variations among these.  I have chosen the revised simplex method 
for the C64 program.  Some other choices might be better for some types 
of LP problems, and I may also write a primal-dual simplex program. 
In the revised simplex method, the constraint matrix A can be stored 
outside of main memory (on disk or REU) and brought in a column at a 
time. The matrix A can be stored in a sparse matrix form.  This is 
probably a good idea for our slow disk storage, but unnecessary for our 
REU storage.  A square matrix B will be based on a set of n columns of A.  
At each iteration a new column of A is chosen to enter B and an old 
column is re moved.  Each column represents an element of x and the 
objective is to get the unbound variables selected into B  with the 
remaining variables set to their limits.  At each iteration we have to 
solve many linear systems using B with different right hand side vectors 
and then update B to account for the column addition and removal. 
There are several ways to work with the matrix B.  B can be explicitly 
inverted.  The inverse can then be explicitly updated using the Sherman-
Morrison-Woodburry formula, or updated in product form by storing a 
sparse matrix factor that accounts for the update.  The later is 
preferred for sparse implementations, but the storage used grows with 
each iteration and eventually a new explicit inverse of B will have to be 
computed. Both methods are numerically unstable and can have excessive 
growth of roundoff errors, necessitating error checks and occasional 
B can also be efficiently used in an LU factored form.  B = LU where L is 
lower triangular and U is upper triangular.  The updating is difficult, 
especially when exploiting sparcity and external storage.  Bartels and 
Golub (1969) developed a numerically stable way of updating the L and U 
factors that enabled L to be stored externally, with U stored in main 
memory.  Forrest and Tomlin (1972) developed a method that allows both L 
and U to use external storage.  This is the method used in most 
commercial codes for solving large LP problems.  However, it is not 
numerically stable and needs to be monitored and refactored. Sanders 
(1976) developed a variation of the Bartels-Golub method that is stable 
and allows most of U to be stored externally.  Fletcher and Matthews 
(1984) developed a stable method for updating the LU factors explicitly 
in main memory. 
In the Fletcher-Matthews update we have: PBQ = LU.  B is the unfactored 
matrix, P is a row permutation matrix, Q is a column permutation matrix, 
L is a unit lower triangular matrix, and U is an upper triangular matrix.  
L and U are stored explicitly (not in a factored form) in a square matrix 
B.  L and U are first formed using a normal LU factorization (Gaussian 
elimination). P is a row permutation matrix that represents the partial 
pivoting normally used to stabilize Gaussian elimination.  Q is an 
optional column permutation that represents the full pivoting that could 
be done with Gaussian elimination to get better numerical stability.  P 
and Q are completely defined by integer arrays.  In the update, one 
column of B is removed, the rest of the vectors are shifted left to fill 
the gap, and the entering vector placed in the right most column of B.  
L, U, and P are then updated to a stable factorization of the new B 
matrix. Pivoting is still required for stability, but only two adjacent 
rows can be exchanged.  This is a weaker form of stability than Gaussian 
elimination with partial pivoting.  It may be advisable to use some more 
extreme measures to assure greater accuracy, such as preliminary scaling 
of the problem (equilibration), full pivoting in the initial 
factorization, or doing a final refactorization.  Q is not changed during 
the update (no column pivoting for stability), but we will have to keep 
track of where each column of A is located in B (or the LU factorization 
of B).  The update is also cheaper when the column of B removed is 
farther to the right. 
I have chosen to use the Fletcher-Matthews update.  This choice is ideal 
for dense LP problems, but less so for sparse problems.  It limits the 
number of constraints that we can handle.  It also has consequences for 
other program design choices that must be made for the C64 LP program. 
Using the simple standard form keeps the program logic simple, but 
converting problems with inequality constraints and upper and lower 
bounds to standard form will make the problem size bigger.  This will be 
more expensive to solve when not taking advantage of sparcity, and make 
our size limit more significant.  I am leaning  toward solving LP 
problems in the form: 
    Max P = c'x 
    s.t.   Ax = b 
           xl <= x <= xu 
There are many more program design choices to make.  There are different 
strategies for selecting the entering and leaving variables (columns). 
There are different ways to pick a starting B matrix.  There are 
different ways to perform "Phase 1" of the revised simplex algorithm.  
Many of the internal tests of floating point results involve tolerances.  
These tolerances do affect the performance of the program.  However, I 
have only seen arbitrary suggested tolerances.  These tolerances should 
be determined by the floating point precision used, the problems size, 
matrix condition number, and perhaps some problem specific parameters.  I 
have not seen any numerical analyses indicating how to set the 
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.  
   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 -|---+                /  |           |                        |   |  
   |   |           3  /    | 1         |                        |   |  
C -|-----------------O U2-A -----------|- 2   RX          ------|---|- 3 TX
   |                  \    |           |                        |   |  	   
   |                    \  |           |                        |   |  
   |                      \            |                        |   |  
   |                                   |                        |   |  
   |                                   |                        |   |  
   |                                   |                        |   |  
   |         /            /            |                        |   |  
   |       /  |         /  |           |                        |   |  
   | 10  /    |11  6  /    | 4         |                        |   |  
L -|----O U3-E ------O U2-B -----------|- 6   DSR         ---+  +---|- 1 DCD
   |     \    |       \    |           |                     |      |  	    
   |       \  |         \  |           |                     |      |  
   |         \            \            |                     |      |  
   |                                   |                     |      |  
   |                                   |                     |      |  
   |         /            /            |                     |      |  
   |       /  |         /  |           |                     |      |  
   | 12  /    |13  8  /    | 10        |                     |      |  
K -|----O U3-F ------O U2-C -----------|- 8   CTS         ---|------|- 7 RTS
   |     \    |       \    |           |                     |      |  	    
   |       \  |         \  |           |                     |      |  
   |         \            \            |                     |      |  
   |                                   |                     |      |  
   |                                   |                     |      |  
   |         /            /            |                     |      |  
   |       /  |         /  |           |                     |      |  
   |  8  /    | 9 11  /    | 13        |                     |      |  
H -|----O U3-D ------O U2-D -----------|- 1   DCD         ---+------|- 4 DTR
   |     \    |       \    |           |                            |  	    
   |       \  |         \  |           |                            |  
   |         \            \            |                            |  
   |                                   |                            |  
   |                                   |                            |  
N -|-----------------------------------|- 5    SIG GND    ----------|- 5   
   |                                   |                            |  
   |  +5V                              |                            |  
2 -|----+------------+          +------|-  PROTECTIVE GND   --------|-    
   |    |            |          |      |                            |  
   |    |            |          |      |                            |  
   |  --+-- 0.1uF    |       -------   |                            |  
   |  --+-- 10V      |         ---     |                            |  
   |    |            |          -      |   ********************************* 
A -|----+            |                 |   *                               *
   |    |            |                 |   *    U-1    1488   RS-232 XMTR  *
   | -------         | 14 +----+ 7     |   *                               *
   |   ---           +----| U2 |--+    |   *    U-2    1489   RS-232 RCVR  *
   |    -            |    +----+  \    |   *                               *
   |                 |            \    |   *    U-3    7404   HEX INVERTER *  
   |                 | 14 +----+ 7\    |   *                               *  
   |                 +----| U3 |--+    |   *    DIODES  SIGNAL DIODES      * 
   |    |\  |             +----+  |    |   *            WILL WORK HERE     *
   |    |  \|                     |    |   *                               *
10-|----|   |---+--------+        |    |   *    NOTE: THE RS-232 VOLTAGE   *
   |    |  /| + |        |     ------- |   *          BE APPX +/- 10 VOLTS *  
   |    |/  | --+--      |       ---   |   *          WHICH IS OK TO USE   *
   |   100uF  --+--   14 |        -    |   *          PER RS-232 STANDARD  *
   |   15V      |     +--|--+          |   *                               *
   |            |     |     | 7        |   *                               *
   |         -------  | U1  +----+     |   *********************************  
   |           ---    |     |    |     |  
   |            -     +--|--+    |     |  
   |                   1 |    -------  |  
   |                     |      ---    |  
   | 120uF               |       -     |  
   | 15V        |  /|    |             |   *********************************  
   | +||        |/  |    |             |   *                               *  
11-|--||----+---|   |----+----+        |   * Commodore User Port to RS-232 *  
   |  ||    |   |\  |         |        |   * Adaptor designed by Stephen   *
   |        |   |  \|         |        |   * Coan, Version 2, 03-NOV-83.   *
   |        |                 |        |   *                               *
   |    --------    100uF  ---+---     |   * This general design has also  *
   |     \    /     15V    ---+---     |   * been used in other devices    *
   |       \/               + |        |   * where a negative voltage was  *
   |    --------              |        |   * not available for the RS-232  *
   |       |                  |        |   *                               *
   |       |                  |        |   * The  user port is a 44 pin    *
   |       +-------+----------+        |   * edge connector and the PC COM *  
   |               |                   |   * port is a female DB 9 (as on  *
   |               |                   |   * on a joystick)                *
   |            -------                |   *                               *
                  ---                  |   *                               *
                   -                   |   *                               *
                                       |   *                               *
                                       |   *********************************  
You'll want to follow the instructions for the NULL modem cable for the  
sake of this project, so use the pin settings on the right hand side.  
@(A)3: Part III: Setting up the LINUX box  
You should know now that if you don't have root access to the LINUX  
machine, you should give up now.  Secondly, you need to have the machine  
already configured with respect to its network hardware and the telnet  
daemon. The popular slackware distribution sets all this up during its  
installation process.  
The first step will be to create the above shell "new_minicom" and its  
accompanying configuration "cua0".  
1. Log on as root, and enter the  /usr/bin directory.  
2. Run minicom by entering its name followed by the name of the port  
   you'll be using.  For instance, enter:  
      "minicom -l -o cua0" for com port 1.  
      "minicom -l -o cua1" for com port 2.  
3. Enter CTRL-A followed by 'z' to view a menu of options.  
4. Enter CTRL-A,P for communication parameters.  You'll want the  
   parameters to be: 2400 baud, 8 bits, no parity, 1 stop bit.  Exit this  
   menu when done.  
5. Enter CTRL-A,T for terminal parameters. ANSI, Backspace, and enabled  
   are fine settings.  
6. Enter CTRL-A,O for configuration parameters.  Select the third option- 
   communication port setup.  Make sure the serial device reads "/dev/cua0"  
   for com port 1 or "/dev/cua1" for com port 2.  Baud/parity/bits should  
   read as you set them above.  Hardware and software flow control should  
   BOTH be turned OFF!    
7. Exit back to the parameters menu and select "modem and dialing."  The  
   reset and initialization strings should be blank.  Auto baud detect,  
   hang-up drops DTR, and modem has DCD line should all read YES.  
8. Exit back to the parameters menu again and hit the option "save  
   configuration as cua0" (or cua1 if you are using com 2).  
9. Exit minicom altogether by entering CTRL-A,X.  
10.We will make this our TEMPORARY new_minicom by entering from the  
      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- 
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)  
      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 : "?"' ]   
        kill -9 $pid  
      sleep 60  
[!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:  

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  

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:   

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's 
see what topics are showing up this month: 
@(A): To C or Not To C, That Is The Question 
Over the past few months, there has been some discussion of the C 
programming language, a common language used in the development of many 
UNIX, Windows, and Macintosh applications.  We're not exactly sure what 
sparked the discussion, but GNU C came up very early.  For those who 
don't know, the Free Software Foundation (FSF) is an organization that 
sponsors the creation and maintenance of many fine applications and  
utilities.  One such group of applications are known as the GNU (GNU's 
Not UNIX) applications.  Many people use the GNU utilities because they 
can be compiled and run on many different machines.  One of the more 
popular apps is GNU C, which can be run on many computer systems as well 
as create object code for all the supported environments.  The system is 
highly customizable, which explains why there was talk of both porting 
GNU C to the Commodore 64, and/or using a DOS or UNIX version of the 
compiler to create object code that would run on the C64.  The thread 
has drug on for quite a while, but seems to be winding down.  We're not 
sure there was a general consensus, but many remarked that GNU C is 
simply too large to run on a C64.  In addition, the assumptions it makes 
about the supported hardware architectures makes cross-compilation a near 
impossibility.  Still, many are searching for a way to bring ANSI C 
to the Commodore system.   
Success may come from CMD, as Doug Cotton mentioned that they were 
looking into a 65C816 cross compiler with the hopes of porting a small 
free C compiler to the 64 environment.   
@(A): The SuperCPU this and the SuperCPU that.... 
Now that the SuperCPU has started shipping from CMD, the newsgroup has 
been abuzz with questions and thoughts about the units.  However, it 
seems the group is always one step ahead of CMD.  Now that the units have 
started appearing on user's doorsteps, questions about the planned 128 
unit and the SCPU RamCard have dominated the topics.  The fact that the 
64 unit actually contains 128 kB or RAM confused some folks, who wanted 
to know why they were paying for this extra RAM, and how they could take  
advantage of it now that they have it.  Then, as fast as folks described 
that the extra RAM was actually used to "shadow" the ROM so that the 
KERNAL could run at full speed, the topic switched from present RAM to 
planned RAM.   
Questions ranging from how much RAM would be available on the RamCard, to 
how fast the RAM could be accessed, to what style of modules could be 
used have been debated.  CMD, the developers of the RamCard, acknowledged 
that the full address space of 16 megabytes would be available on the 
unit and that they would try to provide speeds as fast as economically 
possible. CMD has also stated that they will be utilizing the same 30 pin 
SIMM technology that is used in the company's RamLink product.  Some 
Usenetters debated that 72 pin SIMMs were becoming more cost effective, 
but CMD countered that only those that upgrade to the full capacity of 
the unit would realize any cost savings.   
The substantial increase in power the SuperCPU provides the programmer 
brought many questions and comments on planned or potential new operating 
systems for the unit.  As of yet, none have surfaced, but only time will 
tell.  For its part, CMD has made GEOS compatibility a staple of the new 
unit, so that OS will run correctly.  At least one commercial venture, 
PROTOVISION, is allegedly planning an all GUI OS for the unit.  See 
Newsfront (Section: news) for more information.		   
Brett Tabke, of PHD Software Systems, announced that he is busy upgrading 
his Karma assembler for the 128 to run on the new unit and praised the 
virtues of the new opcodes, modes, and options available when operating 
the unit in "Native mode."  This started some discussion on writing code 
that only runs on the new processor.  The sides were split almost 
immediately, as all noted that while the new applications would run very 
well on the SCPU, they would not run at all on a stock 64.  Proponents 
noted that new software demands the purchase of the SCPU, while purists 
maintained that that would limit the software to a small market segment.   
@(A): The "Virtual 1541"! 
Now, before you start thinking of 3-dimensional plastic cases and track 
0 head knocking in quadrophonic sound, let's explain the topic.  Many 
users have expressed a desire to virtualize the IBM PC as a glorified 
1541 drive with full emulation.  The closest thing as yet is the 64NET 
package, which allows you to load and save programs to the IBM PC hard 
drive like it was a regular CBM drive.  The drawback to 64NET is its non-
standard access method. Before you can access the emulated CBM drive, you 
have to load special software on the 64 and use a special user port 
cable.  So, for users who demand perfect emulation, no choices exist yet.  
The lack of options haven't dented the dreams of many who outlined the 
"technical specifications" of such a virtual disk drive.   

@(#)toolbox: Menu Toolbox III 
             by Jeff Jones (
             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. 


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
   b'lattice  .byt 0,39,0,24,9,10,15,12  

@(A): Instant Pages
   SYS 32768+198,PAGENAME$, items,list$..., hotkeys$
Since it's by far the easiest to use, we'll discuss instant pages
first. A page is a computer screen with a user interface setup. Instant
page allows you to create with one SYS a screen with a tiled background, a
title bar, and a centered working menu complete with hotkeys. Consider the
following code: 

   10 T$="M  Y   D A T A B A S E"
   20 A$(1)="OPEN DATABASE       (O)"
   30 A$(2)="DEFINE FIELDS       (D)"
   40 A$(3)="ADD RECORD          (A)"
   50 A$(4)="SEARCH RECORDS      (S)
   60 A$(5)="PRINT RECORDS       (P)"
   70 A$(6)="RETURN TO LOADSTAR  (Q)"
   80 A$(7)="odaspq"
   90 sys32768+198,T$,6,A$(1),A$(2),A$(3),A$(4),A$(5),A$(6),a$(7)
   100 onf%gosub200,300,400,500,600,700	  
   110 goto 10
Make sure the number of items in your list$ matches the number declared
with ITEMS. If you RUN this program, a typical LOADSTAR type program will
pop up on the screen: 

   M Y   D A T A B A S E 
   OPEN DATABASE       (O)
   DEFINE FIELDS       (D)
   ADD RECORD          (A)
   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


       0        BLACK
       1        WHITE
       2        RED
       3        CYAN
       4        PURPLE
       5        GREEN
       6        BLUE
       7        YELLOW
       8        ORANGE
       9        BROWN
      10        LIGHT RED
      11        DARK GRAY
      12        MED GRAY
      13        LIGHT GREEN
      14        LIGHT BLUE
      15        LIGHT GRAY

This chart applies to all subsequent color values mentioned in the

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 


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,m 
This command will pop up a scrolling (if necessary) menu on your screen.
Your users will be able to CRSR up and down or page with the + and - keys.
You should print this somewhere on the screen so that your users will know.
Here's what the parameters mean: 

X1 is the upper left hand corner of the requestor box. 

X2 is the right extreme of the menu. Any menu item that exceeds the width
defined by X1 and X2 will be truncated. 

Y1 is the top row of the menu, 0- 20. 

Y2 is the bottom row in the menu. Y2 determines how much of your screen
will be taken up by the menu. 

R stands for REVERSE mode. If you want all the items in the menu to be
printed in reverse, put a 1 here. Highlighted items will appear unreversed.

C is the color of the menu and all unhighlighted menu items. 

H is the color of the highlighted (current) item. 

S is the color of selected menu items. 

O is the offset, in case you've sectioned off your menu items, generally
zero. If you want to pop into the menu at a particular point (say at the
last item selected which you've preserved), use offset to do so. The rest
of the menu is still accessible. 

L is the limit or the highest menu item allowed. Note that this will
usually be one less than f% when you use the Rack Em Up command. 

M is for MULTI MODE, which allows the user to be able to select more than
one item. Outside of a file requestor, there are few uses for this. Make
this a 0 for a normal single item and 1 for multi-item selection ability.
Items are selected with RETURN or SPACE. To exit a multi-select menu you
must press F1. Your program should inform the user of this if they are in
the multi item mode.

When RETURN is pressed in single mode, the item number is returned in F%. 

>From ML: 

            ldx <parameters
            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,n 
Sometimes you may have a regular menu and a directory set up in memory.
You may want to set the proper mode for FIND AND CLEAR with this command
before using it. N is 0 for normal retrieval and 1 for file requestor

@(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
   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. 


   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
   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
   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:


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
   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
   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
   params .byt x1,x2,y1,y2,color  

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
   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
   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. 


   lda page


   lda page


   lda page

@(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's 
plastic front panel was accomplished by four screws and three pieces of 
plastic. First, I used masking tape to cover the CMD HD's metal case on 
the front side. This front side already has holes drilled on it by CMD or 
some OEM manufacturer. I used an X-Acto® knife to cut holes in the 
masking tape, popping through the holes in the metal case. When finished 
with the poking of the holes in the masking tape, I have a 'drill image', 
so I peel off the tape from the CMD HD's metal case, and affix it to the 
C128D's plastic front panel on the left side. Making sure that 
everything's aligned, I proceeded to drill holes, following the 'drill 
image', in the plastic front panel. After peeling off the masking tape, 
and then doing a test fit with the CMD HD's front panel with its 
protruding LEDs, and swap buttons,  it was a perfect fit! I then made the 
connection more solid with four screws and pieces of plastic, by 
attaching the CMD HD's front panel to the left side of the C128D's 
plastic front panel. Then, I superimposed the sticker overlay for the CMD 
HD perfectly with the LED's and the push-buttons, and used spray-on glue 
to make the overlay a permanent part of the C128D's plastic front panel.

@(A): Preparing the FD-4000
As for the FD 4000, I used a saw to cut off portions of the plastic front
panel of the C128D where the internal 1571 disk enclosure used to be, cut 
in correct dimensions to fit the FD 4000. It was still rough, so I used a 
file to smooth the edges, on a gradual basis, until the FD 4000 made a 
snug fit. I measured the front cavity of the FD 4000 and used those same
measurements to make the cut on the C128D's plastic front panel on the 
right side. As you can see from the picture, there is little room for 
error, especially at the top of the plastic front panel. Generally, the 
cut was made as far as to the right side of the C128D's plastic front 
panel as possible.

@(A): Preparing for the CMD Hard Drive
Now, to the internals of the C128D. I had to move the power supply
counterclockwise 90 degrees to make room for the CMD HD. I quickly ran 
into a snag, as the power connector between the PCB and the power supply 
was too short. I had to cut off all the wires on the power connector, 
then enlarged it by soldering all wiring to a cannibalized wiring from a 
power supply wire to both ends of the power connectors. For further 
clarification, a close-up of both ends is supplied. The cannibalized 
power wiring was very convenient, as they were color marked, and it was 
easy for me to make sure that the wiring corresponded with each end of 
the power supply connectors. Next, I spliced the +-12 VDC wires on the 
power supply connector to supply continuous power to the fan. Usually a 
fan comes with black and red wires. Splice the black wire of the fan to 
the black wire of the power supply. Splice the red wire of the fan to the 
yellow wire of the power supply. Next, the fan was attached to the power 
supply with screws, to the right of the power cord connector.

The structural improvements to the PCB was made by bending the PCB power
connector end at a 45 degree angle, for it would collide with the 
position of the CMD HD's PCB. Last, I connected one end of the entire 
power supply to the back edge of the C128D's metal case. This was 
accomplished by bending the end of the power supply at a 90 degree angle 
and screwing it together to the metal case of the C128D. However, one end 
of the power supply remained unsupported and would tip over onto the PCB, 
causing possible malfunctions for the C128D. So, a makeshift support was 
propped upon the C128D's PCB to support the remaining end of the power 
supply. This support, like all other supports used, were fitted with 
black electrical tape at the bottom to prevent shorts on the PCB. The 
massive heat sink covering the VIC - II chip and the 80 column display 
chip supported the other end of the power supply.

@(A): Installing the HD

With the power supply situated 90 degrees counterclockwise, we now have 
room to insert the PCB for the CMD HD 85 megger. I took the CMD HD's PCB 
out of its original metallic case that CMD supplied. (NOTE: If you do 
that, you may void CMD's warranty on the unit.) But the CMD HD's PCB 
could not just sit atop the C128D's motherboard, for there may be 
accidental electrical shorts or other problems. So, the CMD HD's PCB just 
hovered above the C128D's motherboard by approximately 1/4 of an inch. 
This was accomplished by erecting two support beams above the C128D's 
motherboard. The beams were obtained at a hardware store. They are 
aluminum and are easily malleable with pliers. I screwed down one end of 
the beam to the middle edge of the motherboard, leaving the other end of 
the beam covered with electrical tape. I could have screwed down the 
other end, but might have cut the motherboard in a way that Commodore 
never intended and screwed up the whole thing. All supports listed in 
this article are screwed down on existing 'drilled holes' in the c128d's 
PCB. Please note that the support beam is nearly aligned with the 
motherboard's power connector. I put electrical tape on top of the 
support beam, as this top will support the CMD HD's PCB. This is to 
ensure a smooth operation of the unit without any electrical shorts or 
other problems.  Also, look at the rear view of the support beam in the 
picture, for it can give you a clear idea of how tall it is in relation
to the C128D's motherboard.

As for the other support beam, it is screwed down on both ends to the
C128D's motherboard on the far left side. This support beam is taller 
than the one explained earlier. The reason is that the CMD HD's PCB will 
be screwed on that support beam, so this support beam would have to be 
aligned parallel to the top of the first support beam. Then the second 
support beam is covered with electrical tape and two holes are drilled at 
both ends, which align perfectly with the CMD's HD PCB's drilled holes. 
(See photo for further clarification.)

Finally, to attach the CMD HD's PCB to the two support beams, I made sure
that both beams were in alignment and supported the PCB in a level 
fashion, almost parallel to the C128D's motherboard. I attached one end 
of the CMD HD's PCB, which has no cable connectors, to the second support 
beam on the far left of the C128D's motherboard. Two screws were used to 
make a secure connection to the support beam. The other end of the CMD 
HD's PCB, the one with all the cable connectors, rested on the first 
support beam, but was not screwed down. It could be done, but as the PCB 
was already secured, I didn't bother. The cables running out of the CMD 
HD's PCB are in a tight space, due to the FD 4000. As you may note from 
the picture, there is no room for the internal 1571. If you decide to do 
an internal CMD HD operation on your C128D, you must sacrifice your 
internal 1571 drive.

@(A): Installing the FD

With the CMD HD PCB out of the way, I began work on the FD 4000. Before 
the FD 4000 was inserted, I cut off pin one of the C128D's chip U113. 
This pin gives a signal that the internal 1571 drive is in existence. 
With that pin cut, the C128D no longer recognizes the existence of the 
internal 1571 drive. It will, however, recognize any peripherals using 
the serial bus, as I use a external 1571 as Drive #8 in my system. I took 
the FD 4000 mechanism and the motherboard (it's built as a single unit) 
out of its original case that CMD supplied. (NOTE: Doing so may void 
CMD's warranty on the FD x000 unit.) I used trial and error to position 
the FD 4000 drive in the C128D's metal casing. This is to ensure that the 
FD 4000 would not protrude too far out of the C128D's plastic front 
panel, or intrude too far inside the C128D's plastic front panel. As you 
can see from the following picture, the FD 4000 unit protrudes from the 
C128D's metal case by approximately 1 1/2 inches.

Lastly, I attached a support beam to the bottom right in front of the
C128D's metal case. This involved some cutting on the edge of the bottom 
of the C128D's metal case in order to make the FD 4000 fit the C128D's 
metal case. The bottom edge of the C128D's metal case was not cut out 
completely, rather, it was bent inwards with pliers, creating a small 
surface for the FD 4000 to rest upon. Again, trial and error was used to 
determine how much to cut and bend the bottom edge, so that the FD 4000 
unit would fit the C128D's metal case and the plastic front panel. 
Finally, the FD 4000 unit was screwed upon the support beam. This FD 4000 
also rests upon the bent in bottom edge. This creates a stable surface 
for the FD 4000 unit to operate without having to insert a second support 
beam onto the C128D's motherboard to support the other edge of the FD 
4000 unit.

Finally, I connected the cables to the CMD HD's PCB and the FD 4000, and 
attached the ribbon cables to the CMD HD's PCB, including that of the 
hard disk drive and the front panel controls. I extended the length of 
the power-on LED wire for the C128D's power supply. This extension was 
made by adding more wire and resoldering the connections. This was 
necessitated because the 90 degree turn of the power supply made all the 
wiring too short. :( Ah, the wisdom of CBM to cut costs by making 
everything short and sweet! I made sure that the CMD HD and the FD 4000's 
on/off switches were already in the ON position. Last, I bought Velcro® 
from an art supply store, and liberally applied it to the CMD HD 85 MB 
drive mechanism. The opposite end of the Velcro® attachment was pasted on 
the inside of the top metallic case of the C128D. This was positioned 
roughly 3 inches from the front edge of the top metallic case. Trial and 
error was used here to determine the optimum measurements. The CMD HD 85 
mechanism was then attached to the inside of the top metallic case of the 
C128D unit by Velcro®. This is a safe method, for the CMD HD has been 
running for almost a year without any glitches. Close the case carefully 
(The HD is on the case, after all!), and attach all the power to a power 
control center with individual switches. The individual switches then can 
be used to control a specific peripheral such as the internal FD 4000 or 
the CMD HD 85, without having to open the unit to access the off/on 
switches, or drilling holes in the case of the C128D to attach these same 
switches. Convenient, isn’t it?

@(A): Lessons Learned

Before concluding the article, it seems possible that one could put a 
1581 drive in lieu of the FD x000 drives. It's possible, but I do not own 
a 1581, so I really cannot comment. I would guess that the general 
guidelines for the FD x000 drives would apply to the 1581. Granted, all 
of this looks quick and dirty. But when I first started out with this 
project with Al Anger, we didn't have step-by-step manuals, or other 
references.  It was truly a new territory for me. (Al has already done 
such hacks for his C= computers before me, and his experience was 
invaluable.) However, there were some bloopers.  One, the c128d died upon 
powering up. It turned out that the fan +- 12 VDC wiring was connected to 
the wrong wire, and shut down the system. With that fixed, the c128d 
powered up okay, but now, the CMD HD died. If that wasn't frustrating 
enough, it was difficult to find out what went wrong, and I was wondering 
if the FD 4000 would be next.  The culprit was a break on the CMD HD PCB. 
I accidentally drilled a cut on the PCB. With some soldering, I fixed it 
by building a bridge between the break in the CMD HD PCB. Whew! 
Everything now worked, and has worked since. Consider those bloopers 
invaluable lessons learned in dealing with sensitive electronic 

@(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
   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.
   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.
   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
   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
   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
   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
   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

o  Commodore Pictures
   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
   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. 
   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) 
   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. 
   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
   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 
   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
   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
   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
   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
   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
   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

o  Commodore Connection
   Geoff Sullivan's  personal site offers articles and software to make
   using a C64 or 128 more enjoyable.  Besides links to other sites, 
   he also offers up Perfect Print fonts and articles on how to expand your
   REU to 2MB and how to build a simple RS-232 converter. Of special
   interest is a collection of customized GEOS mouse pointer icons and a
   program called QWIKSTASH that will copy files in GEOS on bootup.
   C=H gripe: Great resource, but little information about Geoff and how
   he uses his CBM.

@(#)jb: Jim Butterfield: The Commodore Guru - An Interview 
        by Jim Lawless (
@(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:
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   0   0   (X means either 1 or 0)
        HIRAM   0   0
        GAME    1   X
        EXROM   X   0
Q $1C1) What is the first thing that the C64 (and VIC) KERNAL does upon
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
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 
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
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 
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
Q $1DD) What is the largest integer value that Commodore BASIC can handle?
A $1DD) Again, this was a little ambiguous.  I was looking for the maximum
        value that an integer variable can hold, which is 32767, but line
        numbers (which are integers) can be up to 63999.
Q $1DE) What is the ONLY Commodore Editor key not affected by "quote mode"

A $1DE) The DEL key.  I would have answered return, but the 64 PRG spells
        it out that only this key is unaffected.
Q $1DF) What is the range of RND?

A $1DF) 0.0 <= RND < 1.0, or [0,1).  Both mean that the range is from 0 to
        1, including 0, but not 1.0.

        The "VIC Chip" Trivia Set

Q $1E0) We all know that VIC stands for Video Interface Chip.  However,
        in what computer was a VIC chip first used?
A $1E0) The VIC-I was used in the VIC-20.

Q $1E1) What is the difference between the 6566 and 6567 VIC chips?
A $1E1) The 6566 has fully decoded address lines.  The '67 has multiplexed
        address lines for connection to DRAM.
Q $1E2) On what computer would one find a VIC-II chip?
A $1E2) C64, C64C, 64SX.
Q $1E3) On what computer would one find a VIC-IIe chip?
A $1E3) C128, C128D
Q $1E4) On what computer would one find a VIC-III chip?
A $1E4) C65 (64DX)
Q $1E5) Versions of each VIC chip exist for each computer model/video
        standard combinations suppoerted by Commodore.  What model/video
        standard would the 6569 work with?
A $1E5) C64 type machine using the PAL-B standard.  Note that there are also
        PAL-N and PAL-M standards, which required different VIC-II models.
Q $1E6) How much memory could be directly addressed by a VIC-II chip?
A $1E6) 16 kilobytes.
Q $1E7) How many control registers does the VIC-I contain?
A $1E7) 16 control registers.
Q $1E8) How many control registers does the VIC-II contain?
A $1E8) 47 control registers.
Q $1E9) The VIC-II series introduced Movable Object Blocks to the
        Commodore programmer.  By what common name are MOBs known?
A $1E9) "sprites"
Q $1EA) What are the dimensions of a MOB?
A $1EA) 24 dots wide by 21 tall.
Q $1EB) What difference between the VIC-I and VIC-II causes VIC-II equipped
        systems to potentially operate slightly slower than VIC-I equipped
        systems, all other items held constant?
A $1EB) Even with all of the fancy features of the VIC-II (like sprites)
        turned off, the VIC-II doesn't have quite enough time to do all
        of its work, which includes refreshing the DRAM ICs in addition to
        the work of drawing the screen and reading the Paddle inputs. So,
        every 8th rasterline, the VIC has to "steal cycles" from the CPU to
        fetch character data from RAM.  Since this time is not available to
        the CPU to execute programs, a simple program written on each
        machine will execute faster on the VIC because its CPU doesn't 
        have to fight the video IC for cycles.
Q $1EC) In addition to supporting graphical output to an external display,
        what other vitally important function do the VIC chips (starting
        with the VIC-II) perform?
A $1EC) They refresh the Dynamic RAM of the computer periodically.  If the
        DRAM is not refreshed, it would lose its contents.
Q $1ED) Many people know that the VIC-II can deliver up to 320x200
        resolution without much trouble.  What is the maximum resolution of
        the VIC-III chip?
A $1ED) According to the specifications, it is supposed to handle 1280H by
        400V interlaced and non-interlaced.  
Q $1EE) Between the development of the VIC-II and the VIC-IIe, there was a
        related, though not very similar video IC developed for CBM machines.
        Name its TLA (three letter acronym).
A $1EE) TED (Text Editting Device).  It was developed for the 264 series
        (Plus/4, C16).
Q $1EF) How many pins does a VIC-II chip contain?

A $1EF) Every VIC-II has 40 pins.  
        The "BASIC Tokens" Trivia Set
        The following questions refer to the way Commodore "crunched"
        BASIC programs by substituting one of more bytes called "tokens"
        for BASIC keywords in a BASIC program.  The resulting code was 
        smaller, since multiple character keywords were internally replaced
        with smaller length tokens.
        (All the answers were taken from _Commodore Magazine_, April 1987,
        pp 82-85.)
Q $1F0) Commodore BASIC tokens start at what number?

A $1F0) $80, or 128.
Q $1F1) BASIC 2.0 defines tokens without gaps up to $ca. What keyword
        is represented by $cb?
A $1F1) GO.
Q $1F2) Why is the token for PI strange?
A $1F2) It is token $ff, or 255.
Q $1F3) All versions of Commodore BASIC contain at least a subset of
        tokens.  At what number does this subset end?
A $1F3) $ca.
Q $1F4) BASIC 4.0 defines tokens beyond $cb.  What is the last token
        included in BASIC 4.0?
A $1F4) $da.
Q $1F5) There was a BASIC 4.0+ included in the B series.  It extends the
        BASIC with some new commands not in 4.0.  What token range are
        these new commands at?
A $1F5) $db-$e8.
Q $1F6) When a user plugs a Super Expander into a Commodore 64, he or 
        she gains access to 25 new BASIC commands.  The tokens for these
        commands are defined differently from the previous tokens.  What
        is the difference?
A $1F6) They are two byte tokens of the form: $fe XX, where XX ranges from
        $80 to $9e.
Q $1F7) When the Plus/4 and C-16 was developed, new commands were added
        to BASIC.  In addition, many commands from BASIC 4.0 were also
        included.  Unfortunately, the tokens for BASIC 4.0 commands included
        in these new machines differed from those in the older BASIC 4.0.
        If a user lists a program written in BASIC 4.0 on a Plus/4, what 
        will the BASIC 4.0 CONCAT command show up as?
A $1F7) CONCAT is $cc in BASIC 4.0, and is RGR in BASIC 3.5.
Q $1F8) What is the last token used in the Plus/4 line?
A $1F8) $fd.
Q $1F9) If you list a program written on the Plus/4 with the keyword
        SCALE on a BASIC 4.0/4.0+ machine, what happens?
A $1F9) SCALE on BASIC 3.5 is token $e9, which is not in the BASIC 4.0(+)
        list.  The PET will crash.  Interstingly, tokens above $e9 do not
        crash the PET.
Q $1FA) When the C128 was released, it shared many tokens with the Plus/4.
        However, at $ce, the 128 differs from the Plus/4.  The Plus/4 token
        $ce corresponds to RLUM, but the C128 uses the token another way.
        What is peculiar about the C128 usage?
A $1FA) The C128 uses $ce as a prefix byte for a range of two-byte tokens
        that range from $02 to $0a.
Q $1FB) The C128 shares many keywords with the Super Expander cartridge
        for the C64.  As with the Plus/4, though, keywords don't map to
        the same token.  To what token does the C128 keyword SPRITE
        (token: $fe $07) correspond to on the Super Expander equipped 64?
A $1FB) $fe $93.
Q $1FC) What keyword was not included in BASIC v1, but was included in
        BASIC v2?
A $1FC) GO, token $cb.
Q $1FD) The C128 defines all the tokens from $fe $02 to $fe $26, with the
        exception of two tokens.  Name one of them.

A $1FD) $fe $20 and $fe $22.
Q $1FE) The Plus/4 line had the ability to add keywords dynamically when
        running cartridges.  At what point in the token list do these
        "added" keywords show up in the Plus/4 line?
A $1FE) They use $fe as a prefix byte for two-byte tokens.
Q $1FF) If a programmer want to write a single program to run on a
        B128, a plus/4, and a C128, what version of BASIC is the lowest
        common denominator?
A $1FF) Unfortunately, BASIC 2.0 is it.

          The C128 Set:

Q $200) How many general purpose central processin units does a C128
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
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
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  

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  
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  
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 
     5       $a000-bfff      x = 0       x = 160      x = 0      x = 192 
     3       $6000-7fff      x = 0       x = 96       x = 0      x = 128 
     2       $4000-5fff      x = 0       x = 64       x = 0      x = 96 
     1       $2000-3fff      x = 0       x = 32       x = 0      x = 64 
Here's an example: to save block 5 (the most commonly used memory block)  
you do the following steps.  
0. Follow the previous instructions, to get to this point. (The  
   cartridge has been inserted, power is now turned on, and the autostart 
   has been defeated. The Vic20 is showing you its normal BASIC power-up  
1. Type the following, hitting RETURN after each line. (Type  
     POKE 43,0                  (and return) 
     POKE 44,160                (and return) 
     POKE 45,0                  (and return) 
     POKE 46,192                (and return) 
     SAVE "FILENAME.EXT",8      (and return) 
2. Wait for the disk drive to finish its saving process. (Be patient.) 
3. If you have more 8k blocks to copy, repeat all the previous steps,  
   but adjust the POKE statements, according to the information in the  
   chart. Note that the pokes to 43 and 45 are always zero; even page  
   increments. Also, note that the computer will get confused or lock up if  
   you try to copy another block of memory without starting completely over. 
4. When the busy light turns off again, turn the Vic20's power back  
   off. Remove the cartridge, and if you have a modified 8k or 16k RAM  
   expander insert it or activate it. If you have a 32k RAM expander, you  
   can use it. 
5. Load the disk's directory up, (or rewind the tape), and see if the  
   file has been properly saved to the disk. It should show a file size of  
   33 blocks, if all has gone well ... 32 blocks x 256 bytes each = 8k, plus  
   one block for the disk drive's overhead and the file loading address. 
6. If everything looks fine so far, just load the newly created "image" 
   into RAM memory, to see if it runs. Remember a few tips: as with the C64,  
   you always have to use the  ,8,1  loading conventions for any machine  
   language program to reload into memory back where it came from. 
   Also, to properly load up an image that has more than one 8k bank, you  
   will have to type NEW after each load to reset some memory pointers.  
   Otherwise, it moves BASIC to where the cart now is and gets confused. So  
   multi-loads are: (A) LOAD"file1",8,1   (B) NEW   (C) LOAD"file2",8,1 
7. The last step is starting up the image, to see it in all its new  
   glory! To do this, all you have to do is (A) press the reset button  
   you've installed yourself, or if you don't have one installed, (B) type  
   the following "reset" command into the computer...  SYS 64802  (and  
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
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:

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 by