• Please review our updated Terms and Rules here

PDP 11/45, Part 4

Hi All;

Fritzm, "" Maybe when I get back to it tonight I'll try running off the maintenance RC clock -- if the test passes consistently at a slower clock then I'll know I'm looking for a timing race. ""

I tried to see something on my scope when putting Addresses '777770 - 7777776, but I didn't see anything, though I didn't try it with the Stack Limit program..
I may try and see if my Maintenance card is working and do as You did and slow the clock down.. And see if that Helps..

I remember reading somewhere that in many of these old machines, just swapping out a card or putting a card on an Extender could make the machine Non-workable..

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Something just Broke, I can't with Halt enabled even step through the Addresses..
Still trying to figure out what went !!

I Let it sit not on at all, while packing up a care Package for someone..

It is Dead !!

I just tried it again, still NO good..

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Fritzm, Tomorrow I put it all back together, and get ready to Use my Logic Analyzer, So any tips that You may have would be of a Great Help..
Tomorrow, I will re-read Your postings, maybe they will help me figure out what to do.. As, I am not sure where to Start..


THANK YOU Marty
 
Last edited:
Hi All;

It Looks like I may have it back, it at least counts and Displays addresses..
Once I get the other PC set back up, I will try and Run Don's ZZ program..

I took out all of the Boards.. I erased all of the fingers on the Boards..
I sprayed the MotherBoard with Deoxit, along with the Power connectors..
I replaced all of the 7404's on the SJB Board, with 74S04's..

Waited a day and Plugged Everything back in..

OK, It's running the ZZ Program, 1000 Passes..
It hit 1563 passes and Halted..
Restarted.. Passed 161 passes.. Halted
Restarted.. Two Passes, Replaced Data Paths card..
Restarted.. Passed 2000 Passes..

THANK YOU Marty
 
Last edited:
Hi All;

Bill, Your not a Man of many words, are You.. Thank You..

I had, had the Machine working for Extended Periods of Time, before the Latest Breakdown..
And the Only two Boards that I had Exchanged and traded around, was the DATA PATHS and GRA Boards..
So, Most likely one of those had / has a Heat related problem..
And so far, it looks like it was the DATA PATH Board, which I will Mark as possible having a heat related problem..
So far it's Ran over 6000 Passes, 11111 Passes..

I Loaded it with up/down Addressing Test, six Stars so far.. Bell at '402..
Memory Pattern Test, six Stars, Bell at '702..
Moving Ones and Zeros Test, Can't find a Bell in Listing.. Still Running.. Found Bell at '676.. I ran it for three Stars, since it had already been Running with out stars..
Susceptibility Test, bell at '774.. Passed with six Stars..
Worst noise Test, bell at '1272.. Passed with six Stars..
Core Heat Test, bell at '516.. made one pass, Program takes tooo long..
SXT Program, bell at '2562.. Passed six passes..
SOD Program, bell at '3604.. It halted..

This Machine has Not been turned OFF since I switched out the DATA PATH Board..
I have finished modifying one of the M7856 Serial cards, (while waiting) to be able to attach a 9 pin cable, like I did for the M7800..
I will test the two M7856's that I have later, assuming the Machine Passes all subsequent Tests that it passed before..

I Turned off the machine about an Hour ago..

I turned it back on and I am Loading from One of the M7856 Serial Cards, so one works..
At present the other does not work.. I will need to check it out, later..

SOD Program, bell at '3604.. Passed with six Stars..
XOR Program, bell at '7410.. Passed with six Stars..
MARK Program, bell at '7262.. Passed with six Stars..
RTT Program, bell at '2212.. Passed with six Stars..
Stack Limit, bell at '2272.. Failed, still..
Failed on a Load, so I know now, that it most likely is not the Serial Card..
I traded out the GRA Board, and I will see how long before it quits..


THANK YOU Marty
 
Last edited:
Hi All,

New blog entry up at http://fritzm.github.io/category/pdp-11.html with todays findings on traps diagnostic CKBME0 on my 11/45. The upshot is that RTT to a WAIT on my machine sometimes seems to return to the WAIT, and sometimes seems to return to the subsequent instruction. I am going to go study the BRQ logic for a bit and see if I can determine how this is intended to work and what I might check with the logic probe and/or analyzer. I'll update on the blog and here when I find something new.

--FritzM.
 
Last edited:
Hi All;

Fritzm, "" Here I've transcribed the source of the failing test from the older available diagnostic listing, then re-assembled it at the address matching the more modern binary. This makes it a little easier to follow along while debugging the newer binary: ""

I would like to know MORE about "how" You did this ??

