• Please review our updated Terms and Rules here

PDP8/M M8650 Problem

MauriceH

Experienced Member
Joined
Apr 2, 2014
Messages
397
Location
Dordrecht , Netherlands
Have a M8650-YA card that keeps having problems.
So far I mange to get a bit going.
Program 33 of the Toggle (Echo test 03/04) perfect, no problems, also when a Key is pressed continues there is no failure in the print out.
The AC is showing correctly the typed Char, f.i. A=0101. All tests with all kinds of Key's, char, as well as numbers , Capslock etc. they all print correctly.

The prog 32 (Char Print test) just rubbish as a print out, Also the AC does NOT increment, but shows the same rubbish.

The prog 31 (Print Char put in AC) does some correct, and a pattern of failure is to be seen.It repeats the pattern with the same failure.

Now I am trying to figure out and localise what part of the M8650 should be at failure.
-Think RX and TX buffers are OK
-All at the right side of Buffers (RX and TX) part must be ok due to at ECHO test the sent receive is correct.
-RX-TX Address selection paths are OK, as card reacts on control lines and ECHO prog is working.
-X-TAL is OK (even changed it out)
- RX-Decoder E43 had a failure and has been replaced by a 7442(conversion done)

Seems to be a kind of timing issue, or out of sync.
But why is it running ok with prog 33 Echo-test, when I keep pressing a key, and that keeps printing correctly.

Here what I get With prog 31 Print AC
Char "A"
M8650-Prog-31_charA-002.jpg

This With Char "B"
M8650-Prog-31_charB-002.jpg

This with Char "1"
Prog31_char-1.jpg

This with Char "2"
Prog31_char-2.jpg

This is the Char Print prog 33
Prog32-Char-Print_M8650-fail.jpg
 
Also Digged out my Analyzer PM3585. I never used it properly, so have to learn the machine still, but some basics I know.
What Clock should I use for the timing of the DATA bus DATA04-DATA11,
Or the Clock to be used for MD09-MD11

IMG20211106_PM3585_Ana_M8650.jpg
 
Seems to be a kind of timing issue, or out of sync.
But why is it running ok with prog 33 Echo-test, when I keep pressing a key, and that keeps printing correctly.

As I mentioned in the other thread, that sounds like stop bits to me.

Between each character, the line is in the resting "mark" state.
The start bit is always a "space".
The data bits follow the start bit, LSB first.
The stop bits follow the data bits, and are always "mark".

How many stop bits, then, regulates how long the line will be in "mark" state between characters that are sent "back-to-back". It also provides a mechanism to avoid cumulative shift due to tiny (usually less than a percentage point) variations in baud rate between the sender and receiver.

If you can do the echo test, the sender and receiver are on the same page through all those steps except the last, since the "first" character is echoed correctly. Typical auto-repeat keyboards will not result in back-to-back characters at anything but the very slowest baud rates. So there will be a gap in the mark state for everyone to catch up by returning to the idle state.

If, however, your receiver wants more stop bit time than your sender, subsequent characters sent back-to-back won't get seen correctly. The start bit can get missed, and then the line looks idle until a data bits is sent as a "space", and then a wrong character will be received.

So, one thing to check is whether you are sending 10 bits or 11 bits per character, and whether the receiver is expecting 10, 10.5, or 11. If the reciever is expecting the characters to be 10% longer than what your sending, the characters will jumble.

Vince
 
OK read the BOOK : PDP8/e/m/f Small Computer Handbook. page 6-3,6-4
6042 clear print flag (TCF) , clears the printer flag
6044 load printer buffer and print (TPC), TRANSFERC ac5-11 to the LC8-E printer buffer and at TS1 of next instr asserts receive strobe to case char held in buffer to be printed.
6046 Combines TCF TPC 6042-6044

So in prog 31 Print AC changed code 6046 into both 6042 and 6044, FAIL: I can not put a Char in AC,AC-lights will not light up, and nothing will be printed on screen Terminal.
tested program with working M8655->Perfect. So program is OK.

Next Prog 33, echo test 03/04 same replaced 6046 for 6042-6044, M8655 is working this program, Keybord char "A" prints at Mem Add 0006 -> "A"
The Loop: MEM Add 0001 & 0002 till a key is pressed.
EDIT: At RUN the program the working M6855 will echo 2x the char in return.In SINGLE STEP 1x char in return.
Program 33 rewritten:
0000 6032
0001 6031
0002 5001
0003 6036
0004 6042
0005 6044
0006 6041
0007 5005
0010 5001

