OS9/NitrOS9 C Compilers
OS-9/NitrOS-9 'C' Compilers
A 'Research' on the History of the Color Computer/OS-9 C Compilers
A comprehensive guide to what's available, what works, and what does not work.
By Bill Pierce
*************************************************************************************
In the Beginning, There was Color BASIC
Through my years with the Tandy Color Computer (Coco, as it's affectionately called by enthusiests) and the OS-9 operating system, I tried (and learned) many of the programming languages available for both Disk Extended Color Basic as well as OS-9 levels 1 & 2. Like most Coco users, I started with Tandy's "Microsoft Color BASIC". My first Coco was a Coco 2, 16k, "Color BASIC" machine from which I loaded and saved files to cassette tape. "Color BASIC" was fun, but very limiting as the 16k machine had no "hi-res" graphics capabilities and my interests were in graphics and music, so naturally, I eventually upgraded to a 64k Coco 2 with "Extended Color BASIC" which allowed the hi-res PMODE4 graphics. With this machine, I delved into the world of assembly language with the "EDTASM+" cartridge. Before long, I extended my Coco system with a single disk drive and moved on to "Disk EDTASM".
It was about the time I bought my disk drive, that I discovered the "OS-9 Level 1" operating system. In all I had read about OS-9 in the "Rainbow" magazine, it seemed to be a better programming environment, so my next venture was learning "Basic09", and OS-9 assembly language. It didn't take me long to find that OS-9 Level 1's major pitfall was the memory limitations. There just wasn't enough room on a 64k Coco to do "serious" programming... Again, Rainbow came to the rescue! The announcement of the coming of the "Color Computer 3" with 128k of memory, super hi-res graphics, and upgradable to 512k memory was one of the best things I ever read in Ranbow magazine!
It took me a while to save enough money to get a "Coco 3", but when I finally purchased mine, the very same day, I placed an order for my 512k upgrade. Radio Shack soon released "OS-9 Level II" and my world was complete (as far as my "Coco world"). I began to once again delve into the new "Basic09" for L2 as well as OS-9 L2 assembly language. I started many projects, most were never finished. They all suffered the same problem... Even with OS-9 utilizing the extra memory for more windows and better graphics, the "workspace" used by programs was still just 64k. At least they had moved the graphics screens and "get/put" buffers out of the 64k workspace, but in essence, the programs were still limited to 64k!
My experience in "C" programming in OS-9 actually started back on my Coco 2 and OS-9 L1, but I didn't own any of the C programming books needed to learn C, so I was limited to what little knowledge I could gain from reading the very few articles in Rainbow magazin on OS-9 C programming. I would eventually drop C and fall back to "asm". After moving to OS-9 L2, I basically had the same experience... I tried C once again, but with lack of learning materials, I gave up and went back to asm and Basic09.
Fast forward to 2012... I had just recently had an urge to do some Coco/OS-9 programming (an urge I'd get about once every 2 years at the time), and due to a series of events, I ended up with a "monster" Coco 3 system and the sources to one of my favorite programs for OS-9 L2.. "UltiMusE 3". I had some plans for those sources, and low and behold, they were in the C programming language. I made a decision that after 30 years of "Cocoing", it was time to learn "C"! It didn't take long to find that most of the old C documentation and K&R C programming books (plus many more) were available online for downloading.
As far as I knew, Microware and Tandy had only released one version of the OS-9 C compiler (v1.00.00). There was never an update nor upgrade to OS-9 L2, though there was a few additions on the "Development System" package that were aimed to enhance the C package to be more compatible for OS-9 Level 2. Through my research on the internet, I was soon to find out that various Coco programmers had tried to "enhance" and expand the OS-9 C compiler through the years. This page is going to tried to chronicle these various 3rd party upgrades and enhancements and determine what packages actually work to update the Microware OS-9 C programming system to the current NitrOS-9 standards.
NOTE: The "Summary" sections in the file descriptions are purely my own "personal opinion" and may differ from your own experience. For the
most part, I have tried these utilities and my summary is based on my "end results" from attempting to compile VERY large source packages containing 100+ source files. Some of these utilities work well on smaller source packages with shorter line lengths. If I have a negative opinion of a utility, I will try to explain why and the conditions which caused the problem. A good example of such a summary is "c.prep_19b". This version of c.prep had it's "maximum line length" reduced and "label buffer" size reduced to make room for newer features. The sources I was using not only had some very long lines, but with over 100 sources in the package, there was a vast amount of labels, so c.prep_19b failed with "line too long" and "Too many labels" errors, so I had to revert back to the standard Microware c.prep which had larger buffers and then everything compiled fine. In smaller source packages with shorter lines, c.prep_19b performed well. Since most of my C projects are very large, multi-source packages, I could not use c.prep_19b. Similar results were reached on some of the other "newer" utilities.
*************************************************************************************
The Microware OS-9 C Compiler
For the most part, I have found the original MW C Compiler system to be pretty stable. There are a "few" bugs, but most of those only show their ugly heads in very extensive sources. A lot of the problems with compiling C sources was in OS-9 itself and not the compiler system, the limited memory and the fact that most users had only a single disk drive added to frustration in using the C compiler.
The Microware C compiler system consisted of:
Disk 1:
CMDS:
cc1 (C compiler frontend)
c.prep (C source preprocessor)
c.pass1 (1st phase of C compiler)
c.pass2 (2nd phase of C compiler)
c.opt (object file optimizer)
c.asm (C source assembler)
c.link (C object file linker)
copy (standard OS-9 module)
del (standard OS-9 module)
dir (standard OS-9 module)
echo (standard OS-9 module)
list (standard OS-9 module)
Disk 2:
LIB:
clib.l (standard C library)
cstart.r (C start module, for compiling executable files)
DEFS: (header files for the "clib.l" C library)
ctype.h
direct.h
errno.h
modes.h
module.h
os9.h
os9defs
setjmp.h
sgstat.h
signal.h
stdio.h
time.h
SOURCES: (for the most part, sources for the C libraries)
SYS:
abort.a
access.a
cfinish.a
change.a
comp.sys
cstart.a
dir.a
id.a
intercept.a
io.a
make.sys
mem.a
misc.a
mod.a
process.a
profdummy.a
signal.a
stat.a
syscall.a
syscommon.a
tidyup.a
time.a
line.c
prof.c
rdump.c
The Microware Development System
After the release of OS-9 Level 2, Microware/Tandy released the "Development System" which included some new commands and a few "enhancements" for the C compiler. These included "RMA" (Relocatable Macro Assembler), "RLink" (the linker for the assembler) and "Make". Also included in this package was the "cgfx.l" graphics library for including the Coco 3's enhanced graphics capabilities in your C program. Here is a listing of the "Development System" package:
Disk 1:
CMDS:
binex
debug
dump
exbin
login
make (allows the use of multiple sources from both the C compiler and the RMA assembler)
maketerm
modpatch
montype
park
save
scred (a very powerful "line oriented" text editor)
sleep
tee
touch (for "dating" your sources during compilation)
tsmon
verify
rma (a relocatable macro assembler designed to interface with the C compiler)
rlink (the linker for the above)
rdump (for hex dumping of the object files, particularly the libraries)
SYS
errmsg
helpmsg
logbook
motd
password
scred.help
termset
Disk 2:
DEFS
defsfile
os9defs (standard OS-9 definitions for Level 2)
systype
os9defs.a (definitions for use with RMA as the "os9defs' above will not work with RMA)
wind.h (these last 4 are headers for the "cgfx.l" C graphics library)
stdmenu.h
mouse.h
buffs.h
LIB
sys.l (a library for use with the RMA assembler)
cgfx.l (the C graphics library for Level 2)
MODULES
HELP (help files for use with the Level 2 "help" utility)
h0_10.hp
h1_10.hp
ddh0_10.hp
h0_15.hp
h1_15.hp
ddh0_15.hp
h0_35.hp
h1_35.hp
ddh0_35.hp
r0_96k.hp
r0_128k.hp
r0_192k.hp
ddr0_96k.hp
ddr0_128k.hp
ddr0_192k.hp
nilo.hp
h0_10.dd (these are all the new drivers and descriptors for Level 2)
h1_10.dd
ddh0_10.dd
h0_15.dd
h1_15.dd
ddh0_15.dd
h0_35.dd
h1_35.dd
ddh0_35.dd
r0_96k.dd
r0_128k.dd
r0_192k.dd
ddr0_96k.dd
ddr0_128k.dd
ddr0_192k.dd
nilo.dd
cc3hdisk.dr
ram.dr
nildrv.dr
SOURCES
RELS (empty dir)
makefile (and example "makefile" for use with "make"
lsit.a
updn.a
root.a
As you can see, the Development System also came with Hard Disk, Ram Disk, and Nil drivers as well as the C enhancement utilities.
In a nutshell, those were the contents of the OS-9 C compiler system for OS-9 levels 1 & 2.
Eventually, programmers wanted more and better compiler components. Especially with the advent of OS-9 L2, C programmers felt there was more that could be done with the compiler system.... and they proved themselvels right!
As "online" resources from "Delphi", "CompuServe", "The OS-9 User's Group" & BBSs all over the world started to expand, various "enhanced" and "bug-fixed" versions of some of the C programming components started showing up as well as "patches" to fix various problems or add certain features to the C compiler system. One of the first I remember seeing was from a Rainbow article to fix the problem of the C compiler looking for the "DEFS" and "LIB" directories on "/D1". This was actually "hardcoded" into 2 of the C modules. This proposed problems to "single drive" users with only "/D0" available as well as hard drive users with "/H0 or /H1". With OS-9 L2, came the "/DD" drive descriptor allowing ANY drive to be the "default drive", the available patches would change the "D1" to "DD" in these modules allowing single drive owners as well as hard drive users to effectively use the C compiler.
I will next try to list the various C compiler enhancements and patches as well as I can. The files listed are just the ones that I could find. I am sure there were more, but without access to the old Delphi and Compuserve listings, these will probably be lost forever.
C Compiler "Frontends"
"C1" & "C2"
NAME
"C1" & "C2" are both C Compiler executives (frontends).
DESCRIPTION
"C1" came with the original Microware C Compiler and "C2" came with the "Development System" released after OS-9 Level 2 was released.
AUTHORS
Microware
"CC" (known versions 2.2.1 & 2.5.2)
NAME
"cc" is a C compiler executive. It replaces cc1 and/or cc2, which come with the C compiler. cc is compatible with cc1 and cc2, but offers more
features as well as running faster if you have a RAM drive. DESCRIPTION "cc" invokes the appropriate phases of the C compiler in order to compile C source programs. This version is configured to use the two-pass
Level 1 version of the compiler, and to use RMA and RLINK as the last two passes. It also puts temporary files in the first of /R, /R0, /DD/TMP,
whichever it finds first. If you need to reconfigure cc, instructions are contained in the file "read.me".
AUTHORS Carl Kreider, Pete Lyall, Bill Dickhaus, Eddie Kuns, Boisy Pitre
SUMMARY
Since I started out learning C in the past 10 years, I started with Mike Knudsen's "RCR" frontend and have never used any of the "Cx" stuff,
so I could give an evaluation of these utilities.
"RCR"
NAME
"rcr" is another C compiler executive.
DESCRIPTION
"rcr" has gone through several phases since it's inception. The original used all the components of the original C compiler with the exception
of using TK's "make". Originally written to automate the compilation of "Ultimuse3", rcr went through several modifications. The final version
made use of "c.prep", "c.comp" (single pass compiler), "CnoY" (explained below), "rma", "c.opt", and "rlink". Rcr in it's current version is hard
coded to use "/r0" for temporary files and "./RS" for the compiled object code (rels).
AUTHOR
Michael J. Knudsen
SUMMARY
I have used "RCR" for a few years now with great success. Since I do have the sources for RCR, I can modify it to fit my needs in using various
compiler setups.
C Compiler "Preprocessors"
C.Prep
NAME
"c.prep" is just what it implies... A C source preprocessor utility.
DESCRIPTION
"c.prep" is a workhorse for the C compiler as it scans the source and removes all unneeded text, comments, does syntax checking and shortens
all user tags (labels, variable names, etc), to shorter, easier to handle text. All variables are enumerated for quick access and various other functions.
SUMMARY
I personally have no problem with this version of C.Prep, though others swear by the later enhancements which I cannot use (see below).
C.Prep19, C.Prep19b, & C.Prep19c
NAME
"c.prep" is just what it implies... A C source preprocessor utility.
DESCRIPTION
These versions of "c.prep" featured more robust syntax checking and optimization than the original Microware version. There was also an attempt
to make it "ANSI Compliant", which to me is a waste of time if it's not 100%.
AUTHORS
Jim McDowell, Gene Heskett, & Willard Goosey
SUMMARY
The problem I have with these enhanced version of C.Prep are that in adding the newer features, the authors reduced the buffer sizes for the
line length and reduced the number of possible labels. Most of my C projects are very large and I over-run these buffer regularly, making them
impossible for me to use. I did like the tighter syntax checking, but in the end, getting my programs compiled won.
The C COMPILERS
"C.PASS1 & "C.PASS2"
NAME
C.pass1 & C.pass2 were the original Microware compilers.
DESCRIPTION
C.pass1 & C.pass2 are a "double pass" compiler system to compile C sources into relocatable macro assembly files. On the original
OS-9 Level 1 system, there was not enough memory to run a single pass compiler, so a double pass compiler was used. These are called back-to-back
to compile the C sources into relocatable assembly files.
AUTHORS
Microware
SUMMARY
The compilers are slow and cumbersome, but do their job well. I did read about a couple of bnugs at one point, but from what I understand, to
invoke these bugs, very special conditions were required.
C.COMP
NAME
C.Comp is a "single pass" C compiler.
DESCRIPTION
C.COMP is basically "c.pass1" & "c.pass2" combined into one executable module which compiles the C sources into relocatable, macro, assembly
files (see below). I would assume there were some enhancements and optimizations involved.
AUTHORS
Microware (??)
SUMMARY
C,Comp is much faster than using c.pass1 & c.pass2. I'm not sure what enhancements or optimizations were made, but I personally like this compiler and
have used it for years now.
C COMPILER OPTIMIZERS
C.OPT
NAME
c.opt an assembly source optimizer.
DESCRIPTION
C.opt examines the relocatable macro assembly files produced by the C compiler and removes unneeded white space, enumerates variables etc.
AUTHORS
Microware
SUMMARY
C.opt is pretty straight forward and I really have no problems with it. I use the original version as the enhanced version suffers the same problem as c.prep...
The reduced buffer sizes.
