I'd like to examine (disassemble and memory dump) and run the SWTBUG monitor ROM in the SIMH SWTP6800 emulator, but I seem to be having difficulty getting the devices attached properly, or I'm lost in some other way I don't understand. I can set up RAM and ROM devices to a certain point, but I can't seem to get them mapped to the CPU's address space.

Below I've provided a lot of detail on what I've tried so far, but if you don't want to go through all of that, I would still be pleased to see any answers (even perhaps for another CPU) that show any of the following:

  1. How to attach ROM into the CPU's memory space and examine/disassemble it there.
  2. How to attach RAM into the CPU's memory space, deposit data into it, and examine it.
  3. How to run a simple routine in RAM or ROM.
  4. How to run the SWTBUG monitor and interact with it.

I've tried this with both the simh-4.0-Current--2019-07-30-354a1e42 Windows build and my own build from the current head (2b6675b2) of the source on Debian 9. The examples below come from the latter, but I get similar results with the former.

I've got both the swt6800mp-a and swtp6800mp-a2 binaries, which both seem to start ok; I'm currently using the former since that seems to have a slightly simpler configuration than the latter.

$ ./swtp6800mp-a

SWTP 6800, V2, MP-A CPU Board simulator V4.0-0 Current        git commit id: 2b6675b2

I also have the swtp6800-swk.zip contents downloaded from the software kits page, which includes the swtbug.bin file. My work below is based on the swtp6800mp-a.ini file that's distributed in this kit, though I've moved that to another directory to ensure that the session below has not accidentally run any of that.

I can attach that file to the bootrom device and see that the file has been successfully read. The data below match what I see in the SWTBUG assembly listing, as does the disassembly, with the caveat that the destination address of the branch, being relative, is not what we'd see in system memory because the offsets here are from the start of the ROM image, rather than the location at which the ROM image should be mapped in memory.

sim> set bootrom 2708
sim> attach bootrom swtbug.bin
sim> e -h bootrom d0/5
D0: 8E
D1: A0
D2: 42
D3: 20
D4: 2D
sim> e -m bootrom d0/5
D0: LDS  #$A042
D3: BRA  $0102

However, it appears that this ROM is not (or at least not yet) mapped into the address space of the CPU:

sim> e -m e0d0/5
Unit not attached

So I carry on with the the next commands from the INI file to see if something there "attaches" it:

sim> set cpu hex,itrap,mtrap
sim> reset
sim> e -m e0d0/5
Unit not attached

Maybe a power-on reset (which according to the documentation does not clear memory) is necessary?

sim> reset -p
sim> reset -p ALL
sim> e -m e0d0/5
Unit not attached

Do I have the wrong address?

sim> e 0/5
Unit not attached
sim> e a000/5
Unit not attached
sim> e e000/5
Unit not attached
sim> e f000/5
Unit not attached
sim> e fff0/5
Unit not attached
sim> e ffff
Unit not attached

Well, I can't seem to examine memory at all, but maybe I can see if it runs. Using the following INI file:

set bootrom 2708
attach bootrom swtbug.bin
set cpu hex,itrap,mtrap

I look at where I'm going to start:

sim> e cpu pc
PC: E0C6

Wait, that's weird; that's not the proper entry point for the ROM. What's should in the vectors at the top of the address space if the ROM were correctly mapped there?

sim> e bootrom 3f8/8
3F8:    E0
3F9:    00
3FA:    E1
3FB:    6B
3FC:    E1
3FD:    87
3FE:    E0
3FF:    C6

(Sure would be nice if there were a way to dump multiple bytes on a single line.) And how did that PC value get loaded? On reset it should be loaded with the contents of memory locations FFFE and FFFF, but I still can't see them in memory:

sim> e fffe/2
Unit not attached

But anyway, this doesn't match what's supposed to be there according to the listing:

