Micro C Staff
write to an area outside of the current boundaries of printer memory? Perhaps you'll overwrite some other data from your program. Or you might even lobo-tomize the program. Whatever happens, it won't be pretty.
The initial logic of p_draw_pointO takes care of this problem by "clipping,"
or simply not drawing any point that lies out of bounds. You might want to change the else clause during program development. Printing illegal points along the edge closest to where they dis-appear would at least show you the direction the errant points were going when last seen.
Complete User's Guide
To use these functions in your own code, just call p _initO and tell it how large an area you want to allocate. If it can't find that much memory, it'll com-plain and you can exit gracefully. Other-wise, you're on your way.
Most of the code is pretty self-expla-natory. But... I wanted to be able to do text and graphics in any of four direc-tions. Hence the compass headings. To orient yourself, a string printed ''North'' would look like normal text output of a printer.
Printer "lines" run North-South, and
"columns" run East-West.
p ~et_screenO grabs Herc graphics page 0 and stuffs it into printer memory in an Easterly direction. That means text printed along the bottom of the screen would run East.
You can position video graphics within the printer page using the two off-set parameters. Note that a line_ofs of 1 is really 8 printer lines (one pass of the printer head). Also, be sure the screen doesn't go outside printer memory boun-daries - the function doesn't check.
Again, p_get_screenO is the only function you'll need to change to support other video cards.
MICRO CORNUCOPIA, #45, Jan-Feb 1989 41
Fonts
I've hard coded for the one font I created. ("Created" is a euphemism for
"ripped off from the Hercules font.") Figure 2 shows a couple of examples from CHARGEN.C, the program which creates the font file. I finished all the al-phanumerics before I ran screaming from the building. And I'll get as many sym-bols done as I can for the version of CHARGEN.C on the Micro C BBS and the Issue #45 disk.
The eleven bytes defining each character correspond to eleven "scan lines." Byte 0 defines the bottom line of the character and byte 10, the top. I guarantee you'll need a new prescription for your glasses after a few hours staring at the screen figuring out which bits should be "on" for each character.
On To The Practical
That's it - no more fun. Time to create something for the applications-oriented among us. I'll make it a bit more palatable by doing graphing functions that could be used for scientific work as well as business. (Sorry. Didn't mean to talk dirty. I'll avoid the "B" word from now on.)
graph_testO is a bit rough and rocky, but it'll give you an idea of the possibili-ties for using these printer routines.
A labeled and scaled plot requires a ton of information. Rather than pass enough parameters to choke a horse, I stuck 'em in a structure. graph_testO fills the structure as follows.
The orientation of your graph will be the direction of the x-axis. x_min and its ilk locate the axis in printer memory while xdata_min, etc., reflect the actual data bounds. x_step and y _step deter-mine the increments marked by "ticks"
on each axis.
Ideally, data sent to p_draw_plotO would be in the form of a pointer to a linked list. But the array of data simpli-fies matters and will work fine for many applications. In this example, we load the array with values from a sine function and send a pointer to the structure off to p_draw_plotO. Notice that points[O][O]
holds the total number of data points.
To shorten the listing, I've shown only the East versions of the three functions called by p_draw_plotO. Lord knows why anyone would want to print upside down or inside out, but the code on our BBS and on the Issue #45 disk does sup-port graphing in all four directions (for the more perverse among you).
The floats in p_draw_scaleO and p_draw_dataO force real division. Neces-sary, since we need to find what
percent-age of the total span is used by a point in order to scale it along the axis.
In p_draw_scaleO dx and dy repre-sent the number of printer dots per incre-ment on each axis. "Exact" values for these variables would be real numbers.
But the printer only understands integral values for addressing lines and columns.
So we need to round them off.
For non-negative numbers, adding 0.5 and truncating the result performs rounding. So when calculating dx, we add 0.5. Now the compiler casts this real result to an int during the assignment to dx. Voila. The casting truncates the real and we have a well-rounded result. Use of the same technique in p_draw_dataO lets us plot the data as close to its reallo-cation as possible.
This points out the main failure of these plotting routines - they can't deal with real number data and axis labels.
BUGS!!!
You know the feeling. At the end of a programming project you look back and say to yourself, 'What a baboon. If only I'd ... " Chasing bugs can take up more of your time than design, coding, and documenting.
Well, I certainly had my share of silly errors this time. Since I'm a Pascal pro-grammer at heart, a lot of my problems have to do with sloppiness in parameter passing. Of course, prototyping would help a bunch, but I haven't gotten into the habit.
So I tried to send mallocO a long int when all it really wanted was an un-signed int. Now C always tries to cooperate with the programmer. No mat-ter how foolish your code is, C really wants to compile it. That's not to say that the compiled code will execute properly, but it's usually good for a laugh. I got a lot of laughs from mallocO.
My perception of my programming abilities tends to vary from godlike to gawd *&%$#@. With my technical self-esteem at a low ebb this issue, I assumed that the most pernicious of the latest bug batch stemmed from my code. A very entertaining problem, it caused the printer head to do the jitterbug from time to time. Interesting behavior, but hardly useful.
I pared down the code until it did nothing but send graphics lines to the printer. And found that firing the top pin repeatedly would set the print head dancing. My tired old Gemini just couldn't handle the physical stress.
Figures. When I'm sure my code is bad, it's good. And when it just has to be good, it's snot.
MICRO CORNUCOPIA, #45, Jan-Feb 1989 43
Universality
Last issue I marveled over the ap-parent compatibility between printers in the MS-DOS world. I've since had my bubble burst. And to make matters worse, from within the same product line.
I've always liked Star Micronics for their low-cost workhorse printers, but they're the ones who tipped me off to the dangers of printer programming. Their LV 1210 and 1215 require ESC '2' to enable 8/72" line feeds. Unfortunately, ESC '2' sets 1/6" line feeds on the Geminis. Oh well. So much for the "uni-versal" printer interface.
If Figure 1 makes your printer do un-natural acts, check the escape sequences in DUMP.C against your printer's docu-mentation. One of them will no doubt be the culprit.
We have a pretty fair printer museum here at the world headquarters of Micro Cornucopia. But even so, it covers only a tiny percentage of the printer kingdom. If you have a particularly peculiar printer, why not send us the codes necessary to make it jump through the hoops we've talked about here. I'll compile the re-sponses for an entry in Tech Tips.
And Furthermore ...
Some things come to mind as this ar-ticle slips past three weeks overdue:
• More fonts and more sizes would be nice.
• As would circle drawing capabil-ity for pie charts.
• We need more than 64K of printer memory for use with the higher density printer modes or with very large printouts (banners). I think you can do this with a huge pointer to printer memory and use of callocO to allocate storage of lines rather than mallocO to
store bytes. _
But I leave these as exercises for the reader. (The ultimate academic cop-out.)
• • •
Integrand's new Chassis/System is not another IBM mechanical and electrical clone. An entirely fresh packaging design approach has been taken using modular construction. At
presen~ over 40 optional stock modules allow you to customize our standard chassis to nearly any requirement Integrand offers high quality, advanced design hardware along with applications and technical support all at prices competitive with imports. Why settle for less?