Now with the defect M6850 the loop sequence also 0001 & 0002 till a key is pressed.
Program run in "SINGLE STEP"
0001
0002
0001 key 'A' depressed
0003 AC=0101 (Correct for char A)
0004 AC=0101
0005 AC=0101
0006 AC=0101 =>DISPLAY CHAR "I"
0010 AC=0101
0001
0002
0001 Char "B" depressed
0003 AC=0102 (Correct for char B)
0004 AC=0102
0005 AC=0102
0006 AC=0102 =>DISPLAY CHAR "J"
0010
0001
0002
etc:
So char A display I, B=>J, C=>K, D=>L
 
Last edited:
Vince, thanks for the input. I'll see if I can figure out how to count those 10-11 Bits.
For now I changed strap J from J 2-3 (2Bits) to J 1-2 (1 Bit) Baud is still at 110Bd, also changed Terminal VT220 to 1 bit.
If I now Single Step the M6850 with the replaced 6042-6044 I indeed get the correct Char in return. A=A, 1=1
Still original prog 31 print AC in RUN mode, will not print the right char.
 
Think I got it. E20 2nd FF, The Start FF, Never becomes '1' At the red line, Clock UP, Input is alway's '1', Clear is '1'(in active) So output 8 should follow input that is '1'.
IMG20211106-E20-002.jpg
MARK-Control-2a.jpg
 
Looks like you figured it out. Way to go! Seems like it is often a failed 7474.

I noticed that your re-written program is not correct. Here is what you have in PAL

Code:
*0000
START,  KCC             /CLEAR AC & READER FLAG
KEYLP,  KSF             /SKIP ON A KEYPRESS
        JMP KEYLP       /WAIT FOR A KEYPRESS
        KRB             /CLEAR AC, READ CHARACTER, CLEAR FLAG
        TCF             /CLEAR TELEPRINTER FLAG
TTYLP,  TPC             /SEND THE CHARACTER
        TSF             /SKIP IF CHARACTER IS SENT
        JMP TTYLP       /WAIT FOR CHARACTER TO BE SENT
        JMP KEYLP       /GET NEXT CHARACTER
$

The problem is the JMP TTYLP goes to the TPC instruction and it should go to the TSF. Change instruction 0007 to a 5006. The program will work if you single step but not at full speed because it will re-send the character every time the TSF fails to skip. When single stepping the character is sent before the TSF gets executed and it will always skip. This will happen with the M8650 for certain. Not sure about an M8655. It might work because the UART would act as a buffer and ignore all the extra TPC commands.

The above is not the way I would have written the keyboard echo loop. It does not need to be nearly that long Here is my take on it.

Code:
*0200                   /BECAUSE PROGRAMS START AT 200
KEYLP,  KSF             /WAIT FOR A KEYPRESS
        JMP .-1
        KRB             /READ THE KEY
        TLS             /SEND THE KEY
        JMP KEYLP       /GO GET ANOTHER KEY
$

You don't need to wait for the transmitter to finish because the keypresses are the limiting factor anyway so the TSF wait loop is wasted code.

Doug
 
Doug, thanks for explanation. I was trying to see if the BIT setting was the problem, so I thought to split the command.
The New FF did Not solve the problem, And I saw that I already took E20 And E29 out to check separate on a breadboard to check its function.
Typical, we all agree , I Think, That at some point This E20 START should become "1" , Line goes to Clear E29 "LINE".
There is no shortage measured at output E20. I'll go take that E29 out again.
EDIT: Wait a second, If Clear E29 LINE is "0" there can't be any out put from serial. Have to check that analyzer wire I think.

Damn Yes that Blue wire Analyser is broken, changed it from an other Pod. Lesson learned->check your old test equipment.LoL.
But suddenly I have a BUS failure BIT 8 keeps ON. Its the card 8650 not the PC luckily. Next problem.
 
Last edited:
Alright. Either E30 the gate on 6, 7, output on pin 8 or the input of E31 pin 3 or the physical trace between the two chips. Since E31 is the shift register and all bits above the one being picked are correctly received, the problem is during load, not during shift for that one bit which comes from E28.
 
