• Please review our updated Terms and Rules here

Using PDPGUI to run BASIC

Just set-up a basic 11/45 in SIMH with 16K memory and a console. Loaded "cqkce0_11-45.bin" into the memory and set it running at 204 and was greeted with the "LOW LIMIT"? message. I think we are definitely looking at a fault on your machine (or some hardware configuration issue).

I single-stepped the diagnostic and it worked as I commend the disassembly - so loading the .BIN file into your 11/40 and single stepping it via the console should follow the 'flow' of my disassembly comments. Where it goes awry is where we need to look.

I might just change my 11/45 to an 11/40 to match your physical machine - forgot about that... It worked as well setting the SIMH processor to an 11/40.

Running it from address 200 (when set back to an 11/45) gives me the following:

sim> deposit pc 200
sim> g

DCQKC-E 11/40 & 11/45 INST EXER
OPT.CP= 145410

TRAPPED TO 4
PASS #0000 VPC=001026 PSW=000204 CPU
HALT instruction, PC: 005404 (MOV #5432,@#5420)
sim>

I didn't enter anything in the SWITCH register.

TRAP 4 is the user-friendly equivalent of a "HALT" :).

I will have a look at that presently to see if I can decode what it is (with your excellent disassembly)...

Dave
 
Last edited:
daver -

764 = 400
6104 = 0
5640 = 32452, etc.

no changes needed, but as expected nothing to screen.

2) changed 2646, 2650, 2652 to 240 and ran from 204

ran, but same loop pattern as always

5570 / 2 (address/data)
5574 / 4
5600 / 10
5604 / 4
5614 / 10
5622 / 0
5676 / 0
5702 / 0
5706 / 4
5712 / 4
loop back to 5570
 
You shouldn't be at that address (5570...) if you executed the code at 204.

You ended up there by 'error' (fault in your machine) or (for some reason) it didn't print the message and this is where we end up at if it is waiting for some sort of input from the keyboard? (EDIT: Not true)...

I would reload and single-step through the program from 204 making a note of the PC at each step. That should tell us where it is 'wandering off the straight and narrow'...

If you get to address 2726 - it should be trying to output something to the console transmitter...

Dave
 
Last edited:
Perfect! I must have missed it somehow.

This corresponds to this section in the listing:

m35Qlh0.png


This actual diagnostic disassembled:

Code: 
5570:	SUB #2,R0
5574:	MOV R0,#0
5600:	TSTB @#771
5604:	BNE 5614
5606:	SUB #4000,@#5576
5614:	MOV #32546,@#1012
5622:	BR 5676
5624:	MOV #600,SP
5630:	MOV #2622,@#20
5636:	IOT
5640:	BIT (R4)+,@-(R2)
5642:	JSR R5,4336
5646:	HALT
5650:	MOV 5646,@#1012
5656:	IOT
5660:	BIT (R4)+,12453
5664:	LDEXP F0,@-(R0)
5666:	HALT
5670:	MOV 5666,@#5576
5676:	MOV #600,SP
5702:	CLR @#1000
5706:	CLRB @#770
5712:	JSR PC,@#120

I single-stepped in SimH, starting from 200 and the soon ended up in this part. When the simulator executes the JSR PC,@#120 at 5712 is jumps to a subroutine at 120

