The Resurrection of My Homebrew MC6800 Computer System

By D.R. Sentz
June 2, 2014 - July 1 2015, last update 07Dec2019

June 2, 2014- I’ve spent the past few days reassembling and
checking out my old MC6800 computer system, which I built
starting in 1975, completed in 1977, and last checked out in
1996.

I started out with the Motorola MEK6800D1 Evaluation Kit that I

bought in 1975, when it first came out, for $150. I added the
five MC6810 memory chips (that did not come with the kit) so
that I had a fully populated board, with a total of 6x128=768
bytes of RAM from address $0000 to $02FF, plus the 128 bytes of
the MIKBUG RAM from $A000 to $A07F. My version of the “Shooting
Stars” game (from the May 1976 issue of BYTE magazine) uses 543
bytes. I recently wrote a separate report about “Shooting Stars”.

1
 My CPU Board with Five of the MC6810s Removed.

in 1976-77 I built a “mainframe” chassis with a backplane having

both the Motorola “EXORcisor” type card slots and the Altair
“S100” type card slots. I designed and built a backplane
expansion/buffer interface board for the MEK6800D1.

My Homemade Backplane Buffer Board Uses 8T97s and 8T26s

2
I ordered and installed two of the S.D. Sales 4k x 8 S-100 type
static RAM board kits. When I added the external RAM I had to
remove five of the MC6810 chips from the CPU board (addresses
$0000 to $027F, 640 bytes). I still have them in storage.

Replaced in 2014

Replaced in 1996
S.D. Sales Co. 4Kx8 Static RAM Kit

For the console terminal I ordered the SWTPC model CT-1024 video
display terminal kit and a surplus CRT display having a green
phosphor. I built up a pretty nice terminal. I wish I still had
it. Most of the construction and checkout of my computer system
occurred in 1976, the year I graduated from Georgia Tech with my
BSEE degree.

In 1996 I hooked up my original 512K Macintosh as the console

terminal, running MacTerminal 2.0, System 2.0, and Finder 4.1. I
adjusted the RS-232 console interface clock of the 6800 computer
for 600 baud. The MacTerminal “Send File…” command works fine
when the “File Transfer” character and line delay settings are
both 2/60 sec.

So anyway, this morning I fixed the 2nd 4Kbyte memory board

(addresses $1000-$1FFF). There were a total of six 2102L1 memory
ICs on the board that failed sometime after 1996, as pinpointed
by two memory diagnostic programs. Fortunately I happened to
have nine New-Old-Stock 2102L1’s in my parts cabinet, so my
computer is back up to the total 8Kbytes working memory (plus

3
locations $A000-$A07F of the Mikbug “scratch” RAM on the
MEK6800D1 CPU board).

In 1976-77 I constructed an audio cassette interface for my

computer. I used the “Bit Boffer” design by Don Lancaster, as
published in the March 1976 issue of Byte magazine. I also
included the remote ON/OFF control circuit describe in the other
article by Jack Hemenway. My build did not work at first. During
the troubleshoot I discovered two errors in Figure 6 of the
article, the receiver schematic diagram. See photograph below of
my markups.

From Page 35 of March 1976 Issue of Byte Magazine

 The output pin of IC6 was labeled “5”, should have been “6”.
 IC4c and IC4d wiring was incorrect. Markup shows the
correction that made the circuit work correctly.

I wrote I/O drivers derived from the examples in the Hemenway

article. I bought a Panasonic RQ-212DAS cassette unit just for
this application, and it still works. I never did write to Mr.
Lancaster or BYTE magazine to report the artwork errors, but
several other folks did (correction appeared in the August 1976
issue on page 76).

Today, June 2, 2014, I successfully downloaded my “Shooting

Stars” game from the old cassette tape, so the Bit Boffer

4
receiver, including the motor start/stop function, is still
working fine, (after I cleaned the three audio and remote ON/OFF
plugs with ultra-fine hobby sandpaper and wiped them with
contact cleaner).

June 14, 2014- on June 5th I successfully wrote a text file to

