I wasn't sure where to start on designing an API for the CoCo. So for now, I've decided to punt by simply mimicking the commands provided by the CoCo's built-in BASIC programming environment. I won't attempt to transform C into BASIC with implementations of MID$ and the like. But, I will try to implement some of the machine-specific commands for graphics, sound, and the like.
With that said, I have begun by implementing the simplest suite of graphics commands. On the CoCo, this is provided by the set, reset, and point operations for turning pixels on and off and querying a pixel's status on the "semi-graphics" (i.e. VDG mode SG4) screen. Since that mode allows for mixed text and graphics, I also included routines for clearing the screen and for positioning the text cursor.
A funny thing happened on the way to the forum... While implementing the code to calculate the addresses used in the graphics routines, I discovered that the calculation was producing incorrect results. To debug that situation, I deconstructed a complex statement into multiple simpler statements. To my surprise, the calculation then produced the correct results!
I still don't see what difference exists between those implementations that could explain why one performs correctly and the other does not. Sometimes compilers (particularly "small" ones) have some idiosyncrasies, and the Dunfield compiler is no exception. I'll have to dig back through the documentation to see if I am hitting one of those cases. On the other hand, I may simply have done something wrong. I would welcome anyone who is interested to look at the code in _getpos and to let me know if they see the difference.
The program running in the video is a C implementation of a program from page 128 of Getting Started with Extended Color BASIC. As I commented in the video, the C program doesn't seem to run any faster than the original BASIC program. The difference is that the C program checks for keyboard input after each "blink", while the BASIC program just loops with a GOTO and has to be stopped by pressing BREAK. If you remove the keyboard check in the C program, the blink is more like a fast flicker.
I would guess that the same keyboard scan routine is called in either case, with that fact hidden in the case of the BASIC program. The keyboard scan in the ROM does a lot of work, and that work takes time. Hopefully the speed penalty demonstrated with the C program calling the ROM routine illustrates that simply coding a program in a compiled language is insufficient to guarantee improved performance.
I had a lot of fun working on this today. Hopefully I can get some chores done and find more time to work on this tomorrow! If you want to see what comes of that, then I guess you'll have to stay tuned...