Yeb E30 was the trouble maker, replaced it and Back where I was, Failure Print.

What I don't get is why at prog 32 Print test the AC does not Increment.
It just display random Bits at the AC line.
If it was just a Parallel-serial fail, or a Marker Bit count fail at Terminal level I get it to look at the last TX part.

As for now at the start the AC is already a random bit through Bit 0 - 11 the lights are random.
Practacly all lights are mostly on,and random few are OFF.Non of them are permently ON, All are activated on/off.
Bit 11 is fast on/off,rest I can observe on/off.
Can not find any kind of incrementing sequence in the AC display.

The trick is, when I Single-Step the program it runs perfect,Incrementing AC and putting right sequence char on VT220 terminal.
7001
6046
6041
5002
5000
Is the AC print increment test.

Its a mistery.
Program is stepping address, 0,1,2,4,0,1,2,4,0,...
Ah....test this, and when I disconnect the terminal, at Single-step, I can keep stepping the program,
But if I then RUN the program, just Bit 11 is on, and No AC further of flashing lights.
So In RUN mode, something is happening with Sent/Receive and therefore indeed, something could be at serial Bit count,
Ah that way.
 
Last edited:
If I reverse assemble this test I get:
Code:
*0000
LOOP,   IAC             /INCREMENT
        TLS             /SEND AC TO TELEPRINTER
        TSF             /SKIP IF DONE
        JMP .-1         /WAIT
        JMP LOOP        /GO DO NEXT
        $

I see what you mean about a mystery. The program will always start with AC and Link clear if you start the program from the front panel with Load address, Clear, Continue because the Clear will clear the AC and Link. Clear also disables interrupts and resets all the peripherals to a known state by sending the INITIALIZE_H Omnibus signal.

If I read the description correctly it looks like the AC appears on the DATA lines during every IOT. The selected device can manipulate the AC by placing different patterns on the C0 and C1 lines.
If C0 is low then the AC is cleared as part of the IOT.
If C0 and C1 are low then the AC is loaded from the DATA lines.
If both are high then the AC is ORed with the DATA lines. I believe originally C1 was supposed to control the loading of the AC but based on a note in the Omnibus standard too many cards violated this so they changed the C1 line to a don't care and it always loads the AC from the DATA lines.

By convention, if a card does not drive one of these lines low then the processor treats that IOT as an output and the AC does not change. But since the actual transfer is AC -> DATA and the beginning of the cycle and DATA -> AC at the end if a card pulls the DATA lines low then the new pattern will be ORed with the AC.

With that in mind, I would look at E33 and the signals that drive it. This chip drives C0 and C1. Also look at E2 and E15 which place the received data on the bus. There is one line that is used to drive 8 gates on these two chips which if triggered during the TSF or TLS instructions could cause the AC to be changed.

C2 is used to change the PC during an IOT and if that was being triggered you would have much greater problems.

I would do some more testing to see what is really going on. Is the AC really being changed?

Change the first instruction to CLA which is a 7200 and the last instruction to a 5001 and run the program. If the AC is picking up bits then the problem will be with E2, E15 or the signals that drive it. If the AC remains clear then try changing the first instruction to a CLA CMA which is a 7240. This will set the AC to all 1's. Again change he last instruction to a 5001 which is a JMP to the TLS. If the AC gets cleared you should notice this right away.
 
Run the program
7200
6046
6041
5002
5001
AC-is clear and keeps clear,all zero's

7240
6046
6041
5002
5001
AC is 7777

So going to look at E2-E15

Those results are the expected behaviors. In the first program we start with the AC being zero and it stays zero. In the second program we start with the AC being all 1's and it stays all ones. It does not seem like the AC is being modified. How about we get really paranoid and we go back to the original program only slightly modified to have it check that the AC is not getting changed by the serial port IOT instructions.
Code:
 1       0000 *0000
 2 00000 1020 START,  TAD 20          /GET VALUE TO SEND
 3 00001 6046         TLS             /SEND THE CHAR
 4 00002 6041         TSF             /WAIT FOR TRANSMISSION
 5 00003 5002         JMP .-1
 6 00004 7041         CMA IAC         /TWOS COMPLEMENT OF VALUE AFTER SEND
 7 00005 1020         TAD 20          /COMPARE
 8 00006 7440         SZA             /SKIP IF UNCHANGED
 9 00007 7402         HLT             /HALT IF AC GOT CHANGED
