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:
- How to attach ROM into the CPU's memory space and examine/disassemble it there.
- How to attach RAM into the CPU's memory space, deposit data into it, and examine it.
- How to run a simple routine in RAM or ROM.
- How to run the SWTBUG monitor and interact with it.
I've tried this with both the
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
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 sim>
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 reset
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 E0CA 8D F3 OUT2HS BSR OUT2H OUTPUT 2 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