billdeg
Technician
I will have to come back to this tomorrow. Program is not bombing, but nothing printed screen. Need sleep.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Using PDPGUI to run BASIC
- Thread starter billdeg
- Start date
daver2
10k Member
Hope you had a good sleep...
So, I have read the thread and the MAINDEC diagnostic listing and have a few observations:
1) How do you know that the diagnostic software that you have is the same as that described in the listing? Can you post a copy of the diagnostic tape you are using please and I will compare it to the listing.
2) Within the software there seems to be some disagreement as to the state of switch 7. It describes it as both an inhibit and an enable switch. One must be right and the other not.
3) Looking at the code there appears to be three (3) entry points into the diagnostic - 200(8), 204(8) and 210(8). Starting the program at 204(8) instead of 200(8) should prompt you for the memory limits and ask you for "LOW LIMIT?" and "HIGH LIMIT?". The important thing is 'does it ask you for anything at all'? If not, either your console is not working - or the diagnostic software you have doesn't match the documentation (in which case we will get nowhere).
4) The listing implies that it detects if a terminal is present by looking at address 177564 and seeing if it times out or not. If it doesn't timeout - then the software should print "OPT.CP=nnnn" at the start stating what options it has found. I guess it has never done this? EXAMINE memory location 764(8) which should hold the OPT.CP flags to see what it thinks it is running with. Again, this memory location will only be valid for the same version of the diagnostics as the listing describes.
If you can post the diagnostic tape you are using, I think it should be relatively easy to see if it matches the listing. If not, we will have to look for a consistent diagnostic tape and documentation/listing.
Postscript: I have just checked the listing at line 5999 (address 32152(8)) and it checks switch 7 and branches if PLUS to skip printing the message. Positive is indicated by a switch register OFF (binary 0) - so setting SW7 to ON should enable the end of pass printout. Initial thought...
Dave
So, I have read the thread and the MAINDEC diagnostic listing and have a few observations:
1) How do you know that the diagnostic software that you have is the same as that described in the listing? Can you post a copy of the diagnostic tape you are using please and I will compare it to the listing.
2) Within the software there seems to be some disagreement as to the state of switch 7. It describes it as both an inhibit and an enable switch. One must be right and the other not.
3) Looking at the code there appears to be three (3) entry points into the diagnostic - 200(8), 204(8) and 210(8). Starting the program at 204(8) instead of 200(8) should prompt you for the memory limits and ask you for "LOW LIMIT?" and "HIGH LIMIT?". The important thing is 'does it ask you for anything at all'? If not, either your console is not working - or the diagnostic software you have doesn't match the documentation (in which case we will get nowhere).
4) The listing implies that it detects if a terminal is present by looking at address 177564 and seeing if it times out or not. If it doesn't timeout - then the software should print "OPT.CP=nnnn" at the start stating what options it has found. I guess it has never done this? EXAMINE memory location 764(8) which should hold the OPT.CP flags to see what it thinks it is running with. Again, this memory location will only be valid for the same version of the diagnostics as the listing describes.
If you can post the diagnostic tape you are using, I think it should be relatively easy to see if it matches the listing. If not, we will have to look for a consistent diagnostic tape and documentation/listing.
Postscript: I have just checked the listing at line 5999 (address 32152(8)) and it checks switch 7 and branches if PLUS to skip printing the message. Positive is indicated by a switch register OFF (binary 0) - so setting SW7 to ON should enable the end of pass printout. Initial thought...
Dave
Last edited:
billdeg
Technician
Good question. I checked a handful of values to verify in general but not extensively. My interest was more to make sure the code was installed fully not to compare with the code listing.
Yes, I was confused, and I tried it both ways to be sure, but there was no difference in result. The problem is that it says "reset" rather than set like the other switches on the chart.
I can try this and I see the point.
correct, never.
ok.
Starting from here:
http://www.retrocmp.com/images/stories/joerg/pdp11_diagnostic_database////modules/CQKC.html
I took the image CQKCG1.BIC "Extracted from the XXDP+ RL02 disk image"
Could it be that I can't run this without a working disk drive first, chicken and egg problem?
Maybe I should be using the cqkce0_11-45.bin instead.
Neither of these I can open to show a listing except within the PDPGUI itself, on a different PC.
I will try again and report what happens.
Thanks for doing this, Thanks 1 Mb.
Last edited:
MattisLind
Veteran Member
That is the problem that I mentioned. It is really hard to find a diagnostic and the matching listing. It has to be the same revision otherwise it is quite pointless. (Or it will make life a lot harder to decipher what is actually going on). The document has revision D while the binaries are revision E or G. E will probably be better than G though.
daver2
10k Member
The code in cqkce0_11-45.bin and cqkcg1.bic 'look similar' in that they contain the same strings as each other and the documentation listing. I missed the reference to the excellent bitsavers archive - so the cqkce0_11-45.bin is guaranteed to run stand-alone (as it is a paper tape). I can't guarantee that the .BIC will run standalone (although there is something in the back of my mind that thinks it will - whether XXDP set-up some flags after loading but before executing I couldn't say (in which case, loading it directly will not set the flags)).
My recommendation would be to use the cqkce0_11-45.bin variant from now on to be 100% sure you are not chasing a self-inflicted issue!
Dave
PS: You can't get a 'listing' out except by disassembling it.
Dave
My recommendation would be to use the cqkce0_11-45.bin variant from now on to be 100% sure you are not chasing a self-inflicted issue!
Dave
PS: You can't get a 'listing' out except by disassembling it.
Dave
billdeg
Technician
My guess is that cqkce0_11-45.bin from
http://bitsavers.trailing-edge.com/bits/DEC/pdp11/papertapeimages/20040101/tray05/
is going to be closer if not a match to the listing on
http://bitsavers.trailing-edge.com/...D_D_1140_1145_INSTRUCTION_EXERCISER_Sep74.pdf
I am going to download and run this version, see how it goes.
1) start from 204 with the hopes that I am asked to enter a low and high value (I have a 16K system)
2) report what is in address 177564
I will run with switches 15 and 7 up. It appears from the listing that it's ok to flip these up while the program is being run, but I will start the program with these up.
I will set 1002 = 0 and 1003 = 11 because the directions say I should for a serial device, not sure if I missed anything.
Bill
http://bitsavers.trailing-edge.com/bits/DEC/pdp11/papertapeimages/20040101/tray05/
is going to be closer if not a match to the listing on
http://bitsavers.trailing-edge.com/...D_D_1140_1145_INSTRUCTION_EXERCISER_Sep74.pdf
I am going to download and run this version, see how it goes.
1) start from 204 with the hopes that I am asked to enter a low and high value (I have a 16K system)
2) report what is in address 177564
I will run with switches 15 and 7 up. It appears from the listing that it's ok to flip these up while the program is being run, but I will start the program with these up.
I will set 1002 = 0 and 1003 = 11 because the directions say I should for a serial device, not sure if I missed anything.
Bill
daver2
10k Member
Sounds like a plan.
177564 is (really) in the I/O page (so I should have more accurately stated 777564) which should be your console serial card.
Dave
177564 is (really) in the I/O page (so I should have more accurately stated 777564) which should be your console serial card.
Dave
billdeg
Technician
in 777564 = 200
SW 15 & 7 up.
loaded the .bin version into memory, spot check verify ok
L 1002
D 011000
L 204
S
System halted at 10 with data = 204
I repeated the test and it did not fail the 2nd and 3rd time. I also tried with 15 up 15 down, 7 up 7 down combinations.
--------------
L 200
S
System: nothing to screen, went into familiar lights pattern of a computer running a program.
value in 000764 = 200
UPDATE - I also ran with switches 15/12/11 up to stay within 8K and make just one pass.
SW 15 & 7 up.
loaded the .bin version into memory, spot check verify ok
L 1002
D 011000
L 204
S
System halted at 10 with data = 204
I repeated the test and it did not fail the 2nd and 3rd time. I also tried with 15 up 15 down, 7 up 7 down combinations.
--------------
L 200
S
System: nothing to screen, went into familiar lights pattern of a computer running a program.
value in 000764 = 200
UPDATE - I also ran with switches 15/12/11 up to stay within 8K and make just one pass.
Last edited:
billdeg
Technician
I checked points in the code with the papertape I switched to, appears to be a match.
It appears that the code is looping here, see code on page 99 of 028_MAINDEC-11-DCQKC-D_D_1140_1145_INSTRUCTION_EXERCISER_Sep74.pdf:
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
It appears that the code is looping here, see code on page 99 of 028_MAINDEC-11-DCQKC-D_D_1140_1145_INSTRUCTION_EXERCISER_Sep74.pdf:
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
Last edited:
daver2
10k Member
Interesting.
Can you check what value is stored in 764 after loading the diagnostic - but before executing it. According to the listing it should be 400 (TTOPT bit set).
The value you have identified in location 764 (200) doesn't have the TTOPT bit set - indicating that we are not looking at the same thing (documentation <> code) or there was an error (bus timeout) when the diagnostic tried to access your serial port register (hence it assumed that you don't have a console port installed).
I assume you didn't get the "LOW LIMIT?" message when staring from 204? If this is the case, I would be inclined to single step through 204 (following the listing) to see why no message...
Dave
Can you check what value is stored in 764 after loading the diagnostic - but before executing it. According to the listing it should be 400 (TTOPT bit set).
The value you have identified in location 764 (200) doesn't have the TTOPT bit set - indicating that we are not looking at the same thing (documentation <> code) or there was an error (bus timeout) when the diagnostic tried to access your serial port register (hence it assumed that you don't have a console port installed).
I assume you didn't get the "LOW LIMIT?" message when staring from 204? If this is the case, I would be inclined to single step through 204 (following the listing) to see why no message...
Dave
MattisLind
Veteran Member
I don't think the listing rev D is mathcing binary rev E very well. Doing a disassembly in Simh reveals that to start with the jumps (mov really) from the starting points is different:
Code:
sim> load cqkce0_11-45.bin
sim> ex -m 200-1000
200: MOV #5514,PC
204: MOV #5624,PC
210: MOV #5676,PCWhile the listing says:
So the addresses are off somewhat. It is probably possibly to partly use the listing but one have to do some disassembly onself and compare it with the listing to get the full picture.
billdeg
Technician
I have not done this before, but I will try using the PDPGUI for that. I will examine the tape's addresses using the disassembler, and see what comes of it.
daver2
10k Member
The phrase "beggars can't be choosers" comes to mind here - if this is the only listing and binary we have (even though they are not 100% compatible) - then we have to make it work for us...
I did notice (however) that the entry point at 204 doesn't set the stack pointer - this could indicate the initial failure that you had when using this entry point. I wonder if the expectation is that you start off at 200 and then HALT and re-enter at 204 if you need to force some other options (e.g. setting the memory limits).
There doesn't look to be too much code from 204 to single-step through before it tries to print the initial message "LOW LIMIT?" (after you set the stack pointer - R6 - up to something like 600).
Dave
I did notice (however) that the entry point at 204 doesn't set the stack pointer - this could indicate the initial failure that you had when using this entry point. I wonder if the expectation is that you start off at 200 and then HALT and re-enter at 204 if you need to force some other options (e.g. setting the memory limits).
There doesn't look to be too much code from 204 to single-step through before it tries to print the initial message "LOW LIMIT?" (after you set the stack pointer - R6 - up to something like 600).
Dave
billdeg
Technician
I have made an inexperienced persons' attempt at disassembling the code from the computer's memory, uploaded it here:
http://vintagecomputer.net/temp/disassembly.txt
http://vintagecomputer.net/temp/disassembly.txt
daver2
10k Member
That's a very good attempt.
I have pretty much got what I want - but I have to hit the road and get home from work now. I will have a look when I have had my tea and washed up the dishes!
Dave
I have pretty much got what I want - but I have to hit the road and get home from work now. I will have a look when I have had my tea and washed up the dishes!
Dave
billdeg
Technician
ok. This is a great learning experience
If it helps I have an DL11-W (M7856) as the serial card. I also have a DL11 (M7800 I can swap). THey both are "default" console serial cards, to my knowledge.
b
If it helps I have an DL11-W (M7856) as the serial card. I also have a DL11 (M7800 I can swap). THey both are "default" console serial cards, to my knowledge.
b
Last edited:
Qbus
Veteran Member
Still tied up until after the holiday, been looking at your progress. I know everyone has already resolved this but is the issue that you are never seeing anything on you terminal? If you enter the address 777566 and deposit 101 will that result in an “A” on the terminal? And if you examine address 777560 you can see the last thing sent to the input of the DL11. That’s a quick and easy way to confirm that the card is working and addressed correctly.
One of the smart people will have to answer this but I somehow recall that 777560/777566 is the addresses for a Unibus and 177560/177566 is for the Qbus systems but I may have that backwards.
XXPD sucks badly enough but without a con I can’t imagine using it.
One of the smart people will have to answer this but I somehow recall that 777560/777566 is the addresses for a Unibus and 177560/177566 is for the Qbus systems but I may have that backwards.
XXPD sucks badly enough but without a con I can’t imagine using it.
billdeg
Technician
It's not an issue with the serial card, I am using a terminal to send commands through the M9312 CONSOLE ROM program. I can run echo chars, etc. in addition to interact using PDPGUI. While using the serial terminal and I start the diagnostic from 200 only then do I lose serial communications. If I HALT and restart the CONSOLE I restore serial comms. The issue with serial output I think, specifically to the XXDP, is that the papertape was written to be loaded and run from a teletype. To use a serial terminal instead may be the source of conflict.
I was only suggesting that it could possibly be that the DL11 is "more compatible" than the DL11-W, or maybe I need two serial cards, or ??
I was only suggesting that it could possibly be that the DL11 is "more compatible" than the DL11-W, or maybe I need two serial cards, or ??
Last edited:
MattisLind
Veteran Member
.BIN and .BIC files are in Absolute Loader Format. I.e. exactly the same as on the paper tapes. As far as I understand the .BIC refers to that they are chainable. Dan North can probably explain in detail what that is but my understanding is that you from within XXDP can run several of these in sequence.
To me the it sounds obvious that the problem is that there is something in the diagnostic that hangs prior to or when it tries to output something to the terminal. When you halt your machine it will start the M9312 console emulator which handles serial IO. Actually you are not running XXDP. XXDP is a very simple monitor that can load .BIN and .BIC files from a DOS-11 formatted volume. You are running them on the bare metal since you load the diagnostic with PDP11GUI.
Why do you think that there will be a conflict to run something on a serial glass TTY rather than a real TTY? The loading process using a TTY involved the reader run flag. The loader software enables it and the TTY will read one character of the tape and send it serially to the host. When the tape is loaded and the reader turned off the TTY is identical to normal async terminal.
You need only one serial card. DL11-W is just somewhat more modern than the DL11 and includes the timer hardware. The UART chip is a little bit faster.
Your machine is equipped with an excellent frontpanel that allow you to single step through the code and you could follow the execution of the program very easily. Start of att 200 (or 204 if that is better) and single step and see what happens. Follow your disassembly and mark the instructions executed.
OR. Run the program from 200 (204) and then halt it and single step it. Where does it end up? What locations is it executing here? This is interesting information that could bring this forward.
To me the it sounds obvious that the problem is that there is something in the diagnostic that hangs prior to or when it tries to output something to the terminal. When you halt your machine it will start the M9312 console emulator which handles serial IO. Actually you are not running XXDP. XXDP is a very simple monitor that can load .BIN and .BIC files from a DOS-11 formatted volume. You are running them on the bare metal since you load the diagnostic with PDP11GUI.
Why do you think that there will be a conflict to run something on a serial glass TTY rather than a real TTY? The loading process using a TTY involved the reader run flag. The loader software enables it and the TTY will read one character of the tape and send it serially to the host. When the tape is loaded and the reader turned off the TTY is identical to normal async terminal.
You need only one serial card. DL11-W is just somewhat more modern than the DL11 and includes the timer hardware. The UART chip is a little bit faster.
Your machine is equipped with an excellent frontpanel that allow you to single step through the code and you could follow the execution of the program very easily. Start of att 200 (or 204 if that is better) and single step and see what happens. Follow your disassembly and mark the instructions executed.
OR. Run the program from 200 (204) and then halt it and single step it. Where does it end up? What locations is it executing here? This is interesting information that could bring this forward.
daver2
10k Member
A bit of a dummy - I left my 'hand disassembly' at work in the rush to leave!
Never mind - start again...
Adding some comments to your disassembly...
Address 204: Effectively a jump to address 5624.
5624: ; Load up the stack pointer with 600. Fixes the bug with the version I saw in the documentation!
5630: ; Setup the IOT vector with the IOT handler (starting at address 2622).
5636: ; Invoke an I/O Trap (start executing at address 2622.
5640: .WORD 32452 ; This should be the address of the message to output to the console!
...
2622: ; Save R0 to the stack.
2624: ; Get the return address (the address of the WORD following the IOT instruction = string to output) into R0.
2630: ; Move the return address on the stack past the WORD.
2636: ; Test bit 7 of address 764. This SHOULD BE initialised to 400 when the tape is loaded. This bit should be SET for console output.
2644: ; Abandon if this bit is CLEARED (i.e. no console port to output to).
2646: ; Test address 6104? This memory location seems to be initialised to 0 after loading from the tape.
2652: ; If address 6104 is non-zero then DON'T PRINT THE MESSAGE.
2654: ; Pickup the first/next byte of the message from R0 to the stack.
2656: ; Branch if not equal to zero (i.e. not the string terminator) to 2666.
2660: ; Tidy up the stack and return from displaying the message on the console.
...
2666: ; Jump to subroutine 2720.
2672: ; Compare the byte on the stack to OCTAL(12) (ASCII <LF>).
2676: ; Loop back to 2654 if not ASCII <LF>.
...
2720: ; Test the byte at 17564 (console status port).
2724: ; Loop to 2720 if the transmitter is not free.
2726: ; Output the byte character (stored on the stack) to the transmit buffer at 177566.
2734: ; Return from subroutine.
After loading the tape into your PDP check the following memory locations:
Address 5640 should be 32452.
Address 32452 should be the text message to output ("LOW LIMIT?").
Address 764 should be 400.
Address 6104 should be 0.
The test of 6104 seems to be an addition to what is in the listing we have. There also seems to be a bit of confusion in my mind as to whether 6104 is the actual memory location being tested or not (it depends what the addressing mode is etc.).
If all is good - it should work and ask you for the "LOW LIMIT?"... But we know it won't don't we!
I agree with QBUS and try the 'noddy' test on the console output just to make sure something does output.
Failing that - I would suggest patching the instructions at 2646, 2650 and 2652 with NOPs (240) before running at 204 again to see what happens (patch out the testing of this added memory location).
That's all I can think of for now...
Dave
Never mind - start again...
Adding some comments to your disassembly...
Address 204: Effectively a jump to address 5624.
5624: ; Load up the stack pointer with 600. Fixes the bug with the version I saw in the documentation!
5630: ; Setup the IOT vector with the IOT handler (starting at address 2622).
5636: ; Invoke an I/O Trap (start executing at address 2622.
5640: .WORD 32452 ; This should be the address of the message to output to the console!
...
2622: ; Save R0 to the stack.
2624: ; Get the return address (the address of the WORD following the IOT instruction = string to output) into R0.
2630: ; Move the return address on the stack past the WORD.
2636: ; Test bit 7 of address 764. This SHOULD BE initialised to 400 when the tape is loaded. This bit should be SET for console output.
2644: ; Abandon if this bit is CLEARED (i.e. no console port to output to).
2646: ; Test address 6104? This memory location seems to be initialised to 0 after loading from the tape.
2652: ; If address 6104 is non-zero then DON'T PRINT THE MESSAGE.
2654: ; Pickup the first/next byte of the message from R0 to the stack.
2656: ; Branch if not equal to zero (i.e. not the string terminator) to 2666.
2660: ; Tidy up the stack and return from displaying the message on the console.
...
2666: ; Jump to subroutine 2720.
2672: ; Compare the byte on the stack to OCTAL(12) (ASCII <LF>).
2676: ; Loop back to 2654 if not ASCII <LF>.
...
2720: ; Test the byte at 17564 (console status port).
2724: ; Loop to 2720 if the transmitter is not free.
2726: ; Output the byte character (stored on the stack) to the transmit buffer at 177566.
2734: ; Return from subroutine.
After loading the tape into your PDP check the following memory locations:
Address 5640 should be 32452.
Address 32452 should be the text message to output ("LOW LIMIT?").
Address 764 should be 400.
Address 6104 should be 0.
The test of 6104 seems to be an addition to what is in the listing we have. There also seems to be a bit of confusion in my mind as to whether 6104 is the actual memory location being tested or not (it depends what the addressing mode is etc.).
If all is good - it should work and ask you for the "LOW LIMIT?"... But we know it won't don't we!
I agree with QBUS and try the 'noddy' test on the console output just to make sure something does output.
Failing that - I would suggest patching the instructions at 2646, 2650 and 2652 with NOPs (240) before running at 204 again to see what happens (patch out the testing of this added memory location).
That's all I can think of for now...
Dave
Last edited: