SWTPC 6800

[Brent Hilpert]

If you use a 16K board you'll want to config it to start at $8000, so that it covers $8000-$BFFF.
If it goes higher than that it may end up in conflict with the ROMS and IO.

Alternatively, you could start with a minimal machine by reenabling the 6810 RAM on the CPU board and all you would need plugged into the backplane is the CPU board and console device board.



On 2016-Aug-06, at 7:59 AM, Brad H wrote:

> 
> 
> I've definitely got an MP-B.
> What I'm thinking is I'll use one of the socketed 16k boards and go through the RAMs to make sure I have good.  But I'm having trouble understanding how to set the jumpers to get the addressing to A000.  I thought I had that by the guide for the ram on the swtpc site (it's a Digital Research board).  The machine only gets animated when that weird piggybacked mpm board is plugged in.
> I suppose if there are bad RAMs on the DR board that'd do it though.
> Brad
> 
> 
> Sent from my Samsung device
> 
> -------- Original message --------
> From: Chris Elmquist <chrise at pobox.com> 
> Date: 2016-08-06  7:10 AM  (GMT-08:00) 
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> 
> Subject: Re: SWTPC 6800 
> 
> 
> Simplifying the machine configuration can help too.  You should only need
> MP-A (CPU), MP-S (serial interface) and MP-M at $A000 if you have the
> SWTBUG ROM.  It only needs 128 bytes of RAM at $A000 so an unexpanded
> (4K) or partially populated MP-M would be sufficient.
> 
> If you have MIKBUG, then you need MP-C instead of MP-S since MIKBUG does
> not know how to talk to MP-S.
> 
> Removing all the other cards temporarily could eliminate conflicts due to
> addressing, failed components, etc.
> 
> With this minimal configuration, you should be able to get SWTBUG's "$"
> prompt.  MIKBUG will prompt with "*".
> 
> Also, check which backplane board you have.  Depending on vintage, you
> may have MP-B or MP-B2.  MP-B2 allowed the I/O block address (normally
> at $8000) to be changed.  If you have MP-B2 and someone has customized
> the machine, then there will be more to figure out regarding where the
> I/O is really located, what the monitor ROMs expect, etc.
> 
> http://www.swtpc.com/mholley/MP_B/MP_B_Index.htm
> 
> http://www.swtpc.com/mholley/MP_B2/MP_B2_index.htm
> 
> Chris
> 
> On Friday (08/05/2016 at 10:47PM -0700), Brent Hilpert wrote:
>> Do you have some RAM at $A000+ yet?
>> That's all that should matter as far as required RAM goes.
>> 
>> Presuming this is the holley page you were referring to:
>> 	http://www.swtpc.com/mholley/HiTerm/Test6800_Index.html
>> he does mention RAM needed at A000 for the BUGs, as Chris and I have been saying.
>> 
>> Without RAM there there's no stack for return addresses for subroutines executed in the BUGs, so execution could head off to wherever.
>> 
>> 
>> On 2016-Aug-05, at 10:23 PM, Brad H wrote:
>>> Okay so.. I decided to try the MP-C board out, just for kicks.  No change.
>>> Then I decided to add one of the RAM boards.. the next one up in addresses.  Got a little bit when I powered on.  Added one of the old MPM boards.. one that has memory chips all piggybacked on one another.  Now when I powered up, the system was sending four or five characters at a time, linefeed, four or five characters at a time, linefeed ad infinitum.  I added the final MPM board.. zero.
>>> So.. I think we do have some ram problems.. most likely.  I'm thinking it would be easiest to concentrate efforts on the socketed RAM boards.. test all the RAM out.  I'm going to read up on addressing and try to understand a bit better what is going on.  I'm thinking maybe I need to reconfigure the addressing on one of the boards to match whatever that overstuffed MPM board is set to.
>>> Until I get an oscilloscope.. fooling around is about all I can do here.
>>> 
>>> Sent from my Samsung device
>>> 
>>> -------- Original message --------
>>> From: Chuck Guzis <cclist at sydex.com> 
>>> Date: 2016-08-05  3:55 PM  (GMT-08:00) 
>>> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> 
>>> Subject: Re: SWTPC 6800 
>>> 
>>> On 08/05/2016 02:15 PM, Brad H wrote:
>>>> I think I will have to figure out how to do that.  Additionally I
>>>> have one of those PC based oscilloscopes on the way.  I don't know
>>>> how to use them 100% but I'm about to learn I guess. :)
>>>> 
>>>> I have one more question for you guys -- I have a few CT-1024
>>>> terminals and would really like this system to work with one of
>>>> those.  However, all of the CTs are quite delicate and are set I
>>>> think for 7, E, 2 @ 110 baud via soldered jumpers.  I'm a bit
>>>> reluctant to try pulling them apart to get in there and fix that.  Is
>>>> there a way to change the parity, etc settings on the SWTPC to match
>>>> the terminal?  Is it necessary?
>>> 
>>> Well, 110 bps is a bit on the slow side--great for teletypes, not so
>>> much for video terminals.   But you'll have to change the hardwired
>>> jumpers--the UART used in the CT1024 is not software-programmable.
>>> 
>>> If this were my unit, I"d probably solder some pins into the pad holes
>>> and then either use slide on jumpers or wirewrap to set the
>>> characteristics.  That way, when changing things around, you won't be
>>> stressing the PCB.
>>> 
>>> Something like this:
>>> 
>>> http://www.ebay.com/itm/10PCS-20CFemale-to-Female-1-Pin-Plug-Jumper-Cable-Wires-Multicolor-K-/262158878688?hash=item3d09e307e0:g:B-MAAOSwwE5WVLR6
>>> 
>>> Search on "female jumper wires"
> 
> -- 
> Chris Elmquist