the audio tape, thereby verifying that the transmitter portion
of the Bit Boffer is also still working fine. I started a new
page for my handwritten tape directory.

June 21, 2014- I completed the design and source coding for my
“Utility Manager” program. The resident assembler, which worked
fine the last time I tried it (in 1996), is bombing during 1st
pass when it tries to process source code lines having statement
labels. After a few experiments, I am suspecting that the CPU
chip is the culprit, so I am going to order a couple from Jameco
for $4.95 each.

I am also ordering a hi-voltage opto-isolator, #H11D1, and a

rectifier bridge chip, for a modification to my TTY Printer
output interface circuit.

The assembler is operating the reader control relay inside my

computer OK, but MacTerminal is not seeing Xoff codes or is not
responding to them if they are there. I plan to test the
Xon/Xoff protocol in MacTerminal, and to figure out if the
resident assembler is or is not sending Xon and Xoff codes to
the terminal. If it is not, I may design a patch for the
assembler. UPDATE: I reviewed the Resident Assembler object file.
It does send the Xon/Xoff codes to the console whenever it
commands the reader relay on or off.

July 5, 2014- The resident assembler was hanging during pass 1

symbol table build. Last week I replaced the CPU chip and then
pass 1 would complete, but usually with several “ERROR 213”s
that were not traceable to source code errors. Changing the
ordering of the source code would alter the pattern of errors.

This past week I may have successfully fixed both the “ERROR 213”
issue and other erratic hang behaviors, by reseating all of the
socketed small ICs on the CPU board. There have been no “hanging”
incidents since then. Also, the resident assembler seems to be
OK now during 1st pass.

I also checked the clock frequency by listening for the second

harmonic on my old SW radio. It is about 975 kHz, + or – 5kHz.

5
Files on Audio Tape Cassette Thanks to Bit Boffer Article.

6
Remaining SW glitches that may be HW related;

Resident Assembler does not reliably print the “S1...” object

tape even though I have “OPT O” set in the source program. When
it does print, it does not reliably include the “S9...” last
line. OPT NOG seems to work OK.

TSC Space Voyage program hangs at the “short range scan” output
line after the word “ENERGY” is printed.

*UPDATE July 19, 2014* - I traced the “Space Voyage” problem to

the stack pointer. If I start the program at $0103 instead of
$0100 it works fine, or if I change $0100 LDS #$A042 to $0100
LDS #$A043 it also works fine (as do A041, A044, A045, A046, and
A047). So there is some anomaly in stack pointer behavior when
it is set to $A042. Somehow the stack pointer got reloaded to
$0420, which causes some of the Space Voyage object code to be
overwritten by stack operations, namely, a portion of the “Short
Range Scan” function. Code at locations $0250-$0255 also gets
corrupted. I have not been able to determine root cause, but I
have patched the object tape file to make it work, by starting
the program at location $0103, which simply skips the stack
pointer load instruction at $0100-$0102.

Yesterday I removed each IC on the buffer board, sprayed the

socket terminals with contact cleaner, and reinstalled the ICs.
This had no effect on the program malfunctions described above.

July 23, 2014- Continued troubleshooting revealed a bad memory

IC on the low 4Kbyte memory board, chip #1, which is the LSB of
address block $0000-$03FF. The malfunction was not detected by
the memory diagnostics. I used SPACE VOYAGE program source code
listing with judicious insertion of “SWI” and “NOP” instructions
to trace the malfunction to the LSB of memory location $0252.
The revelation occurred when I replaced LDX #$0CBF at 0252 with
INX, SWI, and NOP. At the SWI I observed that the INX
instruction changed during execution of the BSR OUTQUD
instruction immediately before it, from opcode $08 to $09, the
opcode for DEX. The content of the index register at SWI had
indeed been decremented by one instead of being incremented by
one. I replaced that part, a National Semiconductor 21L02-1,
with a Fairchild 2102L1. This is the 8th 2102-type memory IC that
I have replaced over the life of my computer so far, one in 1996,
the six in early June this year, and the one today. In the
course of the most recent troubleshooting I replaced the
original XC6800 CPU chip with an MC6800P that I recently ordered
from Jameco, and I also replaced the MCM6810L-1 Mikbug RAM chip

