vintagecomputer at bettercomputing.net
Sat Aug 6 14:53:10 CDT 2016
Okay... I'm beginning to think RAM config is a part of the problem here.
Here's how the boards are configured:
DRC 16k Bd 1 - Jumpered for 0000-3FFF
DRC 16k Bd 2 - Jumpered for 4000-7FFF
MP-M Bd 1 - Jumpers are - I can't figure it out. Supposed to be A to one of
the pads marked 0 - 7.. instead A goes to a 7401, which is piggybacked on
another chip. Pads 3 and 4 are also jumpered to this chip?
MP-M Bd 2- Jumpered from A - 5
Is it possible I have nothing for $A000 here?
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Sent: Saturday, August 6, 2016 8:24 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
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.
> 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
> (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.
> 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:
>> he does mention RAM needed at A000 for the BUGs, as Chris and I have been
>> 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
>>> 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:
>>> Search on "female jumper wires"
> Chris Elmquist
More information about the cctalk