BASIC Functionality
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.
Parsing Anomaly?
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.
Slow Ride
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...
Someone on Youtube asked about the generated code for the _getpos routine. I have included some output here:
ReplyDeletehttp://www.tuxdriver.com/download/rc2013/2013-07-14/_getpos.txt
It looks like the broken version is generating an "ADDB #1024" instruction. That doesn't seem likely to work, since the B register is only 8 bits wide...
Found it! It was a quirk. The docs that come with Micro-C explain that untyped constants in an expression are treated as 8-bit values by default. This is designed to allow for the use of 8-bit math when possible. I guess that seems reasonable, but it wouldn't have hurt to throw a warning! Anyway, adding a typecast makes the code compile properly.
DeleteAlso, FWIW I turned-on the optimization option and the eye blink is now significantly faster in the demo program. Without optimization, the compiled code does silly things like storing a register value to memory and then loading the same register from the same memory location for use immediately afterward...