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.

Free Simple Hit Counter