7
on the CPU board, having date code 7529, with one of two spares
having date code 7523. The remaining spares have date code 7529.
Both the XC6800 and the replaced RAM may be just fine, but I do
not feel like taking the risk of putting them back in. Both
SPACE VOYAGE and the MP-E Resident Assembler programs appear to
be working properly now, where they had been malfunctioning
before.

Here are several findings and notes arising from this

troubleshooting exercise;

The Resident Assembler “OPT S” directive has never worked as

described in the MP-E documentation, as best I can tell. The
symbol table gets printed, but only at the end of the 1st pass.

MacTerminal is best set to TTY mode in the SettingsTerminal

menu, because the VT100 Xon/Xoff functions will not work
properly with this assembler due to the internal I/O buffering
that seems to occur in MacTerminal. Instead, I set the file
transfer line delay to at least the minimum value that works,
depending on what I am doing, as listed below;

In MacTerminal, FileFile Transfer menu,

 character delay can be left set to 2/60ths, always,
 set line delay as follows;
o 2/60ths for sending object tapes or other text files
o 60/60ths for 1st pass of assembler (1P or 1S)
o 150/60ths for 2nd pass listing (2L)
o 180/60ths for 2nd pass tape (2T)

July 24, 2014- A couple of hours after having fully restored my

old computer to full error-free functionality, the power/sweep
board in the 512K Macintosh malfunctioned. No horizontal sweep
upon power-on, and a thin vertical line centered on the screen.
See separate report on my subsequent repair of the 512K Mac.

In early September I successfully used the MP-E resident

assembler to compile my “Utility Manager” program (see note
above dated June 21) and generate all of the expected printout;
Pass 1 symbol table, Pass 2 assembled source listing, Pass 2
symbol table, and the Pass 2 Object Tape in MIKBUG format.

December 24, 2014- The CPU board has continued to have

unreliable operation of its terminal interface. A couple of
weeks ago it quit working completely. During troubleshooting
yesterday, December 23, I eventually removed and replaced the

8
XC6820 Peripheral Interface Adapter (PIA) chip. This appeared to
solve one problem whereby the PIA chip was not accepting input
from the terminal, nor was it outputting anything to the
terminal. After reseating the PIA, it began functioning normally,
but the output was not making it through IC19, a 4N33 opto-
isolator chip. I swapped IC19 with the 4N33 at IC20. The
terminal interface started working again. After I reinstalled
the buffer board and the two 4K memory boards MIKBUG could not
write to the memory boards. I reseated those three boards plus
the CPU board. Since then everything has been working without
fail, and I completed my demonstration movie. Also, I no longer
need to use a stirring stick to warp the CPU board.

January 23, 2015- My M6800 computer has been reliable all month.
I completed debug and test of my Utility Manager program.
UTMGR3.SRC is the current working version. UTMGR3.OBJ is the
MIKBUG-formatted object code. I completed a teletype driver add-
on program for Utility Manager. The add-on is now ready to test.

The Resident Assembler has been working reliably, except that it

continues to be unpredictable regarding the OPT SYMBOL directive,
working sometimes and not working other times.

There was one instance during a 2L pass where a correct source

line character was misread as a “k” (label read as LkADR)
instead of “K” (supposed to be LKADR), causing an error 205 on a
line of code that assembled OK several times before, and after.
I changed the line delay from 150/60 to 180/60 and re-ran the
pass, and there was no error. I do not know if the 150/60 line
delay caused the problem.

July 1, 2015- The M6800 computer has now been working reliably,
in all respects, since January.

A couple of months ago I ordered a TRENDNet model TU-S9 USB-to-

RS-232 adapter, for only about $9, and I installed Tera Term
v4.86 on my Windows 7 laptop. This setup works great. I can now
operate the M6800 computer using the laptop as the MIKBUG
console. I am using 600 baud for the interface data rate as that
is the best the MEK6800D1 board can do. It only takes 4 minutes
and 10 seconds to load the resident assembler from the laptop.

