                          LORENZIAN WATERWHEEL

This is a model of a special kind of waterwheel. It demonstrates chaotic
motion. It moves in a way that is difficult to predict.

The motions of most mechanical systems are relatively easy to predict. A
stone falls at a rate equal to the force of gravity times its duration of
fall. A pendulum oscillates at a rate so predictable that it's used in
clocks. Eclipses can be accurately predicted many years in the future.

Most waterwheels move at a constant rate determined by the flow of water
and friction. The Lorenzian Waterwheel however moves at varying rates,
and it will even reverse direction after awhile.


OPERATION

The friction, water fill rate and leakage rate can be adjusted using the
F, W and L keys. Use lowercase to reduce the values and uppercase (Shift
key) to increase them. Only certain values, which are set when the
program starts, exhibit chaotic behavior. (Bizarre behavior occurs when
friction or leakage is negative.) The S key can be used to give the
wheel a nudge if it stops.

Although the program runs fine on many computers and under many versions
of Windows, if it does something too weird, try running it without
Windows (i.e. boot into pure DOS). Most problems are caused by hitting
Alt+Enter under Windows 98.


HISTORY

Chaotic motion was first described by a meteorologist named Edward
Lorenz. In 1963 he published a paper in the Journal of Atmospheric
Sciences called "Deterministic Nonperiodic Flow". In it he described the
"butterfly effect": The mere flap of a butterfly's wing could radically
alter the weather days later.

Lorenz devised a mathematical model to predict the weather. It showed
that very small differences in initial conditions led to large changes
after a few days that were impossible to predict. This extreme
sensitivity to initial conditions is the essence of chaos theory.

A colleague of Lorenz's, Willem Malkus, realized that a leaky waterwheel
would exhibit the same chaotic behavior.


IMPLEMENTATION

The simulation of the waterwheel is relatively simple, being only a
little over five pages of code. A particular challenge was getting the
wheel to move smoothly without flicker.

If an image is simply drawn, erased, then redrawn in its new position,
the result will probably flicker annoyingly. The reason this happens is
that if the video beam passes through the erased portion (even for only a
1/60th of a second) it will be very noticeable. There are several methods
that can be used to prevent flicker, but the one that is usually used is
double buffering.

Double buffering draws an image in a buffer then, after the image is
complete, the buffer is displayed. The image in its new position is drawn
in a second buffer, and after it's compete, it's displayed. The first
buffer, which is no longer visible, is erased and the image is redrawn.
The two buffers alternate, and thus the erase and redrawing process is
never visible.

Double buffering can be done either in software or hardware. The software
technique draws the image in normal RAM then quickly copies it into the
video display RAM, usually during vertical blanking.

This program uses hardware buffering. The 64K of RAM designated for video
display is enough to hold two buffers...well, almost.

If 640x350 graphics are used (mode $10), 64K is more than enough. The
number of bytes used (in address space) is 640/8*350*2 = 56000, which is
less than 64K (=65536). The only problem with this is that the pixels are
1.37 times taller than they are wide. This must be taken into account if,
for example, you don't want your circles to look like eggs.

Mode $12 (640x480) has the correct aspect ratio, and it's the one that is
used in the Waterwheel program. The only problem is that 640/8*480*2 =
76800, which is more than 64K. Fortunately there are registers in the VGA
hardware that can get around this problem and even turn it into an
advantage.

The 64K of video RAM can be divided into three chunks, two of which serve
as image buffers that alternate, and one that is constantly displayed.

                 -----------
                | 140 lines |
                 ===========   <- 1 line (unused)
                | Screen A  |
                | 339 lines |
                |           |
                 -----------
                | Screen B  |
                | 339 lines |
                |           |
                 =----------   <- 16 bytes (unused)

        Total lines = 819
        819 * 640/8 = 65520 bytes
        64K = 65536, thus there are 16 bytes left over

The Start Address Register (in the VGA hardware) is set to display either
Screen A or B, depending on which is not going to be drawn into on the
next video frame. The Line Compare Register is set to display the
beginning of video RAM when the 340th scan line is reached. The result is
that the video RAM gets displayed like this:

                    -----------
                   | Screen B  |
                 -----------   |
                | Screen A  |  |  <- screens alternate
                | 339 lines |--
                |           |
                 ----------- 
                | 140 lines |
                 ===========      <- one line (unused)

The bottom 140 lines are perfect for the Speed graph, which doesn't have
a flicker problem.

The source code (WW.XPL) is included in the distribution pack to show how
the details work.

-Loren Blaney
loren_blaney@idcomm.com
