ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/ENTERPRS/C128/TEXT/SC-CORR.ASC

Text File | 2000-06-30 | 14KB | 291 lines

Material on "Super C" from a letter to Bill Robinson, Bandon, OR. I don't have
a record of the date of the letter,but it was probably about 2 years ago at
least. I have not gone much further than this with "C", and have forgotten
most of this. So please don't ask me for advice or help with C.
           Jean Nance 1576B County Rd. 2350 E, St.Joseph, IL 61873


Dear Sirs:

I own a copy of your "Super C" package. I have been working on it over the
last several weeks. So far, I have found the following errors, or very
confusing sections in the manual:

Pages 8 and 9, and part of page 10, discuss "device". It is only half way down
page 10, and after considerable frustration, that you learn that "device" will
not work if you have more than one disk drive!

At the bottom of page 13 "stdio.p"is referred to. This is an error, it is
"std.p". Also, you state that "std.p" contains the list of files on page 12.
It doesn't contain "ctype.h", or "libcs.l".

On page 20 there is a reference to a file "exp-text.c". The correct name is
"text.c".

At the bottom of page 28, you are told the sample program has a line "#include
"stdio.h". The actual line is "#include "stdio.c". Therefore, you need to make
two changes in that line, not one to get the proper form "#include
"h:stdio.h"".

On page 31, it is stated that the compiler prints the source files it is
processing in grey type. These are actually in cyan.

Near the middle of page 33, you have the following. "If both link files. o.o
and libc.l are now on the work diskette or the Ram disk, load the loader---".
Obviously, "linker" is meant here.

These are the more obvious errors in the first 47 pages, which is as far as I
have gone at present. You may think these are all minor errors, but when a
person is working hard to understand an entirely new concept, such errors can
confuse and frustrate.

The format of the manual, such that directions for version 2 and for version 3
are interlaced is very confusing. You could have used different type, or some
other method of indicating which version is being dealt with at any one time.
Better yet would have been two manuals, each of them could have been much
shorter. I have gone through and highlighted version 3 material for myself. It
takes very careful reading to be sure which directions are for version 2,
which for version 3, and which cover both versions. The index is very scanty,
which makes it impossible to look most topics up except by leafing through the
book.

The program on page 39 works. But, the first line of text after you run the
program overlays the command to load the program, so if the program has been
named "objects",  you get something like this: "h:obe=2.7182818". This is
messy! A "backslash n" before the first printf line would have prevented this.
Most of the programs are equally messy, they need carriage returns inserted
and other changes to make them run nicely.

At the bottom of page 40, format instructions are explained, but the reader
must search the book to find that all format instructions are listed on page
181. If format commands can't be listed here, certainly the reader can be told
where they are listed.

Early in the manual, the reader is required to type in programs. But nowhere
are there any directions as to how to type in the backslash, curly brackets,
and other special C characters. I finally found these in the appendix on page
256. They are not listed, but buried in a rather confusing diagram of the
keyboard. And, the diagram is wrong, in that the two sets of graphics obtained
with the shift or Commodore logo key and the key, are not correctly
diagrammed. Look at the Commodore keyboard and compare with that diagram.

On page 42 there is a program that just does not work. You get a blank screen
and the program hangs up. Luckily for me, I have a copy of Kerningham and
Ritchie, and am also working through their beginner programs, from which the
programs in your manual seem to have been borrowed. In the program on page 42,
it is necessary to put brackets () around "celsius +32.0". Then the program
will work!

On the bottom of page 46 there is an explanation of why it is necessary to use
(c-'0') in the line shown. I puzzled over it for a long time, and it didn't
seem to make much sense. Again, good old K.and R. to the rescue. They have an
excellent explanation of this.

