SWTPC 6800

[Brad H]

I'll answer by number here:

1) MP-S is in Slot 1, per instructions.

2) This MP-A board has been modified for both SWTBUG and Flex.  I noted the
traces that were cut and matched to both configs.

3) Ah, this may be part of my problem.  I don't quite understand memory
addressing yet.  The instructions said you needed RAM at A000 if the 6810
chip was disabled (which it appears to be, the correct trace is cut).  My
machine has 4 RAM boards.  2 are MPM, 2 are 16K DRC boards.  For whatever
reason, the DRC boards are config-ed to be first (0000-3FFF) and second
(4000-7FFF).   Trying to strip the machine down and have as little RAM as I
could get away with, I just installed the single board at 0000-3FFF.  These
boards are (thank god) socketed, so I have some means of testing and
removing RAM.  The MP-M boards are not socketed, so I don't want to mess
with those until I have to.  I could config the second DRC board for the
$Exxx-$Fxxx and shove it in there.

-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Friday, August 5, 2016 12:37 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800

On 2016-Aug-04, at 11:46 PM, Brad H wrote:
> Dave
> Yes.. I tried 7 bits.. different parity settings, speeds etc.  Couldn't
quite nail it down.  In every tutorial online for the 6800 being used with
PC terminal, they go 8 N 1.. nobody mentions specifically if you are
supposed to use hardware or xo/off or nothing though.  So that's another
thing.  I'm also confused because some docs mention baud rate settings for
the cpu board?
> I'm also not sure if bad RAM or bad TTL etc could be contributing to just
throwing out random junk too.



(Disclaimer: All my SWTP-6800 stuff is packed away at the moment, I'm going
strictly from memory here.)


Flow control shouldn't be an issue.
This was an early simple (and slow) system, there was no active flow control
(leaving aside the reader-run control for the TTY PTR).
What speed are you running at? I'd suggest starting out at a lower speed
(300-1200).

Do you get a consistent response each time you hit the RESET button on the
SWTP-6800?
The monitor pumps out a single prompt character at reset.
If you always get one character but the wrong character (or couple) after
reset it could be a simple terminal protocol mismatch error, as you are
pursuing.
If it's inconsistent, it may be a deeper problem.
If you have a DSO, you could sample the RS-232 output to the terminal and
decode it to confirm the framing and bit rate are as you intend.


Random questions  / things to check:

1.  The MP-S is in the correct I/O slot for SWTBUG to find it for the
console device?
(The SWTP-6800 backplane decodes the I/O addresses to particular slots.)


2.  IIRC, MIKBUG only knows how to work the MP-C interface for the console,
while SWTBUG can do both MP-C & MP-S.
The proper ROM is present and the CPU board switches are configured
correctly for SWTBUG?
Alternatively, you might consider trying the MP-C rather than the MP-S,
although it's another set of hardware config jumpers to sort out.
(The MP-C was the original console interface as specified by Moto for
MIKBUG, the MP-S came later.)


3.  IIRC, both BUG monitors require some RAM up at $Exxx or $Fxxx for the
monitor stack (that 6810 RAM).
I don't think only having RAM down at $0000 will suffice.
The idea with the 6800 generally was system stuff (including the BUG
monitors) was up at the top of mem, while low mem was freely available to
the user.
(One of the world-view diffs between the 6800 and Z80.)