Cli

Squashed commit of the following:

commit 46b1bddfa6c49962ac77a0b71bc32be0284fb354
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Fri May 17 22:25:51 2013 -0700

    Code cleanup

commit a3d81291f008bbfe21de0d5bc5a65ea0ebe10b63
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Fri May 17 22:18:16 2013 -0700

    Keyboard driver implemented.

    Most keys of the PS/2 keyboard are supported.  Numeric keypad is not, because the scancodes it produces matches the cursor keys, and I don't have software to change that.  The home/end/ins/del/pgup/pgdn keys are unsupported as well, since I don't have any logic to interpret the $E0 prefix byte.  Additionally, the ALT key is not yet supported either, although that's a very easy thing to add.  I just didn't do it because I feel I can use the remainder of the day for making something fun for MakerFaire instead.

    However, function keys are supported, as are the SHIFT and CTRL keys.

commit 01ead3625567eaa3fa843cb7e856f692b7a4312c
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Thu May 16 07:46:08 2013 -0700

    First code for keyboard driver

    Tracks shift key and CTRL key states.  I'm going to skip ALT key for
    now, but it follows exactly the same template.

    My next step seems to be the PS/2 -> ASCII translation table.  This
    table will produce results for both key down and up events, so I'm going
    to somehow need to filter out key-up events.  For my immediate needs,
    they're not interesting.

commit 0dbab9b4698c469884e1e024380b0c1d3689e68f
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Wed May 15 20:02:58 2013 -0700

    Print a carriage return.

commit b6bb1a56df30398a90f8fca01d138d331d8d67d4
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Tue May 14 23:56:22 2013 -0700

    Demonstration of CLI

    This commit provides an integration test of the CLI functionality.  I basically
    stub out the keyboard driver, and slow it down to a speed which is observable
    by a human.  You can actually see the cursor move on the screen, as though
    downloading text from a 1200bps modem.

    I love it when a plan comes together!!

commit 4e5d24061ae820fda0920864a24e62d3f1fc3044
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Tue May 14 23:52:25 2013 -0700

    Text input now visible while editing.

    This rqeuired a few changes to get right.

    The changes to cli.fs were minimal, in retrospect; and my hypothesis of how to
    handle visual output was _almost_ right.  I failed to consider the case where
    input text wraps when the cursor is on the bottom line of the screen, however.
    The solution was to record the input field's screen location in a way that
    scrolled with the rest of the display.

    The cursor.fs module now has a concept of a "bookmark," set with setbm and
    restored with resetbm.  The bookmark's job is to allow the CLI to restore the
    cursor position to the beginning of the right-hand side of the gap buffer
    without having to know the actual current location of the cursor.
    Additionally, it's unaware of the necessity for scrolling.  The cursor module
    implements all this logic, since it has all the data on-hand; however, its
    functionality, i admit, does overlap somewhat with that of the tty module.  It
    was a coin-toss as to whether or not to put this functionality in tty or in
    cursor.

commit fc4d6268a1eaefebbc5d84027d1f2698a2d51a41
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Mon May 13 23:46:49 2013 -0700

    Bytes stored to memory while editing.

    When a user types, graphic characters will be placed into memory, fully
    supporting insert capability, thanks to the gap buffer.

commit a5e7968ae0ffc5e4167c42d9390228f7e99178ca
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Sun May 12 17:14:22 2013 -0700

    CLI tracks cursor, total size of buffer.

    The code does not yet cover rendering to the screen, nor does it yet
    place characters into the buffer.  However, given the valid set of input
    commands, the length of the final result is demonstrated to be correct.
    Since I'm using a gap-buffer to implement the edit buffer, this implies
    that pointer arithmetic should be correct.

commit d79e00df5152173429900c8cd5e652b72787fabd
Author: Samuel A. Falvo II <kc5tja@arrl.net>
Date:   Sat May 11 22:43:57 2013 -0700

    CLI handles zero-length and perfect typing scenarios.

    Squashed commit of the following:

    commit 97207d7042853f9c3f0d8f871aa87e80a63089d5
    Author: Samuel A. Falvo II <kc5tja@arrl.net>
    Date:   Sat May 11 22:40:57 2013 -0700

        When accepting input, the cursor should be shown.

    commit bcf194e3c2c7deba39e4aff5e83b70ae152cd796
    Author: Samuel A. Falvo II <kc5tja@arrl.net>
    Date:   Sat May 11 12:39:58 2013 -0700

        Straight ahead typing now fills the input buffer (IB).

        At this point, no attempt is made to alter the display at all.  Text is going
        straight from keyboard to input buffer with virtually no interpretation at all.

    commit 35f475673929ad558e72c2200e272562da2966c8
    Author: Samuel A. Falvo II <kc5tja@arrl.net>
    Date:   Sat May 11 10:56:04 2013 -0700

        The input handler must terminate when pressing ENTER or RETURN.

    commit 271992ff6c4e88f4d63ed8136a6a4a7862c16102
    Author: Samuel A. Falvo II <kc5tja@arrl.net>
    Date:   Sat May 11 10:47:37 2013 -0700

        For 0-length results test, add fake keyboard driver call.

        The keyboard driver entry-point is getkey, which will eventually block until it
        has a complete ASCII or PS/2 keyboard code that can be represented in a single
        integer.

        Right now, getkey's fake just reads from a buffer.  No blocking occurs.