1

The Resurrection of My Homebrew MC6800 Computer System

By D.R. Sentz

June 2, 2014 - July 1 2015

June 2, 2014- Ive 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.

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.

2

My Homemade Backplane Buffer Board Uses 8T97s and 8T26s

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.

S.D. Sales Co. 4Kx8 Static RAM Kit

Replaced in 2014

Replaced in 1996

3

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 2102L1s in my parts cabinet, so my

computer is back up to the total 8Kbytes working memory (plus

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.

4

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

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.

5

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 213s

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.

6

Files on Audio Tape Cassette Thanks to Bit Boffer Article.

7

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

8

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 SettingsTerminal 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, FileFile 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

9

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 console terminal

now.

Thank you for your interest,

-73