Using PDPGUI to run BASIC

[billdeg]

I manually toggled in the bootstrap, then loaded through teraterm the abs loader and I am in the process now of downloading the BASIC papertape into the system. I set the character delay up high so it will take a while to download, but I wanted to be sure all data goes in correctly. If that works I will trim off the delay. I have used this trick in the past. Don't expect it to work the first time, but that's where I am at the moment. The loaders seems to work. The tape seems to be downloading....time will tell.....I may end up exactly where I was with PDPGUI - program in memory but halts when I try to run from 000. ... stand by.

UPDATE - did not work 1st time.

b

 

[Marty]

Hi All;

Bill, I don't know and I would suggest to ask SomeOne who has Run Basic, BUT are You sure it Starts at '000..

Almost All of the Diagnostic Programs Start at '200, a few at '400.. And Nothing at '000..

THANK YOU Marty

 

[billdeg]

yes, when you re-enter basic after it has been loaded (such as after cold boot). I have videos online to demonstrate initiating basic, demoed at VCF 2x, etc.

 

[AK6DN]

For basic 16104 is the start address for the option configuration dialog. Respond with '?' to go to verbose mode.
Y/N answer to questions, a number 4-28 for memory size to force it to use that size, else no entry to use sized memory.
As noted, 0 is the restart address to get back to the command prompt READY with an empty workspace.

Example follows using SIMH.

Don

[505] pdp11

PDP-11 simulator V4.0-0 Beta        git commit id: d8aafde7
sim> SET CPU 11/04 64K
sim> LOAD BASIC.PT
sim> GO 16104

PDP-11 BASIC, VERSION 007A
*O ?
DO YOU NEED THE EXTENDED FUNCTIONS?Y
HIGH-SPEED READER/PUNCH?N
SET UP THE EXTERNAL FUNCTION?N
MEMORY?
READY

Simulation stopped, PC: 000706 (TST (R2))
sim> GO 0

READY

 

[MattisLind]

Bookmark this
http://retrocmp.com/tools/pdp-11-diagnostic-database/202-pdp-11-diagnostics-database

but seriously, these diagnostics are so obtuse, so hard to determine if the process used to run them is even correct to know if you've found anything actually wrong for sure. So much easier to load and run a program like BASIC from tape to get a clear specific "this is working" answer. I can't believe DEC used this method but I guess it kept the techs employed.

Can't really understand why you think that. I find them not that hard to work with. Load them (PDP11GUI or absolute binary loader). Start them (address 200). Find where they halt. Look up halt in listing. Figure out why it halted by understanding what is not working and how it is implemented in the CPU.

You previously asked for help finding why the CPU might not work. The answer is run the diagnostic and find out where it halted. How would you think that if BASIC is not running it will tell you what problem there is?

I talked to an old DEC support engineer. Running Maindec tapes together with homebrew toggle in snippets was his standard procedure to do fault finding in PDP-11 machines.

The GKAAA0 diagnostic I have here. And then the GKABC0.

 

[billdeg]

I am learning I don't know the logical path of analysis, I would never have guessed to apply the GKAAA0 and GKABC0 tests for the 11/04 to my 11/40. But I loaded and ran them ...

run from 200:
GKAAA0 stops at 010 with data values 011254
GKABC0 stops at 010 with data values 041

Please advise how to interpret this. I found the listing and comments in relation to the 11/04:

OPERATING PROCEDURES :
.R GKAAA0
the test will prints :
"END OF DGKAA"
The diagnostic responds to the detection of all errors by
storing certain information in memory and halting the processor.
SWITCH SETTINGS :
No switch settings available

 

[MattisLind]

I am learning I don't know the logical path of analysis, I would never have guessed to apply the GKAAA0 and GKABC0 tests for the 11/04 to my 11/40. But I loaded and ran them ...

run from 200:
GKAAA0 stops at 010 with data values 011254
GKABC0 stops at 010 with data values 041

Please advise how to interpret this. I found the listing and comments in relation to the 11/04:

OPERATING PROCEDURES :
.R GKAAA0
the test will prints :
"END OF DGKAA"
The diagnostic responds to the detection of all errors by
storing certain information in memory and halting the processor.
SWITCH SETTINGS :
No switch settings available

It does sound like it has trapped to vector 4. When I load it in SimH and examine address 0-16 I get this:

