Modifications to WORKS:

1.21  The explosions were still too fast, so I once again slowed
      them down.  Now they look like the did originally.  Went from
      20 frames/sec to 15.  You figure out how much CPU tie you got
      back.  I don't feel like it.

      Oh, by the way.  I lied in 1.20.  It's now 24 bytes smaller
      than 1.20, and 32 smaller than the original.  I'm serious
      this time... I can't make it any smaller.  Honest.

1.20  Just realized that on a PAL screen the flares would start part-
      way up the screen and that the fix (below) would always be
      visible.  I add 56 raster lines (I believe a PAL screen is ? x
      256 [512 interlace]) to my screen and move the flare origins
      down 56 if GfxBase says the program is running on a PAL system.
      I dunno if these work, since I haven't got a PAL system.  If
      anyone with PAL ever gets this program, tell me if it works
      (pun intended).

      Now takes up 20-25% of the CPU during the explosion, as opposed
      to about 80-85% for the original, which is fairly good.  Simply
      moving the mouse nomrally takes about 20-25%, for example.  It's
      about 5-10% for the flare.  The unblanked mode is negligible.

      Fixed a bug that would crash works if there was an old CTRL-C
      waiting around for someone to notice it when works exited.

      Executable 4 bytes smaller than 1.10, 8 smaller than original.
      This will not happen again.  There is nothing left to trim.

1.12  Explosions didn't look right (too fast, too many dots), so I
      altered them.  Also, I fixed it so that even if sprites do
      somehow get stretched, they should be all but invisible.  I did
      this by putting sprites behind graphics and using holes in a
      black foreground onto a cycling colored background as the dots
      instead of putting cycling dots onto a black background.  This
      new fix may, however, cause problems with monitors that can see
      past overscan boundaries (I understand multisync's with flicker-
      fixers do this).  I already had to increase the overscan because
      it was possible to see it on a 1080.  I'm including a command
      line option to force the program do it the old way.

1.10  Fast SetPixel() routines added (courtesy of Jeff Petkau).  More
      performance improvements.  Now takes about a third of the CPU
      time it used to, so it shouldn't be a bother unless you're
      running a ray-tracer while the screen is blanked.  Unblanked
      CPU usage is negligible.  Executable size has been trimmed down
      to four bytes less than that of the original.

      NOTE:  The system has a nasty habit of turning off sprite DMA for
      me when the current scan line includes the pointer (or any other
      sprite, for that matter) which results in the portion of that
      sprite on that scan line being stretched out vertically.  I
      changed a few things and it should be (it seems to be) a rare -
      if not non-existent - occurrence.

1.01  Some math sped up, more dots per explosion and faster explosions
      as a result.  Not a hell of a lot else.

1.00  First release.