Biorhythm Calculator v1.1

  Written by: Kevin Rahe, Reliable Software
              340 Nine Mile Rd. N.E.
	      Comstock Park, MI  49321

  GEnie address:  K.RAHE 

  SysOp of The ESCAPE:  (616) 784-6550, 300 baud, 8/N/1

  May be freely distributed!

  1-26-87


  To use Biorhythm Calculator v1.1, first fix the filenames by executing the
  EXECUTE_ME batch file:

  execute EXECUTE_ME

  Run the program from CLI or click Workbench icon.  Enter your birthdate in
  the Birthdate gadget in the form:  MM-DD-YYYY or MM-DD-YY.  The graph will
  be instantly redrawn using your birthdate and the system date.  The month
  and year will be displayed at the bottom of the window.  Make sure your
  system date is set correctly, or you may find yourself paging forward or
  backward many months just to get to the current month.  The system date is
  looked up each time the graph is drawn, so you may change the system date
  after you've started the program.  The arrow gadgets will draw the graph
  for the month following or preceding the displayed month.  If you re-size
  the window, the graph will be redrawn to fill the window, but be aware
  that the larger the window, the longer it takes to draw the graph.



  I wrote Biorhythm Calculator with 3 purposes in mind:
  
       1. To learn C (yes, it's my first REAL program in C)
       2. To learn Intuition 
       3. To provide an example of using the Motorola Fast Floating Point
          Libraries with Lattice C


  Feel free to use the header files "ffp.h" and "dates.h" in your own
  programs.  The Fast Floating Point functions are declared in "ffp.h".  The
  usage of most of them is logical, but I have included the correct syntax
  for those that are a bit more cryptic.  Two functions in "ffp.h" will open
  and close the FFP libraries.  OpenMathLibs() returns an integer, which
  will be FALSE (0), if either of the FFP libraries couldn't be opened.

  "dates.h" contains various date conversion and calculation routines.
  Descriptions within the file explain what the various routines do and how
  to use them.

  My arrow gadgets may be a bit unorthodox for non-textual gadgets.  I
  didn't know of an easy way to get an image from my mind (or from a
  graphics program) into C source as HEX data, so I simply drew bounded
  triangles within the confines of a gadget.  Because I didn't allow the
  window to be sized so small that those gadgets would not be visible, the
  triangles don't have to be redrawn again once the window is initialized.
  The effect is that the user can't tell that those triangles aren't really
  part of the gadget.

  If you're surprised by the small size of the object code (less than 20K
  for an 18K source file), I did learn a few tricks to pull with Lattice.
  Since Lattice isn't the most efficient compiler in the world, I tried to
  generate as little Lattice code as I could.  I accomplished this by:

       1.  Using the Motorola FFP math routines
       2.  Using the -v option on  lc2 (which disables stack checking)
       3.  Using BLink (version 6.7) instead of ALink
       4.  Using _main() instead of main()

  1 through 3 above are perfectly legal, and do make a big difference.
  Number 4 MAY be a different story, as I didn't come up with it myself, but
  rather gleaned it from gfxmem.c which appeared on FISH 14.  If you use
  main() instead of _main(), extra code is generated that will open a
  console window if the program is run from an icon.  I did not like, nor
  need, this extra window, so I chose to use this technique.  I am not aware
  of, nor responsible for, any other possible side effects from using
  _main().  Another oddity I came across was the fact that the ORDERING of
  your #include statements can affect the size of the object code.  For
  example, when I put #include <intuition.h> after <gfxbase.h> and
  <gfxmacros.h>, I lost 1 to 1.5K of object code.  I cannot explain this at
  all, however.

  Feel free to modify the source code with any enhancements you might like,
  and redistribute.  All I ask is that you provide all the original program
  and text files AS IS, along with your modifications.  Also feel free to
  flame about my programming style, as this is my first venture with C, and
  I could probably use some fine-tuning in my techniques.  I can't guarantee
  that I'll adopt any suggestions, but I will take them into consideration.



  Special thanks to:
  
  Steve Poling, Grieg Pederson, Louis Makamos, John A. Hodgson, and probably
  a few others.