E3F8                    ORG     $E3F8
E3F8 E0 00              FDB     IRQV        IRQ VECTOR
E3FA E1 8B              FDB     SFE         SOFTWARE INTERRUPT
E3FC E1 A7              FDB     NMIV        NMI VECTOR
E3FE E0 D0              FDB     START       RESTART VECTOR

Maybe a different ROM version? Anyway, let's check the code at that entry point:

sim> e -m bootrom c6/f
C6: BRA  $0073
C8: BSR  $00C2
CA: BSR  $00C2
CC: LDAA #$20
CE: BRA  $007D
D0: LDS  #$A042
D3: BRA  $0102

and compare with the listing:

E0C6 20 A3              BRA     OUTHR       OUTPUT RIGHT HEX CHAR
E0C8 8D F5      OUT4HS  BSR     OUT2H       OUTPUT 4 HEX CHAR + SPACE
E0CC 86 20      OUTS    LDA A   #$20        SPACE
E0CE 20 A5              BRA     OUTCH       (BSR & TRS)

                *ENTER POWER ON SEQUENCE
E0D0 8E A0 42   START   LDS     #STACK
E0D3 20 2C              BRA     AL1         BRANCH FOR ADDRESS COMPATIBIL

Yeah, pretty clearly the correct entry point is still E0D0. And we can confirm that the E0C6 entry point doesn't work:

sim> run
PC=E1AB SP=0000 IX=0000 A=0E B=00 CCR=D0
Invalid Opcode, PC: E1AB

Restarting the whole simulator and trying the proper address doesn't seem to work either, though:

sim> e cpu pc
PC: E0C6
sim> d cpu pc e0d0
sim> e cpu pc
PC: E0D0
sim> g

PC=8005 SP=A040 IX=E114 A=FF B=FF CCR=D9
Invalid Opcode, PC: 8005
  • First step might be to do show bootrom to see if the set and assign did work at all
    – Raffzahn
    Commented Aug 19, 2019 at 21:44

1 Answer 1


I've got copies of the swt6800mp-a and swtp6800mp-a2 binaries,

They are basically the same. The A2 only offers 4 'sockets' for 2 KiB (EP)ROMs at C000, C800, F000, F8000 in addition.

I thought it should be as simple as this, but I keep getting a mysterious "Unit not attached" error:

Well, you might want to name the unit you want to examine as well:

sim> e bootrom 0/10

This will show you the first 16 bytes of your bootrom content. Or

sim> e -m bootrom 0/10

to get it disassembled.

I know it's odd (*1), but the whole SWTPC integration in SIMH is kind of an half finished hack.

To run it, it'll be a good idea to enable some RAM. Either by switchign on the default 128 bytes at A000 with set MP-A2 RAM or 'fliping in' a 8 KiB RAM-card at A000 with set MP-B2 bd5.

*1 - But nonetheless described as modifier under '3.5 Examining and Changing State' in the manual: "A device/unit name identifies the device and unit whose address space is to be examined or modified"

  • Yes, here you got I got as far as I did. But when I do e -m e000/10 to disassemble the ROM code where it should be mapped in the CPU's address space, it's not there; I get "Unit not attached." The same is true when I enable the 6810 and and e a000/10. If this doesn't make sense; wait a bit and I'll update the question to make these details clear.
    – cjs
    Commented Aug 20, 2019 at 1:53
  • I've expanded the question to show exactly what I'm doing and explain how I'm confused about the results.
    – cjs
    Commented Aug 20, 2019 at 6:13
  • 1
    @CurtJ.Sampson You got to include the device. The RAM isn't emulated as main memory, but a device. So you need to add the device when querying the content. As I said, it's a half made hack.
    – Raffzahn
    Commented Aug 20, 2019 at 8:08
  • 1
    Ah, so the issue is that normally in SIMH e e0d0 should show a data byte from whatever location in whatever device is mapped to that location, just as if I'd keyed in an examine from a front panel, but for the swtp6800 simulators they haven't written the code necessary to make this happen? But this does work on other SIMH simulators?
    – cjs
    Commented Aug 20, 2019 at 8:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .