bllklly@uwmacc.UUCP (Bill Kelly) (03/18/85)
Ready Newsletter Digest 14 February, 1985 Vol 3, No 2
Contents:
C64 Power Supply Problems
Assembler: Why is it and What is it (good for)?
Tech Note #7 -- The Input Statement
Magazine Reviews, Part 3
--------------------------------------------------------------------------
Subject: Masthead
From: The Editor
This issue is a bit late, coming out just before the March issue.
I'm trying to post this in digest form for readnews fans--the one
advantage they have over us who use rn! Let me know whether you prefer
this format. --Bill
This information, in a somewhat different form, appeared in READY, the
newsletter of the Madison Area Commodore Users Group. You can contact the
editor through network mail as ...uwvax!uwmacc!bllklly, or through US Mail
at 2721 Granada Way #2, Madison WI 53713.
Copyright 1985 Madison Area Commodore Users Group. All rights reserved.
Published on a monthly basis by MADISON AREA COMMODORE USERS GROUP,
3634 Swoboda Road, Verona, WI 53593.
Material appearing in READY is copyrighted and therefore cannot
be used without written authorization. The exception is that users
groups may publish articles without prior authorization if credit is
given to the author and Ready, and a copy of the newsletter is
sent (after publication) to the editor at the address listed above.
---------------------------------------------------------------------
Subject: C64 POWER SUPPLY PROBLEMS
From: Jim Etheridge
Check the following scenario to see if anything like it has happened
to you or another C64 user you know:
The computer power supply switch is on, but the monitor screen is
dark with blinking white dashes randomly appearing. The red power-on
light is off on the computer, but both red and green lights on the
disk drive are on and the drive is running. Turning the computer power
switch to off causes a normal blank monitor screen, and turning it
back on causes a repeat of the dark background and blinking dashes.
These are the symptoms of another common Commodore hardware glitch,
this time caused by a faulty power supply component.
I am not well versed in electronics jargon, but this component has
been variously described to me as: 1) a resistor, 2) a transistor,
and 3) a voltage regulator. These names came from three electrical
engineers that held the item in their hands, searched through catalogues
tracing its number, and glibly backed up their choice of handle for
it with a shrug. I call it a Whatzit, and since it does have a number,
it will be referred to as the 3052 Whatzit from here on out.
The 3052 Whatzit is easy to find in the power supply. After removing
the four power supply casing screws and removing the top (please don't
do this if the power supply is plugged in or still under warranty)
look at the big metal heat sink on the output side. The 3052 is a
black postage-stamp sized item bolted to the heat sink. It has three
prongs coming out of it that are soldered to a small circuit board,
and prominently displayed for view should be the number 3052, along
with some other non-vital digits. If you have a screw driver and a
soldering iron, the 3052 is as easy to remove as it is to find.
The first time I had a problem like this I took my power supply to
a local computer-repair emporium where they gleefully allowed me to
pay $55.00 for the honor of fixing it. The next time I decided, even
in my electronic ignorance, to try to do it myself. Burn me once,
shame on you, burn me twice, etc....
A visit with my bad Whatzit and power supply to Schrenk's Electronics
supply house in the Park Plaza shopping center proved to be just the
right move. The kind gentleman behind the counter said he had recently
repaired an acquaintance's power supply and was familiar with the problem.
However, he recommended that I replace my 3052 Whatzit (he didn't
know what it was either) with a much more reliable 7805 voltage regulator,
priced at $1.50. The 7805's are all tested and should last the life
of the machine. One glitch is that the 7805's leads are dedicated
differently than the 3052, so, flexible wire leads had to be added
to allow the correct connection to the circuit board. Add three six
inch pieces of wire and some shrink insulation for the leads, that
brings the total repair parts cost up to $2.00.
Since I was such a dummy, the kind gentleman soldered my leads on
and then soldered my new 7805 voltage regulator to my circuit board.
He made me bolt it down and screw the power supply case back together,
though.
He said Schrenk's is not in the repair business, but, if others are
as ignorant as I am, he will be glad to show them the correct connections
to make when they come in to get a 7805.
Now, I may be ignorant on some things, but even I understand the
difference between $2.00 and $55.00.
-------------------------------------------------------------------------
Subject: LANGUAGE SERIES
Subject: ASSEMBLER: WHY IS IT AND WHAT IS IT (GOOD FOR)?
From: Lou R. Goodman
Assembler language is historically one of the first languages that
was developed for computers. It is also one that is called machine
dependent because it is "tied" to the MPU (MicroProcessing Unit), the
workhorse (or brains) of the microcomputer. To see where it came from,
we will have to know something about how computers work (in a very
cursory way). At the January meeting of MACUG Ron Hinsdill said that
he was interested in assembler language until he discovered compilers.
So, what is assembler, what is it good for, where does it come from
and what does it have to do with compilers?
First lets look at the MPU, for the C64 it is a 6510 chip. It is
said that it operates in binary, a mythical land of 1's and 0's. It
is true, but we don't have to know binary. It helps, however, to know
hexadecimal (see the Commodore 64 Programmer's Reference Guide [CPRM],
pages 215-218). The smallest unit that the MPU can access is a byte,
8 bits of information. Anyone who has played with sprites will know
that the value of each bit (a 1 or 0) in the byte will accumulate to
give a it a value that can run from 0 (8 zeros) to 255 (8 ones) or
in hexadecimal from 00 through FF. It is in this frame work of numbers
running from 0 through 255 that the whole computer and processing is built.
The most complicated game, word processor, data base, or what-have-you
program all build on these bytes. In the very earliest machines (1940's)
there was no BASIC or even assembler. All programming had to be in
terms of numbers. This was one heck of a pain (to most people) and
so they decided to try to alias these numbers by giving them names.
One byte (where the numbers are stored in today's machines) will hold
one number (command) that will do only one thing. By always having
the same number have the same thing to do (an "instruction") you can
use one name to alias it. The number is then called an operation or
more commonly an *operation code*. The names that we use to alias
these op codes are called *mnemonics* (silent leading M). This
means that each name has to have meaning for what the corresponding
operation does. For example the Hex Op Code (the operation code expressed
in hexadecimal) 4C is aliased by the assembler mnemonic JMP (jump to
new location) [CPRM, p 224]. The MPU will not understand JMP, however,
it DOES understand 4C.
If the MPU does not understand the mnemonic, what good is it? The
MPU understands the 4C and can act on it if it is correctly placed
in a program but will shake its electronic head at the JMP. The PROGRAMMER,
on the other hand will understand the JMP but probably not so readily
the hex 4C. It sounds like a stand off and a useless set of mnemonics;
the the machine only understands single byte values (known as *"machine"
language*) while the programmer usually has less than no interest
in them but can write programs using the aliased op codes to get things
done. The answer to the problem lies in a program called an *assembler*
(hence, among other things, the name of the language it reads). The
assembler program will read the programmer's mnemonics and (if they
were written correctly) translate them into machine language... and
therewith finally to the completed (hopefully) running program (in,
of course, machine language).
This is the why of assembler. It is so that a programmer can write
a program in a language that is as close as possible to that in which
the machine (MPU) operates, while not going to the actual numbers used
(machine code). Assembler came from the early desire to simply alias
machine code... before anyone thought of languages like Basic, Fortran,
or Pascal.
Notice that in this language, you are allowed to do only one thing
with an instruction. The things allowed will vary as the designers
of the 6510 chip allowed. For the C64 the instructions run from 00/BRK
(force a break in the processing) to FE/INC (increment some value in
memory). As you can see FF is not used. There are, in fact, a whole
series of op codes that are not used (officially) that some assemblers
have taken over or that are used by the developers of the 6510 for
"in house" special meanings. As an aside, a manufacturer of software
was recently bent out of shape as he had used some of the "unused"
codes and a later version of the chip/operating system suddenly used
them, making the software unrunnable on the "same machine" (i.e. Mark
I C64 may not run all commercial software that the Mark III C64 does
or visa versa). So, what does this have to do with Basic and those
things called compilers?
To begin with, you should know how the Basic is run on your machine.
It is run by something called an interpreter. The C64 interpreter
is a program (in ROM, read only memory) that takes the program you
wrote and, line by line, runs it by interpreting what you wrote in
your program into machine code (note, NOT assembler!). If you have
a FOR-NEXT loop, it will look at each line and interpret it, each time
it comes to it and will do this until the loop is done. It does not
save any of the interpretations to be used later so that what is running
WITH your program is this interpreter. How does that differ from a
compiler?
A compiler also interprets the code that you write, but it translates
the WHOLE program all at once and produces a final program in machine
code. Many of the earlier compilers (and many running today) did this
in a two step operation. They would read the statement you wrote,
and then translate it into an assembler code equivalent. After all
of the statements that YOU wrote were translated into equivalent assembler
statements, this "new program" (the assembler language equivalent of
your basic program) would be given to an assembler program to produce
a machine code equivalent. The use of "P-Code" is a variant on this
in which the compiler translates your original basic program into a
sort of pseudo assembler/machine-code format that can then be translated
into machine language or interpreted, depending on the designer's desires.
The BLITZ compiler uses a process similar to this; a part of the final
"compiled" program is a 6K interpreter for their intermediate code.
A true compiler results in a final program in machine code. Thus
you can get a machine code program that will run at machine speed and
not have to wait on an interpreter as in Basic. It is the interpreter
in Basic that makes the language so slow.
So, as Ron noted, you can get the speed of assembler by using Basic
and a compiler. Why then is there still assembler and why do most
software companies desire (demand?) that the programs written for them
be in assembler? What is its advantage? To answer this, let's look
at one facet of Basic that the basic compiler will translate as-is.
Unless you put a % behind a variable, it will be handled in what is
called floating point. This is why when you take a number and manipulate
it you may get a result of 3.9999998 or 1.000001 where you had expected
a 4 or a 1. The compiler handles the Basic verbs for any and all cases
that it will have to handle. This can mean an increase in size of
code or in slowness as it tries to make up it's mind what EXACTLY is
to be done. When you say, for example, A=B+C%, the compiler must recognize
that C is integer. So, for each statement that you write the compiler
must go through a series of questions and then act on the answers.
It is the job of the compiler to either predict the questions it must
ask (and handle the answers) or to signal an error. How does assembler
handle this kind of question?
To begin with, there is no such question, for the programmer from
the word "start" has to do ALL manipulation. S/he can thus "tune"
the program by doing just what has to be done and no more. The code
CAN (not necessarily will) be written to be the most efficient. The
programmer can also take advantage of the full capabilities of the machine
language - something that not all Basic commands/language will. The
assembler program thus has the advantage of being (possibly) more compact,
faster, more efficient and more fully capable of using all of the whistles
and bells of a computer than a program written in one of the higher
lever languages like Basic.
Are there any disadvantages to assembler? Yes there are although
you may not see them as such now. Assembler is what is called "machine
dependent". It relies on a particular MPU and machine configuration
to run. To take a C64 machine language and translate it to, say, an
IBM PC would require major rewriting. Conversion of a Basic program
would probably take a lot fewer changes but... would not run as fast.
So... you pays your money (or time to develop) and takes your choice,
as the saying goes.
Before leaving this discussion of assembler, it should be noted that
the 6510 is almost identical to the 6502 used in the APPLE II. Why
then can't you use an assembler program written for the Apple in the
C64? The difference lies more often with the programmer than with
the program. It would be possible to write some programs that could
do this except, that the architecture of the machines are different
(i.e. where the screen memory is kept, where the Input/Output routines
are kept, etc.). In many cases the programs are nearly compatible
as they both have the same instruction set... As is so often the case
the "fault" lies in the programmer as well as the machine...
So, if your are still with me, what should you do? The only answer
is that it is up to you do make a choice. Programs written in assembler
can be faster, with more pizazz and intricate. But they will take
longer to develop and write as a rule. If you are not comfortable
with basic as a beginner, then you probably shouldn't leap head first
into assembler until you are! If you are a "tinkerer" then a whole
new world of programming and "playing" can be at your beck and call
in assembler. In outlining your choices I am reminded of an old joke
about smoking. In this country there is much competition between
cigarette companies. In Russia, so the saying goes, the cigarettes
are (like so many things) under state control. There instead of telling
you to smoke this brand or that, they just admonish you to SMOKE!
So, take your choice, but whatever you do, write programs!
--------------------------------------------------------------------------
Subject: TECH NOTE #7 -- THE INPUT STATEMENT
From: Bill Kelly
If you write Basic programs at all, the INPUT statement is a must.
There are several tricks to using it more easily and effectively.
Anytime you hit Return without entering any input, the variable
in the input statement is unchanged. You can make this a feature if
you assign a reasonable default value to the variable beforehand.
For instance, suppose a program keeps track of inventory and you often
enter the same part number over and over. A loop like this would allow
entering Return instead of the same value. And if 1 is the most common
quantity, you can assign it to the quantity variable before its INPUT:
100 pn=-1: rem initially a bad part number
110 input"Part number";pn
120 if pn<0 or pn>9999 then print "Bad part number": goto 110
130 q=1: input"Quantity used";q
140 gosub 1000: rem do record keeping
150 goto 110
There's one flaw to this scheme, and that's that you don't see the
default value before entering it. You could change line 130 to show
the default by printing it out and backspacing over it before doing
the input. This works because Basic reads what's on the screen, not
just what you typed.
130 q=1: print"Quantity used? 1{3 CRSR LEFT}";:
input q
It's a bit more complicated if you don't know the length of the value
in advance. However, you can compute the length and adjust the number
of backspaces printed. For instance, we can assign BS$ to be a whole
line of backspaces and select as many as we need from it with LEFT$.
We'll always need 2 backspaces for the ? and space. How many more
we need depends on the value printed. For instance, here we compute
L to be the length of PN.
110 l=len(str$(pn)): print"Part number? ";str$(pn);
left$(bs$,l+2);: input pn
When entering strings, you normally have to avoid entering commas
and colons, which Basic treats specially. However, you can enter quotation
marks around your value and include commas or colons. Basic removes
the quotations, so just the value inside is assigned to the variable.
Finally, some bugs and glitches. I discovered that when you move
the cursor off the current line, then come back to it with the arrow
keys, Basic does something funny. What usually happens to me is that
I hit HOME instead of DEL, then I move down and across to get back
where I was. However, when you finish typing, the variable is set
to the entire line on the screen, *including the prompt*. For
instance, if the program reads 200 INPUT "Your name";nm$,
and you enter Fred, moving the cursor accidentally, then nm$="Your
name? Fred". An easy solution is to delete the prompt with DEL before
hitting Return.
This behavior isn't necessarily a bug. You can write a program that
lists possible values on the screen, then does an INPUT. The user
can then move the cursor to the value he wants and hit Return. That
entire line from the screen gets assigned to the string variable.
Another problem with INPUT *is* a bug! Your prompt, plus the
question mark and space must fit on a single line of the screen. For
a Commodore 64, that means 40 columns; 22 for a Vic. If the prompt
doesn't fit, guess what happens? Same as above, the prompt and the
value entered are combined.
------------------------------------------------------------------------
Subject: MAGAZINE REVIEWS, PART 3
Subject: THE TRANSACTOR
From: Lou R. Goodman
_The Transactor_ is a magazine that is printed in Canada and has
the cover subtitle of "The Tech/News Journal For Commodore Computers".
It is available off and on from distributors like B Dalton's and,
at times, Rennebohm's. Although it seems to appear sporadically, it
is one of if not the best technical journal out on the market. If
you are looking for games, forget it. If you are looking for details
of how the machine works, clues on software tricks and tips, news on
what is happening in Commodore or thematic articles (the issue in had
is on business and education), then this may be the magazine for you.
It is low on advertising and high in content. In volume 5, no. 4,
there is an ad behind the cover, the next ad is on page 77, and there
is a total of 13 ads in the whole magazine. Articles (taken at random)
deal with "Your BASIC Monitor, Part 3: The Assembler", "Nine Easy Pieces"
(9 easy assembler programs as an introduction to "absolute novices"
to C64 assembler), "Phile Master" (a filing system utility, with code),
and "Dynamic Expression Evaluation" (evaluating an expression that
the user types in). The variety is not terribly limited (if you omit
the lack of reference to ZAXXON, Adventure, or other games). But remember,
_The Transactor_ is for the more serious minded "computerists".
For example, the current issue (still available) has a photo-article
on how to adjust your keyboard for key-bounce (the problem where you
hit a key quickly but but many characters out of it without wanting
them!). For my money and my purposes, the magazine can't be beat!!
This review is only BARELY short of being a rave only because _The
Transactor_, plainly said, is not for every one. It is, however,
a superb magazine for those that want to know *more* about the C64
than is covered in most of the other magazines that cater mostly to
games players and semi-enthusiasts. If you can't find a copy ($2.95)
and want to get one, the publisher is in Canada but the American office
is at
The Transactor
277 Linwood Avenue
Buffalo, NY, 14209-9990
A year's subscription (six issues) is $15.00.
-------------------------------------------------------------------------
End of February 85 Ready digest
--
Bill Kelly
{allegra, ihnp4, seismo}!uwvax!uwmacc!bllklly
1210 West Dayton St/U Wisconsin Madison/Mad WI 53706
"I will not harm any vehicle or the physical contents thereof,
nor through inaction allow harm to come to a vehicle or the
physical contents thereof." -- The Repo Code
(Not many people live by a code these days.)