SWTPC 6800

On 2016-Aug-04, at 11:46 PM, Brad H wrote: (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.)