0:	125253
2:	000000
4:	000006
6:	000000
10:	000012
12:	000000
14:	000016
16:	000000

So if it traps to 4 it will start executing at 6 and then halt (since 00000 is halt). Trap 4 is the general "Bus Error, Illegal Instruction, Stack Limit" vector. The PC will then be the instruction after the HALT. Now you should check the stack to find the old PC and PSW. The stack pointer is R6. Whenever there is an interrupt the machine will do MOV PS, -(SP) and MOV PC, -(SP). So after pushing the PS and PC onto stack the SP will point to the a memory location that contain the old PC. Check that value and see in the listing what that is.

You also have the mailbox registers at address 300-310:

300:	000000
302:	000000
304:	000164
306:	026550
310:	000000

300 is the "Message Type code", 302 is "Fatal Error Number", 304 is the "Test number".

The "Test number" shall then the be the number of the test that failed. Check the code there if that matches the one on stack.

If this looks like this is not a good test for a 11/40 then after all there might be some weird incompatibility that is not seen in SimH. It give endless printout like this in SimH:

sim> load GKAAA0.BIC
sim> d pc 200
sim> run
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA
END OF DGKAA

You could then check the very good Diagnostic Database of Jörg Hoppe to find a diagnostics that suits you. The problems seems to be that there are several 11/40 diagnostics where there are no listing available which makes them quite pointless. Maybe CKBA, CKBB, CKBC etc is a good start to see if they pass.



Good luck!

 

[Al Kossow]

You could then check the very good Diagnostic Database of Jörg Hoppe to find a diagnostics that suits you. The problems seems to be that there are several 11/40 diagnostics where there are no listing available which makes them quite pointless. Maybe CKBA, CKBB, CKBC etc is a good start to see if they pass.



Good luck!

you also need to know what cpu options are installed in your 11/40. RTC, Stack Limit, EIS and FIS were all optional.

 

[billdeg]

The diagnostic database from your link helps a lot, thanks. These have 1972-75 pub dates, prob more apt for the machine I am working on.

b

 

[billdeg]

Yes, and this kind of work takes careful organization and study of the machine....I am not going to just pop in a tape, run it and the screen says ... "and your problem is chip 123 on board 456. ..."

I can swap out options and I know that you'd have to change jumpers in many places on the CPU card.

What I think I was asking in my original post was comment on PDPGUI and the 11/40, and if anyone had found success with the PDPGUI tool to do things like load BASIC, or were there issues with it.

 

[MattisLind]

Yes, and this kind of work takes careful organization and study of the machine....I am not going to just pop in a tape, run it and the screen says ... "and your problem is chip 123 on board 456. ..."

Well. That won't be the case that it will identify individual chips to replace. The PDP-11/40 System manual has a list of failing tests versus probability of a module being faulty. Chip level analysis has to be handled by careful reading of the Maintenance manual and a logic analyzer... The VAX11/750 which could have an external maintenance board which ran diagnostics on the CPU could at least try to pin point defective gate arrays. I don't know if the VAX-11/780 front end had similar capabilities.

I can swap out options and I know that you'd have to change jumpers in many places on the CPU card.

What I think I was asking in my original post was comment on PDPGUI and the 11/40, and if anyone had found success with the PDPGUI tool to do things like load BASIC, or were there issues with it.

And the answer is that PDP11GUI cares little about the exact model of the CPU. More about the capabilities of the Console Emulator program, regardless if this in microcode (ODT like in 11/03 etc) or in a macrocode as in M9301/M9312 or a separate 8085 microprocessor as the 11/44. So from the PDP11GUI perspective your machine is identical to a 11/04, or 11/05 or 11/34 with a M9312.

BTW. You surely already know that you can access all off the scratchpad registers of the PDP directly over the unibus, addresses 177700-177717, right? A total of 16 registers used internally to represent among others R0-R7 and some temporary registers. R6/SP is 177706. R7/PC is 177707. Check those addresses using the frontpanel to understand what test is failing.

 

[Qbus]

