![[System board]](mek6800d2_system_board.jpg)
![[Keypad display]](mek6800d2_keyboard_display.jpg)
|
|
|
I thought I'd write a little bit here about the background of the "Farmer Brown" game and my 6800 microcomputer—and I kept writing and writing and writing ... Sorry! At least I threw in some pictures.
The KIM-1 (Wikipedia) was a popular, relatively inexpensive computer that came out in 1976. It combined the 6502 CPU, a hexadecimal keypad, and a 6-digit LED display on a single printed circuit board. For Christmas in 1977, my parents gave me a Motorola MEK6800D2 Evaluation Kit. The D2 kit consisted of a 6800 single-board computer (on the left) connected by a ribbon cable to a separate, KIM-1-like keypad/display board (on the right):
|
|
|
The full-size images by John Kent can be found at 6800 Microprocessor Bits' MEK6800D2 Evaluation Kit page. I don't remember the system board being such a rainbow of colors, but I'll take John's camera's word for it.
The late Jim Butterfield (Wikipedia), a noted popularizer of microcomputing in the early days, coauthored The First Book of KIM, a book about the KIM-1 and containing a good number of assembly language programs, among which was the "Farmer Brown" game mentioned in this web page's title. Here's the "Farmer Brown" program in the Internet Archive's copy of The First Book of KIM: page 64, page 65, and page 66, which are all images of the original pages. The book (and especially the 6502 code listings) in text form can be found here.
The "Farmer Brown" game had different animals, pictured below, moving across the LED display one at a time. When you recognized an animal, you were supposed to press the corresponding key ("A" for ant, "B" for bird, etc.) before the animal reached the other side.
![[LED animals]](animals.gif)
The 6 LEDs on the two computers were primarily used to display a 4-digit hexadecimal memory address (0000-FFFF) and the 2-digit hexadecimal value (00-FF) of the byte at that address. The KIM-1's 6 LEDs were flush up against each other, so the pictures of the animals looked halfway decent. Unfortunately, as you can see here (from Wouter's 8080 page),
![[MEK6800D2 LEDs]](mek6800d2_leds.jpg){kind=small}
the MEK6800D2's LEDs had a space between the 4-digit address and the 2-digit value, so the animals didn't look quite so good! What can I say—I used my imagination! I also put in a decrementing time delay controlling how fast the animals moved across the display. The animals would start out at a reasonable rate and then begin moving faster and faster; eventually, an animal's presence would be indicated by a millisecond flash of some LEDs. "Farmer Brown" wasn't a terribly interesting game, but the fun was in the programming, not the playing!
The D2 was a kit, meaning I had to solder all the parts on the boards. I got a bunch of sockets from RadioShack to keep from having to solder the ICs directly to the boards. Building a RadioShack 5-V power supply and enclosing it in a professional looking metal case with a power-on red light and external contacts helped me develop a deeper appreciation and understanding of electrical current—or lack thereof. I quickly found a used, unshielded 5-V power supply that was the size and weight of a brick at a nearby electronics surplus store. I kept it, still unshielded, on a piece of slate; I was lucky I never electrocuted myself! The computer now powered up flawlessly. The D2 only had 256 bytes of RAM on-board, with empty sockets for an additional 256 bytes of RAM; my next order of business was to purchase 2 more chips to raise the RAM to 512 bytes.
The D2's single-board computer had Motorola's standard EXORbus 86-pin edge connections. I obtained a second-hand EXORbus chassis at the electronics surplus store. From close examination, I discovered that, despite the connector spacing being incompatible, I could fit standard 22-/44-pin blank printed-circuit boards from RadioShack into the EXORbus bus without danger of adjacent 22-/44-edge pns touching and being shorted out by a single EXORbus connector. Therefore, I took some wire-wrap wire, stripped the insulation, and converted all slots but the first in the chassis to approximate 22-/44-connector slots; the first slot, of course, was reserved for the actual EXORbus computer board. Initially, I built a 1K memory circuit on a breadboard and strapped the breadboard to a 22/44 card with a rubberband! Later, I got rid of that, bought a commercial 4K memory board, designed and wire-wrapped an 8K memory board, and designed and wire-wrapped a 1K memory board with two UARTs. (I did that in stages, not all at once.) Since the original 512 bytes of on-board RAM were disabled by the off-board RAM, my computer finally had a grand total of 13K of RAM!
(When I say I designed the boards, I only used digital logic. I understood some basic electronics, but the only analog parts on the boards that I remember were probably just a couple of variable minicapacitors for adjusting the periods of the 555 timers providing the clock signals to the two UARTs.)
![[RTTY teletype]](teletype.gif)
My brother Andy, a real electrical engineer and eventual Extra Class ham radio operator, designed and built for me a one-transister interface to his military surplus RTTY Baudot teletype. I was able to use the keyboard and printer, with the RTTY keyboard later replaced by an ASCII keyboard kit I picked up from a fly-by-night thrift-store-kind-of-place across from the old University of Maryland Book Exchange. (Hence the two UARTs, which could handle both the 5-bit Baudot serial codes and the 7- or 8-bit ASCII serial codes.) I once estimated the RTTY data rate to be about 45 baud, a figure confirmed by various websites; with an analog voltmeter, you could tell different characters apart by the varying movements of the needle!
The MEK6800D2 had an interface to a cassette recorder for saving and loading programs. I borrowed a line from one of the parallel interface adapters to remotely start and stop the cassette recorder. With this capability, I could start the recorder, write-out/read-in a record, stop the recorder, etc., etc. Not particularly useful when you get right down to it.
![[Floppy ROM]](floppyrom.jpg)
I believe I wrote a disassembler and a simple assembler without labels (i.e., you had to figure out destination locations yourself). I seem to recall getting a Tiny Assembler written by Tom Pittman, but he only mentions Tiny Basic on his website. (Tiny BASICs, BASIC interpreters that fit into 1K or 2K of RAM, were all the rage back then thanks to Dr. Dobb's Journal.) The May 1977 issue of Interface Age included Robert Uiterwyk's 4K BASIC interpreter on a vinyl floppy. (You would play the vinyl disk on your phonograph; you could feed the headphone output directly into the computer, but, since my stereo and computer were a couple floors apart, I opted to record the audio onto a cassette and hand-carry it to the basement.) Although the audio recording was compatible with the MEK6800D2's cassette protocol, my computer couldn't read in the whole program at once for some unknown reason. Consequently, I had to painstakingly (1) read the first 256-byte record and store its contents in memory; (2) rewind the tape, programmatically skip the first record, read the second record, and store its contents in the next memory block; (3) rewind the tape, skip the first two records, and so on ... (I only had to do this once. After loading the complete 4K into RAM, I then saved it out to a new recording which loaded properly.) Oh, the joys of the good old days!
With its open-faced chassis, wires flying in all directions, and the unshielded power supply, my MEK6800D2-based microcomputer looked like it was held together by duct tape. Nevertheless, it worked. I last used the computer in 1980 or 1981, replaced it with a VIC-20 in 1982, and eventually tossed the rickety contraption out in the early 1990s.
The point of the article is not very clear. First of all, it presents a keypad input routine and an enhanced LED display output routine for the MEK6800D2, functions which the KIM-1 had and the D2 didn't. Second of all, the article would have included my implementation of the "Farmer Brown" game for the 6800 D2. If I had finished the article, I would have considered submitting it to Byte or Kilobaud. I personally found Kilobaud more engaging and useful than Byte, but the latter had its moments and, in the end, lasted many more years than Kilobaud.
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 (Wikipedia; also see
VintageComputer.net).
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.
The finish to an unfinished article ....