umtroil0@ccu.umanitoba.ca (02/01/90)
I am looking for a good C compiler for my coco3. I can pick up the compiler
put out by RS, but I was wondering what other options I have. This compiler
has known bugs and I want a complete product.
I have the Pascal compiler put out by RS, and have applied a patch to use
it under Level 2. It still has some bugs in it, when I try to write to
the screen (using the standard pascal output path) the escape codes (for doing
graphics) do not quite turn out properly. I seems that
write(chr($1b),chr($42),chr(0),chr(0),chr(0),chr(10));
prompt;
gives me an error of 189 (the 10 seems to be interpreted as a line feed)
Illegal Coordinates. If the 10 is replaced by a 13 the same error occurs.
I have created my own record type to PUT to the screen, and this works fine
but...I then can not use getchar to get a character from the keyboard.
If any one has any patches or suggestions please post them here.
Thanks
Domenicdrp@vpnet.UUCP (Douglas Pokorny) (02/05/90)
Unfortunately, the only C compiler available for the CoCo is the Tandy/Microware one. However, once you patch/replace the CC driver, replace c.asm with rma, and replace c.link with rlink, it makes a pretty nice compiler. The only patch that you really need to make on the CC module is to replace all of the hard-coded "/d0"s and "/d1"s with "/dd"s. Howver, for maximum throughput, I'd recomend getting a whole new CC that pipes the data instead of using temoporary files. +----------------------------------------------------------------------------+ | How do icons work? | | What is an address bus? | | How does a mouse let me move the cursor around the screen? | | Answers to all this and more in Time/Life's new series.... | +-----------------+-----------+----------------------+-----------------------+ | Douglas Pokorny | drp@vpnet | drp@chinet.chi.il.us | The future is in OS/9 | +-----------------+-----------+----------------------+-----------------------+
knudsen@cbnewsd.ATT.COM (michael.j.knudsen) (02/06/90)
In article <1990Jan31.193745.1155@ccu.umanitoba.ca>, umtroil0@ccu.umanitoba.ca writes: > I am looking for a good C compiler for my coco3. I can pick up the compiler > put out by RS, but I was wondering what other options I have. This compiler > has known bugs and I want a complete product. Introl has (had?) one, but it costs around a thousand US bucks. The RS/Microware compiler's bugs are quite manageable if you know what they are -- the workarounds are not ugly nor terribly inefficient. > I have the Pascal compiler put out by RS, and have applied a patch to use > it under Level 2. It still has some bugs in it, when I try to write to > the screen (using the standard pascal output path) the escape codes (for doing > graphics) do not quite turn out properly. I seems that > write(chr($1b),chr($42),chr(0),chr(0),chr(0),chr(10)); > prompt; > gives me an error of 189 (the 10 seems to be interpreted as a line feed) > Illegal Coordinates. If the 10 is replaced by a 13 the same error occurs. Aha, the same old old SCF device problem that bugged me for years. Yes, 10s and 13s (decimal) get expanded into 13-10 pairs, since these are LineFeed and CrriageReturn. The trick is to get your buffered output routine (equivalent to C's printf() ) to use I$Write instead of I$WriteLn. In RS/Microware C, you can set this mode by saying stdout->_flag |= _RBF; before outputting anything. Substitue any other FILE path for stdout. Amazing how thoroughly this fixes the 10/13 problem. If you root around in the back of your RS Pascal manual, you might just find a similar trick. Happy hunting. > I have created my own record type to PUT to the screen, and this works fine > but...I then can not use getchar to get a character from the keyboard. I don't speak Pascal, but in RS/Microware C you can mix buffered (f-style) and raw unbuffered output (PUT style), *if* you remember to fflush() the FILE after each buffered I/O fcn that preceeds a raw one. When writing a lot of graphics commands to the screen in a burst, by all means try to use buffered, rather than raw, output. You'll be amazed at the speedup. To prove it, take a program, including one of yours that fails due to the 13/10 problem, and redirect its output to a temp file. Then MERGE the file, ie: program >temp; merge temp and watch how much faster the screen draws. Hope this helps, mike k. -- Mike Knudsen knudsen@ihlpl.att.com (708)-713-5134 "If you cut out drinking, smoking, steak, and sex, you may live 5 years longer. But would you want to?" --me