Why do serial load GUI thing for Basic when you would be better off installing an M7762 and a RL drive or at least a set of RX drives and going with an operating system like RT-11 or RSX-11? Loading Basic or any of the other utilities from a disk is easy and fast with an OS and that hardware is more then up to the task. Loading Basic in RT-11 is easy, just type basic at the prompt and it runs, and may ask what features you want and the like but no issues like you are having now. This is all speculation on my part so people are probably going to get pissed but systems like the 11/05 and 11/10 were early examples with limited capabilities and maybe at best suited for loading a simple assembly language program via the con but when you get to the heavy weight systems like the 11/40 they were intended to work with large drives, complex operating systems and in most cases multipole users.
RT-11 SJ (Signal Job) only requires 8K with its monitor only using 2K so you can go with the 16K that you have. If you build out to 32K you can also run the FB and XM monitors in RT-11, with the XM (Extended Memory) you can address up to 124K of memory. Your 11/40 is like a car and trying to load an assembly version of Basic is treating it like a lawn mower. Nothing wrong with doing things in progressive steps but somehow I feel that what your doing is like trying to load cassette basic on a PC, and when you were dealing with a IBM 5150 that was state of the art but your 11/40 is at least a 486 if not a P1 by comparison. I know you have the skills and the hardware around there to do this and just to prove that I am not a complete jerk in saying this I would be willing to pull a drive, cable and controller card and come up there and help you sort thru your stuff and get the system going with an RL drive. Just a question of finding the time or you can drag down a drive and card and I have systems that we can test it on.

 

[MattisLind]

I think it is quite good idea to check that the CPU works first. I often try to bring up XXDP as the first thing, running some CPU diagnostics. So I think it is a good idea to check out things thoroughly. BASIC is one thing that can be run on the bare metal without anything else than the serial port.

