• Please review our updated Terms and Rules here

Using PDPGUI to run BASIC

so, if the computer is running the CONSOLE program, how can it be bombing on what I think is a pretty simple test program? I assume this works in the 11/40 SIMh, wow this is strange. BUT I don't have experience, I have been trying to get the system running so I can learn. If you see my dilemma, I have read the process or manual and even started writing code in a notebook but that's the same thing as doing it on the machine.
 
It could be useful to check the stack and the stackpointer now to see if the IOT does anything useful. SP is in register R6 which can be accessed over the unibus at 177706 if you don't have the MMU. It should have been decremented by four by the IOT. Then check the memory location the SP points to and the next higher location.
 
You have a quite small problem in the CPU logic probably. It could be something like how instructions are decoded. Something that is not causing the console emulator to crash since it happens to use instructions that work - so far.

You have written that it won't boot. Although there can be other things as well but M9312 does some more CPU diagnostic prior to boot. Maybe it halts in there?
 
OK - so is the 11/40 actually STARTing the program correctly and it is failing when it tries to execute the IOT - or is the 11/40 not STARTing the program correctly at all?

Memory location - Value

20 - 220 ; IOT trap vector (New PC)
22 - 340 ; IOT trap vector (New PSW)

200 - 012706 ; MOV #600,SP
202 - 600
204 - 240 ; NOP
206 - 0 ; HALT
210 - 4 ; IOT
212 - 240 ; NOP
214 - 0 ; HALT
216 - 0 ; HALT
220 - 0 ; HALT
222 - 0 ; HALT

START the program running from address 200.

The program should HALT with PC=210 (i.e. the address of the next instruction to be executed). If this works - it demonstrates that your 11/40 actually started the program running (because we got from address 200 to here).

Hit CONT.

The program should HALT with PC=222 (i.e. the address of the next instruction to be executed). If this works - it demonstrates that the IOT instruction worked as intended.

If my assumption is correct (that it is the IOT) then the first HALT should work correctly and the second not.

I will await the results and (if a failure) have a think overnight...

Dave
 
Yes, there are other things that could be checked - you are correct.

This little test programs works correctly in SIMH.