Code: 
Step expired, PC: 005702 (CLR @#1000)
sim> s

Step expired, PC: 005706 (CLRB @#770)
sim> s

Step expired, PC: 005712 (JSR PC,@#120)
sim> s

Step expired, PC: 000120 (MOV #4450,@#114)

Code: 
120:	MOV #4450,@#114
126:	MOV #340,@#116
134:	MOV #6,@#4
142:	MOV #172100,R0
146:	MOV #1,R2
152:	MOV #1,(R0)+
156:	ASL R2
160:	BCC 152
162:	RTS PC

ySF6aTf.png


So how come it doesn't take the JSR to 120??
 
daver2 said:
You shouldn't be at that address (5570...) if you executed the code at 204.
Click to expand...

Yes. That is yet another indication that there is something wrong in the machine. When I stepped in SimH from 204 I never got to this part. Only if step from 200. So there is something with JSR/JMPs maybe that is wrong in the machine.
 
But my original comment still stands - it shouldn't have got there by rights without printing the messages or executing the subroutines to obtain the memory limits from the user via the console keyboard (JSR R5,RECO) . This is the FIRST error that needs addressing (when executing from address 204).

It is almost as though your console port doesn't work - even though it does...

Sorry Mattis - we are replying too quickly to the thread!

Dave
 
You're absolutely right. There should have been a printout already. What if the IOT is not working correctly as well?

I strongly suggest single stepping from the console from address 204. It should be very interesting to see what is going on.

EDIT - When single stepping into the IOT routine there is a JSR to do character output. It could be that one that fails not the IOT.. With some single stepping we would know for sure.
 
Bill,

That's exactly right regarding starting from 204 with the ENABLE/HALT in the HALT position and CONTINUING.

And we wouldn't have got where we are now without your first rate disassembly!

We are waiting in anticipation...

Dave
 
from 204, hit CONT to step through the program results, just as reported before, I am not skilled enough at interpreting the machine code unfortunately, but I will understand once someone can explain it:

000204: mov #005624,pc [012707 005624]

jumps to 5570
5574
5600
5604
5606
5614
5622
5676
5702
5706
5712
rinse and repeat.

here is the disassembly

005570: sub #000002,r0 [162700 000002]
005572: rti [000002]
005574: mov r0,#066330 [010027 066330]
005576: add 105737(r3),@(r0)+ [066330 105737]
005600: tstb @#000771 [105737 000771]
005602: br 005566 [000771]
005604: bne 005614 [001003]
005606: sub #004000,@#005576 [162737 004000 005576]
005610: jsr r0,r0 [004000]
005612: adc @012737(sp) [005576 012737]
005614: mov #032546,@#001012 [012737 032546 001012]
005616: bit (r5)+,-(sp) [032546]
005620: bne 005646 [001012]
005622: br 005676 [000425]
005624: mov #000600,sp [012706 000600]
005626: br 005230 [000600]
005630: mov #002622,@#000020 [012737 002622 000020]
005632: blt 005300 [002622]
005634: .word 000020
005636: iot [000004]
005640: bit (r4)+,@-(r2) [032452]
005642: jsr r5,004336 [004567 176470]
005644: ldexp @000000(r0),f0 [176470 000000]
005646: halt [000000]
005650: mov 005646,@#001012 [016737 177772 001012]
005652: ldcfd @001012(r2),f3 [177772 001012]
005654: bne 005702 [001012]
005656: iot [000004]
005660: bit (r4)+,012453 [032467 004567]
005662: jsr r5,004336 [004567 176450]
005664: ldexp @-(r0),f0 [176450]
005666: halt [000000]
005670: mov 005666,@#005576 [016737 177772 005576]
005672: ldcfd @005576(r2),f3 [177772 005576]
005674: adc @012706(sp) [005576 012706]
005676: mov #000600,sp [012706 000600]
005700: br 005302 [000600]
005702: clr @#001000 [005037 001000]
005704: bne 005706 [001000]
005706: clrb @#000770 [105037 000770]
005710: br 005672 [000770]
005712: jsr pc,@#000120 [004737 000120]
005714: jmp (r0)+ [000120]
 
Well I wasn't expecting that!

Either the MOV #5624,PC instruction isn't working (it should have just loaded the PC with the value 5624 - and the next instruction should have been executed from 5624) or your machine didn't single step properly.

Can you deposit a few 240's into memory locations starting at 204 and perform the same test again. It should execute a NOP at 204, then a NOP at 206, then a NOP at 210 etc. If not (and it goes ballistic) either your single stepping doesn't work or we really have a problem executing instructions...

Dave
 
stand by

entered 8 240's starting from 204

returned to 204 (load address)

hit CONT

jumped to 5570.

BUT - when I RUN from 204 it dies at 224.

REPEATED

FROM 204

CONT - counted through the 8 NOPs then jumped to 5570
 
Last edited:
Hmmmm - I think we are homing in on the little devil...

Just to confirm - you do have the ENABLE HALT in the HALT mode (switch DOWN) don't you?

Dave
 
But that is weird. It should jump to 5624 but instead it jumps off to 5570. There is some basic problem with jump/mov ins the CPU I would say. You need to start replacing cards to find the faulty one and then dig out the logic analyzer.

Is it possible to trace the microsteps using the 11/40 console somehow? It sure could be interesting to follow the microcode flow when executing that first instruction.

If you just assemble your own testprograms. JMP, JSR and MOV. Do they execute correctly when single stepping. Can there be a pattern somehow to be seen? One strange thing is that I am pretty sure that the M9312 tests some instructions before attempting to run the console emulator.

Code: 
      66 165020 005003                  T1:	clr	r3			; R3=000000 C=0
      67 165022 005203                  	inc	r3			; R3=000001 C=0
      68 165024 005103                  	com	r3			; R3=177776 C=1
      69 165026 006203                  	asr	r3			; R3=177777 C=0
      70 165030 006303                  	asl	r3			; R3=177776 C=1
      71 165032 006003                  	ror	r3			; R3=177777 C=0
      72 165034 005703                  	tst	r3			; R3=177777 C=0
      73 165036 005403                  	neg	r3			; R3=000001 C=1
      74 165040 005303                  	dec	r3			; R3=000000 C=1
      75 165042 005603                  	sbc	r3			; R3=177777 C=1
      76 165044 006103                  	rol	r3			; R3=177777 C=1
      77 165046 005503                  	adc	r3			; R3=000000 C=1
      78 165050 000303                  	swab	r3			; R3=000000 C=0
      79 165052 001377                  	bne	.			; br . if FAIL
      80                                
      81                                	; ------------------------------------------------------------
      82                                
      83 165054 012702  165000          T2:	mov	#data0,r2		; R2=165000
      84 165060 011203                  	mov	(r2),r3			; R2=165000 R3=165000
      85 165062 022203                  	cmp	(r2)+,r3		; R2=165002 R3=165000
      86 165064 001377                  	bne	.			; br . if FAIL
      87 165066 063203                  	add	@(r2)+,r3		; R2=165004 R3=152000
      88 165070 165203                  	sub	@-(r2),r3		; R2=165002 R3=165000
      89 165072 044203                  	bic	-(r2),r3		; R2=165000 R3=000000
      90 165074 056203  000012          	bis	12(r2),r3		; R2=165000 R3=165006
      91 165100 037203  000012          	bit	@12(r2),r3		; R2=165000 R3=165006
      92 165104 001777                  	beq	.			; br . if FAIL
      93                                
      94                                	; ------------------------------------------------------------
      95                                
      96 165106 010703                  T3:	mov	pc,r3			; R3=165110
      97 165110 000123                  	jmp	(r3)+			; jmp self, R3=165112
      98 165112 012703  165122          	mov	#T3B,r3			; R3=165122
      99 165116 000133                  	jmp	@(r3)+			; R3=165124 PC=165120
     100 165120 000113                  T3A:	jmp	(r3)			; R3=165124 PC=165124
     101 165122 165120                  T3B:	.word	T3A			; point to previous instr
     102                                
     103                                	; ------------------------------------------------------------
     104                                
     105 165124 105767  165004'         T4:	tstb	data1			; test a byte, if we get here...
     106 165130 001377                  	bne	.			; br . if FAIL
     107 165132 022222                  	cmp	(r2)+,(r2)+		; (R2)+=165000 (R2)+=165002 R2=165004
     108 165134 105722                  	tstb	(r2)+			; (R2)+=000 R2=165005
     109 165136 001377                  	bne	.			; br . if FAIL
     110 165140 105712                  	tstb	(r2)			; R2=165005 (R2)=200
     111 165142 100377                  	bpl	.			; br . if fail
It is indeed testing som jumps at least. So it shouldn't be all wrong...
But you maybe isn't running the diagnostics? If I remember correctly this is depending on the switches on the M9312 board.

I know that you have verified the memory contents using PDP11GUI and it all matches. But what if you test the diagnostic with MOS memory instead of CORE just as a quick test?
 
That's effectively what we were trying to do - execute our own little program of NOPs from 204.

I am getting a little tired now - it is bedtime in the UK!

Can you try with the NOPs again and this time set the ENABLE/HALT to HALT (switch down) load address 204 and START instead of CONTINUE - just to rule that one out.

Dave
 
daver2 said:
That's effectively what we were trying to do - execute our own little program of NOPs from 204.

I am getting a little tired now - it is bedtime in the UK!

Can you try with the NOPs again and this time set the ENABLE/HALT to HALT (switch down) load address 204 and START instead of CONTINUE - just to rule that one out.

Dave
Click to expand...

OK. stays at 204 when I hit start with the other switch in the HALT position.
 
You must log in or register to reply here.
Back
Top