resurrection of my mc6800-based microcomputer
Post on 04-Nov-2015
19 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
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
top related