I can use either the Mac512K or the PC as the MIKBUG console

terminal now.

9
January 5, 2016- I operated the old Windows98 Toshiba Laptop
with HyperTerminal as the console terminal, at 300bps, 7 bits
data, space parity, and 2 stop bits. It has a 9-pin RS-232C
connector on its back side, mapped as serial port COM1, so the
USB adapter is not necessary. The console data rate switch on
the back of the M6800 computer must be set to down position for
this 300bps and 2-stop-bits mode. The up position is for 600bps
and 1-stop-bit. The installed HyperTerminal does not have a 600
bps option.

The stop bit thing is an artifact of the MIKBUG ROM and the
MEK6800D1 board design. Their idea was that the speed selections
would be 110 bps with 2 stop bits for a mechanical teletype set
as the console (such as the Teletype Corp. model ASR33), or 300
bps with 1 stop bit for a CRT terminal. These were still state-
of-the-art devices in 1975.

A long time ago I retuned the 300bps@ 1-stop-bit option to 600

bps. For the Windows98 terminal, just this week, I retuned the
110bps@ 2-stop-bit option to 300bps. The 110bps vs. 300bps stop
bit definitions are built into the MIKBUG ROM and cannot be
changed, but everything works fine as long as the corresponding
terminal stop bit selections are configured to match.
Here are the audio tape file directories as of January 5, 2016;

PANASONIC RQ-212DAS 1ST TAPE, SIDE 2, LABELED "SEE SHEET IN BOX"

THIS DIRECTORY WAS HANDWRITTEN ON A YELLOW SHEET- SHOULD BE IN MANILA FOLDER LABELED "uP stuff CASSETTE SOFTWARE DRIVERS"
TAPE START END
PROGRAM NAME TYPE DATE UTILITY NOTES
COUNTER ADDRESS ADDRESS
000-003 SHOOTING STARS BINARY 0000 0243 2/22/77 PUNCHER (MINIMUM PUNCHER DATED 2/22/77)
020-028 SPACE VOYAGE -A BINARY 00C1 07FF 2/23/77 PUNCHER TECH. SYSTEMS CONSULTANTS (TSC)
028-037 SPACE VOYAGE -B BINARY 0800 0FFE 2/24/77 PUNCHER ALL TSC DOCS ARE IN 3-RING BINDER
037-038 RANDOM NO. ROUTINE BINARY A04A A06F 2/24/77 PUNCHER TSC
00C1 0FFE
040-058 SPACE VOYAGE BINARY 2/25/77 PUNCHER COMPLETE (MAY NOT BE USEABLE)
A04A A06F
00C1 0FFF COMPLETE-USE "CORRECTED SPACE
060-079 SPACE VOYAGE REV. A BINARY 2/26/77 PUNCHER
A04A A06F VOYAGE LOADER" DATED 2/26/77
080-083 FLOATING POINT PACKAGE BINARY 0100 02FC 2/27/77 PUNCHER TSC
SCIENTIFIC FUNCTIONS
085-093 BINARY 0300 08F9 3/24/77 PUNCHER TSC
PACKAGE
TEST PROG. FOR SC. TSC, USE W/ FLOATING POINT
093-095 BINARY 0900 099C 3/24/77 PUNCHER
FUNCTIONS PACKAGE- SEE TSC DOC.
095-098 CALCULATOR EMULATOR BINARY 0300 04FF 3/24/77 PUNCHER TSC
100-117 MICROBASIC INTERPRETER BINARY 0020 0CA3 3/25/77 PUNCHER
118-130 RESIDENT EDITOR BINARY 0100 09A3 7/25/77 PUNCHER SWTPC #MP-E PAPER TAPE VERSION
131-162 RESIDENT ASSEMBLER BINARY 0088 15B6 7/25/77 PUNCHER SWTPC #MP-E PAPER TAPE VERSION
168-173 4UTILITIES.OBJ TEXT 0000 0258 6/5/14 PUNCHER2 ORIGINALLY LOGGED ON QUAD SHEET

