Getting a memory map of your system is an important step. You need to know what memory addresses each board is attempting to use, so that there is no overlap. Also remember that the ROM board has RAM on it too. You would not want to map both boards to the same A000 space, but why do you need this at all? What wants free RAM there? One important rule is that you don't want to overlap RAM. Can you get to a monitor prompt without any RAM installed other than that which is in the ROM board? b

I did a capacitor check on the modified MP-M board. On the 100uf/16v one down at the bottom center, the most I get is 430uf and then it starts dropping. I can't seem to get a proper reading out of the same one on the upper right.. that's the same on both MP-M boards. So I'm wondering if I'd be best to try replacing that cap and see what happens.

Okay I think I'm starting to figure this out a bit. Beginning with basics, I cleaned up the contacts on all the SS50 pins. The system seems to power up more reliably now. Next, I poked around in the monitor to figure out exactly which addresses the modified MP-M board was dealing with. Since it has 64 chips on it (32 ICs x with 32 more piggybacked), I assumed it probably has 16K. I figured out it went from 8000 to around BFFF. I think. So next I installed the DR 16K boards. I configured one for 0000-3FFF, and the second for C000-FFFF. So that leaves 4000-7FFF uncovered. So now I went to the second MP-M board. This board has 8K installed, and I assumed it followed the MP-MX specs for upgrading to that. But, it doesn't. There were several cut traces and jumper wires. I have no idea why or what for. So I went and reversed all of that, and then set the address jumper to start at 4000. That gave me 4K more of RAM, covering 4000-4FFF. I don't know why it didn't give me 8K, up to 5FFF. I'm thinking it has something to do with the way it was modded. At any rate, the machine is almost fully decked out. I was able to load TSC Basic without any issues. Yay! So I think next goal is figure out how to use the RAM diags properly and then sic those on it and see how things check out.

-----Original Message----- From: Chris Elmquist [mailto:chrise at pobox.com] Sent: Wednesday, September 7, 2016 6:13 AM To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>; Brad H <vintagecomputer at bettercomputing.net>; 'General Discussion: On-Topic and Off-Topic Posts' <cctalk at classiccmp.org> Subject: RE: SWTPC 6800 weirdness Both MIKBUG and SWTBUG need RAM at $a000. Originally this was provided by a 6810, 128-byte SRAM on the MP-A CPU board. To run Flex and other stuff that wanted larger stack and workspace, people modified a 4K MP-M to reside at $a000 (instead of somewhere below $8000) and then removed the 6810 from the CPU board. This results in 4K of RAM at $a000 instead of 128 bytes but you need one or the other-- but not both and not neither ? else the monitor won't run and without 4K, Flex won't run either. Chris On September 6, 2016 5:01:53 PM CDT, Brad H <vintagecomputer at bettercomputing.net> wrote: Thanks Chris. I figured it was something like that with my first MP-M. I am curious though why simply setting another board to cover 8000-BFFF won't allow the system to operate in that board's absence. It bothers me that I'm reliant on that heavily modded unit to be able to operate. I have another general question for folks out there. I'm trying to understand exactly how memory addressing works in relation to these boards. For example, if I understand correctly, the original MP-M had 16 2102 chips for a total of 4K. The memory address jumper chose which addresses that 4K applied to. So for example, if I set the jumper to 5, the card would occupy $5000 to $5FFF? My question is, if I am correct that my second MP-M, having 32 RAM chips, has 8K, and I've set it the jumper to '4', where does the other 4K of RAM go beyond $4FFF? It doesn't seem to go to $5000. The instructions for upgrading to the MP-MX spec don't say anything about having to modify the card to span a greater address range, in fact, the jumpers for board # are identical to the 4K MP-M. So I'm confused.. what's the benefit of going out to 8K if the board can't address more than 4? I'm sure it's something I'm missing here.

On Wednesday (09/07/2016 at 08:04AM -0700), Brad H wrote: Unless your MP-B (and MP-A) have been additionally modified to move the I/O region away from $8000, then your problem is that you are addressing RAM on top of the I/O region from $8000 to $8FFF. You need RAM at, $A000 to $A07F (128 bytes) or $A000-$AFFF (4K bytes) $0000 to $7FFF (as much as you have, no more than 32K) You can't have RAM at, $8000 to $8FFF this is the I/O region The monitor ROM occupies, $E000 to $FFFF There might be add-on PROMs on floppy controllers in the range, $C000 to $CFFF There might be floppy or other special I/O in the range, $D000 to $DFFF The $8000 I/O range is decoded on the motherboard and the original systems took the entire 4K block from $8000 to $8FFF. You cannot also put RAM there because it collides with the I/O devices such as the MP-C, MP-S and anything else on the SS-30 bus. There were modifications later that moved the I/O elsewhere but if that is done, then lots of the software (and firmware) needs to change too and most certainly the stock MIKBUG or SWTBUG will not work with I/O somewhere other than $8000. So, I think another problem you are facing is that when you put in some of these other memory boards, they are getting double addressed with other memory boards or with I/O and that will certainly cause bad behavior. Yes. Exactly. Depends on how the modification was implemented. I'm not familiar with those mods so you will either have to reverse engineer what was done to figure out how they are decoding the second bank on the board or remove the mod and return the board to stock configuration. It's possible that the mod enables the additional RAM at a fixed location (such as $0000) and it is unrelated to where the jumper is set. It's all a matter of how they wired up the chip select(s) to the piggy backed RAMs. Understood. Without documentation, it's a greater challenge. The upside is that these were very simple machines and pretty easy to understand once you spend some time with them. Lots of the secrets (of the system design anyway) are here, http://swtpc.com/ (with many thanks to Michael Holley for that archive) Chris -- Chris Elmquist