In terms of performance the 11/40 is just double of the 11/05 and 11/10 (according to Computer Engineering). The big benefit of the 11/40 is probably the optional MMU and depending on what you do the optional EIS and FIS. And of course the bigger frontpanel. I have never tried one so I cannot tell how it compares with a 11/05 front panel. Other than that I think the KY11-LB of the 11/34 and 11/04 is a quite useful thing as it can live in a completely dead system (the 11/05 panel is dead if the CPU microcode isn't running)

RT11SJ and RT11FB runs very well on a PDP-11/04 or a 11/05. Even on the 11/03 it runs quite nicely. I think it boils down to what kind of disk system there is. Running RT11 off a RX02 floppy is a quite slow process while running off a MSCP compatible disk is quite quick.

 

[billdeg]

assuming you have for sure the correct diagnostics for the machine in question, the ability to correctly load and run them, and the ability to interpret the results. Otherwise you're just spinning your wheels

 

[billdeg]

Why do serial load GUI thing for Basic when you would be better off installing an M7762 and a RL drive or at least a set of RX drives and going with an operating system like RT-11 or RSX-11? Loading Basic or any of the other utilities from a disk is easy and fast with an OS and that hardware is more then up to the task. Loading Basic in RT-11 is easy, just type basic at the prompt and it runs, and may ask what features you want and the like but no issues like you are having now. This is all speculation on my part so people are probably going to get pissed but systems like the 11/05 and 11/10 were early examples with limited capabilities and maybe at best suited for loading a simple assembly language program via the con but when you get to the heavy weight systems like the 11/40 they were intended to work with large drives, complex operating systems and in most cases multipole users.
RT-11 SJ (Signal Job) only requires 8K with its monitor only using 2K so you can go with the 16K that you have. If you build out to 32K you can also run the FB and XM monitors in RT-11, with the XM (Extended Memory) you can address up to 124K of memory. Your 11/40 is like a car and trying to load an assembly version of Basic is treating it like a lawn mower. Nothing wrong with doing things in progressive steps but somehow I feel that what your doing is like trying to load cassette basic on a PC, and when you were dealing with a IBM 5150 that was state of the art but your 11/40 is at least a 486 if not a P1 by comparison. I know you have the skills and the hardware around there to do this and just to prove that I am not a complete jerk in saying this I would be willing to pull a drive, cable and controller card and come up there and help you sort thru your stuff and get the system going with an RL drive. Just a question of finding the time or you can drag down a drive and card and I have systems that we can test it on.

I'd love you to come visit and I agree 100%. I much prefer to boot with RT11 than BASIC...All of this effort (loading XXDP and BASIC) is to try to determine what's going on with my machine at a "lower level" to troubleshoot why when I try to boot RT off the M7762 that the system loops but does not boot off the disk pack. Bad drive? Bad cable, bad disk pack, bad CPU? If you did come up I'd be thrilled and much appreciative, but I know it's an inconvenience to travel two hours north. Please let me know when you might be free. I'd offer to take my 11/40 to you, maybe it will have to come to that.

There is a forest from the trees thing here...what evidence is there that the CPU is bad? It could just be that I have a bad M7762 and that's why I can't boot.

I am unsure if the actual tape I used to load BASIC on the 11/05 is the same as the version made available online, I assume it is, and that it's compatible with 11/40 CPUs...many variables to manage.

Bill

 

[MattisLind]

Otherwise you're just spinning your wheels

Sure. It could feel like that. But what came out of the previous attempt to run GKAAA0.BIC? Were you able to investigate the stack to understand where it took the trap? Did the mailbox memory registers tell you anything useful? Did you ran any of the other tests, CKBA, CKBB etc? Otherwise you could try the CQKC diagnostic which should test most parts of the CPU.

 

[billdeg]

I will have to learn more about how the processor works to understand the results. I will get back to you about this, if I make progress.

 

[Qbus]

Once again I am going to throw more rocks, I have XXDP on disk (RL) and other then proving things work that are already working I have found it to be almost useless, some of the trap test and thing may localize you to a general section but beyond confirming that a card has failed I have little use for it beyond that. At least that’s been my experience, but that’s me and as my wife will tell you I am not exactly the sharpest tool in the shed.
The last six months or so have been working with Data General Nova platforms but have done a couple Q and Unibus systems and have a simple routine for bring them up and on line. First: Get the local interface working, regardless of it is ODT, local keypad or switches and lights. Once you have that then you can write to memory, read from memory and push and pull from I/O devices. From what I have read sounds like you got that nailed. Second: Working in assembly run some simple loops, I love increment a registers by one, send the results to the printer and then jump back. Third: drive interface and OS, if a system will load and run an OS there is not much else it won’t do. I have found problems with CPU cards that will allow them to run simple loops and the like but not allow them to boot RT-11 but will still work just enough to load the XXDP service pack. The diagnostics will point to the obvious like you have a CPU or memory fault but my experience has been old fashion card swapping and a familiarity with addresses and assembly language are way more useful.
This is why I propose getting an OS to load first and not spend any additional time trying to see what software may run and what wont. You have completed steps one and two and now just need to get past step three. Maybe the thing would be to get your drive, pack and controller and confirm they work in another system first and then see why they won’t work in the 11/40? That’s what I would do myself. I like the approach of testing every system like I/O, drives and memory in a known working system first and then knowing they are functioning and after that it just brings it down to card placement, backplane configuration or CPU issues and from what I recall you have two of those systems so you got spares along with your other working Unibus system. As much as I hate to say it maybe the thing is to try to push the relevant XXDP test for the 11/40 from the GUI and see if they run? That will at least confirm if there is a CPU card issue.
I was just up in Wilmington this last weekend and although I do try to avoid going above the canal as much as possible it’s not an unknown event. It may be best to bring your drive and card down here and we can run it up on my 11/34

 

[Marty]

Hi All;

Maybe, Bill could do as QBus says as well as Bring down any Memory Boards that He has as well as the Disk Controller to Test them..
And Just before He Leaves, put XXDP and a CPU Test on His core Memory and Show Bill where to look from The core to get XXDP going and have Bill take notes, and that Way He has Eliminated the Disk Controller and Memory as to are they or are they not the Problem..
And Hopefully with XXDP and the CPU test in Core the /40 would be working well enough to execute it and say what it finds..
Of course, You could bring the whole kit and kaboodle and go from there..

That is something I wouldn't mind doing with my /45, but no one lives in this area that I know of who has the capability to be of some help..
And I don't have the means to take it anywhere, so it would need to be someone who lives in the general area to come here..
And I couldn't Impose on anyone for that kind of a favor..

THANK YOU Marty

 

[billdeg]

I am going to work more on this tonight. I am going to run GKAAA0, CKBA, CKBB CQKC. I am going to make a chart of the registers' values and if there are instructions / docs for each test try to report what appears to be the relevant info to diagnose.

So far I seem to be able to run any diagnostic, at least load and run it. I get a result. It will be interesting to see what comes of this phase of testing.

Bill