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-boun...@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@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.)