THANK YOU Marty
 
Hi Marty,

I used PDP11GUI. First I disassembled memory around the halt. Then I looked into the old listing "around" the failed address until I found the same sequence of instructions in the source code. Re-typed just that test from the source code, then added the handful of needed symbol definitions, .ASECT and ".=" directives to set the assembly address of the first instruction, and a .END directive at the end. Used PDPGUI to assemble it, then grabbed the output from the listing window.
 
Hi All;

Fritzm, Thank You for Your Information and Timely Response..

On Monday when I am more awake, I will look into that further, and possibly try it.. Doing the same section as You did, until I have it figured out..

THANK YOU Marty
 
Hi All;

I started to Read some of the CPU Maintenance Manual, and It got me wondering, I haven't read enough to prove or to dis-prove my theory..
But, maybe I need Memory Management to work for the Stack Limit Test to Work..

Fritzm, You have a good Memory Management set of Cards and that Test Pases.. At present I can't prove it or not prove it..
And I don't think You can help me unless You have an SJB Card to prove my theory..

Anyway, I think I am going to make an attempt to get my Memory Management Cards Working..
I know that at Least two bits are Stuck on, (8 and 9) And I can follow with my scope the Path from Switch to Led..

THANK YOU Marty
 
Last edited:
Hi All;

Fritzm, That's what I figured, and until I can get my boards fixed I can't prove either way, either..

I did a small amount of scoping and reading last night, it's going to be a bit harder than I would have first thought..
But, I have a handful of Ic's that are good, so that's encouraging.. I did follow a section from switch to led..


THANK YOU Marty
 
Marty,

The listing of the stack limit testing that you sent me doesn't appear to use memory management.

Can you point me at the website for the original listing of the code that you copied and I will compare the two.

To save me reading the millions of previous posts (sorry, I am being a bit lazy...), exactly what was going wrong with the test you are running?

We should be able to narrow it down by placing HALTs at various tests in the sequence to see where it goes wrong.

Just packing up for a business trip this week - so I could do with a little distraction before my colleague picks me up.

Dave
 
Hi All;

Dave, Thank You for Your Input..

"" The listing of the stack limit testing that you sent me doesn't appear to use memory management. ""
That's good to hear..

"" Can you point me at the website for the original listing of the code that you copied and I will compare the two. ""
I don't Remember where I got them from, but, most likely it was BitSavers.. But, I will attach it.. It Won't let me attach a PDF file.. Sorrry..
Look at BitSavers (software listing) under DEC, under PDP 11, then under /45..
I sent it to You by Email..

"" To save me reading the millions of previous posts (sorry, I am being a bit lazy...), exactly what was going wrong with the test you are running? ""
I don't Remember, but, it failed Immediately, Right after it Starts.. I Remember that the code it shows is around 1053ish, now that the whole thing is typed in..

"" We should be able to narrow it down by placing HALTs at various tests in the sequence to see where it goes wrong. ""
I am not sure, but I suspect that the '77777x is not completely working..

"" Just packing up for a business trip this week - so I could do with a little distraction before my colleague picks me up. ""
Take the 11/45 with You..

THANK YOU Marty
 
Last edited:
I tracked it down on good old bitsavers...

First of all - after entering a program and assembling it - check the octal codes for the code produced in the listing and look for any differences. With OCTAL life is easy as your eye is only looking for the numerals 0 through 7 and this makes life much easier...

I have dumped the octal code from the stack-limit.bin file you sent me "od stack-limit.bin" and compared it to the original listing file and the listing file you sent me. I have found the odd error that Marty has entered - however, the assembler is NOT producing the correct operands for the instructions it is assembling!!! Hence the crash...

For an example of a Marty error (shall I call it) check address 001032 MOV @ICNT,@#DISPLAY verses MOV ICNT,@#DISPLAY. A different addressing mode for the source operand.