Along about now, I decided to just explore the book. I saw a reference to the
graphics demo program (cdemo) on page 203. Since I am using version 3, I was
instructed to follow the directions, and compile the code which is on the
system disk. How do you do it? Well, you first erase your Ram disk. Then, you
load the demo code, and proceed to compile and link it. This gives you an
error message in the compiler. Finally I took a look at the demo code with the
editor. It includes two files from the RAM disk!. These, of course, aren't on
the Ram disk because the contents of the Ram disk have been erased.

First I tried erasing everything from the RAM disk except the two files that
are needed by the demo. However, there isn't enough room on the RAM disk to
save the program if these are on the RAM disk. So, I changed the program to
get the files from disk a instead of h, and saved the new version to disk b.
Then I went through the procedure again, using the new version as my source.
Everything went fine, it compiled, it linked, there was room enough for the
final program on the RAM disk. There was only one little problem. The damned
program doesn't work!

(Note to Bill. The reason it didn't work, which I discovered for myself, is:
Commodore C graphics are 40 columns. I was trying to run it in 80 columns. It
does work in 40 columns. However, not easily. The procedure, arrived at by
trial, error and many curses, is as follows: Set your computer for 40 columns.
Load "cdemo" which is on work disk 1 and on work disk 2. Nothing happens! Do
not touch any keys, let it sit for at least 2 or 3 minutes. I presume it is
doing something important during this period and I don't know how long it
takes. Then hit the up arrow. Then hit return. The program will run. It will
run forever,and the only way to turn it off is to hit the reset button. By the
way, it appears that if you start hitting keys, especially the up arrow/return
combination too soon, you load only part of the program. It will run for a
while, but won't run to completion. Mysterious!)

Returning you to my letter to Abacus:

Having invested $37.95 in this, and a lot of work, I am not about to throw it
out, but boy, am I tempted! I can only assume that the rest of the book is
just as full of errors and ambiguities as the section I have already covered.
This is a no way to learn a language.

One last question. In version 2, it is apparently possible to make a compiled
form of a program that will run directly from Basic. This is apparently
impossible with version 3. Does this mean that a C program compiled with
version 2 in the proper form can be loaded directly from Basic by someone who
does not have the C system disk? Would this mean that you could show a friend
who doesn't have C a program you have written in C? Or just that the part of
the C system needed to run a program is loaded, then the program itself is
loaded, and the program runs. If a compiled C program is actually in machine
language, isn't it possible to load it somehow from Basic? In either version 2
or version 3?

(Note- Apparently, the answer is that C version 2 can be compiled to run from
Basic. Version 3 cannot. They sent a sheet with directions for making a disk
that will boot from the 128. It loads the central processing program, so you
end up with a disk that a person with a 128 can use to run C programs. (C test
disk). They don't make it clear whether this would be copyright infringement
or not. I assume not, since you don't have the editor, compiler, or linker
just the processor.  A version of the material is on pages 115 and 116,
(sysgen) and you may be able to get the information from that. I think what
they sent me is clearer, let me know if you don't have luck with 115-116 and I
can get it photocopied.)

(Continuing letter)

I am rather shocked to find a product put out by Abacus that has so many
serious and frustrating errors. I will keep going at this, but I resent the
time I have to spend discovering errors and compensationg for them. This
package  has been on the market for several years. In that time, did you ever
feel the responsibility to either put out an "errata" sheet, or better yet, to
reprint the whole thing?
                                    Your sincerely,

To Bill: Their reply was very apologetic. They enclosed a disk of utilities. I
am sending you a copy, since you too will have to struggle with the manual.
Their explanation was that the manual was written in German and translated
into English. (The person who did the translating, I assume, knew German, and
English, but very little about C.) Apparently, only recently have they
obtained permission to create a new version of the manual, and they are
working on it. I also enclose a copy of the "test disk" referred to above, a
copy of my work disk 1 and a copy of my work disk 2. I can't make most of the
programs on the utility disk work, but admit I haven't spent much time at it.

The programs on the work disk are mostly in two forms, source code, and a
program that can be run from C. For example, "countword.s" would be source
code. Load it into the editor, and see what it looks like. "Countword" would
be the result of compiling and linking "countword.s", and can be run directly.


This is an outline of how to do things. I find it useful because I worked it
up. Hope it is of some use to you. I have a shortened version of this on a
sheet of paper and keep it available at all times, to help me remember how to
do things.


COMMANDS:

Copy. Must be loaded from system disk.
                 copy h:name to a:*

means, copy program "name" from Ram drive to 'a' drive, using the same name.

                   copy h:name to a:name2
means copy program "name" from Ram drive to 'a' drive using different name.

If any other command is given, "copy" is no longer available and must be
loaded again. When copy is available, the "a:" prompt will be red.

Rename. Is on Ram disk at loadup.
                com r:newname=oldname
means rename program "oldname" as "newname".

Scratch. Is on Ram disk at loadup.
                   com s:name

means scratch program "name".

Format. Is on Ram disk at loadup.
                 com n:name, id

EDITOR.

To write a new program:

Load editor from system disk with "ce"
F5, and then type "new". Enter 80 for line length.
Enter file name as h:name.h

Enter an extra line with F7, and color it yellow or other readable color. Then
enter more lines by hitting F7 until you have the number you need. Type in
code, proofread it carefully! Proofread it again!

F5 and then S to save. It will be saved to Ram disk.

Load. To load a source code file into the editor.
      Load editor with "ce".

F5 and then L. (load).
Enter drive designation and file name and hit return.
        For example: b:program.c (return)

Shorter  way to load a file into the editor: assuming program to be loaded is
in "b" drive. Type:
      a:ce b:program.c (return)

Save. To save a copy of an edited source file to disk.

F5 and then F for file name change.
Put work disk in drive a or drive b. Change name to "a:name.s" or "b:name.s"
and then "S" to save to work disk in drive a or b.(I prefer ".s"  for source,
they seem to prefer ".c" [code?] )
Get out of editor with F5, X.

COMPILER.
     Be sure edited program and any link files needed are on Ram disk!
     Load compiler from system disk with "cc".
     Enter "h:name.h" (Return)
     Enter "h:name.o" for link file (default)(return)
     Enter "h:name.e" for error file (default)(return)

     Hit return. If there is any trouble, go back to editor, load source file,
make necessary crrections and start over. Save to same name.(Automatic
replace).

Note. They confuse the issue by suggesting that you use "o.o" for the link
(object) file rather than "name.o". This works, but I preferred to use the
default form that includes the name at first. Later when you have a feel for
what you are doing, using "o.o" will save some typing and disk space.

Note. The material on page 140 and following explains the use of the compiler
and is actually easier to follow than the material in the early chapters.
Notice you can do this:

     a:cc h:program.h h:program.o h:error.e  (Return).
The compiler will be loaded and the code will be compiled. A bit more
efficient, I suggest you do it the original way at first, until you see what
is what.

LINKER.
     Load linker from system disk with "cl"
     Enter name "h:name" (Return)
     Enter "libr.l" (default) (Return)
     Enter other library file name if needed. (Return)
     (When all library files needed are listed:
     Enter "h:name.o" (Return)
Note. See page 150 and following for a fairly good description of how to use
linker. You can link with one line of code, too, like so.

a:cl h:program h:libc.l h:program.o (Return)

or even:

a:cl h:program h:libc.l h:another lib file  h:program.o

Other library programs may be included here if needed. This will link all in
one shot.

You can also compile and link all in one shot. Like so.

a:cc h:program.h h:program.o h:error.e h:program h:libc.l (Return)

The compiler is loaded, the program compiled, the linker is loaded, and the
program linked. "h:program.o" is understood here, so it isn't necessary to
type it in.  You are going through all the steps to compile and link, but
faster and with less typing.

SAVING. After linking and compiling, run the program from the Ram drive. If it
the way you want it, save it to work disk. To do this, load "copy" from system
disk. Save with   copy h:name to b:*, or copy h:name to b:name2.