10
PANASONIC RQ-212DAS 2ND TAPE, SIDE A, LABELED "BIT BOFFER 2"

TAPE START END

PROGRAM NAME TYPE DATE UTILITY NOTES
COUNTER ADDRESS ADDRESS
007-010 SHOOTINGSTARS BINARY 0000 0243 JAN. 7, 2015 UTMGR3 BEFORE FIX TO LAST BYTE WRITE OP
010-013 SHOOTINGSTARS BINARY 0000 0243 JAN. 12, 2015 UTMGR3 AFTER FIX TO LAST BYTE WRITE OP
013-016 SHOOTINGSTARS BINARY 0000 0243 JAN. 14, 2015 PUNCHER2 AFTER FIX TO LAST BYTE WRITE OP
RE-TEST AFTER I'FACE REMOVED FOR
016-018.5 SHOOTINGSTARS BINARY 0000 0243 JAN. 15, 2015 PUNCHER2
PHOTO AND REPLACED- PASSED
TESTING BIT BOFFER AND TAPE
RECORDER FOR WRITE AND READ
PASSED AFTER I UNPLUGGED
020-023 QST_MESSAGE1 TEXT 0100 037A MAY. 03, 2015 UTMGR3
"MICROPHONE" FOR READBACK.
VOLUME=4 (UPDATE 3OCT2015-
VOLUME=6 WORKS TODAY)
PART 1 OF RIBBON_GO_ROUND.txt
023-052 RIBBON_GO_ROUND1 TEXT 0100 1AC4 4-Oct-15 UTMGR4
VOLUME=7 WORKS BETTER
PART 2 OF RIBBON_GO_ROUND.txt
052-070 RIBBON_GO_ROUND2 TEXT 0100 0FD6 4-Oct-15 UTMGR4
VOLUME=7 WORKS BETTER
070-071.5 UTMGR4_TTY4_READTTY_1 BINARY 0000 00FF 7-Oct-15 PUNCHER2 PART 1 OF UTMGR4…
PART 2 OF UTMGR4… THE PROGRAM
STARTING ADDRESS IS $1C00. USE
071.5-078 UTMGR4_TTY4_READTTY_2 BINARY 1B00 1FF6 7-Oct-15 PUNCHER2 MIKBUG TO LOAD 1C00 TO LOCS $A048
AND $A049, THEN "G" TO START
UTILITY MANAGER

June 27, 2018- Today I finally re-installed the XC6800 CPU chip
that I had swapped out 4 years ago during the troubleshooting
activity. The XC6800 is working fine.

August 5, 2018- The 600bps mode started to not work reliably on

MIKBUG "L" command, very sensitive to exactness of the interface
clock rate. I tried to fiddle with CPU clock to speed it up a
little, but I cannot do this accurately without an oscilloscope
due to 1 and 2 having to each be set. In any case, it has been
working OK, without failure this morning, after all the fiddling.

December 7, 2019- The 600bps problem got worse, until I had to

revert to 300bps mode several months ago. Yesterday around mid-
day I received my brand new Tektronix TBS1052B-EDU oscilloscope
that I ordered from Newark. By 3:15 pm yesterday I used the
'scope to observe that the MPU clocks were about 850 kHz and
wrong duty cycle. I successfully readjusted the CPU clocks to
their approximately correct settings, at 1.00MHz. I also
adjusted the baud rate clock for both 300bps and 600bps modes.
The 600bps console mode is now working fine again.

11
 1 and 2 XC6800 Clocks After Initial Readjustment, 07DEC2019

December 11, 2019- I adjusted the MPU clocks again, to just meet
the 450ns and 470ns "90%" pulse widths as described in the
instruction manual for the MEK6800D1 board. The frequency after
this more precise adjustment is 1.0027 MHz. See also my separate
write-up of this adjustment and the results.

Thank you for your interest,

-73

12