After many hours of envying KIM-1 users because they have Jim Butterfield's The First Book of KIM, and pitying them because they don't have a 6800 chip, I finally bought the book when it appeared at a neighborhood book store. In addition to its excellent section on expanding the KIM, The First Book of KIM has a fascinating assortment of programs, mostly games.
However, I am one of the chosen few who has a
Motorola MEK6800D2
Evaluation Kit. Being elite has its disadvantages, though. First, even
with the memory expanded to 512 bytes by the addition of two RAM chips, the D2
still has only half of the KIM's 1K memory. (Of course, everything a 6502
programmer can do, a 6800 programmer can do in half the space!) Second, a
perusal of the games for the KIM shows a heavy dependence on two monitor
subroutines, SCANDS and GETKEY. Subroutine
SCANDS displays a 6-digit buffer on the 7-segment LED readout of
the KIM. GETKEY checks for a key closure and, if found, returns
the key code of the key depressed. Motorola, not to be left behind, put two
similar routines, OUTDS and KEYDC, in their JBUG
monitor. Unfortunately, these are not subroutines (no RTSs).
Bye, bye, games ...
Wait! All is not lost! A little study of the JBUG assembly listing to
determine what lines of code are necessary and one can then copy
OUTDS and KEYDC into user memory as subroutines.
While this would be impractical for a 256-byte system, it is quite feasible
for the expanded 512-byte system ($10 for the 2 RAM chips). My subroutines
take up NNN bytes, leaving NNN bytes for other purposes.
The first subroutine I put in my "library" I call GETKEY too.
This is a complete rewrite of the KEYDC and KEYDC/
segments of the JBUG monitor (0xE14E to 0xE168). My versions starts by calling
a subroutine, PINIT, which initializes the keyboard/display PIA.
Following initialization of the PIA, a jump to monitor subroutine
KEYCL scans the columns of the keyboard matrix to see if any key
is pressed. If no key is found, the subroutine returns immediately; otherwise,
continue.
The rest of GETKEY simply scans the keyboard a row at a time, with
each row scanned column by column. (A good description of this process is found
in the hardware and software section of the D2 manual.) The bit configuration
for the row combined with the bit configuration for the column provides the
coordinates of the key that was pressed. This is the value that is returned to
the calling program in the A register. Note that the A and X registers are
used by the subroutine - save and restore their previous contents if necessary.
That wasn't too bad. The display subroutine was another matter. JBUG's
OUTDS routine displays the data (7-segment LED patterns) located
in a 6-byte display buffer called DISBUF. This method is also
used by the KIM monitor. However, the game program I intended these subroutines
for (Farmer Brown) would necessitate constant manipulation of the data in the
display buffer. The necessary shifting and blanking would take time (not that
important) and memory space.
My alternative is a general-purpose subroutine called SCNDIS,
which will display any number of bytes from anywhere in memory. The information
displayed is the 7-segment pattern represented by bits 0-6 of each byte in the
display buffer. SCNDIS uses three arguments passed through
registers:
For example, calling SCNDIS (X=0x0140, A=3, B=2) would cause the
3 bytes stored at locations 0x0140 - 0x0142 to be displayed once on the
2nd, 3rd, and 4th digits of the readout.
Using this subroutine, the above-mentioned shifting of an item on the display
only involves incrementing and decrementing the digit start value passed to
SCNDIS in the B register. Blanking of digits to the right of
an item is controlled by the byte count in register A, blanking to the left
by the digit start in register B. As you can see, no operations are performed
on data, only on pointers.
...