Using PDPGUI to run BASIC

[billdeg]

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.

      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?

My MOS is not reliable enough for testing. I started but got DC LO AC LO on the front panel. I put the core back in.

 

[daver2]

So - something seems to work!

Can you reload the diagnostic; load address to 204; ENABLE/HALT switch DOWN; START - it should HALT (!) and then keep hitting CONT noting the PC at each step. Stop when we end up at 5570 :-(!

Dave

 

[billdeg]

I am going to start over, really verify everything carefully. stand by

 

[billdeg]

retest results.

1. re-loaded the entire program
2. set 1002 to 000, set 1003 to 011 (i.e loaded 1002 and deposited 011000)
3. loaded 200
4. hit CONT address jumped to
165530
165524
165530
165524
etc / loop

5. set back to 200. Set HALT to ENABLE and START
system ran program in familiar lights pattern / obviously running.

6. Hit halt, loaded 200
7. CONT now changed:

5574
5600
5604
5606
5614
5622
5676
5702
5706
5712
5570
5574
repeat.

so, something happens right off, then it falls into the loop. There is a little period where things happen before "the loop"

 

[billdeg]

almost re-loaded, stand by.

 

[daver2]

But aren't you trying something different now?

If you ran it and it went loopy it could have corrupted the program...

This was the point of single stepping it from a known position (204) from the outset. This worked before with NOPs - so it should work with the diagnostic (unless we have a fault) - and this should identify it. The only thing we have changed is the program and not the process used to run it. If you change too many things at once...

Dave

 

[billdeg]

So - something seems to work!

Can you reload the diagnostic; load address to 204; ENABLE/HALT switch DOWN; START - it should HALT (!) and then keep hitting CONT noting the PC at each step. Stop when we end up at 5570 :-(!

Dave

loaded from "tape" (NOTE: doing this undid your NOPs from before)
with HALT
loaded 1002 and set = 011000
loaded 204
hit START (with HALT down)
CONT from this point:

0204
5624
5630
5636
0006
0010
0006
0010
0006
0010
etc

System left running, HALTed.

NEXT:

set address to 204.
put up switches 15,12,11 up
ENABLE/START

system halts at address 10 with dataa 767.

repeated with only switch 15 up - same results

repeated @200 - went back into the loop pattern described earlier - did not halt, instead went to 5570, etc.

Once the program jumps to 5570 it's "broken" and will not repeat the earlier results unless I whipe everything clean and download a fresh copy of the program. That does not mean the program is corrupted, I make no other conclusion as there is no explanation other than I assume a register changes after the first run from 200, and from that point on it does not matter any more if I start at 200 or 204, it'll jump to the area at or near 5570 and loop.

 

[Marty]

Hi All;

I just got out the 11/45, I still have to put it together, and see IF it will Run..
I will let You know of my Progress and if I can get it to Run..
Then, I can try some of the same type of things that Bill is working thru..

THANK YOU Marty

 

[daver2]

Hi Bill - sorry, I just couldn't keep my eyes open any longer !

Hi Marty - welcome to the party!

The instruction single-step of:

0204
5624
5630
5636

Are exactly what I would have expected. This is showing me that your 11/40 seems to be doing something correctly and not just disappearing off to 5570 all of the time...

I did have a think whilst in bed. You should only use the CONT switch if you mean to continue from where the Program Counter (PC = R7) 'left off'. You should not use the CONT switch to 'start' a program running. To start a program running - load the address of the program start into the switch register, LOAD ADRS and then START. When you HALT the running program, loading a new start address into the switch register with LOAD ADRS and then CONT won't have the desired effect (it will just continue from where it left off before you hit the HALT). This may not be the intended action...

Can I suggest that you repeat the above test (e.g.

>> loaded from "tape" (NOTE: doing this undid your NOPs from before)
>> with HALT
>> loaded 1002 and set = 011000
>> loaded 204
>> hit START (with HALT down)
>> CONT from this point:
>>
>> 0204
>> 5624
>> 5630
>> 5636
>> 0006
>> 0010
>> 0006
>> 0010
>> 0006
>> 0010

and see if you get the same result. This just demonstrates that it wasn't a 'fluke' and that the correct instruction stream (well, the first few instructions) is repeatable.

If so, I would reload the diagnostic from tape again and this time START it running but with the ENABLE/HALT "UP" (i.e. do not HALT) and see what happens.

The above instruction stream tells me it is getting as far as the IOT instruction at 5636. It's interesting then that it disappears off to location 6 though... It is just possible that you can't single step through an IOT instruction.

I will have a think about that during the day. I am out at a school today (the kids are making model solar power electric cars as a school project - so I am there as a sponsor representative, helper and whatever else needs to be done for an enjoyable day).

If we can't single step through an IOT instruction - the next course of action would be to place a HALT instruction part way through the expected instruction stream, start the program from 204 and see if it HALTs at our halt instruction or disappears off into a loop. If a HALT at where we expect - we can move the HALT a bit further down the chain. If it disappears into a loop - we can move the HALT a bit further up the chain. The outcome is to identify a single instruction where it is not doing what we expect - and then try to isolate why. We also need to repeat this reliably - otherwise we could end up chasing our tail.

Hope this makes sense.

Dave

 

[Qbus]

I know your deep into this thing but somehow I think that maybe you need to look at your M9312 Bootstrap Terminator card. Not have ever operated a 11/45 or used a M9312, my Unibus systems have the smaller M9301 and 2 Bootstrap cards but looking at the manual for the M9312 it looks like if you have the straps set on it correctly it will allow the system to start in console emulator that’s somewhat similar to what all the Qbus systems have in microcode. You would be allowed to deposit and examine data via the terminal in addition to the front panel switches. The M9312 also has several diagnostics programs that it can run before starting the emulator so by checking the configuration of the card and having the appropriate jumpers in place that may tell you a lot about what’s going on in the system. Also you may have two or four of the boot roms installed and if that’s the case this can be real useful. When the card is set to run the emulator when the system is turned on you will be able to do the Load, Deposit or Examine commands directly from the terminal and if the system won’t come up in run in that state the internal diagnostics may be of great assistance in determining why. I have always found the ODT and BDV-11 onboard diagnostics and bootstraps to be of great value on Qbus systems but only have the limited bootstrap only roms on my Unibus system but you have the deluxe M9312card that may be the solution to your issues on that system.
Maybe take a break from beating your head on XXPD and the like and read the M9312 Bootstrap/ Terminator manual.

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/unibus/M9312_TechRef.pdf

And give it some thought. It’s an assumption on my part but from a quick review of the manual it appears that if the card is set up correctly it will place the system into a RUN state with a prompt on the terminal screen and if it you can’t first get there all this other stuff is a waste of time. But remember that’s an assumption and we all know what the word assume is defined as.

 

[Marty]

Hi All;

I have an M9301 currently in my 11/45, and at present I don't know If any of my M9312's work any more..
QBus, I am not sure what Bill has in His 11/40.. But, If He has anything at all It most likely would be one of these two types of Boards..
And Yes, that would be worth checking out, and seeing what Prom's he Has and If Don would be willing, (Not to put any word's in His mouth), but, maybe He could make some that Bill is Missing for His 11/40, like Don's ZZ program, that could Help check out for basic memory functionality..

THANK YOU Marty

 

[Qbus]

The M9312 appears to be the card to have if you’re running a Unibus platform. On my 11/34 it has the keypad and local display for entering addresses and memory locations but having a program in bios that would allow you to directly examine or enter memory locations from the con would be sweet. The thing is just having the boot stuff run or not tells you a lot about the state of the system and from what it sounds like I don’t think his hardware is up to that point, that’s all pure speculation on my part so I may be completely wrong but if you got a 9312 card might just as well put it to work.

 

[Marty]

Hi All;

QBus, at present nothing works as it should, So, I have to find out where the source of the problem is..
I have three options, one is the M9312 or M9301, Second is the M7800 or M7856 and Third, various switch setting of the Various Board..
And Of Course it could be the 11/45 itself, is not fully functional, as of Yet..

THANK YOU Marty

 

[daver2]

Qbus,

As I understand it (from reading the much earlier posts) - Bill has had the terminator/bootstrap working with a serial port and PDP11GUI. Hence the reason he suspects the serial port is OK but the machine isn't. However, I suspect that not all of the features of the serial port are being used by the bootstrap (e.g. interrupts). I suspect it will be polled. This is how the diagnostics seem to treat the console serial port when displaying messages - so there is a pretty good similarity here.

Based on my understanding that the bootstrap/terminator card works with PDP11GUI - I suspect the fault (initially) lies elsewhere (although I seem to remember Don writing a serial port test program in a thread somewhere that I would also like to see running on Bill's machine).

Dave

 

[Qbus]

I think the console emulator and its diagnostics are somewhat useful in that if enabled a good amount of the CPU functions and the memory is tested, don’t know about Bills system and if it’s enabled or not and if it is passing the basic diagnostics. I am assuming that he is not getting a lot of love from the console port and doing a lot if not all this from the switches at the front of the system. If he enables the console emulator function that will prove that the basic CPU and memory functions are good, if he has already done this then I am just blowing hot air.

 

[billdeg]

Hey all...I have two working serial cards, both 9600b. One is an M7856 the other a M7800. I have a thread on my site that documents the correct switches and jumpers plus links on how to test. This is thoroughly covered there.

http://vintagecomputer.net/browse_thread.cfm?id=641

I am only using the front panel in conjunction with the serial card, such as when I have to run a program with certain switches up. Sometimes it's just as easy to run something from the front panel I don't mind using it.

The bottom line is that I can do things like echo characters...I can download data reliably into RAM from the PDPGUI. I can run the tests that come with the PDPGUI. The only issues I have are

1) There is a particular tape I am trying to run from the XXDP set - DCQKC. I disassembled it and posted here:
http://vintagecomputer.net/temp/disassembly.txt

The program is not outputing to the serial port. I can start it using the serial port, but once the program starts and I see it running, I lose the serial port. I could have been working on the serial port all day until then, it's only when I try to run this program am I not getting screen output. I am hoping with the clues provided in the posts above someone can advise what's going on. It's complicated. The tape is probably designed for a teletype, the newer versions are designed to be run from a RT11 / RL02. I am trying to install from a serial port emulator. I am hoping it's just a coding thing with the diagnostic, but it could be a subtle issue with the CPU.

2) I do not have a working RT11 setup. Either the CPU or M7762 is bad or I have a fault with something like NPGrant, etc. I have done my best to verify that I have a properly functioning UNIBUS, but it is possible that there is a "customization" I don't know about from the previous owner.

Because I can't simply boot the RT11 I have circled back to try to get the XXDP DCQKC running. If successful we can rule out CPU fault and move on to the RT related hardware.

Hope that helps. If anyone wants to chat by phone PM me and we can talk that way. I have to be close!

b

 

[daver2]

Bill,

Did you see my post #109 from very early this morning? It had a few new suggestions - carrying on from your testing yesterday.

Dave

 

[billdeg]

not yet, I will check now. Here is a pic I just took to demonstrate that I can use the console to enter a program that interacts with the serial port.

 

[billdeg]

<snip>
If so, I would reload the diagnostic from tape again and this time START it running but with the ENABLE/HALT "UP" (i.e. do not HALT) and see what happens.

The above instruction stream tells me it is getting as far as the IOT instruction at 5636. It's interesting then that it disappears off to location 6 though... It is just possible that you can't single step through an IOT instruction.

I will have a think about that during the day. I am out at a school today (the kids are making model solar power electric cars as a school project - so I am there as a sponsor representative, helper and whatever else needs to be done for an enjoyable day).

If we can't single step through an IOT instruction - the next course of action would be to place a HALT instruction part way through the expected instruction stream, start the program from 204 and see if it HALTs at our halt instruction or disappears off into a loop. If a HALT at where we expect - we can move the HALT a bit further down the chain. If it disappears into a loop - we can move the HALT a bit further up the chain. The outcome is to identify a single instruction where it is not doing what we expect - and then try to isolate why. We also need to repeat this reliably - otherwise we could end up chasing our tail.

Hope this makes sense.

Dave

This is what I have been doing all along, but I just now re-downloaded a fresh copy.

identical results.

1. download
2. set 1002 to 11000
3. load 204
4. enable/start
5. program runs
6. hit halt
7. program counter is always somewhere within the loop

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

If I re-load 204, enable/start it's always the same return point, somewhere within the above loop. I have SW 15 up (halt on error)

what locations would you like me to halt?

QBUS - I am running the CONSOLE ROM using M9312 ROM/Terminator card. That's what the photo above is from. Also, I have verified the NPG Grant are correctly closed throughout the unibus on all live backplanes. My DD11C has no jumper in B and D (for custom reasons).

 

[daver2]

You can't argue with a picture!

With reference to my comments in post #80, I would place a PDP-11 HALT instruction (value 0) at each of the following successive memory locations in turn:

2622
2644
2646
2652
2654
2666
2726

You could cut down the number of tests by choosing a value in the middle (say 2652). If it HALTS at that point - the problem must be later. If it doesn't HALT at that point - the problem must be earlier. Keep narrowing it down until you get to the point where it HALTS correctly at one instruction - but doesn't HALT at the next. We can look from there.

Dave