knudsen@ihnss.UUCP (11/28/84)
<header with bad CRC?>
I have finally proven to myself that the putc(char, channel) function in
the stdio library is defective in Coco OS9 C.
Namely, it strips off the high-order (sign) bit 7 when going to stdout.
This makes it unusable for feeding graphics coordinates to CCIO, since these
must range all the way up to 255 (or -128 thru -1, in C's viewpoint).
I can think of 3 courses of action:
(1) Write complaints to Tandy and Microware. Go into suspended animation,
have HAL wake me up when we get to Pluto...
(2) Write my own assembly-code substitute, and figure out some way to
represent stdout to it (the rest is easy).
(3) Dig around in the stdio libe with DEBUG and look for AND{a|b} $7F or
some such thing in putc, and patch it out. (Say, might the & 0x7F be in
the macro defn of putchar() in stdio.h? That would be a quick fix! I am
using putchar(), not putc() directly. I'll take a look this evening).
I know the & 0x7F is not in OS9 itself, since the PUT #1,char in BASIC09
works perfectly -- all 8 bits. mike k
PS: Is it asking too much that Microware/RS at least *document* such cute
features, eg, "putchar() strips the parity bit."?emjej@uokvax.UUCP (12/02/84)
[when you send some mail/and you want it truncated/who ya gonna call?...] /***** uokvax:net.micro.6809 / ihnss!knudsen / 6:14 pm Nov 28, 1984 */ I have finally proven to myself that the putc(char, channel) function in the stdio library is defective in Coco OS9 C. Namely, it strips off the high-order (sign) bit 7 when going to stdout. This makes it unusable for feeding graphics coordinates to CCIO, since these must range all the way up to 255 (or -128 thru -1, in C's viewpoint). /* ---------- */ Just wanted to confirm that this is a CoCo-ism; it does not happen elsewhere in Microware C. I can't help but think that somebody at RS is hosing things severely...first the device drivers, now this...oy! James Jones