Marty should be able to run exactly the same program (from post #164) on his 11/45 and give us the results from that.

The bootstrap/terminator module doesn't use the IOT instruction (hence one of the reasons I am interested in it - as this is a key difference).

Dave
 
reply to Mattis:
the problem is that the program does not stop, I have to HALT it. Would not these values then be arbitrary? I need help to do this. Please advise.
 
daver2 said:
OK - so is the 11/40 actually STARTing the program correctly and it is failing when it tries to execute the IOT - or is the 11/40 not STARTing the program correctly at all?

Memory location - Value

20 - 220 ; IOT trap vector (New PC)
22 - 340 ; IOT trap vector (New PSW)

200 - 012706 ; MOV #600,SP
202 - 600
204 - 240 ; NOP
206 - 0 ; HALT
210 - 4 ; IOT
212 - 240 ; NOP
214 - 0 ; HALT
216 - 0 ; HALT
220 - 0 ; HALT
222 - 0 ; HALT

START the program running from address 200.

The program should HALT with PC=210 (i.e. the address of the next instruction to be executed). If this works - it demonstrates that your 11/40 actually started the program running (because we got from address 200 to here).
Click to expand...

Ran the program. Stopped on its own at 210.

Hit CONT.
Click to expand...

with ENABLE still up, stays at 210. From ths point if I hit HALT and then CONT it jumps to 200. CONT again 204, CONT again 206, CONT again 210, CONT again 200, CONT again back to 204 loop.


The program should HALT with PC=222 (i.e. the address of the next instruction to be executed). If this works - it demonstrates that the IOT instruction worked as intended.

If my assumption is correct (that it is the IOT) then the first HALT should work correctly and the second not.

I will await the results and (if a failure) have a think overnight...

Dave[/QUOTE]

yes you were correct.
 
Thanks Bill,

You've confirmed what I thought was the case. Now we have to work out why IOT doesn't work.

We need to persuade Marty to run the same thing on his 11/45. Marty...

You could try a much more complex (ho ho...) program:

200 = 005000 ; CLR R0 - Set general purpose register R0 to 0.
202 = 005200 ; INC R0 - R0 should be incremented from 0 to 1.
204 = 005200 ; INC R0 - R0 should be incremented from 1 to 2.
206 = 005200 ; INC R0 - R0 should be incremented from 2 to 3.
210 = 000000 ; HALT - The processor should halt and if you examine general purpose register R0 (in I/O space) it should be 3.

You should have no problem with that as it doesn't contain an IOT instruction - but this time it should do something we expect with a register.

Dave
 
I have been running this program, which is similar

5000
5200
6100
0005
0775

This works quite well and displays "chase the lights" on the front panel. I can load this from the console or the front panel. Of course if I load and run this from the CONSOLE prompt I lose access to it and have to HALT/resart the CONSOLE to get back to a @ prompt.

What CPU error could be so selective to disallow the IOT? That is the $64,000 question.
 
Last edited:
Hi All;

As some of You know I have been silently following Your progress..
And I am in my own Frustration mode, as not being able to figure out the Cryptic ways to make PDPGUI work on my machine..
So, Yes, I will try the above program and then do the other one and let You know the Results..

Yes, I get a '3'..

Entering the Program at Posting 167, It stops at '216, which is really 214, as it steps one more before stopping, or at least that is what I have been told..
I changed the Data at address '22 to '200 and I get the same result, '216.. Please, let me re-enter it, as the Data may have gotten corrupted..

Dave, Please let me know what You expect on my machine.. I does not work with start and Continue as Indicated by Bill's 11/40, Is there a slight difference ??


THANK YOU Marty
 
Last edited:
MattisLind said:
You have a quite small problem in the CPU logic probably. It could be something like how instructions are decoded. Something that is not causing the console emulator to crash since it happens to use instructions that work - so far.

You have written that it won't boot. Although there can be other things as well but M9312 does some more CPU diagnostic prior to boot. Maybe it halts in there?
Click to expand...

unfortunately no, I rechecked today. I can run ZZ and it'll return what I'd expect and give me a prompt for the next instruction.
 
billdeg said:
unfortunately no, I rechecked today. I can run ZZ and it'll return what I'd expect and give me a prompt for the next instruction.
Click to expand...

But that will be normal if you don't have the special 'ZZ' boot PROM installed in your M9312.
Typing the two letter code of a non-existent boot device just takes you back to the command prompt '@' on the M9312.

Send me a PM with your shipping address and I'll send you a 'ZZ' debug boot PROM you can install into your M9312.

PROM listing: http://www.ak6dn.com/PDP-11/M9312/23-ZZZA9/23-ZZZA9.lst

Don
 
Hi All;

Bill, NO, See the Picture of my M9312, it goes into one of the four BootRoms and NOT in place of the Console ROM, that stays there..

THANK YOU Marty
 
billdeg said:
Oops I see I do have the 248F1 - A0 SG - Can I just use that? Does it replace the CONSOLE rom I take it?
b
Click to expand...

248F1 is the 11/04/34/etc (ie, non 11/60 non 11/70) console PROM for the M9312. It is an 18pin device, goes in the console socket on M9312.

My custom ZZ PROM is a 16pin boot PROM for the M9312 that works in conjunction with the 248F1 console PROM.

When started, the ZZ boot PROM runs thru the diagnostic/memory test code in the M9312 continuously.

If a system can't run this amount of simple instruction diagnostics and memory test likely it won't be able to boot an other code.
 
Last edited:
Finally Got it.

I took at look at the processor boards and found that the M7235 and M7234 were wired for a KJ11. So...I dug around and found one. Stuck into the machine and voila - I have a working diagnostic on the terminal.

Hurrah!

I re-loaded CQKCE0-11-45.bin and it's running now...with output to the screen.

Let's hear it for never giving up.

For anyone who is trying this, remember to load 1002 and set data - 011000 if you're using a serial terminal. I started from 200 with 15 up to HALT on error. The test takes a while for each pass not sure yet how long but I'd say at least 15 minutes, but I did not set the switches to limit the RAM to 16K, not sure what will happen.

I was even able to load BASIC and get to the READY prompt, enter in a small program. Now I can sleep too.

Bill
 
Last edited:
billdeg said:
wired for a KJ11. So...I dug around and found one.
Click to expand...

Lucky.. back in the day, stack limit boards were hard to find.
It took a friend of mine a couple months to find one so he could run Unix V6 at home.
This was the first machine I ever saw Unix running on ( circa 1978 )
I still have the WE V6 pocket card he gave me.
 
Well done Bill...

So, you did have a CPU fault - just not of the hardware failure kind; but a mismatch between how the system was configured and what was actually installed.

My guess is (with the missing stack limit board) that the IOT instruction was attempting to save the CPUs PC and PSW to the stack - which screwed up (because of the missing card) which would have caused a TRAP 4 - which wasn't initialised by my test program.

It is interesting (looking back at your disassembly of the diagnostic program that you were trying to run) that the PC address for TRAP 4 (which covers stack limit checking) is loaded with 5570 - which is one of your 'magic' addresses in the loop that you got stuck in posted in #119. The action on detecting a stack violation is described on page 7-6 of http://www.mirrorservice.org/sites/...ndbooks/PDP-11_40_Processor_Handbook_1972.pdf. It is interesting to note that a "RED ZONE VIOLATION" results in the SP being set to memory address 4 and the old CPU PC and PSW being stored in memory addresses 0 and 2 respectively. Looking at your disassembly of the diagnostic gives us values in memory address 0 and 2 of 5716 and 4 respectively. If we treat 5716 as the faulting return address from an invalid stack operation - this traces back to the first instruction using the stack (005712: jsr pc,@#000120). this is in the code path followed from the 210 entry point of the diagnostic (210->5676->5702->5706->5712 - stack fault). You can also get to the same point by following a path from the 200 entry point to the diagnostic (i.e. the instruction at address 5712 is the first instruction to utilise the stack pointer from what I can see on both the 200 and 210 entry points - but not the 204 entry point). My guess is, therefore, that you ran the diagnostic last from the entry point at 200. It failed. You halted it and then disassembled what was in the machine's memory (preserving the stack fault information). This is all guess work of course...

Dave

Marty - are you having problems running my test code as well?
 
Last edited:
You must log in or register to reply here.
Back
Top