For an example of an assembler error check address 001010 where the assembler has produced 016706 000502 whereas it should have been 016706 177460 (ish - I can't quite read the printout). The BIN file also contained 016706 000502. The 000502 contains an apostrophe - indicating it is relative to the Program Counter (PC) - but that doesn't get turned into the correct operand by the 'so called' linker. I suspect PC relative operands don't work...

Just off to pick up my son from church...

Back...

Mode 67 is an offset relative to register 7 (the Program Counter = PC).

In the case of what the DEC assembler has produced - it is a negative offset (i.e. lower in memory from where the PC is located) and in the case of the MACRO11 assembler - it is a positive offset (i.e. higher in memory than where the PC is currently located). This will not go down too well with the 11/45 CPU...

I suppose I could find the space in the boot of the car for the 11/45. My colleague takes his electric guitar with him!

I have checked the macro11 assembler with pclink11 as well - and it still produces erroneous code. Although it is getting a bit late in the UK so my judgement could be impaired... I seem to remember Don mentioning about this somewhere back in the thread?

Dave
 
Last edited:
Could someone post the .mac source file for the code under question? I can't seem to replicate the issue under question in macro11.
 
Hi All;

Dave, Thank You for the Help.. I am not surprised that there are not more typing mistakes..

"" First of all - after entering a program and assembling it - check the octal codes for the code produced in the listing and look for any differences. With OCTAL life is easy as your eye is only looking for the numerals 0 through 7 and this makes life much easier... ""
I know that is what I attempted to do when typing in the program, it looks like I didn't do so good of a job..
I know I found a boatload of mistakes when I did the other file by comparing the output produced..
I also remember that, that particular line, I had previously changed to make the output produce an output of other sources and when I changed it back, I must have typed it in Wrong..

Don, I'LL see if I can send it to You.. I'LL need to locate Your Email, I think You sent it to me before..
I can then send You the whole .MAC file.. Mistakes and ALL..
OK, Don they have been Sent..
Dave, Tomorrow, I will fix my .MAC source file.. I await more finds from You..

THANK YOU Marty
 
Last edited:
Ok, got the file, and assembled it. dumpobj produces errors on creating the .bin. When this happens all bets are off.

From what I can tell dumpobj does NOT handle mode7 / register 7 (ie, pc indirect references like @foo) correctly, and sets the warning flag.

These modes are used in that test. macro11 is generating a correct .obj file (with internal displaced RLD entries) but dumpobj does not process those correctly.

I'll take a look at fixing dumpobj.c, I really don't think it will be that hard. But for now you are stuck. ==> I'm not so convinced this is possible after studying the code some more ...

I don't know how PDP11GUI generates .hex files from .obj files, maybe he wrote his own linker / translator.

For my own purposes my obj2hex.pl script does process all the valid RLD entries, so I can produce a correct .bin from your .mac file.

Don
 
Last edited:
Hi All;

Don, Thank You for looking into it..

"" For my own purposes my obj2hex.pl script does process all the valid RLD entries, so I can produce a correct .bin from your .mac file. ""

Don, could You send me this file, so I don't have to send my MAC file changes to You to have it .binned.. Until, You have the chance to fix the Dumpobj file problem.. THANK YOU !!!

THANK YOU Marty
 
Ok, here is my obj2hex.pl PDP-11 'linker/translator' for object files. Originally written to generate M9312 BOOT/CONSOLE PROM image from .obj, extended to add additional functionality as a more proper linker. Does not (yet) handle multiple .obj files, so it does not do any global relocation. Handles multiple .psect in a single file however, with all the complex relocation types. It is still a work in progress, but I use it for developing my complex PDP11 diagnostics I've written.

Requires perl be installed on your system, does not require any special CPAN modules. May need to into CYGWIN setup to install perl if not present (not likely).

Don

Example:

Code: 
make --always
macro11 reg-11-45a.mac -d md -d me -e bex -l reg-11-45a.lst -o reg-11-45a.obj
dumpobj reg-11-45a.obj reg-11-45a.bin > reg-11-45a.dmp
obj2hex.pl --debug --verbose --binary --obj reg-11-45a.obj --out reg-11-45a.bic --log reg-11-45a.log

macro11 stack-limit.mac -d md -d me -e bex -l stack-limit.lst -o stack-limit.obj
dumpobj stack-limit.obj stack-limit.bin > stack-limit.dmp
[B]Probable errors in binary file[/B]
obj2hex.pl --debug --verbose --binary --obj stack-limit.obj --out stack-limit.bic --log stack-limit.log

obj2hex.pl is available here: https://drive.google.com/open?id=0B7Csc-dWWfTYclk4a2FKMmV2bDA ***DEPRECATED*** see end of post for github info

marty directory with assembled files and makefile here: https://drive.google.com/open?id=0B7Csc-dWWfTYcFhDN2VWWkIzY3c

Maybe I'll go and submit this up to my area on github (along with tu58em which is already there) ...

Don

OK, it's now official on github: https://github.com/AK6DN/obj2hex
 
Last edited:
Hi All;

Don, Thank You for the Files.. Yes, I will have to Run it under Cygwin..
I copied the Stack-Limit.bin file and I will try it out on my real PDP 11/45 tomorrow.. Thank You !!

THANK YOU Marty
 
You must log in or register to reply here.
Back
Top