10 00010 2020         ISZ 20          /INCREMENT VALUE TO BE SENT
11 00011 5000         JMP START       /BACK TO THE TOP
12 00012 5000         JMP START       /FOR WHEN THE ISZ SKIPS
13 $
Essentially the same program but it will tell us if the AC is getting changed from what we want it to be. Will halt on an error. AC will have the difference. LOC 0020 will have the value that was sent. You can set LOC 20 to whatever you want the initial pattern to be.

If this runs without halting then we know the AC is not being modified and what you are seeing in the display while the program is running is something else. And it should look the same because 99% of the time is spent in the TSF wait loop with the AC set to the desired value. The 8 or so microseconds per character sent where it isn't the value probably can't be seen in the display.

If this runs, then the assumption that the AC is being changed is false. And I was making this assumption based on what you said about the display not appearing to increment. What baud rate do you have it set to? at 9600 baud you would only see counting in the upper bits of the AC, AC0 through AC5 or maybe AC6. The rest would be changing too fast to see. At 110 baud you would see counting in all but perhaps AC11.
 
I already had replaced E33 too, before.
Any way I probe that E33 and E44. With prog 32 Print AC no action of E44 and E33 C0 and C1, signals keep the same during run Prog 32 AC increment,
With Prog 33 the lines C0 & C1 are activated.
Also I made a 5x STOP argument probe on C0, and indeed after 5x Keypress the Analyzer stops.
Then indeed C0 & C1 are activated as seen in the picture.

Prog 32 no activation of C0&C1
IMG20211110-Prog32_Probe.jpg


Prog 33 Echo 03/04 test
IMG2021111021-E33-probe-002.jpg

Took Clock from Output E34 that is in line of I/O Pause
Test-E33-001.jpg

See E33 fith from left already been changed SN7401N (new old stock)
IMG2021111021-E33-probe-001.jpg
 
E43 N8251 (convert to 7442 but probe is at N8251 pinning)
It is following the truth table
Wave form is at a Terminal Keypress 'A' and C0,C1 are following.

There is a Glitch spike to '0' at output E43-13 =Q0' (
But probing the E47 output Its still '0' due to fact input E47-5 is 1.
E47-4 output is only '1' when both inputs are '0' So the spike has no consequences.
E43-N8251-Table-see_Waveform.jpg
IMG2021111-prog33Echo-Keypress.jpg
IMG20211111-E47-probe.jpg
 
Doug,
Thanks for all the input and effort.
Did run your prog,
Doug Testprog2.jpg - Click image for larger version  Name:	Doug Testprog2.jpg Views:	0 Size:	67.9 KB ID:	1232505

If I RUN the program AC is seen No increment All AC are "random", M8650 at 110 Bd
Than stop and Single step the prog.
Again Lead 0000, clr cont-Single step
2e Run After Power-Off, Load 0000 CLR CONT SS
Then Load CLR CONT-Free RUN - HALT
3e RUN Load 0000 CLR CONT SS

Doug Testprog-result.jpg - Click image for larger version  Name:	Doug Testprog-result.jpg Views:	0 Size:	149.7 KB ID:	1232506
 
I am confused by the table. I am assuming that the program is halting at loc 7 which means the AC is being changed either by the TLS or the TSF or both. The value left in the AC at the halt is the difference between LOC 20 and the changed AC. When it halts you have to take the value in loc 20 and add it to the AC at the time of the HLT. I wanted to keep the program as simple as possible so I didn't have it add the value back in or save the changed value and then do an exclusive or to find out what bits changed. The program increments loc 20 after every character is sent so for the value in the AC to mean something we need to know what is in loc 20. But if it is halting then the AC is being changed. And that still looks like a C0 and C1 issue.

You have said that the AC is random several times. The AC can be random only after a power on before the clear key is pressed. Does the AC clear when you press clear? The program expects that the AC is clear when the TAD at loc 0 is executed. If it isn't, then it will halt every time. The AC will be clear at the JMP START at address 11 and 12 because the skip over the HLT occurs if the AC was zero.

It seems to me like this board must have suffered some trauma. Over voltage or a bad ESD event come to mind because you have found so many sick parts.
 
Back
Top