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.