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 <chr...@pobox.com> > Date: 2016-08-06 7:10 AM (GMT-08:00) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk@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 <ccl...@sydex.com> >>> Date: 2016-08-05 3:55 PM (GMT-08:00) >>> To: "General Discussion: On-Topic and Off-Topic Posts" >>> <cctalk@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
